I have had NarsilM v1.2 on my Q8 for a long time, but now I’ve flashed your new firmware anduril-q8.2018-01-24.hex
and noticed that the e-switch LED is illuminated when the lamp is turned off.
I’ve been playing around like crazy with this new firmware testing “everything” and after that the e-switch LED is no longer lit when the lamp is off.
I couldn’t figure out how to make the e-switch LED lit again while the lamp is off, so I had to re-flash the Q8 again with the same firmware anduril-q8.2018-01-24.hex and now the e-switch is illuminated again when the lamp is turned off.
My question is, how to toggle between e-switch LED behavior?
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.
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?
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.
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.
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.
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.
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.
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.