E-switch UI Development / FSM

I was thinking power cycle to exit muggle mode, because itā€™s consistent with how one must exit momentary mode, and it also works for lockout mode.

With a D4 flashed in the right way, itā€™s actually harder to power cycle than it might seem at first. I got standby power down to 0.35 uA (0.00035 mA), so I can take off the tailcap, walk away to have a conversation, come back, put the tailcap back on, and the light doesnā€™t know it was disconnected from power while it was asleep. So in practice a power cycle means ā€œloosen tailcap, click button, tighten tailcapā€ or ā€œloosen tailcap while light is coming out the frontā€.

What would it take to support the Schokiā€™s MP3431 driver ?

That dependsā€¦ FSM can technically run on tiny25, but only just barely. It really needs tiny45 before it can do much at all, or tiny85 if you want something fancy like Anduril. And for that, things arenā€™t looking good:

Older e-switch code had a smaller base footprint but used more space for each feature. It could be approximated with something like ā€œ500 bytes base + 500 bytes per featureā€. FSM has a bigger footprint but makes additions significantly smaller, like ā€œ3000 bytes base + 100 bytes per featureā€. Or something along those lines, anyway.

I guess, to add support, what it would take is a bigger version of the driver with a bigger MCU, preferably SOIC8 (though reflashing pogo pads or holes would work too). It could be tiny85 or tiny1634 like Mike C uses, or tiny841, for the easiest options. For tiny1616/1617 things get more difficult, and for non-AVR options things also get more difficult.

Actually now the design uses a 4x4 MCU and ATTiny85 should fit.
I wonder about the OTSM discussion that I donā€™t understandā€¦ :blush:

Oh, if it has tiny85 now, then I just need a driver with flashing pads/vias or SOIC8, and I could add support for it fairly easily ā€” some way to reflash without soldering. Not necessarily for production use; just for development purposes.

As for codeā€¦ I donā€™t know what the pinouts are, but Iā€™d need to add a driver layout definition and probably adjust the ramp tables. Maybe change a bit of init code. And it may also need new code to measure voltage. I seem to recall some discussion about that, and I donā€™t know if it was ever resolved. So battcheck and LVP might not work, depending on whether thereā€™s a way to measure the battery voltage.

The OTSM stuff is irrelevant for FSM, and for e-switch lights in general.

FSM-based apps shouldnā€™t need any changes, or should need only very small changes. Mostly they should ā€œjust workā€ after the base library gets support for the new driver. Change one line per app to select a different driver type, and maybe update anything driver-specific it does (if there is anything).

Overall, porting should be relatively easy. Thatā€™s half the point of abstacting out the hardware layer and separating it from the UI code.

Glad to read that. :slight_smile:

I flashed my driver with anduril firmware and I really like it. I have some questions:

  1. Is there a way to turn off the thermal stepdown?
  2. Can you add brighter, dimmer option to the tactical strobe?

1. Disable USE_THERMAL_REGULATION at compile time. (should compile, but is untested)

2. Perhaps. It wouldnā€™t be difficult. Not sure if itā€™s a thing many people want though; usually tactical strobes only go at the maximum brightness. On small high-powered lights this risks overheating though, so itā€™d probably be a good idea to lower it for those or make it configurable.

On my Q8 with AndĆŗril sometimes in the momentary tactical mode it leave the main led on after a few presses. I didnā€™t know the exact press combination but playing with it and somtimes it stays on. And once I got in ramping stuck in one level and no button presses helped just when I disconnected power.

I still need to tweak the debouncing and event detection a little more, to handle extra-noisy switches. It mostly works, but can run into some weirdness when the switch bounces for an unusually long time. Itā€™s a bit difficult to test though, since I havenā€™t found any really-noisy switches to test with.

Maybe I can find a noisy switch somewhere in my drawers of parts.

A scope would help too, so I could measure this stuff instead of guessing. I usually do pretty well at programming blind, but it sure is helpful to have data to work with instead of just theories.

I installed Anduril on Q8 and on tactical mode I can get it stuck switched on with the switch released just like ZozzV6 mentioned earlier.

Also there is slight delay when switching the light off. Is it there because of ramp down UI (click, click&hold)? Is it waiting second click&hold? The delay is a bit too long for my liking.

I like lightning mode. Thank you ToyKeeper!

Now I am waiting impatiently for candle mode. Googling for ā€œled candle flicker algorithmā€ shows up some interesting results.

The delay is because itā€™s waiting to see if youā€™re going to click again for a double/triple click. The timing of that can be changed by re-defining RELEASE_TIMEOUT. The default value is 24 frames.

