E-switch UI Development / FSM

Hi TK.
Is it possible to share the unnamed firmware?
Thanks.

Ah, thanks.
I couldn’t get that from the flowchart

The “good night” mode sounds great. If the timer in a flashlight is good enough for that kind of thing then I wonder if you could make an alarm clock mode that slowly ramps up the light after a programmed (with clicks) time.

In general terms, I agree. The tricky part is translating that to specific implementation details — especially if the UI is intended to satisfy both enthusiasts and muggles.

The common 3-mode SK-68 UI (high, low, strobe) is very muggle-friendly but enthusiasts usually hate it. Or the HiveLD driver has lots of features for enthusiasts, but it requires a 9-page manual to operate, and setting config options requires a soldering iron and a metronome.

Getting both power and simplicity at the same time is somewhat tricky. The “unnamed” UI definitely errs more toward power and less toward simplicity. That’s kind of the point of it though — to be fancy and full of features that I want on my personal lights.

That was a thing I left alone in the D4 interface. On my custom UIs though, I generally do a single very-quick blink when power is connected. Very very quick. Unless it’s intended for a dual-switch light (e-switch and power cut switch), in which case it definitely shouldn’t blink at power-on.

The quick blink can be just as bright, but it doesn’t look as bright because it’s so short. Regardless, if you don’t want to be seen, it’s a good idea to cover the front of the light while tightening the tailcap.

It could perhaps be made optional, or I could maybe add a lockout config option to specify whether lockout blinks on exit or not. With soft lockout on 4 clicks, I usually go for that instead of unscrewing the tailcap. Perhaps it could have two or three modes: blink on exit, moon on exit, or no feedback at all.

I have some ideas for improving thermal regulation, and plan to try them soon. It won’t take the entire rest of the ROM though.

About the ramp blinks, those are there because people requested it. Before, the ramp was actually too smooth and left people feeling lost, with no idea how bright it was or how long it would run.

But if the space isn’t needed for other things, it would be relatively easy to add an option to toggle the ramp blinks.

Bingo. That’s not a software thing. The software has access to only one pixel, one button, and one poorly-placed thermal sensor.

Yes, but not quite yet. I’m still working out a few details. Mostly trying to coordinate with other people, which takes time.

The timer is pretty good (in my test, it timed an hour to a precision of less than a second), but waiting 8 hours before turning on is a little tricky. It would mean one of the following:

  • Leaving the MCU on all night, at about 5 mA, so ~40 mAh power used each night just waiting.
  • Implementing a special “twilight” half-sleep mode specifically for things like this alarm clock mode. (like standby, but the WDT would wake up every couple seconds and send a “tick” to the current State handler, with ADC turned off so it can’t sense low voltage)

I don’t like that first one, because 5mA is really high for a mode where it isn’t doing anything. I may be able to make the second one happen though, and it might be kind of nice for other things too (like controlling an indicator LED during standby mode).

In any case, if you want a light to blast in your face each morning, that might be do-able. :slight_smile:
(it’s just going to need a bit of plumbing work first)
(OTOH, timers exist which plug into wall outlets and turn on whatever they’re connected to at a specified time, so that’s probably a cheaper and easier way to do it)

TK, as you already stated, a refined thermal regulation would be a welcome feature. Perhaps the possibility to config in the ui it’s sensitivity to react to temperatures changes, and the correspondent amount of decrease and increase of power to the emitter(s), would permit a fine tune of this function to the many different setups that we use in ours lights (small and big hosts, single and multiple emitters, drasticaly different levels of driver current etc).

I have a SRK with Q8 driver, and a D4, and hopefully soon a D1, to test on. If I can make the thermal regulation “just work” on all those, it’ll probably be flexible enough for most purposes with no need to fine-tune anything. Hopefully the physical traits (like power level and thermal mass) will give the regulation enough feedback to adjust itself. Like, a big light heats up slower so it can react slower or in smaller steps.

However, that said, at a firmware level there are quite a few knobs to tweak, to make sure it reacts at the right speed and intensity without oscillating. And I need to test with tail-standing and no fan, since that was a scenario where the D4’s regulation would over-shoot and then take a long time to recover. It did fine with a hand to sink heat to, or with moving air, but the stagnant air case didn’t behave very well.

TK is it possible to add in the blinkies the heart beat and the sos like Crescendo have?

