However, Anduril doesn’t work on a twisty. It requires an e-switch.
A twisty seems to work best with only a few types of interface:
Single mode on/off.
Two contacts, or a collapsing contact: gives a low mode and high mode, depending on how tight the head is.
Direct drive with QTC to adjust brightness. Squishy material with variable resistance depending on pressure. Tighten head for more lumens, loosen for less. The QTC material itself tends to wear out over time though, and LVP isn’t feasible.
A small number of modes selected by turning the light off-then-on quickly, like 2 or 3 (or maybe 4)… and maybe a way to turn memory on/off.
The KC1 uses the first UI type, which is good as long as the single mode is the one you want. People disagree about which mode that should be though… so it would be cool to have an option to select that at time of purchase. Like, I would ideally want 10 lm on NiMH, which I’m guessing could run for about 10 to 15 hours per charge. But for some people, the best mode is 500 lm, which can only run for a few moments at a time but looks crazy impressive from such a small light.
Of the UIs I listed, 3 of the 4 can be implemented without a MCU. Only the 4th UI needs a processor to control its behavior.
The Thrunite Ti3 / TiS has 3 modes and a (hidden) Strobe. I don’t know if they are using a real MCU or only an LED driver chip (SOT-23-6 or something, PAM2801 for example) like in cheaper lights where the modes are fixed and no re-programming of the functions is possible.
So it is possible to build such a light. And I think it would be also possible to build a very compact 10440 light with an e-Switch on the tail. However, it requires effort and some time.
But I don’t think that a revised KC1 will be released in the next months/years so I think I will use the TiS until it dies.
Neither I3S or E3A support it officially but it’s still being used, you can see even Wolfgirl’s review a few posts above using 10440 in the Skilhunt E3A
After 3 channel light Hank is come back wit a twist because is too much simple?
I am joking… but I am happy because for you is not code work for another flashlight
Did you ever look into the DQG Hobi lights at all? My Hobi+ Ti (10180, or 10440 with extension tubes) has three modes - an actual driver - and built in usb charging behind the threads. All while being the smallest of several 10180 lights I own.
Interesting, first time I hear about DQG and the Hobi. Some googling seems to indicate they were all the rage a few years ago, and available from Banggood, but are basically unobtainable now?
Eneloop in it, 90% charge retention after 10 years. 100lm for ~40 minutes. Great emergency light that can be stored anywhere and still has reasonable performance.
Or, put a 10440 in it and it’s probably the most wow factor per gram for showing off.
Yeah. There have been a few lights where it has been possible unofficially (e.g. some of the AA Zebralights), but I removed that mention because I didn’t want someone else to try it and be unlucky.
I think it’s more like 70% after 10 years… 90% is after just one year: Eneloop - Wikipedia
For emergency once-every-many-years purposes, it would be best IMO to use a Lithium primary: 100% or so after up to 25 years, much more capacity and larger temperature range to boot; I specially like its cold-temp performance: https://data.energizer.com/pdfs/l92.pdf
Thanks for the report, TK! These DDs do sound awesome!
Like, instead of a regulated driver needing a voltage regulator for input, a voltage divider for battery measurement, and a lowpass filter for output, those can all be removed.
Which should lead to simpler, more reliable flashlight electronics with no loss of function (on the contrary), and lower manufacturing costs to boot. Seems like a win cubed!
PS: any news re: the DD’s adoption by any manufacturers that you aren’t under NDA to and can tell us about?
I am a bit curious about this. From an outsider’s perspective, it looks like the early days of Anduril were somewhat dictated by the selection of a super-flea bitten MCU (ATTiny85) which required things like PWM / low pass filters to get the job done. Even if these external components added to the cost of the BOM, the total BOM cost might have been cheaper than just going with a more expensive and nicer MCU with D/A. If this is the case, it seemed like the early hardware companies effectively pushed / outsourced the complexity to the software side (which they got for free?), letting the hardware companies reduce their BOM and software labor costs (assembly labor is cheap).
anduril still uses both of those on the t1616 too. PWM is how brightness is controlled on every driver and does not necessarily mean there is any visible in the LED output - the driver circuit is just controlled by a PWM signal sent from the MCU running anduril. A low pass filter is used so the battery voltage doesn’t oscillate.
A lot of early driver designs were done by hobbyists, and it was a chip that made sense at the time with the capabilities that people had. For example, the t85 is much easier to hand-assemble boards with than the t1634 or t1616. Because people were building their own boards for custom lights first, then the manufacturers arrived later, as I understand it, and there was at that time a lot of bidirectional collaboration, but also lower technical understanding on both sides. A lot of the current tech talent in the community has grown specifically out of ToyKeeper’s work, and before that, firmware was of much more varying and generally lower quality. It wasn’t a case of a manufacturer cheaping out that it was ever used, but it IMO definitely is today (e.g. a certain well known manufacturer… ).
Hank’s drivers haven’t been updated since the t1634 was the current MCU to use (the 1616 has been a generation after the 1634, but at this point development from scratch of drivers would be best done with avr32dd), so TK working to get them updated is exactly whjat we want, and not a negative on Hank or anyone else who makes lights and actually wants to work with people here.
The development community is happy to create anduril. that’s the point. We want it to be used, we just want a set of standards to be set out for manufacturers to follow to get software support, that firmware for their lights can be maintained and updated. I’ve spent my own money on different model lights just because I specifically wanted to have one for development, to fix a bug or get an old build updated. I’m happy to do that if it means anduril adoption by manufacturers.
the Attiny85 actually costs more than the T1616 and AVR32DD20, maybe because it’s made on a much older process ? (it’s very old) I don’t know.
The point is mostly about saving room, I’ve made very small regulated drivers thanks to the T1616/AVRDD DAC, on top of their small size :
no LDO because no constant voltage needed to power the MCU when using the DAC.
no low pass filter to filter the PWM signal on regulated drivers.
not external batt sensing voltage divider, because no LDO, (except on dual fuel driver where VCC isn’t connected to BATT+, this is where the second VCC of AVRDD is useful for batt sensing without an external voltage divider)
That’s great. I’m more interested in an open driver than open firmware, because the former allows the latter more easily and opens the door to other options. Hopefully there will be documentation / schematics
There is a long and detailed history involved… but it doesn’t resemble your description. The early MCU type had absolutely nothing to do with hardware companies or cost-cutting.
It was chosen because back in the foggy days of ~15 years ago someone in the community picked attiny13a as the control chip to write firmware for in a torch driver, and they shared source code. This set things in motion in a “railroads are a certain width because of chariots in ancient Rome” sort of way. After a flurry of firmwares for attiny13a, the community upgraded to attiny25, and then it was just a short hop up to attiny85. It was good enough, and hobbyists could still easily hand-solder a driver with it thanks to its SOIC8 format.
When Anduril was created, the attiny1616 didn’t even exist. So when the t85 became too limiting, the best upgrade available at the time was attiny1634… and Hank was the first to adopt the new architecture. It’s getting near its limits though, so I’m working on upgrading to the latest and greatest – AVR DD.
… and in the process, I’ve been rewriting quite a lot of FSM. I’ve been slowly untangling the spaghetti and turning it into something at least slightly less messy. People won’t notice the changes at an end-user level, but paying off technical debt like this is essential for moving forward.
Bit off-topic, but all the railroads aren’t the same. You can’t go from Finland to Sweden with train, because Finland has wider rails. Just one example. End of off-topic.
The point is not an easily-disproven myth about ancient origins of a ‘universal’ rail gauge as it is the right of way for horse-drawn wagons from millennia ago - and the modern railroad that subsumed them - are substantially similar.
