Not sure if you got any responses to this but my vote would be to stay consistent where possible, therefore 7 clicks to change aux mode for both off and lockout modes. I was planning on making this change to my tweaked version but then completely forgot after battling with Atmel Studio.
I got Anduril compiled in VS7 under Windows - no problem. But then again, I NEVER had problems with doing anything in VS 7. Anyone's issues with VS7 I believe I also resolved for them. I hear it time and time again, and always, never had problems.... I don't get it.
could the voltage be scaled in a ‘op amp’ sort of config, to compare a received ‘level’ and turn it back up so to speak, if you could do that with current and volts it’d be auto buck booste style…theres a reason i like auto buck booste, the voltage changes very very little until near the end where the battery dies verses the buck cc/cv types with only two pots varying from cell to cell config and changing through the battery discharge, the charger type cc/cv with the third pot on the circuit board stay pretty solid…ehhh… haven’t got the tecno jargon to explain it sy.
in newbie talk, two inputs on the chip, one for voltage level one for current sense, and adjust. anything else especially frequencies/duty cycles would be as close to ‘perfect’ as you could get them at this level of hardware, no inductors of bulk required?
to hi tecky it, a PID type set up could possibly ‘predict’ its stability a lot more, but instead of a fan or heater, it’s the two input channels regulating constantly and consistently .(tie it in with the temperature and its all three in a couple of equations?).
depending on how many bites in the loop would limit the times per second, or what ‘frequency’ it checks and corrects, i’m thinking could it be run at the led pwm frequency… that’d be about as accurate as you’d want?
edit in, the anolog output may well be of use.
I think you might be looking for a driver hardware development thread, not a UI design thread.
i wouldnt be suprised ToyKeeper 
What about this?
- In general 7 clicks to choose low, high, blinking. And
- a shortcut for temporarily off, till next normal use: Ramp a bit and switch off the light immediately. That works pretty well on NarsilM.
Don’t know if an AUXtempOFF-Bit needs too much space. Or if it collides with other stuff.
On that note, is there a simple way in FSM to have an output pin that is high when the µC is running and low while sleeping? This would help a great deal with some control schemes, e.g when you need to control a converter via its enable line, or an opamp/comparator…
I used a PWM channel before with a fixed value in the ramp table but that has its limits.
btw, have you ever come across the ATtiny43U? It’s a weird one, but it looks like it could be useful in some niche cases. But it only has 64b of EEPROM, would that be enough for the ATtiny45 FW variants?
Yes. Ish. Look in fsm-standby.c, where it handles the process of going to sleep and waking up. Set the pin low/high there, and it should automatically do the right thing regardless of which UI is running. It may also need something in fsm-main.c to set the pin state at boot.
No, and maybe. It depends on how many bytes of eeprom the UI requires. Check the value of EEPROM_BYTES and EEPROM_WL_BYTES to see if a particular UI can work. For example, DarkHorse only needs 5 bytes.
Thank you. That sounds like it should do it. As for ‘how’,….something like say DDRB |= 0b00010000 in the main c …? Maybe? And then… 
I’ll figure it out.
Would it be okay to add a delay of a few µs after that pin goes high (to make sure everything is up and running) or would that cause issues somewhere else?
Is it valid to say that ramping uses lots of EEPROM? Don’t know why but that’s what’s stuck in my head.
This one’s on the bucket list anyway.
Dunno. Try it and find out.
The WDT ticks every 16ms, so anything shorter than that is probably okay.
No, that’s in regular ROM (PROGMEM). The only things which go in EEPROM are the user configuration values which need to be remembered after a battery change. I think even the most complex Anduril build uses only ~15 bytes. The most I’ve used is 108 bytes, and that’s in my lightsaber UI. It stores a dozen user-defined lighting patterns, and they’re 9 bytes each.
I’m experiencing something odd with Anduril. I have one D4 and two D4Ses flashed with a slightly tweaked version of Anduril from Nov/Dec 2018 in which I added a shortcut to moon.
All temp sensors have been calibrated and the limits set to 45c. The thermal stepdown on all three work as expected when the lights are at ceiling level, however on turbo only the D4 seems to throttle correctly; the D4Ses get extremely hot (+55c) with very minimal stepdown. Re-calibrating the sensors and setting the limits much lower (e.g. 31c) doesn’t appear to make any difference either.
Are there any known issues in Anduril with thermal stepdown from turbo? I see in the config files that the D4 has THERM_HARD_TURBO_DROP defined whereas the D4S does not. Could this explain the difference in behaviour or should the D4S still be throttling to stay within the limits?
… Or is this working as intended and I simply need to RTFM? 
What the hard drop does is: as soon as a thermal prediction is above the configured limit, it triggers a quick ramp down to a hardcoded “sane” level. Afterward, it does normal regulation, but it doesn’t attempt to back up above that sane level. I think this is the stepdown you see on the D4.
If you want the D4S to do that too, turn on the hard drop. However, their increased thermal mass should allow for a higher “sane” level, and they might not need it at all.
This demonstrates the difference between the two. It’s on a different light, but the orange line shows the algorithm the D4 uses, and the blue line shows what the D4S does. In this case, the “sane” level is set at about 3000 lm:
Thanks TK, that makes sense.
Panic over! I think… So I let everything cool last night and tried again this morning, after re-calibrating and setting limit to 45c I’m happy to report it’s working as expected now!
I guess either the calibration or temp limits weren’t sticking or, the more likely scenario, my temp calibrations were wrong. Which is odd because calibrating the sensors was the first thing I did after flashing Anduril. I also did it a few times last night but I guess they hadn’t fully cooled down. If this is the case the D4Ses take a loooong time to get back to room temperature. Side question: does the temp sensor need calibrating after subsequent flashes?
With them working as expected now I think I’m good to leave the hard drop undefined 
Yes. Each firmware re-flash erases the old config data.
Have to say, thanks a bunch for being awesome and setting up FSM the way it is TK. Being a newbie and poking around some of the code is made far easier because of it.
Additionally, BLF Q8 is a fantastic stock testbed for trial runs too, so heads up to anyone looking to start fiddling, using a Q8 and the clip on flasher means opening up, flashing, and closing the flashlight to a functional state takes all of 5 minutes, I flashed at least a dozen separate alterations until I got the altered function I liked.
Whole reason for this post: ended up changing a couple things in Anduril to suit my needs. I found using momentary set to the max regulated output was perfect for EDC uses, preventing pocket-burning accidental activations and allowing quick access for a bit of light, however I got tired of power cycling to get out of momentary.
Took advantage of the MOON_DURING_LOCKOUT_MODE function in Anduril.C and set it up to use a separate value defined just below for LOCKOUT_MOON_FANCY, which is currently MAX_1x7135. While in the 4 click lockout mode, a single click is momentary moon, a double click is momentary max regulated, or whatever value is chosen before building. Ended up being far easier than I expected.
It’d be nice to have a way to set this value through the flashlight itself, outside of using memorized_level or reflashing any time I would want to change it, but that’s beyond my understanding for now.
Setting one of the ramp floors to the level I would want did occur to me, but I like to use both ramp modes with full range on each end, so doing so setting a ramp floor high enough would interfere with that.
Yeah. It would be. I’m not sure how the interface should work though, or whether it would be worth the cost in bytes. Fortunately, that last bit becomes a lot easier with an even bigger MCU, which will probably be a thing eventually.
About the UI for it, there would need to be some way to mark a specific level as the default. And perhaps some way to toggle between memory and the default level. Or maybe a timeout where memory would expire. Or … something.
Here’s one idea. If it was only used for momentary, there’s a particular symmetry available. Ramp to the desired level in the normal ramping mode, and click 5 times. This would set the level for momentary mode. Then turn it off, and go to momentary with another 5 clicks. Relatively simple, and the symmetry should make it easy to remember. But it’d still have the downsides of momentary, like needing a power cycle to exit. And setting the level this way is harder than the current method, since it’s the same thing except with 5 more clicks.
I don’t really know how it should work. It’s not an itch I have, so I’m not sure how best to scratch it.
Yeah that was one issue I ran into a couple of times when debugging. Andruil built for the Q8 with muggle mode and all the fancy blinkies enabled will compile, but iirc enabling LOCKOUT_MOON_FANCY in addition puts it over by 6 bytes or something close, so memory is already at a premium depending on the light. Fortunately disabling muggle mode wasn’t a deal breaker for me.
The idea of using 5 clicks when on to set a defined value for momentary would be great if it could be saved in the eeprom so it lasted a power cycle. At the very least it would be another user defined value that could be called for in momentary or elsewhere if anyone made any additions akin to the alteration I made.
Two variables, memorized_level which is used everywhere and momentary_level, a value only used during lockout/momentary. When enabling momentary mode, use momentary_level if level is > 0 else use memorized_level. A power cycle would reset the flashlight but the momentary value would still be remembered and not have to be set every time before entering momentary.
Reset to zero could be done with 8 clicks from off, leading momentary to use memorized_level again as it’s currently set to do. The functions are obscure enough that it would be difficult for anyone to accidentally set the value or reset it, and probably easy enough to disable the function before building.
It’d be neat, but hardly worth the memory for most I’ll agree. If I really want a user defined value I can still use memorized_level for the double click lockout momentary
It sounds like you might have an old version or maybe some odd compiler settings. I just tried a default build for BLF Q8 and it came to 7358 bytes, or 89.8% full. It was bigger in the past, but I completely rewrote the button-press code and event system to reduce the size. It’s available in the fsm branch, though I forget whether it has landed in trunk yet.
I’ve been slowly refactoring things to reduce size and/or make the code cleaner. Two of the things on my list to do next are the thermal regulation code and the ramping code. Thermal regulation is going to take a while, but ramping might be simple if I find the right abstractions to use. I want everything with a “hold to change” function to use the same code, with the same reversing functionality. I’m not sure if it’ll end up being smaller, but it should at least be more consistent.
There’s a very good chance the thermal code could be a lot smaller… but I’m going to have to basically build a physics simulator and code emulator in order to test things… and then translate the new algorithm to C and test it on real hardware… then update the simulator to be more realistic… and then test on real hardware again… and so on. I’ve been avoiding it for like a year because it’ll be a long and frustrating process.
Oh that’ll do it, I’m using the release from trunk, not fsm. Looks like I’ve got some more poking around to do.
Re: thermal management, I don’t think anyone would blame you for waiting on rewriting it, that sounds like a royal PITA
Since i found out my older DMM has precise mA/yA current measurement, I’ve been measuring a lot of lights lower levels.
So how about trying different firmwares on the same host. To see the current differences.
Host: Emisar D4S with 219C’s. (5000mAh 26650 cell)
Anduril (v.2019-01-15)
Standby (AUX off): 0,042mA [13,6 years]
Standby (AUX HI): 1,17mA [0,5 year]
Moon: 1,86mA [0,31 year / 112 days]
Narsil (v.1.3)
Standby (AUX off): 0,023mA [24,8 years]
Standby (AUX HI): 1,15mA [0,5 year]
Moon: 5,19mA (pvm lvl 2) [0,1 year / 40 days]
The Narsil moon level is a lot lower, but uses a lot more power.
I used to have Narsil on the lights that could use it, the only thing holding me off Anduril, was Narsil’s lower moonlight. But I eventually made the switch
So… I’ve been told before that Narsil’s way of making it’s lower moonlight level, is very inefficient. But damn, thats a lot of energy wasted in the MCU.
Can someone explain it to me in plain english, what’s actually going on here?