Disable Factory Reset (13H), when in Simple mode
discussion:
On some anduril 2 lights, for example the Wurkkos TS10, Sofirn SC21 Pro, and Sofirn SP10 Pro, the factory default UI ships in Simple mode with a ceiling of 150/150.
When Im planning to lend an Anduril 2 light to a child, or an untrained adult, I like to preset a lower ceiling in Simple mode.
I do not want them to be able to do a Factory Reset (13H), in Simple Mode, as that will reenable the ceiling of 150/150
Seconded. Both factory reset and version check should not be available in simple mode.
While version check doesn’t do anything bad it might still be very confusing to someone if accidentally activated.
I have received help from quahog who produced some new hex files for me that accomplish two things
change the Anduril ramping style to Nitecore D10 style
for TS10 and SP10 Pro and for SC21 Pro
remove the 13H factory reset from simple mode… these files are not in a public host, but if you give me your email by PM, I can share them.
I also have hex files that combine both #1 and #2 (D10 ramping, plus no 13H Factory Reset in Simple mode)… not in a public host, but if you give me your email by PM, I can share them.
I don’t have a strong opinion either way but I’m wondering how someone could accidentally press the button 13 times and hold on the last press. Surely the chances of this happening are quite low
Yes, absolutely. But given enough people with hands to try it’s going to happen eventually. 
Suggested Option
Lockout should Survive a battery disconnect.
discussion
Presently, if my SC21 Pro with Anduril2 is in lockout, it will become unlocked if I unscrew the body by half a turn, and then retighten.
This is not as child safe as I would like, because if I put a locked light where a child can reach it, they would be able to unlock simply by unscrewing and retightening the body tube.
If they are old/smart enough to unscrew/retighten they can probably click 3 or 4 times, too.
I think the proper way to deal with this is to not have high-powered lights where a child can get to them unsupervised.
Totally agree. That does not mean the additional safety feature Im suggesting is a bad idea.
I was recently visiting grandchildren. I have taught the 2 year old and 5 year old how to change the battery in a flashlight. They have no problem unscrewing and retightening the body tube. But I do not let them use flashlights unsupervised. Their mom does not want the 2 year old to swallow a battery.
I have not taught them how to do 4C yet. The light is in Simple mode with a 20 lumen ceiling, and Turbo is disabled. They are learning not to shine the light in their, or other peoples eyes.
I dont leave my lights unattended, but Im interested in features that improve the childproofing of my Anduril lights. imo there is no good reason why a battery change should unlock a locked light.
My Sofirn HS10 can also be locked w 4C. It stays Locked, even if I remove and replace the battery. I would like my Anduril lights to have the same ability.
I understand your reasoning. On the other hand unscrew/retighten is sort of a soft reset (and a hard reset when holding the button) so … not sure about that one.
If there is any way you can get a build environment working (it works in Windows, OSX, and Linux), it sounds like you would benefit a lot from it.
Specifically, you could either disable factory reset entirely, or set the defaults to your liking so a reset wouldn’t matter. Anything less is unlikely to be effective.
The 13H factory reset could be hidden in simple mode, but the “loosen, hold, tighten” reset can’t. It happens before loading eeprom, because it wouldn’t work otherwise. Part of why it exists is to recover from corrupted eeprom, which means it can’t change its behavior based on any saved settings. So getting rid of that means removing it entirely. It’s either there or it’s not, and simple vs advanced mode is irrelevant.
Not sure hiding 13H would really help though. If the user can do 13H to reset the light, they can probably also do 10H to go to advanced mode… and they’ll probably do that first.
The cleanest solution is probably to set the defaults so that you don’t have to configure anything via the UI, and a reset would only take you back to your preferred defaults.
I wish I could.
If you can suggest a Tutorial, I will do my best to follow it.
My iMac runs IOS 10.12.6 and cannot be updated further.
So, whats the difference in these two ramp styles?
Just curious. I really enjoy Anduril(2), but have generally not been a Nitecore follower, so I really have no idea.
Oweban made a guide for OSX:
It looks like his site is down at the moment though, so I put his OSX guide onto my site instead:
You probably don’t need to bother with the avrdude portions, since you already have a working solution for that. Getting avrdude set up can be complicated for tiny1616-based lights like you’re using, so I’d suggest sticking with what you’re already doing.
Also, instead of running make to build all the configs at once, I’d suggest building one at a time, for whatever light you’re modifying at the time. For that, try something like ./build-all.sh sp10 to build just the ones with “sp10” in the name.
It may also be useful to grab a different code branch, depending on what you’re doing. Like, I don’t have Wurkkos models merged in yet, so gchart’s branch would be a better choice there. But I should have those ready soon-ish. I’ve been running around like crazy trying to catch up on everything.
Anduril ramps up on 1H, down on 2H. It can also ramp down on 1H, but only if you started at the top of the ramp (so the only direction it could go is down), or if the user was “turning around”. In other words, if you just ramped up, then release the button and press it again in less than a second, then it’ll ramp down.
The D1 turns around every time, no matter how much time passed. Each hold goes in the opposite direction of the one before. So it can go in unexpected directions sometimes, and requires ramping a little then turning around again if the ramp direction isn’t currently pointed where you want it.
Anduril can use D1 style ramping if the user sets AUTO_REVERSE_TIME to a value higher than the timer can count. It’s a trivial 1-line change in the source code.
Or… the solution I’d recommend is setting the auto reverse time to, um, maybe a few minutes? That way it would reset to a predictable direction if it has been long enough for the user to forget which way they last ramped.
The D10 ramp style, lets me reduce brightess with a single press. Without having to rush to do it within a fraction of a second.
When I turn on the light, I have the habit of using 1H which starts ramping up from off. I usually end up making the light slightly brighter than necessary, iow, I tend to overshoot. I like to back off the brightness, to save batteries, or if I move closer to the target. 1H is a predictable way to go down, after going Up.
with Anduril 2 style, I find it aggravating that if I dont ramp down fast enough, the light ramps UP when I want Down, from a single press. There is a timer of only a fraction of a second, that allows 1H to turn the brightness down, instead of Up… I feel that timer is too short, and I dont like feeling rushed. I want consistency, after Up, I want Down, without having to use 2H (although that still works too).
thanks for the pointer…
avrdude does not run on my iMac.
That is where I got stuck when I last tried to follow that tutorial.
Will give it another go and skip avrdude… thanks
Try these. Easy change. Based on gchart’s fork (TS10 etc. support, extended simple UI (aux config, strobes, and ramp shape switch in simple mode)), tactical mode merged in (advanced UI), no other changes included. If you’d prefer a build without extended simple UI, can do that too as right now it’s set per-build-target. Tested on my TS10 only.
Edit: Fixed, actually working now…
…I should do some more work on my project to automate custom builds, but life has just been a complete dumpster fire the last few weeks without much sign of slowing down any time soon…
good morning
I started the tutorial, which says:
“This guide has been tested on a fresh install of macOS 10.15.5”
fwiw, I have older IOS 10.12.6, I cannot use 10.15.5
I opened Terminal,
step 1, pasted in the code:
xcode-select --install
terminal replied:
xcode-select: error: command line tools are already installed, use “Software Update” to install updates
step 2. I paste in this commad
/usr/bin/ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)”
I get this response:
curl: (22) The requested URL returned error: 404 Not Found
-e:1:in <main>': undefined local variable or method “”’ for main:Object (NameError)
What should I do next?
It’s install.sh, not just install for the filename.
do you mean for step 1 or step 2?
thanks for trying to help
pretend I have no idea what Im doing and need to be spoonfed exact steps to follow…
Step 2. Use the command from https://brew.sh/ (i.e. /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)") - looks like at some point they renamed the installer from install to install.sh (the latter is better practice) and their site to reference HEAD which will always be the latest main version, while master is a specific branch (with a deprecated name - most tools now default to main instead).