I know this is kind of late, but could you consider adding the ability to change the speed that the AUX LEDs change color? I would also love if there was also a medium brightness for the AUX LEDS instead of just low and high. Thanks!
I donāt think this is a good idea. It would work for using momentary mode as a tactical UI or just an ultra-simple flashlight UI, but for uses like light painting or signaling you need to be able to click rapidly without accidentally changing modes.
I would use this, along with a timer if included.
Itās 10C/10H now BTW.
Why?
I donāt think this is good for rapid-clicking uses of momentary mode either. Definitely put it behind a compile-time option.
OK, so no two separate top of ramp and turbo if set that way. Thatās a shame because having both is nice. I would like a simple mode to do everything minus the fun stuff like candle and lightening, also minus configuration. Just so a beginner canāt get lost in something he canāt change without reading the manual. I guess having a reset feature eliminates that threat.
Itās really pretty hard to get lost in something you canāt change in the Anduril 2 advanced UI, much more so than Anduril. Every configuration is 7H or 10H, which is pretty tough to do accidentally. The blinky and mood modes always turned off with a single click. Probably the easiest thing to get stuck in is momentary mode.
For those who have the Lume1-FW3X driver, here is an update for anyone interested in Anduril2. I worked on some fixes and adjustments and I've had it running my my copper FW3C for a while now, and so far I think it's running mostly bug free... but I'm sure I may have missed out some! If you're interested, please feel free to try it out here. I could definitely use some help with testing all the use cases.
.hex files for flashing: https://github.com/loneoceans/lume1-fw3x/tree/main/anduril2
If you're flashing a new 1634, set fuses as low = 0xE2 and high = 0xDE
If your PCB is dated 01/20 (Rev B), you have to swap MISO and MOSI if you're programming using Emisar/Noctigon's pogoprogrammer.
If your PCB is dated 06/20 (Rev B), the flashing pogopads are the same as the Emisar/Noctigon ones.
Some things I adjusted:
Found bug in thermal control when using external temp. sensor (also applies to some versions of Anduril1) - external temp sensor formula is used for one calculation but not for the inverse calculation; added new define for allowing defining inverse formula in the cfg file
Added small feature called "Turbo Extra C" - additional flag to allow running Turbo at higher temperature
The Lume1-FW3X is regulated through the entire range (low to 3A) + the highest level being the FET (no PWM is used). This causes the flashlight to heat up fast, but sometimes it's desirable to have the light have a slightly higher threshold temperature before throttling down.
Added a new configurable definition TURBO_TEMP_EXTRA, which you can add to the thermal ceiling, only for Turbo mode. So for example, in this build, the default is +5C.
The behavior now looks like this - at all regulated levels (1 to 149), the flashlight regulates to 50C. When the user goes to Turbo (ramp level 150), the temp_ceiling is raised momentarily to 55C, and the flashlight will not throttle until 55C is hit, whereupon it will drop out of turbo, and throttle the usual way and regulate temperature at 50C.
This value can be set to 0 to revert to the original behavior.
Flag to remove gradual transitions for FET during temperature throttling
Some of my drivers use a 3.9kHz control signal since I'm using 10 bit (instead of 8 bit PWM, which would be a 15.6kHz frequency)
In these drivers, the behavior is not to throttle the FET via PWM, and step down to CC regulated modes outside of turbo
Anduril enables gradual transitions if thermal throttling is enabled; this leads to a 3.9kHz PWM whine when stepping out of turbo from the FET switch and circuit inductances
This flag disables this gradual transition so the driver transitions from 100% turbo to 100% regulated directly, without PWMing the FET
Note: it is also possible to set the FET PWM frequency to 15.6kHz (8 bit) to mitigate this issue, but the FET needs to be controlled by a different timer (as opposed to the same TCPWM block as the main PWM control signal) - however, this requires a physical hardware pin change. It's also possible to change the TCPWM from 8bit to 10bit on the fly since these two channels are never used at the same time, but I haven't got around to implementing that yet since it's a slightly bigger code change.
Factory reset by default re-calibrates the temperature sensor to 21C, which is not desirable in our case since the Lume1 driver already has a factory calibrated low-drift temperature sensor.
I added a flag to disable temp. cal during a reset.
For the Lume1-FW3X firmware, here are my default configs and would appreciate any feedback:
Default Temperature Threshold - at 50C
New small feature I added in Anduril2 - Turbo Extra - +5C (or set your own)
Minimum thermal stepdown current level - ~500mA output (1.5W)
Default brightness level - ~250mA
Default ramp mode - smooth
Simple UI Level and Steps - low (~10mA) to 2A output / 4 steps
Advanced UI Level and Steps - low (~3mA) to 3A output / 7 steps
Flashlight Model Number: 0314
SOS - enabled in Blinky Group
I generated two files, one for regular Turbo operation, one with 2C to Turbo. Which do you think should be the default?
For convenience, TK's excellently written manual: http://toykeeper.net/torches/fsm/anduril2/anduril-manual.txt
After flashing, your flashlight will be in SimpleUI mode. From off, it's 10H to get into AdvancedUI mode to unlock the features!
And finally an observation... if anyone made your own Tri-LED AUX board, the disco aux-LED mode is particularly nice... looking at the optic feels like looking into some sort of small portal.. or a flux capacitor thing..
I have a mode that I would like to see, if only in the LT1. The old FAA obstruction/tower beacon mode with red light of one second on, one second off. It looks like 1.25 on and 3/4 seconds off because of filament glowing after power loss. I find the mode so relaxing when looking at old towers.
I came across a red glass vase that fits over the LT1. So if it comes about that there is an obstruction beacon mode, I am ready.
Also I always default to Anduril full UI - think this is fine for us BLFers, but factory production probably makes better sense to default to the Simple UI.
There's a lot to absorb in your post, and a few things I'm not clear on. Great to see the support though for Anduril2! Truthfully I'm more interested in seeing 1 Series MCU's come to fruition with Anduril2 because of their advantages, just one being a true factory calibrated internal temp sensor.
The TURBO_TEMP_EXTRA I understand and sounds good! Been thinking of adding a setting for GIVE_ME_30SECONDS_TURBO, so we can at least do a 30 sec measurement of lumens and throw from start, just not sure exactly how to implement it so it's not in effect when we don't want to use it... --> maybe 2C from Turbo would engage the 30 secs of no thermal reg.
Please let me know if you have any questions! I've only scratched the surface and I'm sure there's more I can help contribute to.
For temperature calibration, I see that the 1-series has a factory compensation values pre-programmed in the factory so I assume it will be better than the +-10C for the Attiny45/85 series, but I can't find anywhere on the datasheet that says what their calibration process tolerance is.. did I miss it from the datasheet or is there a whitepaper somewhere that talks more about it? If it's +-2C or better, I suppose that's probably good enough for most people.
I got a prototype Attiny1616 driver from gchart, flashed it, and it came up dead-on at room temp -- this was the only ATtiny driver I've ever seen this happen with!! And I've done many! So to me with this rather small sample of 1, it's close enough
Yup, every driver that Iāve built with the 1-Series that Iāve verified temperature on has been pretty much dead on.
Speaking of thatā¦ I just merged the 1-Series code into a fresh pull of Anduril 2. Now to (1) flash it on a driver, and (2) figure out how to publish it back up to Launchpad.
Okā¦ gotta admit I have no idea what Iām doing here with BZR/Launchpad. I think I just branched the code, added in the 1-Series changes, and published it.
