E-switch UI Development / FSM

1024 posts / 0 new
Last post
Agro
Agro's picture
Offline
Last seen: 1 month 17 hours ago
Joined: 05/14/2017 - 11:16
Posts: 6801
Location: Ślōnsk

TK, why is DEFAULT_THERM_CEIL defined per-UI?
Shouldn’t it depend on hardware instead?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 50 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

It could be defined per-hardware instead of per-UI. Hasn’t really come up before. It’s intended to be a value that the app/UI code can use to tweak behavior of the library.

Also, there isn’t really a per-host hardware definition concept. FSM’s hardware definitions are more about the driver type than about the host or emitters.

Mostly, there hasn’t been a need yet.

Agro
Agro's picture
Offline
Last seen: 1 month 17 hours ago
Joined: 05/14/2017 - 11:16
Posts: 6801
Location: Ślōnsk

I tried compiling FSM.
It doesn’t have a makefile, weird. OK, I wrote one. But then it lacks system includes.
I see no mention of the compilation process in spaghetti-monster.txt.
TK, how should I compile it?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 50 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

Nearly every project had the exact same Makefile, so I converted things to a build script per MCU type. Here’s what I do to build and flash it:

> cd ToyKeeper/spaghetti-monster/anduril
> ../../../bin/build-85.sh anduril
avr-gcc -Wall -g -Os -mmcu=attiny85 -c -std=gnu99 -DATTINY=85 -I.. -I../.. -I../../.. -o anduril.o -c anduril.c
avr-gcc -Wall -g -Os -mmcu=attiny85 -o anduril.elf anduril.o
avr-objcopy --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0 --no-change-warnings -O ihex anduril.elf anduril.hex
Program:    7372 bytes (90.0% Full)
Data:        288 bytes (56.2% Full)
> ../../../bin/flash-85.sh anduril.hex
Agro
Agro's picture
Offline
Last seen: 1 month 17 hours ago
Joined: 05/14/2017 - 11:16
Posts: 6801
Location: Ślōnsk

Thanks, I managed to compile it now. Though these scripts use some avr-size extensions from Win-AVR, I had to remove -C and —mcu. And the following grep.

Agro
Agro's picture
Offline
Last seen: 1 month 17 hours ago
Joined: 05/14/2017 - 11:16
Posts: 6801
Location: Ślōnsk

BTW, have you considered refactoring temperature control out of the UI code?
The way it is now all UIs have to duplicate it.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 50 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

I think, conceptually, the UI code is probably the right place to handle signals like “low voltage” and “overheating”. However, it might be nice to put the details into a shared file so it doesn’t need to be duplicated.

The base library will probably make bad choices if it tries to handle those conditions with no knowledge of what the UI is doing. Like, low voltage in strobe mode or beacon mode probably requires different handling than a steady output mode. Or, overheating in candle mode, it’ll need to modify the UI’s internal variables in order to get dimmer, since it’s constantly changing brightness. Otherwise the candle algorithm would clobber the thermal algorithm.

So I don’t have a good and clean solution yet.

Agro
Agro's picture
Offline
Last seen: 1 month 17 hours ago
Joined: 05/14/2017 - 11:16
Posts: 6801
Location: Ślōnsk

ToyKeeper wrote:
I think, conceptually, the UI code is probably the right place to handle signals like “low voltage” and “overheating”. However, it might be nice to put the details into a shared file so it doesn’t need to be duplicated.

The base library will probably make bad choices if it tries to handle those conditions with no knowledge of what the UI is doing. Like, low voltage in strobe mode or beacon mode probably requires different handling than a steady output mode. Or, overheating in candle mode, it’ll need to modify the UI’s internal variables in order to get dimmer, since it’s constantly changing brightness. Otherwise the candle algorithm would clobber the thermal algorithm.

So I don’t have a good and clean solution yet.

I don’t think UI should do thermal regulation. The way I see it is that UI constantly changes the desired brightness. But the actual brightness would be decided elsewhere.

UI would still need to be notified about:

  • the fact that overheating started or stopped
  • the current output ceiling
  • (?) that output ceiling changed

