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

FWIW, Neal has asked to have a working sample made and sent to me for testing.

The firmware used should be this one: http://toykeeper.net/torches/fsm/anduril.2018-12-02.FW3A.hex

Recommended fuse values are:

  • Low: 0xE2
  • High: 0xDE
  • Extended: 0xFF

So, BOD is enabled. Without BOD, it’s very difficult to exit momentary mode because the standby drain is too low. It took several minutes to drain far enough to cause the driver to reboot, and with BOD it’s only a few seconds. This should also help avoid other theoretical issues with low voltage.

Factory reset isn’t included, because it’d cause too much delay making sure there are no bugs. I did a quick proof of concept but there were too many issues to move ahead with the change right before production. So I went back to the 12-02 version which, despite the date indicated, has been under test for about three weeks on various lights. It’s virtually identical to the 11-11 version.

Anyway, it seems things are finally moving quickly.

Does BOD mean brown out detection?
the ability to stay on through super short power cycle?

If so I think this would be a good thing.

Is it a good thing?

Yeah the Emisar is watt I was comparing it to.

However there IS a nice subtle design aspect of the FW3A body I do like A LOT which stands out. The sleekly well-crafted ‘combat grip’ ridge right above the tail cap. Extremely useful and a feature I wish many of my rear switched single-cell flashes had incorporated.

Elegant simplicity.

I may buy this just for this brilliant point alone and the way it was executed.

Kudos to the brain that insisted it being there.

:+1: :beer:

PS. I wanna clarify that this finger grip ridge isn’t uncommon per se. Just that it appears the FW3A’s is actually large enough for even glove wearers butt yet isn’t too large as to be ugly and out of proportion to the rest of the outer design. Plus it looks well smooth machined and thus comfortable. Sharp ridges and fingers pressing down don’t work for me. :sunglasses:

Thank goodness!! … :+1: :+1: :+1:

Yes.

It is like LVP, but built deep into the attiny85’s innards. Basically, if voltage drops below 1.8V at any time, even for a few microseconds, it’ll stop code execution completely. The main purpose of this is to make sure the MCU won’t attempt to do anything when it’s out of its supported voltage range, because its behavior is unpredictable when voltage is too low. This helps prevent random eeprom corruption and things like that.

The benefits outlined in the attiny manual don’t seem to matter for flashlight purposes, but it doesn’t hurt. I’m using BOD for its side effect — increasing standby power. Because it makes no difference to battery life but it makes a lot of difference when attempting to exit momentary mode. Without BOD, it could sort of get stuck in momentary mode because there was no fast way to force residual power to drain.

Without BOD, standby power was so low I had to use a high-end 6-digit Fluke meter to measure it. So, basically zero. Or ~0.0001 mA, if I recall correctly. This is impressive, but too low for this purpose. So with BOD, standby power is about 0.02 mA. Low enough to be negligible for battery life, but high enough to make the light shut down only a second or two after power is removed.

Put me down for one!

Please add me to the list for one!

Put me down for one please!!

I would be interested in for sure. Thanks!

@Toykeeper
I redid the Andúril UI graphic a bit and sent it to the BLf adress on Toykeeper dot net
Any comments if good or useless?

Hi there, cool looking project!

Put me in for one.

2 more please!

Late to the party but i’ll have 2 (one of each LED config).
Thanks!

interested from one LH351D

Can the rest of us see it?

Agreed. As for the factory reset thing, knowing a little bit about some issues, you’d either have to have a complete duplicate set of incorruptible memory to re-programme the thing, and worry about bootloaders (also corruptible), or checksum it on startup and clear out anything looking wrong and start again if possible, or just declare it dead, return to manufacturer. Difficult to see how to do any of these hypothetical things.

Unless the worry is just about getting stuck in a loop due to a bug, configured into non-volatile memory with no way out. Which is quite another matter.

Or just trying to start again quickly with what’s still there, in a default configuration. Which makes sense.

Turning on BOD is the right thing to do at this point, despite resistance from some other people. It has been a controversial issue in the past, but I think the benefits are more accepted nowadays.

Yes, it should make things easier for printing in black and white.

I need to do some updates too, but I’ve been procrastinating about it because there’s not much room left to add anything. It could use some info about how to control aux LEDs, for lights which have those, but I’m not looking forward to rearranging things to make it fit.

I’m so looking forwards to this. Am I on the list already? If not, I’d love to buy at least one with the LH351D LEDs.

Nice to see this project coming together!

When do you think it will go into production TK? 3 months? 6 months?

Is there any idea of how long after the first run the LH351D run will happen?