E-switch UI Development / FSM

212 posts / 0 new
Last post
Flashy Mike
Flashy Mike's picture
Offline
Last seen: 5 hours 23 min ago
Joined: 01/14/2016 - 16:38
Posts: 753
Location: Germany

Tom E wrote:

This is great news btw! Sorry, haven’t been following the progress but it sounds all good. Are you using PWM’s to control the brightness? If so, is it the same typical rate, ~15K?

TK might have used the internal pullup resistor.
LightRider
LightRider's picture
Offline
Last seen: 57 min 34 sec ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA
Tom E wrote:

This is great news btw! Sorry, haven’t been following the progress but it sounds all good. Are you using PWM’s to control the brightness? If so, is it the same typical rate, ~15K?


Have you considered or looked at external temp sensor support? Are you having the same issue of I/O pin shortages or have you looked at I/O pin sharing as Mike C has done? I really think for us to take the next step, we need to look at the 16 KB Atmel with greater I/O pin counts – this would solve a bunch of road blocks I’m having. We just need to team up with a board designer and come up with an easy way to dnld the firmware to one of these MCU’s. Couple options there – not difficult to do, takes some extra real estate, but we also save real estate because of the smaller foot print of these MCU’s, if we go with the square 5×5×5×5 configuration.


From this chart: https://en.wikipedia.org/wiki/Atmel_AVR_ATtiny_comparison_chart


best option seems to be the 1634, pricing/package options here: https://www.arrow.com/en/products/search?q=attiny1634


 


 


 

+1
Tom, if you and TK decide on the next MCU and adapt the firmware, I believe the rest of us will follow and jump on board very quickly. I say just go for it! (On your spare time that is) Wink

goshdogit
goshdogit's picture
Offline
Last seen: 2 hours 15 min ago
Joined: 12/03/2015 - 21:28
Posts: 400

ToyKeeper wrote:
I got a Q8 in the mail today…
Finally! Party You had a long wait.

ToyKeeper wrote:
Anduril now has indicator LED support.
Awesome! I just reflashed three Q8s to play with this evening.

How about a third setting to select indicator high/low/off when the main emitters are on?

What HOLD_TIMEOUT value are you using on your Q8? I’m still using 15 without issue.

ZozzV6
ZozzV6's picture
Offline
Last seen: 1 hour 6 min ago
Joined: 03/24/2016 - 12:19
Posts: 996
Location: Near to my soldering iron.

Is the low brightness barely visible or it depends on led forward voltage ? Or with a higher resistor on switch board I can lower the brightness more?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 10 min ago
Joined: 01/12/2013 - 14:40
Posts: 6400
Location: (469219) 2016 HO3
Tom E wrote:
Are you using PWM’s to control the brightness?

No, I set the pin as input for “low” mode. Same trick I used in Ferrero Rocher.

Tom E wrote:
Have you considered or looked at external temp sensor support? Are you having the same issue of I/O pin shortages or have you looked at I/O pin sharing as Mike C has done?

I haven’t really looked into external sensor support, but I’ve tried to structure code in a way which would make it easy to change between internal and external. Pin shortages haven’t been an issue yet but they probably will be in the near future. ROM space hasn’t been an issue yet either, but again, it probably will be.

If I recall correctly, we’re mostly waiting on toolchain support before going to newer MCUs.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 10 min ago
Joined: 01/12/2013 - 14:40
Posts: 6400
Location: (469219) 2016 HO3

goshdogit wrote:
How about a third setting to select indicator high/low/off when the main emitters are on?

What HOLD_TIMEOUT value are you using on your Q8? I’m still using 15 without issue.

I haven’t changed the default HOLD_TIMEOUT. I think the current value is probably pretty close to Goldilocks for the population average, but I’m kinda guessing.

Instead of high/low/off while the main emitters are on, how about a slightly different approach? Set indicator brightness based on main emitter brightness — “low” for moon to 7135, “high” for 7135 to turbo, “off” while main emitter is off? I just tried this on mine, and it seems to work reasonably well. It automatically stays in sync with the main emitters, it eliminates the need for a mid-ramp blink, and it can still be set independently for the two “off” modes (off and lockout).