The delay can also be eliminated entirely by mapping the ā€œoffā€ action to EV_click1_release instead of EV_click1_complete (a.k.a. EV_1click), but this will interfere with detecting double clicks. So youā€™d need to have a ā€œturn emitters offā€ action on button release, followed by a ā€œgo to ā€˜offā€™ stateā€ action after the timeout happens. This should be safe, but has the side effect of making it briefly blink off after the first click, even when ā€œoffā€ isnā€™t the action you were intending.

Iā€™m not completely happy with candle mode yet, but hereā€™s an example graph of its output:

Mostly, it seems a bit too spastic when used at low levels, and perhaps a bit too spastic overall. Itā€™s like a candle in a breezy environment. Perhaps I should change it from free-running waves to fading waves triggered by random disturbances. Or maybe just decrease the amplitude on the mid-frequency oscillator. Or maybe make the mid oscillator fade and refresh at random. Itā€™ll take some experimenting. It already does a random sample-and-hold modulation on the mid oscillator frequency, which helps, but it feels like it needs further adjustments.

In another thread, ā€˜stephenkā€™ mentioned that an adjustable strobe frequency is useful for light painting.

I suggested he look into AndĆŗril, with its adjustable-frequency ā€˜Party Strobeā€™ and ā€˜Tactical Strobeā€™ modes.

He then mentioned that a momentary strobe would also be useful.

Could AndĆŗrilā€™s momentary mode also work with strobe modes? If not officially supported, could it be a compile-time option?

Momentary strobe? Thatā€™s not a thing Iā€™ve considered.

I added it as a ā€œTODOā€ note in the code, but I donā€™t have any plans to add it in upcoming production lights. I suspect that my rainbow saber thing may be more relevant for light painting anyway, since itā€™s specifically designed to make pretty patterns in the air while swinging a lighted sword. It does whatever patterns the user tells it to, and has a full color palette to work with. This includes a momentary ā€œoverdriveā€ function, which could potentially be configured in a manner similar to what he might want.

ā€¦

Hmm, I just tried it by turning the brightness down all the way on a police flasher mode, hoping that itā€™d become momentary-only so it only lights up in overdrive. However, the brightness mod is additive instead of subtractive, so it still flashes while idle ā€” just not as bright. Overdrive works fine, but the non-overdrive isnā€™t dark like I had hoped. This could be fixed by making it subtractive, but Iā€™m not sure if thatā€™d be a good idea outside of this momentary thing.

Iā€™m a bit late here, but Iā€™d like to add my two cents. First of all, youā€™re 100% correct that itā€™s impossible to create, test, and host dozens of .hex files for every hardware configuration out there. However, I do think there is good demand for an alternative to NarsilM on TA drivers. Perhaps we could talk you in to creating one ā€œmasterā€ triple-channel.c file, a la Bistro Tripledown? Youā€™ve made it easy enough for all of us to utilize your /bin/ files for things like ramping table calculation, etc. Iā€™m proficient enough in C and Python to write basic programs and edit your (very well-commented) code, but I have no clue where to start when it comes to adding a third power channel.

In this case, the only change necessary to support popular hardware is to uncomment one line at the top of the file.

// Physical driver type
//#define FSM_EMISAR_D4_DRIVER
//#define FSM_BLF_Q8_DRIVER
//#define FSM_FW3A_DRIVER

Thereā€™s a good chance the TA drivers would work with the FW3A options.

However, adding a new driver type is a bit more tricky.

At the moment, the moon-in-lockout checks the floor for both ramps and uses whichever is lower. This makes the behavior consistent regardless of which ramp is active, but it can also make moon too low sometimes. Do people think it should instead use the current ramp floor instead of checking both? This would effectively give it the ability to change the lockout brightness by switching between ramps, perhaps with a day mode and a night mode, but it might also lead to surprises if the user forgets which ramp is active.

I think Iā€™d prefer it use the current rampā€™s floor.

I havenā€™t reflashed AndĆŗril in a while. Iā€™ve been waiting for Candlelight Mode to be perfected. :partying_face:

Has Muggle Mode been implemented? Does lockout work in Muggle Mode? I like the thought of being able to teach muggles the importance of lockout, both software- and hardware-based.

Ah, been a bit distracted by holiday stuff and fixing FW3A issues, so candle mode hasnā€™t changed.

Muggle mode is implemented but not published yet. There hasnā€™t been much consensus about how that should look, so for now itā€™s a simple latching on/off at 1x7135 (~150 lm) with no bells or whistles. I havenā€™t even made it dim for LVP yet, though I probably should. For now, it just turns off.

How hard would be to do this:
only one mode (100%), it works while you hold down the e-switch, shuts off when you let go the e-switch. Driver is nanjg 105C?

Need this for diving light that had magnetic switch and driver died so I thought to use regular nanjg 105c and replace e-switch with reed magnetic switch!