Flashlight Firmware Repository

Flashlight Modding and DIY Parts
1461

I have a ramping UI now with smoothly-user-adjustable strobe with both party and tactical modes, facilitated by cooperative multitasking so it doesn’t interfere with event handling. This should also make it easy to add biking mode, battcheck, SOS, and other slow blinkies.

So, the current test UI is:

From off:

  • 1 click: Go to memorized level.
  • 2 clicks: Go to highest level. (shortcut to turbo)
  • 3 clicks: Strobe mode.
  • Hold: Go to lowest level, wait, then ramp up. (shortcut to moon)
  • Click, hold: Go to highest level then ramp down.

In normal/steady mode:

  • 1 click: Off.
  • 2 clicks: Go to/from highest level (temporary turbo).
  • 3 clicks: Strobe mode.
  • 4 clicks: Toggle between smooth and discrete ramping (150 levels vs 7 levels).
  • Hold: Ramp up.
  • Click, hold: Ramp down.
  • Full thermal regulation is active in this mode.

In strobe mode:

  • 1 click: Off.
  • 2 clicks: Toggle party strobe (freezes motion) vs tactical strobe (bright, disorienting).
  • 3 clicks: Go to normal/steady mode at memorized level.
  • Hold: Increase strobe speed.
  • Click, hold: Decrease strobe speed.
  • Speed range is 3.8 Hz to 120 Hz for party strobe, 2.6 Hz to 82 Hz for tactical strobe.

When voltage is low:

  • If in strobe mode, go to steady mode at a low level.
  • In steady mode, step down by about half the ramp.
  • If already at lowest steady mode, turn off.

After LVP or thermal step-down, ramping goes from the stepped-down level, not from the original level it was at before. So, if it steps down and you want it back up, just hold the button to force it back up. However, it will probably step down again in a few seconds.

Moon and turbo aren’t memorized unless you manually ramp to them.

So far, nothing is remembered across a battery change. I haven’t written the eeprom API yet.

It currently compiles to 3480 bytes, but if I turn off thermal regulation that goes down to 2888 bytes.

1462

Wow you are making some good progress! Sounds good!

1463

… and now there’s an eeprom API too, with and/or without wear-levelling. It splits the total eeprom space into two halves, one for wear-levelled data and one for regular data.

This completes the ZebraLight clone UI. It’s pretty much identical(*) to the SC600 / H600 MkIII UI now. It doesn’t attempt to add anything from ZL’s new UI as used on the SC53, but that looks like it would be pretty easy to do.

With all features included, it compiles to 3982 bytes. It should work on tiny45 and tiny85. It may get a bit bigger later though, as things are added to the toolkit. In particular, I have some ideas to try out for improving the thermal regulation.

* Except I replaced their ridiculous “double-click 6+ times to configure the secondary level” with “click, release, then hold to configure the secondary level”. That particular detail always bugged the crap out of me.

1464

For AS7 users, I fixed library issues but I now face a memory overflow problem (106,6%).
Any ideas?

1465

I pushed an update of RampingIOS.c (D4 firmware) to trunk. It adds support for higher-voltage battery configurations, like 2S/3S/4S. That part of the code wasn’t really functional before.

1466

I have Convoy L6.
With stock driver, is it possible to have ramping firmware?
I would love to have it, if any. :innocent:

Edit: no bother, confirm that the stock driver can’t be flash with ramping firm.

1467

I have built a PD68 Tripledown FET+1+3 driver to use for driving 2 XPL’s on the FET+1 channel and 1 deep red XPE2 on the +3 7135 channel 2 . Could Crescendo be made to work for this?

1468

Crescendo has no concept of multiple emitters, but if you can fit what you want into a single “ramp”, it should work fine. I guess maybe you’d ramp up the red channel, then turn it off and ramp up the white channel?

That doesn’t sound ideal to me, but it’s about as close as Crescendo gets to handling two independent LEDs of different colors.

If you want that, you should only need to edit the ramp tables. However, Bistro is probably somewhat better suited for this sort of thing since it has specific modes and mode groups.

1469

Thanks TK. I’m just trying to figure out if it’d be an option. I’m probably going to wind up with Bistro if I can make it work.

1470

Mode groups should be pretty do-able, but the thermal regulation and LVP may get a little confused depending on how the ramp is set up. They both assume the ramp is only one light source, in ascending order, so if it is configured as two ramps instead, it could do weird things like stepping down from the bottom of one channel to the top of the other channel.

It’s definitely not ideal. It may be enough to be usable, but I don’t have any firmwares which are designed for this sort of thing.

1471

Finally got around to checking back here a little (last few posts at least).

Bistro HD's thermal stepdown code is no longer level based. It is mode based. Specifically though you must define a safe mode to step down to in the modegruops.h file.

This doesn't help LVP stepdown though. Of course almost anything can be done.

actual_level = (actual_level >> 2) + (actual_level >> 1);

Maybe let actual level represent an attenuation instead of a level, and apply it always in set_level. It would probably need to become a global.

1472

If it changed from a user-configured safe temperature to a compiler-configured safe mode, doesn’t that defeat the point of thermal regulation? The idea is to dynamically go down however far it needs to, to stay at a safe temperature.

1473

