E-switch UI Development / FSM

1034 posts / 0 new
Last post
Lexel
Lexel's picture
Offline
Last seen: 1 year 2 months ago
Joined: 11/01/2016 - 08:00
Posts: 5895
Location: Germany

ToyKeeper wrote:
Lexel wrote:
I fglashed a driver with
INDICATOR_LED_SKIP_LOW

seems the first time after flashing it is in low mode
then 7 clicks do ON/OFF

That’s an error in your config file. Stop setting the default to a mode you don’t want.

please where do I find the config line does the default mode to low?

Quote:

// the button lights up
#define USE_INDICATOR_LED
// the aux LEDs are behind the main LEDs
#ifdef USE_INDICATOR_LED_WHILE_RAMPING
#undef USE_INDICATOR_LED_WHILE_RAMPING
#endif
// enable blinking indicator LED while off
#define TICK_DURING_STANDBY

#define INDICATOR_LED_SKIP_LOW

// If TICK_DURING_STANDBY is enabled…
// off mode: high (2)
// lockout: blinking (3)
#define INDICATOR_LED_DEFAULT_MODE ((3<<2) + 2)

OR

#ifdef USE_INDICATOR_LED
// bits 2-3 control lockout mode
// bits 0-1 control “off” mode
// modes are: 0=off, 1=low, 2=high, 3=blinking (if TICK_DURING_STANDBY enabled)
#ifdef INDICATOR_LED_DEFAULT_MODE
uint8_t indicator_led_mode = INDICATOR_LED_DEFAULT_MODE;
#else
#ifdef USE_INDICATOR_LED_WHILE_RAMPING
//uint8_t indicator_led_mode = (1<<2) + 2;
uint8_t indicator_led_mode = (2<<2) + 1;
#else
uint8_t indicator_led_mode = (3<<2) + 1;
#endif
#endif
#endif

ToyKeeper wrote:

Lexel wrote:
I got returned a Anduril flashlight from a customer who reported that the light gets very regularely stuck in a sort of blinky endless circle

I tried hardware fixes but it seems that the firmware itself gets stuck somehow

That was fixed in 2018. It happened sometimes when the switch signal was extremely noisy, and could generally be fixed by replacing the switch… but I modified the code to tolerate unusually bad switch hardware last year. Sounds like the firmware on that light is probably very old.

That was firmware from April 2019, its a buck driver
The light keeps blinking, even if I press the switch permanently it does an extra blink and goes on
my guess may be noise from the switching node

nick779
nick779's picture
Offline
Last seen: 3 months 2 weeks ago
Joined: 03/09/2018 - 15:46
Posts: 453
Location: Pittsburgh, PA

TK, I just noticed behavior in the 6/2 Anduril builds that I wasnt sure was intentional.

We have the two step lockout, however if you have the ramp minimum set to anything other than 1, the second stage becomes moonlight and the first stays the min ramp level.

Might it make sense for the lockout to maybe have some logic like “if MIN_RAMP_LEVEL > 1 ; LOCKOUT_STG1 = 1; LOCKOUT_STG2 = MIN_RAMP_LEVEL” or something similar?
Maybe even have a lockout config option for 6 clicks to toggle between single stage = min ramp and dual stage = 1/60lumen

Edit: does anyone know if Anduril has lvp with the aux leds?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 44 min 41 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10834
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.
Lexel wrote:
That was firmware from April 2019

Ah, okay. I wonder what’s causing it to go into a reboot loop, then. Something must be pretty noisy to set it off like that. Like, triggering interrupts faster than they can be handled, causing an overflow or something, until it goes into a reboot loop.

nick779 wrote:
TK, I just noticed behavior in the 6/2 Anduril builds that I wasnt sure was intentional.

We have the two step lockout, however if you have the ramp minimum set to anything other than 1, the second stage becomes moonlight and the first stays the min ramp level.

