E-switch UI Development / FSM

Wow - this is strange. There's no manual on this light that documents how the AUX LED's work? From the UI diagram, I can only guess there is no auto setting of the color based on voltage, but you manually set the colors - it clearly shows that. Are you sure that code is relevant to this D4SV2 build?

Yes, it is relevant to this build. It has manual colour setting but also 2 other settings, rainbow/demo and voltage. You can set it independently for off and for lockout.
Mine is definitely in voltage readout both for locked out and for off, though I use different brightness to differentiate between them.

BTW I noticed something that may be (or may not be) a bug (unrelated):
{

2302-void indicator_blink(uint8_t arg) {
2303- // turn off aux LEDs when battery is empty
2304: if (voltage < VOLTAGE_LOW) { indicator_led(0); return; }
2305-
2306- #ifdef USE_FANCIER_BLINKING_INDICATOR
2307-
2308- // fancy blink, set off/low/high levels here:
2309- uint8_t seq[] = {0, 1, 2, 1, 0, 0, 0, 0,

2330-void rgb_led_update(uint8_t mode, uint8_t arg) {
2331- static uint8_t rainbow = 0; // track state of rainbow mode
2332- static uint8_t frame = 0; // track state of animation mode
2333-
2334- // turn off aux LEDs when battery is empty
2335: // (but if voltage==0, that means we just booted and don’t know yet)
2336: uint8_t volts = voltage; // save a few bytes by caching volatile value
2337- if ((volts) && (volts < VOLTAGE_LOW)) {

rgb_led_update() treats voltage of 0 specially.
indicator_blink() doesn’t.

Dunno, depends on the state each of those is called. Maybe the state of "voltage = 0" is only relevant when rbg_led_update() is called?

For you AUX LED issue, dunno, maybe there is a bug in the voltage setting. For the hardware, I assume you can verify if the green LED's are working, if so, then I'd suspect a bug in the firmware. With that 1634 processor, there's plenty of I/O pins, so I assume she's got one dedicate to the green aux LED's, so if the full green setting is working, then it should work the some for voltage reading.

Ohh - it helps to use a fixed space font like Courier new for quoting code. I do this all the time.

I worked on adding voltage Cal to Anduril. All coded, compiled, ready to test. I made it work to enter the fudge factor via clicks. 5 clicks is 0.25, 7 clicks is 0.35, etc. Max of 10 clicks.

Installed this just now on a SP36, previously had NarsilM v1.3 on it, and been testing it - the voltage fudge factor configuration seems to be working fine!

If I set it to 3 clicks, it reads 3.8V. If set to 10 clicks, it reads 4.1V. A difference of 7 clicks is about 1.75V, so this makes a lot of sense. Now if we (or I) could get this rolled in the official Anduril? Seems like a great feature. I was gonna spend the time doing it with NarsilM but it would be a lot more effort, because I also would have had to roll thermal config in.

Wooo Hooo!!

Well, crap. The Astrolux EC01 is one of my favorite torches right now. My son has one, and I have 3. Now that I’ve sent all that money their way, I find out they’re violating the GPL. I figured since they say right in the titles of their product pages that they’re using Andúril, that they would have done it right.

Another observation:
When I’m in voltage blinkout mode with the cell I have in the light now, the first result is either 2.6V or 3.6V (not sure, the light turns on and off as I do the clicking), probably 3.6V. But later it shows consistently 3.7V.
Is it that turning it on for the split second drops cell voltage by 0.1V and the first blinkout starts before the cell recovers?

Tom E,
Great feature, but it will be used once after flashing firmware and forgotten

True, hopefully, but that's the point - just like thermal config settings. I'm tired of re-flashing simply to tweak these settings, like I've been doing for years with Narsil. Also, there's been a lot of complaints in production lights on the inaccuracy of the voltage readings, so we will have a fix for that.

I've noticed this in my Anduril lights as well - usually a 0.1V variance, but not sure if it happens in Narsil as much. Well, the D4SV2 is a 1634 light, so the low pass filter is enabled in the cfg-emisar-d4sv2 file. Just reviewed it, and it's the same low pass filter I implemented in Narsil, actually first written by DEL. DEL's/Narsil's implementation is interrupt driven for the A-D conversions, and best as I can tell, so is Anduril, but the interrupt processing is deferred. Her interrupt handler is 1 line of code in fsm-wdt.

The only difference I can see between Narsil and Anduril is that Narsil throws away the first, or every other ADC voltage reading, and Narsil doesn't defer the processing.

So the cell will lag under load - I've certainly seen this, though I thought it was with more weak type cells, like 16340's, etc., but maybe even on a good cell, the lag could be seen as a small dip.

Awesome Tom E, sounds like a very worthwhile addition!

I guess that battery sag could be fixed by blinking number of volts , reading voltage again and blinking 0-1 numbers for full volts and then the decimals. Careful not to blink 4.9.
Or better: blindly do 2 blinks and then the rest.

Might be easily fixable by a delay. I recall from DEL, there was a reason to skip the first reading... This was back in the day of the Q8 development.

The low pass filter we use is still subject to 1 off glitchy readings - it's not doing averaging of any kind.

This seems beyond my skills so far though…

It’s in the datasheet. If swapping between temp readings and reading VCC, then this applies: “The first ADC conversion result after switching voltage reference source may be inaccurate, and the user is advised to discard this result.”

Another thing to consider when reading MCU VCC as battery voltage is that the voltage drop over the diode is only the same if the current draw from the MCU is always the same. Alterations in current draw from MCU do lead to alterations in voltage drop. It’s different depending on diode of coarse, but the drop over the diode is not fixed, it is current dependent. I didn’t bother about it with the good old fashioned 7135 & FET drivers but it became much more noticeable when I started powering some components (like digi-pot) directly from the MCU pins. I went back to using a voltage divider.

Ahh - ok. I'll have to check Anduril again for support of this. Is it true then using the external voltage divider would solve all the flaky problems we see in voltage readings/reports?

It's a shame because with a FET+1 driver, pin #7 is a spare but we stayed away because of the extra amp draw in e-switch lights. I've used higher values for the voltage divider resistors to reduce the parasitic drain and it seemed to work well.

For me it was a no brainer with the divider because of current draw when turning digi-pots on/off and having 4 output channels on/off made the readings pretty bad. I had moved on from the 85 when I started doing these kind of things so pins wasn’t an issue.

I’m using the 3217 now so I definitely don’t have a shortage of pins. The negative side of my voltage divider does not go to GND, it goes to another pin so I can control it’s connection to GND. When shutting down on E-switch lights I just set to high impedance input and turn on the pull-up resistor, that entirely eliminates parasitic drain from the divider.

That's a nice feature, to eliminate the parasitic drain.

I wonder what would it take to merge that into the main source tree…
What kind of maintenance would be needed? I guess only adding cfg files?

No idea - I'm totally confused with that mgt UI. I use git at work every day, not on the web, but with a master repository.

I got base mods to Anduril itself (anduril.c), fsm-adc, setup files, and of course added the project and solution files for Atmel Studio.

Also added voltage reading calibration to the UI - 4 clicks std method.