It would also make writing UIs easier. Forgetting about things like “I should be careful entering strobe if I’m overheating” would not lead to the light being overheated in any case. Unless UI forces something like #define NO_THERMAL_CONTROL.

As to low-voltage…I’m not sure if this is the same or different than high-temperature. It is quite unusual for UI to purposefully disable thermal regulation and allow the light to overheat. However never-leave-in-the-dark logic makes as much sense as a hard limit to protect battery from inexperienced hands.
I’m leaning to thinking that it would be best to do a PID controller that tries to keep voltage above the set floor, fluidly dimming down (or brightening up, f.e. when battery warmed up to above-freezing), just like thermal regulation. With either shutoff or not when further regulation is not possible. So it would be quite similar to thermal control when it comes to interaction with UI.

Agro
Agro's picture
Offline
Last seen: 1 month 17 hours ago
Joined: 05/14/2017 - 11:16
Posts: 6801
Location: Ślōnsk

BTW there’s one low-voltage protection that I’ve never seen implemented.
When you can’t regulate down anymore, turn off. But just once. If the light is turned on again, keep working.
It will protect the battery in case of accidental activation. And will act as a signal that nothing more can be done to maintain battery life.
Certainly not muggle proof, a muggle will turn it on and think it was a malfunction.
And this is not the best way to signal low-battery as it may turn off in a bad moment, f.e. during a difficult crossing.
And the best way to protect from accidental activation is to make sure such activation doesn’t happen.
So it may make no sense. But I wanted to show the idea in case someone thinks it’s actually useful. Or gets inspired to make it actually useful.

goshdogit
goshdogit's picture
Online
Last seen: 6 min 13 sec ago
Joined: 12/03/2015 - 21:28
Posts: 1370

Hi, ToyKeeper! You mentioned in the FW3A thread that you’ve implemented muggle mode into Andúril.

Is this latest Andúril version ready for release to the firmware depository? I’m itching for muggle mode and candle mode with a timer. Big Smile

Thanks again for all your hard work! Thumbs Up

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 50 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

Candle timer doesn’t exist yet. Smooth ramp muggle mode works, but it needs more testing. It still feels a bit unfinished. The config mode changes need more testing too, since that got completely rewritten to save space.

If you want to try it anyway, I can publish the recent changes. It has a relatively high risk of bugs at the moment though.

Mostly, I’ve been feeling the need to rearrange the code to make it cleaner, but that’s always a high risk sort of change. And in this case, it might make the compiled code bigger. The strobes (including candle) are kind of a mess and I haven’t found a good way to untangle it yet.

goshdogit
goshdogit's picture
Online
Last seen: 6 min 13 sec ago
Joined: 12/03/2015 - 21:28
Posts: 1370

ToyKeeper wrote:
Mostly, I’ve been feeling the need to rearrange the code to make it cleaner, but that’s always a high risk sort of change.
That sounds like quite a task!

I’ll gladly reflash a Q8 and help with bug hunting if/when a major rewrite happens. Smile

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 50 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

Okay, I got Anduril (and FSM) working on the BLF GT. Here are the latest builds:

The GT build doesn’t always work in party strobe mode, due to the buck driver wanting pulses longer than 1ms, but I didn’t notice any other issues yet.

The UI diagram is updated too, showing that muggle mode can be exited with 6 clicks. The various config modes also moved to 4 clicks for consistency.

goshdogit
goshdogit's picture
Online
Last seen: 6 min 13 sec ago
Joined: 12/03/2015 - 21:28
Posts: 1370

ToyKeeper wrote:
Okay, I got Anduril (and FSM) working on the BLF GT.
Thank you, ToyKeeper!

The GT is my ninth flashlight running Andúril. Party

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 50 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

Does the new muggle mode seem okay? People voted for a simplified smooth ramp, so that’s what it does.

I’m also hunting for any other bugs which might pop up.

goshdogit
goshdogit's picture
Online
Last seen: 6 min 13 sec ago
Joined: 12/03/2015 - 21:28
Posts: 1370