ZozzV6 wrote:
Is the low brightness barely visible …?

No, it’s still fairly bright. It’s about 1/3rd as much power.

ZozzV6
ZozzV6's picture
Offline
Last seen: 1 hour 6 min ago
Joined: 03/24/2016 - 12:19
Posts: 996
Location: Near to my soldering iron.
ToyKeeper wrote:
ZozzV6 wrote:
Is the low brightness barely visible …?

No, it’s still fairly bright. It’s about 1/3rd as much power.


Hmm I want high as bright as original with narsil and a very low that I don’t see in daylight just in complete darkness. But still great option. Maybe If I change the switch board led resistor to set low mode low enough for me the high will be bright enough for daylight.
LightRider
LightRider's picture
Offline
Last seen: 57 min 34 sec ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA

Anyone know what is the cause of this error?

avrdude verification error first mismatch at byte 0×0000
0×00 != 0xa0 content mismatch

I successfully flashing the MCU with Narsil. I then tested the driver and it worked. I changed one line of code built a new hex file and tried to reflash the driver but received the error above. I then tried ti flash the first hex file but received the same error.

I’m about to flash a new MCU, but before I do I am hoping for some feedback as I ended up rendering the last MCU unresponsive after several reflashing attempts.

I know this isn’t the best spot for this but I don’t get much response from the Narsil page. I don’t think a lot of able people follow that thread other than tom and he is a busy man. I always feel bad trying to get his attention. Anyway… TMI Smile

goshdogit
goshdogit's picture
Offline
Last seen: 2 hours 15 min ago
Joined: 12/03/2015 - 21:28
Posts: 400

ToyKeeper wrote:
Instead of high/low/off while the main emitters are on, how about a slightly different approach? Set indicator brightness based on main emitter brightness — “low” for moon to 7135, “high” for 7135 to turbo, “off” while main emitter is off? I just tried this on mine, and it seems to work reasonably well.
Clever!

Can we still have an ‘always off when main emitters are on’ option?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 10 min ago
Joined: 01/12/2013 - 14:40
Posts: 6400
Location: (469219) 2016 HO3

LightRider wrote:
Anyone know what is the cause of this error?

avrdude verification error first mismatch at byte 0×0000
0×00 != 0xa0 content mismatch

It usually means a physical issue with the SOIC8 clip connection or how it’s wired. You can probably just carefully re-clip it and try again.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 10 min ago
Joined: 01/12/2013 - 14:40
Posts: 6400
Location: (469219) 2016 HO3
goshdogit wrote:
Can we still have an ‘always off when main emitters are on’ option?

Perhaps.

For now, it just syncs the indicator to the main emitters. An option to control what it does during use would be a good idea though, since “stay off” seems to be a pretty common thing people want. Not sure where to put it though, unless I add another explicit config mode somewhere.

I haven’t done it yet, but it looks like the Q8 needs a different ramp than the D4. I was hoping they’d be close enough to use the same values, but the ramp on my Q8 looks pretty not-linear with FSM. The mid-ramp elbow is pretty noticeable. I did at least make it use a different voltage adjustment factor for Q8 though, so battcheck should be closer to accurate.

I also need to fix thermal regulation again, since the last time I tried it on a D4 I got weird results. It’s probably okay on a Q8 due to its extra mass, but that needs testing too.

There’s also the blinking indicator thing to add, and maybe an alarm clock function, which both need a half-sleep mode. And perhaps a goodnight config mode. Maybe change “goodnight” to “sunset”, and “alarm clock” to “sunrise”. And perhaps a super-simple muggle mode (and muggle config mode to set safe limits).

With all that, I might actually run out of space. It still has about 1000 bytes left, but space is definitely starting to become a concern. Maybe I can refactor the existing config modes into a single common function — same UI but smaller code.

Kinda just thinking out loud here.

Oh, and one of Dale’s Q8s was acting up; sounds like an extra-noisy switch or something. That could probably use some attention. I have some theories, but can’t test them with my hardware because it’s not misbehaving that way.

