I don’t have any groups that Turbo isn’t the highest setting, but my hidden modes don’t include Turbo
Yup. It’s basically how it should behave, assuming Turbo the first hidden mode and also the highest setting.
Good points, I bet this is how it is supposed to be.
Not sure if there’s an easy fix for that and if so you’d want to decide what Turbo as a hidden mode actually does. I mean if “all 7135’s” is the highest regular setting would you want Turbo as a hidden mode to be really the FET 100% or just the same as the highest regular setting, “all 7135’s” in this case…
I don’t think I could fix it either way, lacking the coding skills, but that just came to my mind…
By the way, it’s the “if (my_reverse_modes)” part in void count_modes() that does it.
Nice, so if you disable that then the first reverse mode should indeed work again, but like was said you would have a situation of Turbo>Turbo if the mode you are using already has turbo. They to get anymore details then that will use up too much code space.
So basically do you want the first hidden mode to work or not?
I could change that and release a separate hex file with that change I suppose.
Those two statements look very contradictory to me.
It may look contradictory to you, but I’m just beeing honest. And I wouldn’t call it a fix to just delete:
if (my_reverse_modes) {
// TODO: yuck, isn’t there a better way to do this?
int8_t i;
src += solid_modes;
dest = modes;
for(i=0; i<solid_modes; i) {
src —;
*dest = pgm_read_byte(src);
dest ;
}
if (my_enable_moon) {
*dest = 1;
}
mode_cnt —; // get rid of last hidden mode, since it’s a duplicate turbo
}
Because than, you run in the situation that TA described. Turbo->Turbo
How would I go about disabling that? Comment out every line or just the IF statement?
I won’t be changing this for the “normal” release but I could add it as an optional release. Most people can flash a hex file but editing code is a whole other ballgame. I don’t mind having 10 different hex files for people to pick from as long as they make sense and there is a reason.
I’m not sure I understand the problem, but my wife tells me that has never stopped me from putting my 2 cents in anyway.
Isn’t the simplest workaround to put a dummy mode in the first reverse slot?
True, although then if used in the normal low>hi setup you would get that dummy mode. But really I guess that is no worse then not having anything in the hi>lo mode.
I could put a second battcheck mode there.
Or even a second Turbo mode
Ok, I added 2 more HEX files to the bistro release.
One of them has 14 modes with soft start enabled.
The other has a second turbo mode added to the hidden modes to allow it to work with the hi>low mode groups.
Link to it here: Bistro Texas Avenger V1
Nice that you found an easy solution.
Also I think what I wrote before is not correct and just stupid basically.
If you wanted to fix it with uncommenting something in this code, I think you’d just want to uncomment “mode_cnt —; ”, and leave the rest untouched, because that is what actually handles the reversing of the modes, I think… Proves again how little I know.
So does the change affect all groups in either mode order?
Now, with the second turbo added to the hidden modes, HI-LO order will reverse-press to >turbo>batt-check>strobe>etc, and LO-HI order will reverse-press to >turbo>turbo>batt check>strobe>etc?
Correct, it would take new code to make it adapt to both situations and there is no room for it. So you kind of need to pick before hand which mode setup you want. This new firmware is basically just for the hi>low groups that do not have a turbo mode built in. Everything else should use the normal version.
Here is an LDO version of the 17mm driver, I recommend using this if you know it will be used in a multicell light. The LDO can be jumped with a diode if you desire though and then used in a 1S light. The pads for the diode span the top 2 pins on both sides. The line would face the MCU.
TA17-LDO - 17mm LDO 2s+ Driver
This is basically the same as the above LDO drivers except it uses a different LDO and doesn’t have the jumper resistors. Highly recommended to use this driver in multi-cell lights over the zener version.
LDO : designed around the LT3009EDC-5 or LT3009IDC-5
OSHpark link: OSH Park ~
Good deal! That works for me. Thanks for working that out.
Been meaning to find this post. I felt the same. Similar tricks have come up since and I've found some limit to them. You don't want to unblanace cells, probably not even if a light sits in a drawer for 6 months.
I actually don't think 220kohm is enough to eliminate problems from that even if it does mean 18 years for a full drain, but so long as battery monitoring is done off that single cell (I don't recall) then it's fine, because that will be the lowest one.
Just something to keep in mind if thinking about doing similar tricks elsewhere. Even a few percent imbalance can mean one cell crashes to very low voltages before the others, and then its probably ruined. People leave lights in drawers for months. We're doing something slightly similar on the Texas Buck, but that's 10nA of current on a voltage sense pin, so that's ok.
In the SRK driver the LVP and the MCU both run off the same cell, so all is well. If that cell is drained too much the whole light will shut down.
Don’t forget that pulling 1S off the pack to drive the electronics is precisely what laptop battery packs do. So, there is precedent for doing that, and it must not be that bad of an idea. The counter-argument is that if it is left sitting long enough, the laptop pack does get out of balance on that one cell, and the protection circuit will shut down the entire pack because of it. So, it’s definitely not a perfect approach.