ToyKeeper wrote:
Does the new muggle mode seem okay?
Seems great so far. I voted ‘smooth ramp,’ so I’m quite pleased. Smile

ToyKeeper wrote:
I’m also hunting for any other bugs which might pop up.
I’ll update my Q8s and do some bug hunting. They’ll get some extensive use this weekend, so I’ll let you know if I find anything.
TUNE4IT
Offline
Last seen: 7 months 1 day ago
Joined: 01/26/2018 - 08:20
Posts: 16
Location: Netherlands

I really like the smooth ramping muggle mode. (Even though I voted for baton style, which i still think is easier to use and probably uses less space on the attiny)

I first tested it on the blf q8 since it comes apart so easily Smile

However, on the q8 the output does have a sort of bump in the middle of the ramp and it seems te be a bit jittery. Not as smooth as the main ramp. But I guess this is probably to reduce the size of the mode?
Also I noticed there is no click, hold to lower the output. It is more like hold , hold to lower the output. Perhaps this can be the same as the main ramp.
And finaly the ‘waiting time’ in muggle mode when you hold the button from off and the light starts to ramp seems to differ, but this can also be just me.

The four-click config modes is nice to have some more consistancy, though it will take a few days to get used to. LOL
The best thing in my opinion is the 6 clicks to exit, it happened way to often I lend a flashlight in muggle mode only for one person the unscrew the battery compartment and not understanding a thing how the light works.
The indicator led is also exactly how it should be in muggle mode; flashlight off, indicator led off. No questions why the led is on when the lamp is off.

goshdogit
goshdogit's picture
Online
Last seen: 6 min 13 sec ago
Joined: 12/03/2015 - 21:28
Posts: 1370

TK, are the files in the depository up to date for building this latest version of Andúril? The dates seem to indicate so, but I wanted to double-check.

I like to disable boundary blinks and lower the value for HOLD_TIMEOUT.

ToyKeeper wrote:
Anyway, I just wrapped the definitions of HOLD_TIMEOUT and RELEASE_TIMEOUT to make them definable from the UI code instead of having to dive into headers. So, after this update is pushed, just stick an extra line in the main UI file and it’ll override the toolkit’s defaults.
Does this still apply to the latest version?
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 50 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

The repository files should be up to date, and the HOLD_TIMEOUT thing should still work.

I’ll probably merge the branch into trunk soon too, since it’s reasonably stable.

Aside from the limited range and slower speed, differences from the main ramp are there to reduce code size. The smooth ramp is, unfortunately, the largest of the muggle mode styles… and I still want to add some other things before the FW3A release.

TUNE4IT
Offline
Last seen: 7 months 1 day ago
Joined: 01/26/2018 - 08:20
Posts: 16
Location: Netherlands

That’s what i thought unfortunately. Maybe i’ll try to edit muggle mode to a baton style mode, however I have no programming skills so that might take a while.

goshdogit
goshdogit's picture
Online
Last seen: 6 min 13 sec ago
Joined: 12/03/2015 - 21:28
Posts: 1370

ToyKeeper wrote:
The repository files should be up to date, and the HOLD_TIMEOUT thing should still work.
Thanks! I successfully built GT and Q8 Andúril hex files without boundary blinks and HOLD_TIMEOUT set to 17. I reflashed three Q8s and my GT. Thumbs Up

I’ll wait for timed candle mode and your other changes before digging the drivers out of my Emisars. I tried to build a hex for them anyway, but got a bunch of errors. FWIW, I was able to build one for FW3A drivers without issue.

I know you don’t use Atmel Studio, but I thought someone might have some idea what is causing these:

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 50 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

That looks like the driver definition line was omitted or misspelled. Check the area which says:

#define FSM_EMISAR_D4_DRIVER

goshdogit
goshdogit's picture
Online
Last seen: 6 min 13 sec ago
Joined: 12/03/2015 - 21:28
Posts: 1370

Thanks, you’re right! When I deleted the slashes, I accidentally got the hash too. Smile

