TL;DR: I’m rambling and ranting about optic-nerve stuff from 2017. Feel free to ignore.
—
Although I hadn’t heard of it when I made the optic nerve thing, I quickly discovered the Oveready BOSS and other Lux-RC lights because people brought those up when I told them about what I made. So I looked into those.
What I found was:
The BOSS appears to use about 16 bytes of config data.
It takes about 20 seconds to transmit this data, giving a transfer rate of ~0.8 B/s or 2.8 KiB / hour. This is very similar to what I found in my tests. Plus, it takes about 20 seconds to set things up and get the light into programming mode beforehand.
The UI allows up to 2 mode groups, each with up to 4 modes.
The mode group is chosen at boot time, by battery voltage. One group for the single-cell configuration, and one group for a 2-cell configuration. So it is not a usable method for working around the 4-mode limit.
With only 4 modes, an evenly-spaced distribution would be 0.2 lm, 153 lm, 1036 lm, and 3300 lm. I find these to be way too far apart.
Blinkies include SOS, beacon, and strobe… but to get any of these, the user must sacrifice slots from the 4 available in the mode group. There are no other blinkies (like battcheck) and no hidden-blinky function.
There is also a dim red mode which activates any time the light sensor is overloaded, so the user can flash turbo against their palm to get to a dim red mode. This is not possible when using the LED itself as a sensor though, so the FW3A wouldn’t be able to do it. Lux-RC/BOSS uses a separate light sensor instead, for the sole purpose of adding this feature.
The optical sensor is the only way to configure the light.
An animated GIF can be used instead of the app, if one takes the time to encode their preferred settings into a GIF.
To send an entire attiny85 ROM of 8192 bytes, it would take about 2.5 to 3 hours. Given a suitable bootloader, like maybe 512 bytes at the beginning which is only used to reflash the rest, this could be reasonably safe but it would be painfully slow and error-prone. In the interest of reducing errors, it could send each byte twice and then take about 5 hours. But it would be able to completely reprogram the light with no hardware aside from the flashlight itself and a web browser. Just make sure the flashlight battery is full, and make sure the display device is plugged in, has all screensavers disabled, and won’t be disturbed.
I found it particularly odd that it only allows up to 4 modes… especially with such a wide output range. At that point, it hardly even seems worthwhile to make it programmable because none of the possible configurations are anywhere near what I’d want. At least allow 8, or even better, 16. Some people like as many as 20 different stepped ramp levels on their D4S. And I’ve used 31 distinct levels on occasion for testing purposes. Some of my clicky lights have close to 20 different modes, including all the blinkies. So 4 just seems unnecessarily restrictive.
And choosing the mode groups based on the number of batteries was really odd too. It would take a full minute and a habit of carrying extra batteries and maybe an extra tube in order to change groups. And getting to the red moon involves a trip through turbo, unless it’s configured as one of the main 4 modes. So then the config could, I guess, be “red, 10 lm, 600 lm, 3300 lm”.
Anyway, long story short… I would do a lot of things differently. So, um, I did do a lot of things differently. And I found I didn’t really need an optical sensor and a phone app in order to configure things, so I didn’t use it. On the FW3A, and on other Anduril lights, I hope people like the solutions I came up with instead.
This is very true. It’s especially cool how people can save a GIF or a video on their phone in order to reconfigure the light. It’s like having bookmarks for favorite configurations.
OTOH, the H17F is a good example of how not to design a configuration interface. It’s better than HiveLD, but that’s not saying much.
Instead of requiring detailed configuration and a lengthy programming manual, it’s often preferable to design away the need for most of those options… and then, for the few who really want to get into detail, open the floodgates all the way by making the source code open and relatively easy to edit and flash. Cover the majority’s needs with a few simple options, and give full unrestricted freedom to people who want it. Allow choice, to whatever level of detail is desired… but don’t inflict choice on those who don’t want it.
At least, that’s what I try to do. I don’t always succeed though.
I had forgotten about that particular Olight. They accidentally made a model once which would trigger the switch sensor when the LED was aimed at something bright. So taking the light out during the daytime would cause it to turn on.
If I recall correctly, they didn’t make that mistake twice.
The FW3A doesn’t really have physical lock-out. It needs to be unscrewed pretty far to break electrical contact. However, switch contact is only there when it’s fully tightened.
Anduril has a compile-time option to start at the memorized level when power is connected, for use on lights with a side e-switch and a tail clicky switch. This could also be used on something like an Emisar D4 though, by loosening the tailcap.
That’s interesting. My D4 breaks connection with the head also. I have been looking for an e switch light that doesn’t need lock out. Something safe for your pocket. This would at least make it a twisty. I don’t like to twisty and then click. For those short few second jobs.
I do actually like the H17F. It may be a pain to work with, but I can at least get it set up in a way that I like and leave it there. I pretty much won’t buy a multimode light unless I can set each mode, as I like my modes more biased to the lower end than factory defaults usually go.
On the other hand, I agree that the end game in UI development is not needing to program individual modes. Anduril does a very good job of “just working” for almost everyone right out of the box. Control rings like HDS Rotary or V11R are also excellent options.
However, the tail button helps a lot for avoiding accidental activation. And the momentary function of lockout mode is designed specifically for “those short few second jobs”.
Looks good! I finally got round to playing with Anduril last night and figured most of it out from looking at the diagram and reading anduril.txt. I got stuck in muggle mode for a while because I thought I was in momentary mode but that’s definitely user error :person_facepalming: . The only things I would’ve added are brief explanations and default/min/max values, which you’ve done! :+1:
Thank you! Do you mind if I translate it into German? I'm not sure if joechina is already up to creating something comparable (printable pdf in a nice layout).