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.
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.
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 
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:
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.
This is where I get embarrassed :person_facepalming:
Sorry to have asked here, and thanks for all your clear explanations! 
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
If anyone has successfully run level_calc.py in Windows please see my post here:
Been meaning to add this point here. In bistro-HD we probably found a neat kind of bug.
As in bistro original (although done differently) on first boot if no mode number is saved it's assumed that no data is saved so boot up initial values for the mode and all menu toggles get saved.
Unfortunately this takes, oh, maybe 30ms or so and the mode gets written first. That's bad because the mode is the check to see if there is valid data. It should get written last.
It seems this bug has probably struck some people if power is lost in the first 30ms of the first boot, which could certainly happen.
I believe, not quite certain, that this goes back to original bistro which seems to do things in the same order, but I could be wrong, as the version I actually looked at wasn't quite original. I'll check.
I have not changed this yet, because I need to review what impact reversing the saves has elsewhere. Like are there other places where it's better to write the mode out fast before the other saves? I'll have to see. It's something to consider in firmwares in general probably.
We're not really going to get ZFS installed on an attiny25 though so may have to live with some compromise. This shouldn't affect later bootups, or not in this bad of a way. Actually OTSM probably protects against bad writes to single bytes in later boots just like switch does. There should be enough cap to get through the write, although it might interfere with the click timing for that click if the battery is low. Normally that's only an issue after a menu toggle, in which case click timing isn't even important.
Hmm. Good point. I haven’t heard any reports of failure in that manner, but it’s a trivial change with no impact on code size, and it should make things more robust, so it seems like a good patch to land.
It doesn’t even need to change the layout of eeprom… just the order of saving data.
As for writing the mode quickly, it’s a separate function in bistro and gets called separately when needed. It’s not generally done for speed though, but to avoid unnecessary wear on the eeprom. The mode is wear-levelled but the config settings are not. The general guideline there is to use wear-levelling if a value is likely to change frequently during regular use, or use fixed addresses if the value only changes when the user modifies a config setting.
Yes that's right, it's usually done separately for mode only. the only question is if there's some advantage in the toggles, where both are saved. HD has reworked this significantly and I think it's ok in HD, because the mode save back to zero is now done on startup as soon as it's realized that it's a menu mode (saved a couple of duplicate instructions). In bistro, the first mode reset to zero is combined with the muggle_mode menu toggle. So if you magaged a button press at exactly the wrong 30ms there, I think you could set the muggle mode, but if mode_save is last, still end up starting back in the menu.
Presently it's just that if you click out too fast, mode gets saved to zero, you are ejected from the menu and the mode option isn't saved, but that's fine, that's what should happen if you click before the flash. So changing it creates a very tiny race right there possibly. One extra call to save_mode fixes it though.
Anyway, I didn't really mean to worry too much about any particular firmware, just to point out that we don't have atomic saves and it's good to think about save order. I have seen this bug hit probably, very hard to know something like this with certainty but it certainly can happen, and then at least removes one uncertainty.
Of course the fact that this is the worst bug in bistro is pretty great.
I was a bit confused. Anyway in HD at least and I think bistro too, modes do normally get set back to zero before clicking out of the menu, but the worst would be muggle gets set and mode doesn't and you end up in some random mode, I think only of the three though as ones beyond that should wrap, unless you medium click out or long-click-memory out, then it won't wrap so then possibly a non-muggle mode still left in the array. It's definitely not as clean as saving to mode zero first but might not be so bad and probably not as bad as the firstboot bug. I'm always reluctant to add two extra bytes for an extra call if I can avoid it, lol.
So the firstboot save (reset toggle) is actually the commit if firstboot is enabled, so just saving that last fixes it in that case. In HD to save spce, the saves are in an array and looped though, so that also constrains firstboot to actually be the be the last (or could be first) toggle, which might not always be a desirable constraint in the future if adding more toggles. It seems like no free lunch.
In case it's of use to anyone, I made a little tool to calculate voltage divider values. It's based on RMM's spreadsheet and level_calc.py. Here are some example calculations with it:
> ./voltage_dividers.py How many cells in series? (1) 4 R1 value? (191000) 560000 R2 value? (47000) 33000 MCU reference voltage? (1.1) ADC range: 144 - 216 Standby power: ~0.049 mA Press Enter to exit:> ./voltage_dividers.py 4 470000 33000 2.56
ADC range: 73 - 109
Standby power: ~0.057 mA> ./voltage_dividers.py 4 330000 47000 1.1
WARNING: ADC values outside expected range of 32 to 224
ADC range: 323 - 485
Standby power: ~0.076 mA> ./voltage_dividers.py 4 470000 22000 1.1
ADC range: 116 - 174
Standby power: ~0.059 mA
> ./voltage_dividers.py 1 22000 4700 1.1
ADC range: 114 - 171
Standby power: ~0.270 mA
The ADC values should match RMM's spreadsheet, but I'm not sure if the standby power calculations are correct. I just made up a formula which got reasonably close to some values I've measured over the past couple years.
Standby current is a bit strange, assuming no bleeder resistor or tail LED the first example should just be
16.8V/(560,000Ohms+33,000Ohms)=28uA but you get 49. However all your examples are at very very low levels so leakage through anything can mean 49 is more accurate which could explain your hint at a mystery equation, especially leakage from an LDO I suspect, but that will depend on the particular components used.
You could just use the simple voltage divider current, with a note that at the level of 10uA or so other things may impact the result for the whole driver.
Hi everyone. I have a problem with one soft. I’ve been looking for a firmware for a long time that would suit my needs, and when I found it didn’t work. It’s about dth_Momentary_v1_1 by dthoang. After powering on, the led flashes and it’s the end. It does not respond at all to the button. What could be the reason?
I am testing this firmware on nanjg 105e, fuses are set to LOW 75, HIGH FF. Button directly soldered to the second tiny13 output
Please help
Leviatan, sounds like it’s probably a physical issue… something shorted or not connected or perhaps connected to the wrong place. Hard to say exactly, without more information.
Thank you ToyKeeper, for building this repositry. I have just recently bought a USBasp board, the required wires and a Pomona SOIC8 clip and flashed my first couple of drivers. The first trial test with Nlite on a nanjg ak47 and the other using your tail-light firmware.
That tail-light firmware is pretty much just what I want. I have diddled with the code slightly; I’m mainly after the blinky modes. That is sort of strange to say because I totally have no use for blinky modes that many lights come with. Bike blinkies are different.
I changed the blinky count and frequency. I am not a “coder”; many decades ago I wrote some simple stuff in Basic. A very long time ago.
Anyhow, I wanted to say Thanks. I hope to have some fun and learn something new.
Thank you ToyKeeper, for building this repositry. I have just recently bought a USBasp board, the required wires and a Pomona SOIC8 clip and flashed my first couple of drivers. The first trial test with Nlite on a nanjg ak47 and the other using your tail-light firmware.
That tail-light firmware is pretty much just what I want. I have diddled with the code slightly; I’m mainly after the blinky modes. That is sort of strange to say because I totally have no use for blinky modes that many lights come with. Bike blinkies are different.
I changed the blinky count and frequency. I am not a “coder”; many decades ago I wrote some simple stuff in Basic. A very long time ago.
Anyhow, I wanted to say Thanks. I hope to have some fun and learn something new.
What information is needed?
I would rule out the physical issue. I checked on the same layout:
- eswitch-13 by Tom_E
- MiniMo by DrJones
- STAR_momentary by JonnyC
- Ferrero_Rocher by ToyKeeper
All of these work perfectly. The exception is dth_momentary_v1_1 by dthoang, on which I care the most.
Below is the photo of my layout on which I’m testing:
Ah, that makes more sense. In that case, it sounds like dth_Momentary either has a bug or is expecting a different physical layout than the others. Looking at the code, I’m guessing probably a bug. What happens if you copy the is_pressed() function from STAR_momentary.c into dth_Momentary?