If you have a light where the default isn't safe, you've modded it very very very heavily, and it's your own concern, and you may want to recompile.

But the attenuation trick could apply to both and I see that it could be applied in a pgm_read_byte macro alternative possibly to avoid doing the bit shifts in three places for three ramps.

1474

Remember the biggest reason for this feature is mas produced lights. Determining a safe level there is especially easy. Anyway, it should work fine even on a Q8 with spring bypasses. Remember also mine is NOT a thermal regulation, it's a thermal safety. It doesn't need to dynamically find the highest mode it can possibly hold. It goes to a reasonable mode that still provides light, quits annoyingly jumping around, and you can tap back up to the original mode when you need. It's just BLFA6 but with the initial step down actually temperature triggered.

1475

One of the popular use cases for bistro is pre-flashed drivers which go in a variety of hosts not known to the person who made the driver. There is a need for making it self-adjust to match the host, since recompiling isn’t an option.

1476

On the bistro modegroups the stepdown level is unspecified, which means it defaults to RAMP_SIZE/2 which is 1 7135 plus a PWM of 11, 5%, of the FET. Find a light where one 7135 and 5% of FET is dangerous and I MIGHT call it bug, BUT I'd probably call that a truly hazardous light instead.. It's impossible to program any firmware that will do anything that anyone might want, and do it well too. This was discussed quite a bit before, including with you, and nobody raised this concern, for the reasons stated. Tom E also said it's very similar to what he is doing.

However, there's a point that all channels attenuation is better than either levels or modes, so I may see about implementing that anyway. That doesn't necessarily solve your complaint, although it could be part of a solution. I just really can't bring myself to care from that angle though. It's just not a valid issue for anything like a normal light, and I'd even be more inclined to lower it to RAMP_SIZE/4 than have poor regulation. If people use this right, they should never actually have it used at all. The temp threshold should be at a level that actually hurts but isn't quite dangerous, and it should never get that hot without the user intervening. The point not being that it's ok if it doesn't work safely, but that it's ok if the step down is set pretty low. I suppose about the weirdest I could see is if someone built a light with like 10 7135s on the "one" channel. I don't even know of any board presently with a pin configuration that makes that possible using bistro. I do know of boards where it's possible using bistro HD. I guess you can fault it for making more crazy things possible.

1477

Hi!!
Sorry if this has been addressed before on this thread!
I have some doubts/questions and I hope you can help me, please! Or please indicate me the right thread(s) for it :wink:

So far, the driver swaps I made in my lights were using drivers with biscotti firmware, bought from Simon. I’m happy with those, but I want to try something different, even not being a “modder” nor a “flasher”.

The lights I want to mod are tail clicky lights - a Convoy S2+ and some 14500 lights -, and I want to try the Crescendo firmware.

I’ve seen the diagram and this UI is pretty much what I like (until getting lights with Narsil or Anduril, probably :D…).
Finding drivers with this UI installed without having to change all the internals of the light is awesome, to try something different!

I’ll probably buy these drivers from MTN:

However, I have some doubts about the firmware and the drivers. I appreciate your help clarifying this to me:

a) how low (in lumens) does the Crescendo on these drivers allow a light to go? Ex: 0.03 lm or 0.2 lm or…?
One of the reasons why I want these is to try to get really LOW illumination levels.

b) being FET drivers, are they “too powerfull” for lights with only 1 emitter (XML2, XPL-HI, XP-G3)? Are they more suitable for lights with multiple emitters?

c) Also, are they suitable to use with batteries like 14500/16340?

I appreciate your help in this, and I’m sorry for the noob questions! I just want to get some lights with nice configurations, practical and useful in the UIs they have!
Thanks again! :+1:

1478

A. It depends, and is somewhat random, but it’s probably around 0.1 to 0.5 lm.

B. If you use a FET, a high-amp cell, and a low-voltage emitter (like XP-E2 red, or 219c), it can easily turn the emitter into smoke. If you use a FET, a high-amp cell, and a higher-voltage emitter (like XP-L HI), it’s usually fine. If you use a FET and a low-amp cell, it may be fine or it may run into issues — the most likely is that the cell’s protection could trip, if it has protection. Or, on a multi-emitter light with low Vf, it could actually overload some unprotected cells.

C. Yes, but smaller cells make it easier to trip protection or overload the cell.

So… try to match the cell to the emitter. Some configurations work well, others don’t. Data is generally available from HKJ for cells, and match/djozz/Texas_Ace for emitters. The emitter Vf curve and cell’s voltage sag curve should meet at a point which is safe for both the emitter and the cell.

None of the above has anything to do with firmware though; it’s all about the hardware.

1479

This is where I get embarrassed :person_facepalming:
Sorry to have asked here, and thanks for all your clear explanations! :slight_smile:

A - Nice, that range is fine, with 0.1-0.5 at lowest levels!
B & C - Probably will use XPL-HI with some of these: Aspire IMR18350; Samsung 30Q; Sony VTC6; Sanyo UR14500P. Gotta check the emitters data, though! I don’t have multi-emitter lights to use, I would only make one if these drivers were not suitable for single emitters!

Thanks again for the explanation TK!! It helped me understand a lot more than just about the drivers or firmware :wink:

1480

If anyone has successfully run level_calc.py in Windows please see my post here: