FW3A, a TLF/BLF EDC flashlight - SST-20 available, coupon codes public

Yes, that is what it would be limited to. But making a cross-platform app which runs on everyone’s devices is no easy task. So I’d probably design it as a web page with most of the features implemented via javascript. And then make a different version of the page for each version of each supported model of flashlight. Abstract out the options so each version and each light can be loaded in from a bunch of definition files. The app would most likely involve significantly more code than the actual firmware it’s meant to configure.

But doing it via a phone app isn’t really much faster or easier than clicking the button a few times to configure it. And if the flashlight needs a companion app in order to configure it, that’s mostly a sign of a bad UI design.

It could be pretty useful as a means of reflashing the firmware or for makers who want an easy way to calibrate things before shipping an item to a customer. Sending an entire ROM is slow though. With no meaningful control over the device being used to transmit data, it would be unsafe to assume a high frame rate. In a browser, for example, even 15 fps may be pushing it. And although the sensor is pretty fast, the sender (screen) is generally pretty slow and possibly even inconsistent because it’s common to see timing aberrations when other parts of the system are busy. Like, if the OS decides to do a routine maintenance task in the middle of transmission, the browser is likely to lose some time slices here and there. So the data transmission timing windows need to be pretty large. And it’ll need a way to detect corrupt or failed data transfers. But when errors happen, the light has no way to send data back so it can’t request corrections. It may thus be necessary to send each byte two or three times to be sure.

Basically, with all the complications added up, it’s an awful lot of effort for very little benefit, and would only be usable for small amounts of data. Maybe a few dozen bytes. And it would likely mean removing other firmware features to make room.

Actually an LED gives of a bit of current when you shine on it.

Try this, if you can:
Shine a laser on one of 2 LEDs connected in parallel.
The other one will light up. (yes, very dim of course).

I discovered this when my cheapo blue / purple laser still worked.
I had a bunch of 5730 LEDs on a LED board, in parallel.
I was playing “excite the phosphor with a laser” :stuck_out_tongue: and then i noticed all the other LEDs lit up (yes, dimly of course).

It would be cool if it were possible via the USB charging port, if a light has one.

My BOSS 70 is my second most used light and I would very much disagree that the optical programming is not practical. It makes the initial programming much easier than, for example, an H17F and I don’t need a cheat sheet to remember various combinations of clicks. I can also keep a few other programs downloaded as videos on my phone if in case I want to change the mode groups for single mode, CR123 friendly, etc.

I don’t really see it being useful on anduril as there isn’t much end user tweaking to be done, but for programmable mode groups I find it to be a very nice feature.

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.

Downloading data from a monitor is not a new tech. I had one of theses watch : Timex Datalink - Wikipedia


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 have a Olight that if I shine about 1000 Lumens into the lens of the light it will make it come on in the mid mode. S1A Cu.

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. :stuck_out_tongue:

Hey TK. I have a question. Not sure if I should ask it here or in the E-switch thread but here it goes.

Can this light be locked out by twisting the head?

And is there a dual switch version of Anduril that will allow it come on in mode memory??

Basically be able to function as a single speed twisty?

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.

Have you had the fw3a come on in your pocket?

Thank you.

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.

Something interesting about Anduril:

No… but I don’t have pockets.

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”.

On another note, I finally wrote a user manual for Anduril. This is only a first draft, but I hope it makes sense.

It’s a bit long, so I’m not sure if it will fit well onto paper. There’s a lot to cover though, so even this version is still pretty terse.

add me - one at LH351D


Toykeeper, you have mail :slight_smile:

Edit: You think it is long? Then don’t open the PDF