Flashlight Firmware Repository

per cell is OK
I was asking if it is possible on a boost driver that it can do LVP and voltage readout for 1S and 2S with one firmware
right now its only 1S or 2S, but many driver support 1 and 2S or NimH and Lithium

The light can’t really tell what you’re doing with the button. It only knows that it’s currently connected to power, and can also sense at boot time whether the previous disconnection was short or long. So it’s intended for use with a reverse clicky because that type of switch makes short disconnections easy from a latched “on” state.

With a reverse clicky, if the light is off, the first “tap” will need to be a full click because a half-press does nothing in that state. Otherwise, all “taps” are quick half-presses.

It’s also possible to do a long half-press to reset the light to the “off” state. In that case, the next “tap” is merely “release the button”.

That’s much trickier. For 1S with li-ion, we can use a shortcut to measure voltage — connect the battery directly to GND and VCC, and measure the voltage directly from the power supply. But for other designs the driver needs stabilized VCC plus another pin to measure battery voltage through a divider or similar.

It’s not so bad if the different supported power sources have non-overlapping ranges. For example:

  • 2.6V to 4.4V for 1xLi-Ion
  • 5.2V to 8.8V for 2xLi-Ion
  • … and nothing else

It can tell what type of battery configuration it’s using based on which of the two ranges the measurements are in. 1S has ADC values of 66 to 112, or 2S has ADC values of 132 to 224.

When it gets difficult is if the driver wants to support LVP on power sources with overlapping ranges, like 16340 and CR123A. One gets about 2.6V to 4.4V, while the other does roughly 1.0V to 3.6V. Or to make it an omnivore with swappable battery tubes, it may need to tell the difference between:

  • 0.9V … 1.8V: 1xNiMH, 1xAlkaline, 1xLithium
  • 1.0V … 3.6V: 1xCR123A
  • 1.8V … 3.6V: 2xNiMH, 2xAlkaline, 2xLithium
  • 2.0V … 7.2V: 2xCR123A
  • 2.6V … 4.4V: 1xLi-Ion
  • 2.7V … 5.4V: 3xNiMH, 3xAlkaline, 3xLithium
  • 2.8V … 3.6V: 1xLiFePo4
  • 3.0V … 10.8V: 3xCR123A
  • 5.2V … 8.8V: 2xLi-Ion
  • 5.6V … 7.2V: 2xLiFePo4
  • 7.8V … 13.2V: 3xLi-Ion
  • 8.4V … 10.8V: 3xLiFePo4

If it needs to be a true omnivore, I’d probably get rid of LVP and make it display raw voltage, relying on the user to decide what counts as “low”.

I want just plain 1S/2S of 3.7V normal lithium batteries, no CR123 or LiFe support integrated into Narsil
if 3S would work as well would be a bonus
Not sure if that can be done on Bistro OTSM as well

OK thanks for confirming and the info.

I have a question . A friend wants me to Mod his Lumintop Copper Tool. Is there a diy driver like the one in this flashlight (3rd gen Reylight Ti LANs are up on Kickstarter) available? One that can work with 1,5V up to 4,2.
If not is there a option to flash ToyKeepers ramping for clickys Firmware on the MTN-10DD? If i uderstand it right the firmware is very similar to Narsil. And i really like the ui.
And do anybody know if it is possible to use the E-Switch from the Lumintop Tool Ti with any Mod driver like the MTN-10DD?

There’s a lack of NiMH drivers and dual-voltage drivers, particularly in such a small size. I haven’t even tried to mod a 1xAAA light though.

My ramping-for-clickies firmware is Crescendo. It’s similar to Narsil in the sense that both have ramping and some blinkies, but otherwise it’s pretty different. Their interfaces don’t have much in common.

Thanks!
What MCU do i need for Crescendo? The MTN-10DD runs on a 13a MMU.
A dual-Voltage driver would be prefered but i give up on that. I searched for hours and found nothing small enough. But i am also not 100% happy with the MTN-10DD. I would like to get the MTN-10DD with two 7135 chips instead of the FET. With this mod i am not trying to get the most power out of the light. 700mA for ~300lumen out of a XP-G3 S5 would be perfect and would give my friend a decent runtime in low levels with the Efest 10440. Even on High he should get ~30min of runtime. And i think/hope that the light will not get to hot at 700mA.

Anyone with knowledge about the Tool Ti E-Switch? Compatibility with other drivers. . .?

Crescendo can work on tiny13 or tiny25, but on tiny13 it won’t be able to fit config mode or as many features.