Lexel
Lexel's picture
Offline
Last seen: 10 months 2 weeks ago
Joined: 11/01/2016 - 08:00
Posts: 5895
Location: Germany

ToyKeeper wrote:
Okay, I got Anduril (and FSM) working on the BLF GT. Here are the latest builds:

The GT build doesn’t always work in party strobe mode, due to the buck driver wanting pulses longer than 1ms, but I didn’t notice any other issues yet.

The UI diagram is updated too, showing that muggle mode can be exited with 6 clicks. The various config modes also moved to 4 clicks for consistency.

I had recently requests for my drivers for GT Anduril, is it possible to get the whole Atmel Studio 7 files for GT Anduril?

goshdogit
goshdogit's picture
Online
Last seen: 6 min 13 sec ago
Joined: 12/03/2015 - 21:28
Posts: 1370

Lexel wrote:
is it possible to get the whole Atmel Studio 7 files for GT Anduril?
Lexel, here’s what I do to build an Andúril .hex file in Atmel Studio.

You’ll need to download files from three folders on TK’s flashlight firmware depository.

Download the Anduril.c file from this folder.

Download 21 .c and .h files from this folder.

Download 5 .h files from this folder.

You should now be able to paste the code from Anduril.c into a new Atmel Studio Project. Place the other 26 .c and .h files in the project’s folder.

Set the driver type by removing the “//” from the “//#define FSM_BLF_GT_DRIVER” line. Add “//” to the other driver type lines.

Add a line “#define ATTINY 85” to specify the MCU model.

Make any other changes to the user-configurable options, such as blinks at the boundaries and ramp floor and ceiling.

Build and flash the .hex file.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 50 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

I took some time today to add the “votive candle” mode (candle mode timer). It’s off by default, meaning candle mode will go until it’s manually shut off or LVP activates… but the user can click 3 times to turn on the timer and add ~30 minutes. Click 3 times again to add another 30 minutes, and so on. The maximum time it can handle is about 4.5 hours.

For most of that time, it’ll run normally. However, for the final minute or so, it’ll gradually dim, sputter, and then shut off.

The UI diagram has been updated too.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 50 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

If anyone wants to test the candle timer but doesn’t want to wait 30 minutes each time, the part to tweak is the value of MINUTES_PER_CANDLE_HALFHOUR. Set that to like… 2. And then each test should take less than 3 minutes. Smile

The timing is a bit wonky because I used a power of two as the base unit of time, which didn’t line up evenly with human-friendly minutes. This helps reduce code size and improve consistency when the clock tick counter rolls over, but it also makes “30 minutes, exactly” unattainable. I think the current behavior takes about 31 minutes per triple-click “bump”.

goshdogit
goshdogit's picture
Online
Last seen: 6 min 13 sec ago
Joined: 12/03/2015 - 21:28
Posts: 1370

I reflashed a Q8 to try votive candle mode, and it works great! It burned for about 29 minutes.

I was excited to reflash several other lights, but managed to launch my flashing rig off the desk and break a few of the soldered connections to the SOIC clip. I’ll fix it tomorrow. Big Smile

I’ll be using timed candle mode on the nightstand and hanging near my hammock during camping trips.

Thanks for the continued improvement, TK! You really do spoil us. Thumbs Up

ZozzV6
ZozzV6's picture
Offline
Last seen: 1 month 3 weeks ago
Joined: 03/24/2016 - 12:19
Posts: 2427
Location: Near to my soldering iron.

TK can you make turbo level setting like ramp max implemented? I have a Skilhunt DS10 but for that size of flashlight and for 2A protertion tripping 16340 battery I want to set turbo under 2A curent a bit and ramp max to 0,6A as that is he stock max current for that light. It will be useful for low forward voltage leds or smaller hosts not to heat up real quick in turbo.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 4 hours 50 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

Zozz, you can achieve that effect by changing the values in the ramp table. Basically, cut the FET values in half or something. Maybe even calculate a new ramp with level_calc.py if the shape doesn’t look right. Or use a driver with only 7135 chips and no FET.

It can’t reliably control current on a FET though, so it’ll take trial and error to get things working at the desired level.

Pages