Sure, it would be easy to add heart beacon and SOS. I’m not sure it would add much though… It already has a beacon with adjustable frequency and brightness, and the momentary mode is good for sending Morse code.

Does anyone actually use SOS?

I never had to use SOS in practice. But if one day I needed it, sure it will be good to have it in hand. :slight_smile:

Can you imagine an actual event where an emergency worker sees a strobing light, stops, watches it for a while and says - “whelp, I know it’s a blinking light out here where I don’t expect to see one, and I’m a lookin for a missing person, but that ain’t an SOS strobe, so theres no way I’m gonna check it out!”

A flashing light will attract attention. If it happens to be flashing out the current state of the battery, rather than slavishly repeating three dits, three dahs over and over, someone is going to count them and realize there is a pattern. Heck, even amateur radio has done away with Morse code requirements, most people are not going to notice it.

I would personally like to do away with SOS, I don’t minds police strobe, or biking strobe, and I use batt check a lot. SOS just seems like a gimmick.

UI (by Tamagotchi) that very popular in Russian forum.
From off:

sc- short click
lc- long click

1 sc – memored mode , (may be adjusted in menu)
2 sc – transition to turbo and back
3 sc – strobe mode. change of strobe modes by hold.
4 sc – lock – 1 mode (beacon off). Unlocking 4SC.
5 sc – lock – second mode (beacon mode is determined by its settings). Unlocking 4sc.
1 lc – moonlight.
Hold – change modes from the first (red) firefly, than moonlight and then Minimum> Medium 1>Medium 2>Maximum>Minimum>…
1Sc and hold – the battery indication.

from on

1 sc – turn off.
2 sc – transition to a turbo from any mode except the munlay. Repeated 2k – switch to the mode from which the turbo was switched on.
3 sc – the inclusion of strokes. Retrieval of strobe modes with hold.
1 lc – change mode to 1 mode down.
Hold – change modes from the main line up in a circle.
1sc and hold – scrolls down to the minimum mode .

That sounds like a Far Side cartoon!
I’m reminded of a early DX light I had that spelled out SOSOSOSOS.
If you really needed to signal someone you could just run your hand in front of the light and “tap” it out yourself.
To save you extra effort remember that mountaineering distress signals are simply groups of 3. Can be 3 anything, just something that stands out.
The Batt Check would work with a slightly depleted battery if you covered it up for the decimal readings.

“All it says is SSSSSSS, must be someone messing around”.

Awesome, that’s pretty close to what we came up with too, which is a good sign. It seems several people have independently created very similar e-switch UIs with roughly the same basic operation. This tells me it’s probably a genuinely good solution, one of the tallest peaks in the problem space, since people keep creating similar designs.

I wonder why big-name commercial lights are usually so different than this obvious solution.

That sounds more complex that I was expecting. How about if it was done from moonlight (I’m guessing that’s under 20mA in most lights)? Would that make it pretty simple to implement? Overnight moonlight is often useful in these cases too.

Do you think a half-sleep mode would use much less than 5mA?

I’ve actually got one of those mains powered “sunrise clocks” that are supposed to emulate the sun rising to help you wake up in the morning. The technique works (fairly well, at least) but instead of a gradual ramp it jumps up about 10lm of 6500K every minute (to about 100lm). I can imagine something like the D4’s ramp being much nicer. Having it in a flashlight would make it useful for camping and hotels too.

Really, I just want an excuse to buy the equipment needed to flash a driver :stuck_out_tongue:

Have you considered implementing PID algorithm for thermal control?

Copying and quoting from another thread, we have a perfect host for the above described light: The S42. I realize that the uC would need to be changed to an AT of some flavor, but perhaps by giving up in light charging we could gain enough real-estate to get the USB interface to function.

My S42 just sits on my desk at work, begging to be used, but the UI is just prohibitive.

Have you considered looking at the code? :stuck_out_tongue:

But joking aside, a wide range of things fall into the category of “PID algorithms” and it basically already uses one. It just has kind of a weird “I” term implemented as a lowpass or latch on the “D” term. And it’s heavy on the “D” term in order to predict temperature in advance to compensate for lag in measurement.

I’ve been meaning to try a version which uses an actual “I” term of sorts as its primary output, to see if it behaves any better, but I’ve been busy and the testing for thermal stuff always takes a long time.