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.