And I was doing some “bump testing” to see how the Q8 reacts to being hit during use, and a couple times I managed to get it into a state where it wouldn’t respond… and afterward once it acted like eeprom had gotten slightly corrupted (it had an invalid ramp floor setting, which made a couple things act weird). Not sure what I can do about that.

goshdogit
goshdogit's picture
Offline
Last seen: 2 hours 15 min ago
Joined: 12/03/2015 - 21:28
Posts: 400

More improvements?! You really do spoil us, TK.

I update Andúril on my Q8s whenever you announce a revision since they’re so easy to open and reflash.

ToyKeeper wrote:
I also need to fix thermal regulation again…
Will there be a compile-time option to configure thermal regulation for different lights? I’m running Andúril on my D1, D4, and X6R, too.

ToyKeeper wrote:
And I was doing some “bump testing” to see how the Q8 reacts to being hit during use, and a couple times I managed to get it into a state where it wouldn’t respond… and afterward once it acted like eeprom had gotten slightly corrupted (it had an invalid ramp floor setting, which made a couple things act weird).
Did this require reflashing to fix?

I don’t purposely bump my lights looking for an issue, but even with occasional drops I’ve not encountered a power-interrupt with any lights.

I’ve yet to drop a Q8 though. Big Smile

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 10 min ago
Joined: 01/12/2013 - 14:40
Posts: 6400
Location: (469219) 2016 HO3

I haven’t really found that different thermal regulation parameters are needed for different lights. In general, if it works on a D4-219c, it pretty much works on everything else too — especially bigger lights which hardly even need regulation. Or at least that’s what I’ve found so far. But getting it to behave well on a D4 has been tricky.

The weird bump-test result didn’t require reflashing, but I did have to set the ramp floor again in config mode. It could also be avoided by verifying the values at boot, but that takes extra bytes I prefer not to spend if possible. Instead, it just verifies a single header value and assumes all the following values are okay.

I’ll have to see if I can make it happen again, because it occurs to me that I didn’t try doing a full power cycle first. It may have simply loaded a bad value, rather than actually having bad data in eeprom.

ZozzV6
ZozzV6's picture
Offline
Last seen: 1 hour 6 min ago
Joined: 03/24/2016 - 12:19
Posts: 996
Location: Near to my soldering iron.

I had problems with my laptop compiling anything and I have to ask somebody a favor! I want to build an L6 with Texas avenger 30mm LDO 3 channel driver and with XHP70.2 led with 2S battery setup. I like to use indicator led in the side switch. For the indicator I sacrifice the middle output channel so remove the Nx7135-s from the battery side and use their MCU output pin as the indicator led. Can someone make a hex file for me for this setup from the newest Andúril firmware? I will be greatly appreciated!
Thank You!

joechina
Offline
Last seen: 5 hours 19 min ago
Joined: 03/05/2016 - 08:23
Posts: 561

TK:
An Idea for SMOOTH and DISCRETE
To switch between SMOOTH and DISCRETE you use 3 clicks.
I don’t know if you indicate the state to the user.

To show the user what he is using the main LED does this:
SMOOTH:
It dims from low to a brighter level and back down to low. Within one second or quicker. Like a single dragon breath from Manker Lamps.
DISCRETE:
It goes through three brightness​ steps within a second. Sth. like Low Mid High

wuuHOOuuu vs. TickTickTick

When you add a mogle mode you can use another 3 clicks and blink out eg. low high low high or another sequence.
So you can cycle through SMOOTH, DISCRETE and MOGLE MODE.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 10 min ago
Joined: 01/12/2013 - 14:40
Posts: 6400
Location: (469219) 2016 HO3

joechina wrote:
TK:
An Idea for SMOOTH and DISCRETE
To switch between SMOOTH and DISCRETE you use 3 clicks.
I don’t know if you indicate the state to the user.

To show the user what he is using the main LED does this:
SMOOTH:
It dims from low to a brighter level and back down to low. Within one second or quicker. Like a single dragon breath from Manker Lamps.
DISCRETE:
It goes through three brightness​ steps within a second. Sth. like Low Mid High

It blinks off and back on quickly to indicate that something happened… and if it’s going from smooth to discrete it’ll also jump to the nearest stair step. But otherwise it doesn’t attempt to indicate what happened.