Might it make sense for the lockout to maybe have some logic like “if MIN_RAMP_LEVEL > 1 ; LOCKOUT_STG1 = 1; LOCKOUT_STG2 = MIN_RAMP_LEVEL” or something similar?
Maybe even have a lockout config option for 6 clicks to toggle between single stage = min ramp and dual stage = 1/60lumen

The first click is the current ramp floor, and the second click is the other ramp floor. Those can be whatever you set them to.

I’ve been pondering whether it should instead do first click = lowest ramp floor and second click = highest ramp floor, to ensure it goes in low-to-high order… but I’m not sure if it would be an improvement.

nick779 wrote:
Edit: does anyone know if Anduril has lvp with the aux leds?

Only in the most recent version, on the D4V2. I didn’t add LVP in sleep mode until that project.

Older lights with aux LEDs won’t shut them off when the battery gets low… but the D4V2 does. It wakes up every 30 seconds or so to measure voltage while it’s “off”. I still need to fix some of how that behaves though… if the user presses the button during that narrow timing window, IIRC it doesn’t respond how it should. But at least it allows the voltage readout to update as the battery drains, and it keeps the battery from draining too far.

i42dk
i42dk's picture
Offline
Last seen: 3 weeks 6 days ago
Joined: 08/30/2017 - 05:35
Posts: 201
Location: Denmark

imgur link

Just noticed this. This is a BLF Q8 running Anduril 02-06-2019 in “OFF“mode, aux off.
Looks like it’s powering the MCU down and up again?
My Q8, and D4S’s do this, my D4’s are steady @ 21yAmps

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 44 min 41 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10834
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.

i42dk wrote:
imgur link

Just noticed this. This is a BLF Q8 running Anduril 02-06-2019 in “OFF“mode, aux off.
Looks like it’s powering the MCU down and up again?
My Q8, and D4S’s do this, my D4’s are steady @ 21yAmps

That’s odd. The speed looks way too slow, unless the DMM is sampling infrequently.

It should cycle between ~5 and ~30 uA about 8 times per second.

This happens on devices with the “sleep ticks” feature enabled, because it leaves the WDT enabled during sleep so it can wake up and change the aux LED state, like for the “blinking” mode. The exact cycling speed is defined by STANDBY_TICK_SPEED.

If there’s no aux LED though, or if you compile without TICK_DURING_STANDBY, the power use should be lower and steady, as you described on the D4.

Agro
Agro's picture
Offline
Last seen: 9 hours 18 min ago
Joined: 05/14/2017 - 11:16
Posts: 6945
Location: Ślōnsk

TK…could you please share some hints on when can we expect 1634 sources?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 44 min 41 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10834
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.
Agro wrote:
TK…could you please share some hints on when can we expect 1634 sources?

It’s hard to say for sure. It would have been out by now, but people keep asking me to help them clone Emisar products, so I keep pushing back the release date. I’m not in the business of helping people undercut my clients.

Agro
Agro's picture
Offline
Last seen: 9 hours 18 min ago
Joined: 05/14/2017 - 11:16
Posts: 6945
Location: Ślōnsk

I see, thanks for clarificaiton.

hodor
hodor's picture
Offline
Last seen: 6 hours 37 min ago
Joined: 07/11/2018 - 03:58
Posts: 1109
ToyKeeper wrote:
Agro wrote:
TK…could you please share some hints on when can we expect 1634 sources?

It’s hard to say for sure. It would have been out by now, but people keep asking me to help them clone Emisar products, so I keep pushing back the release date. I’m not in the business of helping people undercut my clients.

I suppose that’s the problem with open source.

Personally, I prefer the design and execution of Hank’s lights and Anduril is icing on the cake. I will always choose his lights compared to the clones. I would hazard a guess that a lot of other flashaholics would too.

hodor
hodor's picture
Offline
Last seen: 6 hours 37 min ago
Joined: 07/11/2018 - 03:58
Posts: 1109