I’m also not sure it would be a good idea on a twisty light. The UI is designed to take advantage of quick repeated interruptions in power, like a double tap, which is hard to do on a twisty. But it should be fine on a reverse clicky.

The Lumintop Copper Tool has a clicky switch. The Lumintop Tool Ti is using a “Electronic-Switch circuit” (Available on BangGood now:ReyLight Custom-Lumintop‬ Tool Ti AAA, L-M-H - #219 by T18) (ATTN Lumintop Tool Ti users - #3 by sp5it). I found the info about the switch circuit a few minutes ago. Will have to read if they have found a solution to use it with a 10440. And i still hope to find or build something with two 7135 chips. Wight has the A10DD-L v009 driver with FET +1 and 13a SSU. Maybee i could fit a second 7135 instead of the FET on the board.

For a 1xAAA-sized light, I’d be happy with just a single 7135 chip. I don’t really need more than 150 lumens from something that small. It’s impressive that a FET+1 can fit though.

I think going with one 7135 will be it. At least he will get a much longer runtime out of the 10440. But only if i can get the f… glue out of the light. I hate it!!! Why do they have to glue everything together. In the last 2 month i have seen 3 lights (all 1xAAA) that are “for now” impossible to get appart. At least not without damaging the surface of the light or the driver/switch PCB.
But one question do i still have. Which firmware would you use on a single channel driver (i do not know if it will fit, but i could try to fit a tiny25 instead of the 13a if it would make a huge difference).

Single channel…

  • Crescendo: ramping with blinkies. Needs some tweaks to fit on attiny13
  • My simply named “ramping UI”: ramping with no blinkies. Has a few runtime config options. Fits on attiny13 with plenty of room to spare
  • Biscotti: non-ramping. I don’t think Biscotti needs an introduction :slight_smile:
  • Babka: non-ramping. Built from Biscotti with some added runtime config options.

Mostly depends on what you like… ramping or mode groups? Blinkies or no blinkies? Ontime, offtime, or 3-level offtime? Configurable via the button or only at compile time? Can a tiny25 fit? Is there room for an OTC?

Some of my favorite lights use pretty old firmware, like “S7” or “brass-edc” (same thing, really). It has a single mode group, a bunch of blinkies, offtime, no memory, and no options.

I don’t Know if this would be the correct place to ask this question but I assumed this would be the best place that might have the answer.
I looked through the datasheets for the attiny13a and I could have missed it but does anyone Know how much current output any pin (say PB1) can sink to a load? I thought the datasheet was saying it could output a total for all pins combined of 60ma, just not sure I read it correctly.
Reason I ask is if you could run that pin at say 50% pwm how much current would that be. I’m thinking that a very low moonlight mode might be possible without even using a amc7135 using dual channel FW and one FET. Maybe its just wishful thanking but I gotta ask. :person_facepalming:

Moon is easy to do without a 7135 or FET. All it needs is a pin to a resistor to an emitter. The attiny’s internal pullup resistor can then be used to set the emitter into three states — high, low, and off. Or you could use PWM on it, but that requires keeping the attiny awake so it’s a lot less efficient.

Several lights, like the BLF Q8, use this method to light up a button while the light is otherwise asleep. At only 0.1 mA it can be bright enough to work as a moon mode of sorts, and at 0.03 mA it works well as a locator light.

You could do the same thing on the main emitter(s), possibly using less resistance, to produce an incredibly efficient moon mode.

From what I understand looks like it might push 40ma from one pin. Above that and the magic smoke comes out. So if that’s the case if you added a 400 ohm resistor to the PB1 and used a pwm value of 100% that would be about 10ma (low mode) I think. 10% = 1ma (moonlight mode). Or maybe just a 4k resistor for moonlight at 100% pwm.

Thank you Toykeeper. :smiley:
I kept having this crazy idea in my head. So we really don’t even need a amc7135 to achieve moonlight mode, just one resistor, FET and dual channel FW. But its more efficient to use the pull up resistor.
I believe a 8.4k resistor gives .5ma and uses .0021 watts. I would need to test to see just how low that is.

Moon plus FET still isn’t very good at the low/med modes. I’d recommend doing FET+1 (or FET+N) on pins 5 and 6, and using pin 2 or 3 for a dedicated moon channel.

Resistance also depends on the type of the LEDs. E. g. 3k is a good value for a decent moonlight with Nichia 219C. You shouldn’t do PWM, just power the i/o-pin and let the MCU sleep. And you can’t use the internal pull up resistor with main LEDs, since in our usual FET and 7135 drivers the anodes are connected to batt+ and the cathodes have to be pulled down. With several resistors at different pins you can even have different levels of low moon.