Adding a detailed indication would require creating an asynchronous feedback system of some sort. It’s not terribly difficult, but it does expose the code to an entire new class of bugs. For example, Narsil does async feedback to indicate which power channel is being used, and if the user clicks during the feedback it can have side effects like turning the indicator LED off. It happens because there are multiple different logic threads fighting simultaneously for control over a shared resource.

Originally this was considered a bug because it wasn’t implemented on purpose, but Tom left it that way because he liked it. Not all interactions of this type are going to be beneficial though… and I’ve tried to avoid making it even possible. However, I think it should be reasonably safe, due to the way events and tasks are scheduled in FSM instead of running immediately. I haven’t tested, but I think the worst effects would be to delay things like state changes until the feedback animation has completed. Or possibly to interrupt the animation, depending on how it’s implemented.

joechina wrote:
So you can cycle through SMOOTH, DISCRETE and MOGLE MODE.

I don’t think it’d be a good idea to include muggle mode in the cycle. Muggle mode is intended as a one-way trip, a state you can put a light in before handing it to someone who doesn’t know much about it, and they hopefully won’t be able to exit muggle mode by accident.

joechina
Offline
Last seen: 5 hours 19 min ago
Joined: 03/05/2016 - 08:23
Posts: 561

So the safest way to end mogle mode would be disconnect from power?

ZozzV6
ZozzV6's picture
Offline
Last seen: 1 hour 6 min ago
Joined: 03/24/2016 - 12:19
Posts: 996
Location: Near to my soldering iron.

I think a battery disconnect can happen in a muggle hand. But a click, click, click, hold or some combination not happen offten.

joechina
Offline
Last seen: 5 hours 19 min ago
Joined: 03/05/2016 - 08:23
Posts: 561

In a few years we need lamps with a projector LED so we can project a UI diagramm on the ground.
Smile

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 10 min ago
Joined: 01/12/2013 - 14:40
Posts: 6400
Location: (469219) 2016 HO3

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”.

Agro
Offline
Last seen: 11 hours 2 min ago
Joined: 05/14/2017 - 11:16
Posts: 903
Location: Ślōnsk

What would it take to support the Schoki’s MP3431 driver ?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 10 min ago
Joined: 01/12/2013 - 14:40
Posts: 6400
Location: (469219) 2016 HO3
Agro wrote:
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:

Schoki wrote:
The 85 isn’t available in a package small enough to fit the underside of the board, I need 3×3mm, even 4×4mm is too big.

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.

Agro
Offline
Last seen: 11 hours 2 min ago
Joined: 05/14/2017 - 11:16
Posts: 903
Location: Ślōnsk
ToyKeeper wrote:
Agro wrote:
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:

Schoki wrote:
The 85 isn’t available in a package small enough to fit the underside of the board, I need 3×3mm, even 4×4mm is too big.

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 4×4 MCU and ATTiny85 should fit.
I wonder about the OTSM discussion that I don’t understand… Blushing
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 10 min ago
Joined: 01/12/2013 - 14:40
Posts: 6400
Location: (469219) 2016 HO3

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.

Agro
Offline
Last seen: 11 hours 2 min ago
Joined: 05/14/2017 - 11:16
Posts: 903
Location: Ślōnsk

Glad to read that. Smile

laythaws
Offline
Last seen: 3 days 3 hours ago
Joined: 01/15/2015 - 00:57
Posts: 104
Location: Location::Location::

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?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 10 min ago
Joined: 01/12/2013 - 14:40
Posts: 6400
Location: (469219) 2016 HO3
laythaws wrote:
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.

ZozzV6
ZozzV6's picture
Offline
Last seen: 1 hour 6 min ago
Joined: 03/24/2016 - 12:19
Posts: 996
Location: Near to my soldering iron.

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.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 10 min ago
Joined: 01/12/2013 - 14:40
Posts: 6400
Location: (469219) 2016 HO3
ZozzV6 wrote:
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.

oto
Offline
Last seen: 1 day 14 hours ago
Joined: 01/05/2017 - 09:30
Posts: 63

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.

Pages