Not sure if this is the correct thread to ask but… I have an Astrolux C8 with a bleeder resistor on the driver and a lit tailcap. Everything worked well but the turbo step down was too quick so I changed TURBO_TIMEOUT to 255 in the A6 firmware (blf-a6.c) and flashed it to my C8. I didn’t specify fuse values when flashing. Upon testing I noticed I couldn’t step backwards anymore. Is this due to a core timings change somewhere in the firmware? Should I play around with the resistors again to get the modes working properly? If it helps, I bought the C8 new from BG one year ago.

i42dk
i42dk's picture
Offline
Last seen: 3 weeks 6 days ago
Joined: 08/30/2017 - 05:35
Posts: 201
Location: Denmark
hodor wrote:
Not sure if this is the correct thread to ask but… I have an Astrolux C8 with a bleeder resistor on the driver and a lit tailcap. Everything worked well but the turbo step down was too quick so I changed TURBO_TIMEOUT to 255 in the A6 firmware (blf-a6.c) and flashed it to my C8. I didn’t specify fuse values when flashing. Upon testing I noticed I couldn’t step backwards anymore. Is this due to a core timings change somewhere in the firmware? Should I play around with the resistors again to get the modes working properly? If it helps, I bought the C8 new from BG one year ago.

Sounds about right, the fuse settings. Had the same issue after flashing my BLF A6. The timing was way off. After reflashing it with the correct fuse values, it worked correctly again Smile

hodor
hodor's picture
Offline
Last seen: 6 hours 37 min ago
Joined: 07/11/2018 - 03:58
Posts: 1109

Doesn’t flashing without specifying the fuse values leave them unchanged? Or are you saying I need new fuse values for the (presumably) newer firmware?

i42dk
i42dk's picture
Offline
Last seen: 3 weeks 6 days ago
Joined: 08/30/2017 - 05:35
Posts: 201
Location: Denmark

Fuse values, are based on what type of MCU you are flashing. ATtiny13, 25, 85 etc.

Last time I flashed my A6 I used these settings:

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 44 min 41 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10834
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.
hodor wrote:
I have an Astrolux C8 with a bleeder resistor on the driver and a lit tailcap. Everything worked well but the turbo step down was too quick so I changed TURBO_TIMEOUT to 255 in the A6 firmware (blf-a6.c) and flashed it to my C8. I didn’t specify fuse values when flashing. Upon testing I noticed I couldn’t step backwards anymore. Is this due to a core timings change somewhere in the firmware? Should I play around with the resistors again to get the modes working properly?

It probably needs different values for the OTC calibration. The CAP_SHORT / CAP_MED values might not match the hardware.

Specifically, it may be a good idea to use the blf-a6 branch of the code instead of trunk, because it’s what the light probably shipped with. The copy in trunk has had updates and the calibration is set back to a default which I think matches MtnElectronics’ drivers instead of Banggood’s drivers.

Looking at it now, the blf-a6 branch uses values of 245 and 180, while the trunk branch uses 190 and 94. So that may be what you’re running into.

Banggood’s drivers don’t really have the standby drain configured very well to begin with, and the lighted tailcap makes it worse. Here’s what I measured a few years ago. The blue line is ideal, and is what trunk uses by default. The red line is what Banggood’s drivers do. And when you add a lighted tailcap, it follows an even higher line.

hodor
hodor's picture
Offline
Last seen: 6 hours 37 min ago
Joined: 07/11/2018 - 03:58
Posts: 1109

Thanks TK, very helpful and informative post as usual. I’ll check it out on the weekend. Beer Beer

Update: worked like a charm! Beer

tocirahl
Offline
Last seen: 1 day 10 hours ago
Joined: 10/18/2016 - 13:00
Posts: 128
Location: Austin, TX

I just wanted to post a suggestion for improvement.

When clicking 4 times to exit lockout, it would be nice the if the behavior were:

