Maybe. I think I found the code, but I’d have to port it to adopt and translate changes back upstream… which might be difficult without hardware. It’s hard to tell if I broke anything when I can’t test it. I wonder if I could get Fireflies to send me a Nov-Mu for code maintenance purposes.
1 Thank
That sounds like a great idea, but I read they are difficult, with support and communication.
Edit - and I read somewhere that they react better to Facebook messages than to emails. Just read this, I don’t have Facebook.
2 Thanks
Somewhere in my many random branches I have an attempt at porting the fireflylite changes to the latest pre-multichannel version - I’d need to refamiliarise myself with what they changed since IIRC there are a few code changes and not just hwdefs, but it’s definitely possible.
I’ve found they respond to emails reasonably, just that their responses make Hank’s look verbose 
1 Thank
Yes, I find Hanks way to communicate is hard to beat. Quick reaction, few words, spot on comments. 
1 Thank
Yes, in the past was difficult and some people have very bad experience with Jack and FireflyLite, but now you can use a mail and they are a little bit responsive. I solve many problems with @Fireflylite-Ivy.
3 Thanks
I did find a quirk, the voltage reads something like .3V or .4V too high, so I can’t even adjust it in the OFF-3C-2C-7H menu. Readings were good before updating. I did run my headlamp dry, resting voltage read about 2.7-2.9, I don’t remember exactly, but it’s pretty low though for resting voltage.
This reminds me an LVP issue with my boost dm11 (different firmware revision, original single channel branch). I must have forgotten the flashlight on because I found it completely dead and battery voltage read something like 2.3. No problem with voltage reading on that one. I mention this in case maybe it’s a real bug somewhere in the dm11 code… even if I understant that it would be weird that I would be the only one the experience… but I let you be the judge if it’s worth investigating!
EDIT: OHHH I see there’s dm11-boost update on bazaar, I’ll try that tonight or tomorrow. I hadn’t seen the update on toykeeper.net, otherwise I would’ have waited to post.
That’s definitely higher than it should be. The hardware variation is usually within 0.1V, and sometimes as much as 0.15V… but I haven’t heard of a .3V or .4V error before. Very unusual.
FWIW, the voltage calibration menu is Off-3C-7H without the 2C in the middle. It allows adjusting the calibration by +/- 0.3V. It’s in the manual under “voltage config menu”.
That would all be great, but IMHO it would be even better if we could tell at least the revision of an image by looking at its filename and via version blinking…
Now that you mention it, I actually find it a bit of an irritant when I try and use mine in moonlight as the bright voltage display (and in blue!) really ruins my night vision.
I’ve been meaning to delve into the code and have a look on how to turn that off or at least reduce its brightness, specially if the flashlight main LEDs are at low brightness level, but have been pretty busy with RL as of late.
@ToyKeeper, is there a way to do that already, or would it involve changing the code?
Go into voltage check; then 7H, wait for the 2nd buzz, release and do not enter any value. That should turn it off, any clicks would enter the number of seconds the off-voltage will display.
2 Thanks
Did I hallucinate or wasn’t this already implemented? As in, turning off from a low mode will show the voltage momentarily in low mode instead of high. I just think the threshold may have been set at a too low brightness.
2 Thanks
Hi, thanks as always @ToyKeeper for what you do!
Firmware 2023-07-08 probably issues?
• Tactical mode is memorised in strobe mode so strobe mode loose memory
• In every strobe mode if you add the second channel or change the channel it will not memorised after OFF
Cool Features
• If you have Emisar with blue and red, police strobe is so cool!
• Now we can set all RGB colors we want for reading Voltage or Temperature
1 Thank
The first is a known issue that I hope to fix. It modifies the global strobe memory var when using tactical mode, but it should have a cleaner solution.
The second is similar to the first. It’s not really set up right now to change channels per mode, but that probably needs to change.
Both are consequences of building new features on top of code which wasn’t designed for those features.
It would be a simple matter of using a separate variable for tactical mode, no?
If no one’s working on that, I could take a stab at it and send @Toykeeper a patch.
The strobe memory thing currently does this:
- The strobe type is stored in a persistent eeprom variable. The 3H mode group sets this var so it’ll start up in the same mode next time, and the strobe handlers read this var to determine which pattern to display.
- Tactical mode sets this var too, to make sure the strobe handlers display the right pattern. But it overwrites the last-used 3H mode group value in the process.
What it probably should be doing is…
- The active strobe type should be only in RAM. Strobe handlers should read this var to determine which pattern to display.
- The 3H mode group keeps its last-used strobe number in a separate var, in eeprom… and copies it to the RAM-only var when a 3H mode is active.
- Tactical mode would also copy its desired mode to the RAM-only var.
It’s not particularly difficult… I’ve just had too many things to do.
I also need to add an array to hold the desired channel mode for each strobe mode, so it can remember those individually… and also an extra var to remember the default channel mode for regular ramping and other stuff. This should work in much the same way as strobe memory, where it copies the eeprom var to a RAM-only var based on which UI mode the user is in.
… and I might need to make it use different jump-start levels based on which channel mode is active. Maybe. Kinda hoping it won’t be necessary.
… and I need to make sure it doesn’t use unnecessary space on lights with only one channel mode, like pretty much everything with attiny85. Those older lights are still supported.
2 Thanks
…and you need a vacancy 
I am so sorry for disturb you with my request but for me it’s a mission 
1 Thank
Thanks for the very detailed response.
Looks like things are more complicated than I thought at first.
Still willing to try it, if no one is planning to right now.
These are both fixed now.
- Tactical mode does not overwrite the strobe memory any more.
- Each strobe has its own channel memory, so every strobe can be a different color. Ramp mode uses its own channel too, so the strobes don’t interfere.
Additionally, tactical mode’s strobe actually stops now when the user lets go of the button, instead of playing the rest of the animation first.
I’ve only tested on a D4K-3ch so far though. I need to do more testing and make sure other lights still work. The strobe channel memory required changing some stuff in FSM and the hardware definitions, not just Anduril’s UI.
3 Thanks
Thank you so much! I’ll try with the next firmware!
2 Thanks
From the changelog, I presume “Now” means ≥753, right?
I don’t have any multichannel lights to test them with, but I will test them on my TS10 and FC13 and if they seem to work, re-factor my 8C_quick_aux_switch mod and post the binaries.
Thanks again for all your work, TK!