4-clicks, the light turns on to the last memorized mode
click, click, click, hold, the light turns on to moonlight and starts ramping up
5-clicks, the light turns on to ramp ceiling
click, click, click, click, hold, the light turns on to ramp ceiling and starts ramping down

etc.

Essentially, the fourth click should act as if the light were already out of lockout. This makes sense since if you’re taking the light out of lockout, the next thing you’re going to do is probably turn it on.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 44 min 41 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10834
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.

tocirahl wrote:
I just wanted to post a suggestion for improvement.

When clicking 4 times to exit lockout, it would be nice the if the behavior were:

4-clicks, the light turns on to the last memorized mode

I’ve considered doing something like this… making it so anything which exits an “off” or “lockout” mode will also turn the light on. That would mean 4 clicks to exit lockout would go to the regular ramp mode instead of “off” mode. And it might also mean 6 clicks to enter muggle mode would turn the light on.

However, I have no plans to do the other changes mentioned:

tocirahl wrote:

click, click, click, hold, the light turns on to moonlight and starts ramping up
5-clicks, the light turns on to ramp ceiling
click, click, click, click, hold, the light turns on to ramp ceiling and starts ramping down

etc.

Essentially, the fourth click should act as if the light were already out of lockout. This makes sense since if you’re taking the light out of lockout, the next thing you’re going to do is probably turn it on.

Basically, it sounds like the suggestion is: Reduce the “exit lockout” mapping from 4 clicks to 3 clicks, and force the button timing to reset after the 3rd click so it will start counting from 0 again. This would mean 5 clicks to access the ceiling, 6 clicks for battcheck, 7 clicks to go immediately back to lockout mode, etc.

But I intend to keep 5, 6, 7, and other clicks the same as they are now — momentary moon without unlocking the light. The most likely changes are:

  • Maybe remap 3-click aux LED controls to 7 clicks, to improve consistency between “off” and lockout modes.
  • Maybe remap 4-click “exit lockout” so it goes to an “on” state instead of “off”.
tocirahl
Offline
Last seen: 1 day 10 hours ago
Joined: 10/18/2016 - 13:00
Posts: 128
Location: Austin, TX

Ah I didn’t realize you are able to adjust aux LEDs in lockout. That complicates things somewhat.

Anyways what you are describing sounds like what I was suggesting.

hodor
hodor's picture
Offline
Last seen: 6 hours 37 min ago
Joined: 07/11/2018 - 03:58
Posts: 1109

ToyKeeper wrote:
The most likely changes are:
  • Maybe remap 3-click aux LED controls to 7 clicks, to improve consistency between “off” and lockout modes.
  • Maybe remap 4-click “exit lockout” so it goes to an “on” state instead of “off”.

Both sound sensible Thumbs Up

i42dk
i42dk's picture
Offline
Last seen: 3 weeks 6 days ago
Joined: 08/30/2017 - 05:35
Posts: 201
Location: Denmark

A thought just struck me, and I have to put this out there…

Imagine a website that can build a custom anduril.hex file for you Love

Imagine a GUI, with some simple drop down menus and boxes to tick.
Select host, select emitter. Select or deselect what extras you want.

Perhaps an advanced menu where you could rearrange what 3 clicks, 4 clicks does, etc.

And then boom, it spits out a freshly assembled .hex Smile

Tally-ho
Tally-ho's picture
Offline
Last seen: 1 month 3 weeks ago
Joined: 07/23/2011 - 04:15
Posts: 1394
Location: France

I would wish that in the ramp config of the stepped ramping there was a forth option to adjust the speed of the ramp. I would like it to be a bit faster.
I would also like a way to adjust the button release timeout from a menu for the light to turn off way faster. Like with computer mouse, I prefer quite fast double click, with anduril I tend to activate turbo while I don’t need it.

jasontheguitarist
Offline
Last seen: 1 hour 40 min ago
Joined: 02/25/2019 - 11:45
Posts: 421
Location: South Carolina

I kind of think a cool option would be to adjust the turbo level in the software, rather than having to flash a lower turbo version. I think it’d be useful to be able to lower the turbo level to the same as max ramp, meaning double click from off OR on would go to max regulated mode. Basically disabling the FET channel. For the FW3A, the light is really too small to sustain turbo for more than a few seconds anyway, so the option to disable the fet altogether would be interesting. Sort of a better muggle mode, since the FET channel is really what muggles need protecting from.

Tally-ho
Tally-ho's picture
Offline
Last seen: 1 month 3 weeks ago
Joined: 07/23/2011 - 04:15
Posts: 1394
Location: France

ToyKeeper, one thing that doesn’t feel right for me with anduril both in stepped and stepless ramping but particularly in stepless ramping is when I’m ramping up and stop too soon (“a tad more light should be just fine”), there is no way to immediately go a bit up.
When inside the window delay, 1H goes down but 1C + 1H also goes down.
Would it be possible to change this ?
I know that I would prefer 1H to always go up and 1C + 1H to always go down because it is how it works outside of the window delay, but to not confuse people who got used to how 1H actually works, would it be possible to have 1C + 1H to go up immediately ?

SammysHP
SammysHP's picture
Offline
Last seen: 15 min 24 sec ago
Joined: 06/25/2019 - 14:35
Posts: 1122
Location: Germany

This is controlled by the compile-time option USE_REVERSING. If you are able to compile Anduril yourself, you can comment that option out in anduril.c (or #undef it in the model config).

IMHO the timeout should be shortened from 1s to maybe 1 or 2 times hold time.

hodor
hodor's picture
Offline
Last seen: 6 hours 37 min ago
Joined: 07/11/2018 - 03:58
Posts: 1109
jasontheguitarist wrote:
I kind of think a cool option would be to adjust the turbo level in the software, rather than having to flash a lower turbo version. I think it’d be useful to be able to lower the turbo level to the same as max ramp, meaning double click from off OR on would go to max regulated mode. Basically disabling the FET channel. For the FW3A, the light is really too small to sustain turbo for more than a few seconds anyway, so the option to disable the fet altogether would be interesting. Sort of a better muggle mode, since the FET channel is really what muggles need protecting from.

I agree that it could be a useful feature to be able to set the limit of turbo on the fly. Disabling the FET all together probably isn’t feasible as it is used for all unregulated modes, just PWMed to achieve the desired brightness.

Coincidentally, I have a few BLF A6 drivers I’m looking into doing just that (reducing turbo level in the firmware though) so I can use them in single emitter lights without risk of frying the emitter.

Tally-ho
Tally-ho's picture
Offline
Last seen: 1 month 3 weeks ago
Joined: 07/23/2011 - 04:15
Posts: 1394
Location: France

@SammysHP, thank you.
I compiled a few times in the past so I should be able to do it again. I changed computer since, so I probably need to reinstall some stuff and read again a few BLF threads to refresh my memory.
I definitely need to dig in the compile time options to make anduril works like I would like. Currently it’s pretty fine except the delayed off to be way to long. I prefer the delayed off over immediate off mainly for not turning off LED (short blink) with a 2C or 1C+1H.
I also need to change the ramp levels. When set to stepped ramping and 5 modes, the steps in brightness doesn’t feel right. The second level after the floor (when set to the lowest (1)) is too bright for me.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 44 min 41 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10834
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.
jasontheguitarist wrote:
I kind of think a cool option would be to adjust the turbo level in the software

With Inferion’s post about using DSM to control output, I’ve been pondering how to possibly add this to FSM. I’m not sure if it will be feasible though. It seems like it would probably require doing the ramp-shape math on the attiny instead of using a full-fledged computer to calculate that… and doing arbitrary power roots in an attiny takes up a lot of space and computing time.

More importantly though, using DSM requires very precise timing on an interrupt which fires off tens of thousands of times per second, and that might not be possible in C. Basically, it changes the PWM duty cycle on every cycle, which allows it to hit in-between levels.

The upside of this is that it could have totally smooth and totally arbitrary adjustment across the entire brightness range, with pretty high resolution. It could potentially also improve thermal regulation, since it’d be doing power calculations in linear space instead of perceptual space. And it should also then be easier to make the turbo level adjustable.

There are a few downsides though:

  • Lots of math required on the attiny chip, to calculate the right values for a multi-channel light with a perceptually-linear ramp.
  • Very tight code loop required, possibly beyond what a C compiler can handle.
  • Probably wouldn’t be feasible to adjust the ramp shape in detail, like how the existing ramp calculator works. For example, on many FET+N+1 drivers, the +N part needs to start significantly above zero, to avoid making the ramp appear to stall at the boundary. This is relatively simple to work around in the current design, but would likely be quite difficult or complicated when using DSM.
  • May be difficult or impossible to get the stepped ramp to exactly hit the channel boundaries.
  • Requires rewriting quite a bit of code, both in the FSM library and in the applications which run on top of it.
  • Requires rewriting the thermal code too, and coming up with completely different abstractions for how the low-level and app-level code interact.

So it’s interesting and I’d like to at least find out if it’s feasible. But I can’t make any promises yet.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 44 min 41 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10834
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.
Tally-ho wrote:
it’s pretty fine except the delayed off to be way to long.

A couple months ago, I changed the release timeout from 24 to 18 WDT ticks. This might be enough to make it feel better. If not though, feel free to reduce it more. Smile

Tally-ho wrote:
When set to stepped ramping and 5 modes, the steps in brightness doesn’t feel right. The second level after the floor (when set to the lowest (1)) is too bright for me.

That is largely due to the ramp shape being inconsistent at the bottom end. The effective resolution is not low enough to get the exact levels desired, and I didn’t want to repeat the same level too many times in the ramp, so the lowest part is shortened.

This is something which DSM might help with, but I don’t really know yet. In theory, it might be able to increase the resolution of the bottom end and potentially even make the lowest level lower. But in practice, it might not work.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 44 min 41 sec ago
Joined: 01/12/2013 - 14:40
Posts: 10834
Location: (469219) 2016 HO3 // I get way more privmsgs than I can respond to, so please ask in a public thread if possible, for a faster answer.

I think, to start with, I’ll probably refactor the interrupt handlers. It currently handles the logic of those inside the interrupt itself, which is a bit sloppy. If I reduce the interrupts to just setting a “something happened” flag, I can move the logic elsewhere and handle it at a more convenient time. This, in turn, might make it feasible to have the DSM interrupt running all the time without nearly as much timing jitter.

Basically, the DSM interrupt needs to happen every 256 clock cycles, out of the 8 million which happen each second. Or maybe every 137 cycles, or perhaps every 512 or 274. I can work out the exact details later. It’s roughly 30,000 to 60,000 times per second. In any case, this means the MCU must never get stuck in an uninterruptible state for more than ~100 clock cycles, because it would break the DSM timing. So I need to go through and reduce all uninterruptible states to be extremely short, and if necessary, move the longer portions of that code to a less critical place.

It’d also probably improve things in general, and as a side effect would make the sleep code able to react better by knowing what woke it up. This should, for example, eliminate the occasional short blinks in the aux LED blinking mode.

So… that’s step 1.

Then I should be able to at least test the DSM idea to see if it’ll work in C. If so, I can work on all the other steps… and if not, at least I improved something along the way. Smile

hodor
hodor's picture
Offline
Last seen: 6 hours 37 min ago
Joined: 07/11/2018 - 03:58
Posts: 1109

Anyone know how to keep the switch / indicator LEDs the same brightness regardless of main LEDs? Specifically on a SP36. Currently the switch LEDs have low brightness while the main LEDs are in regulation and high when the FET is engaged.

Apologies if asked before, I searched and couldn’t find the answer. Also looked in the code and couldn’t find anything.

Pages