Much better, this is something that a layman can actually understand which is the target of the TA series, make it assessable to anyone that wants to give it a try.
Which is why I go to such great lengths to for example allow a single HEX file to be all that 95% of people need and most people to never have to touch the code.
Is there a one size fits all Bistro HD firmware HEX download to go with these instructions? I will need to add that to the OP to make HD “official”
It's important that those 2S 3S and 4S resistors can only be used with a 5V LDO. If you use a different LDO, you need different resistors. I think I previously checked that you call out 5.0V LDOs?
Also notice I update "Any values of with R1 < 1/3 R2"... to any "similar" values with...
[quote=Texas_Ace]
Nope. It's not possible. You need
bistro-TAv1-OTSM-HD-attinXX.hex for 1S
and
bistro-TAv1-OTSM-LDO-HD-attinyXX.hex for 2S.
Unfortunately I didn't think about 4S yet, that's a different build as it's a 1-FET driver, so should be warned off for now. I'll add a config for it in the next couple of days, probably will call it bistro-TAv1-OTSM-LDO-HV-HD-attinyXX.hex? (oof :FACEPALM: )
a septate Hex for each cell config is ok, that is easy to figure out. My problem stems from too many choices with no clear reason they exist.
For example I recently modded my Router with Tomato firmware and while it is a simple task, there are dozens of options of which firmware to use with no clear explanation of what the differences are.
This is the case with many firmware related things and it really bugs me.
Where are the links to the HD firmware?
The links are in the HD thread of course:
https://budgetlightforum.com/t/-/44344
When you unpack it, the hex files are quite clearly in the hex directory. HD is not one firmware for configuration of one board. It is a collection of many firmwares for many configurations of many boards. It includes a stock Q8 Fet+1+indicator eswitch firmware for example, and will likely soon includes builds for the a TA Q8 driver with tripple channel and the indicator on the divider pin, and maybe yet another for Q8 4S. And that's just the Q8 builds, but that's life, those all require different firmwares.
The hex files are very clearly named, there's a detailed listing of all of them in the manual*, and for a specific purpose like un-specialized TA board builds, you can just direct people to which ones to use.
Of course if you want to compile your own, you can do that and get all kinds of customization to choose from, but you get to start with the default config and make changes from there as you wish.
But for normal use, you just flash the correct hex, no options to choose from. bistro-TAv1-OTSM-HD.hex or bistro-TAv1-OTSM-LDO-HD.hex as stated above. I think those names are pretty obvious and easily distinguishable from things like bistro-dualswitch-dumbclick-HD.hex.
I don't see the problem. Yes, the HD page as a BUNCH of information right now, and I may work on organizing that differently. But it's written, for a) me, so that I can actually remember how it all works later (already needed that) b) other developers so they can have a chance of knowing how to jump into (and it's very light on that, but at least one programmer already helped out to track down a bug), c) board customizers (who are likely also d) who need to know what hardware to select and who are eager to choose cheaper parts with the "same" specs, d) hobbyists who might just want to customize modegroups and ramps, and e) folks who just want to flash the bistro-TAv1-OTSM-HD.hex, and f) people who bought a pre-flashed board and just want to know how to use it, and all this for many different drivers. So yes, that's a broad audience. Your audience only includes two of those, and for a subset of the configurations. I fully expect someone publishing a particular board will give people the short version of which hex and what hardware to use on that particular board.
As for re-organizing things, I'm considering a linked table of contents to break things down, and possibly a format with more rich text. An obvious one is just using the board itself and linking to multiple posts. That's not terrible but I can't keep a copy or distribute it in other ways then. I could also make it an html, tiddlywiki or something, but then it's not directly viewable from the board. And in the end... there's a limit to how much time I'll spend re-organizing it, if any. So, some short summaries of which hex to flash from an OP like yours is useful. We could also add comments about battcheck calibration. I do have a new post to link to for that for LDO, that for now is in sync and uptodate with the manual, but details like that will evolve naturally.
One tool I am likely to add is a click-to-flash tool. I don't think I presently include my flashing script. Of course you're welcome to grab hex's and post them with a flashing script on your server. The only requirement is that you link to or include the code, since it's gpl3 (the HD post will do).
Anyway, I'm using a bat script that I associate with .hex files. Then double clicking a .hex file flashes it. I can write a second .bat or powershell script probably to associate the first bat script, or maybe make it associate itself if you just double click it, or just dont' associate it and tell people they need to type:
flashany.bat yourfile.hex on a command prompt.
Open to suggestions of course.
Of course I will be opening up more possible uses for bistro on your boards, with the e-switch and dual switch options already existing experimentally for standard, non-Q8 buids as well (and the Q8 builds as well). Those certainly can be run from your boards, but I don't see that as being mainline anytime soon and I don't think you need to make a strong point of it until or if people like it and you want to. You still have narsil to link to for that.
Personally I don't love that in narsil you have to remember which way you were going, and possibly turn around if I understand it right, and can't bump up in modegroups, so I plan on playing with bistro-HD in e-switch lights, which of course doesn't have ramping at all, for now at least.
I will be zipping all the HD firmware together onto a single file like the TA-bistro or even adding it to the TA bistro, not sure yet.
It all needs to be in a single download though, multiple downloads to do a simple task is something that has always annoyed me.
It's all zipped in a single download right now, include "one-click" batch files to recompile (if you have the compiler installed of course). The first thing you'll want to do probably is look at it.
However, again as HD is not one firmware but many, it could also make sense to have it in a browseable server so you can post links to specific hexes. Unless I get it on git though, I probably won't do that.
As for adding it to TA bistro, it already includes TA modegroup OTC hexes as well, the only differences with yours being the new thermal control, that it has room you were always asking for for the extra modegroups you had planned (and actually adds two modes already, one you had to remove, and one that's my own I think), that voltage calibration is simplified, and that it's more customizable now since all the defines actually work now. The TA tripple version is the version I started with.
I know my new thermal control didn't end up exactly how you liked it either, but I think it ended up closer to that than the existing one. If you feel strongly about keeping the old way, it's one define and we can set it back for the OTC builds to make them TA-originals. Distributing separate source codes from drastically different stages in development though doesn't make a lot of sense just to change one option.
If there are things to add to the download, like a linux Makefile for example we can work on that. TK was already thinking about doing it. It should be only a small modification of the existing Makefile. This is about the one that got un-done with HD, and would be useful to get it redone.
And I'm planning to add my flashing script in the next release.
Full list of TA tripple clicky builds included:
.\hex\bistro-TAv1-OTC-HD-attiny25.hex
.\hex\bistro-TAv1-OTC-HD-attiny45.hex
.\hex\bistro-TAv1-OTC-HD-attiny85.hex
.\hex\bistro-TAv1-OTSM-HD-attiny25.hex
.\hex\bistro-TAv1-OTSM-HD-attiny45.hex
.\hex\bistro-TAv1-OTSM-HD-attiny85.hex
.\hex\bistro-TAv1-OTSM-LDO-HD-attiny25.hex
.\hex\bistro-TAv1-OTSM-LDO-HD-attiny45.hex
.\hex\bistro-TAv1-OTSM-LDO-HD-attiny85.hex
OTC builds work on 1S or 2S as they always did.
So question, for the 46mm board, you use a 5.6A worth of 7135's.
So I just ran the geometric progression going from 1.3mA moon mode to 16A max in 20 modes (19 steps), and you get a step ratio for current (before worrying about how to achieve that with PWM) of 1.63 between steps. And it checks out, that you gets from A to B with all the steps in the middle.
If you divide 16 by 1.63^2 you get 5.9, so 5.6A roughly corresponds to mode 18. I can make that kind of 16.5 if I force mode 2 to be 7ma, (pwm of about 7 assuming PWM of 2 is 0 amps), so the same as your mode 2, and then make 18 steps from there, but you have ALL7135 down at mode 14. I realize this can't possibly work out perfectly for every light, but ALL715 and turbo are only closer together for smaller lights typically, not farther.
On the one hand, it would kind of seem strange to have a big bright light like a Q8 and only have one or two modes between 5.6A and 16 A out of a group of 20 modes (in a group 5 sure, or maybe not even 1). So did you just intentionally flatten the geometric curve up top, maybe to make room for "the biking group"? Honestly I've never really used any of the modes between ALL7135 and TURBO, partially because of my non-hot lights, and actually your mode groups don't use them much either, but they are there, where in my math they just aren't.
I'm not saying any of this bad, just curious. I only noticed because it is making it difficult for me to map your modegroups on to a new geometric FET+1 ramp (even though I made the ramps a bit wrong in the released version anyway). I'd either need to bend the ramp, or modify the modegroups a little, basically shortening the biking group.
For a firmware like narsil with ramping a smooth ramp is very important. For a mode based light I find it far less so.
My general rule of thumb for modes is 10X spacing (For example my EDC is setup with moon, 35ma, 350ma and 3.5A) and I find the spacing to be about visually perfect. I also don’t like more then 3-4 modes on my lights, more I find to be useless in the real world. Who really cares if it is at 1000 or 1200 lumens?
Also keep in mind that 16A is pretty conservative for a SRK style light. Mine do 25-30A and even the Q8 does over 20A.
In the end it was not worth having a septate mode group for that particular driver when I was limited to 23 groups. Now that you can have as many as you want, feel free to add whatever you feel is worthwhile.
I love giving people choice as long as they are not forced to actually make a decision unless they want to.
I'm talking about the ramps though not the modes. Yes, 16A is conervative, although not everyone recharges batteries every 30 seconds or uses 30Q's, or bothers to clean the tail board, so I think it's a good number to use, especially since it might get used on other lights, but that might explain some of the difference.
I just can't make a geometric ramp of 20 levels (I shouldn't have said modes) leave 5 levels in between 5A and 16A. LIke you said, X10 is even ok for actual mode spacing, and there's not even a factor of 10 between there. Level spacing in the ramp should be tighter than mode spacing but still, 2 modes in between them is all I can fit in a geometric ramp if I force the low end a little. Just was wondering if you had intentionally bent the ramp in the middle somewhere, because it seems bent in the middle, stretched at the high end and compressed at the low end probably. Yes, it's not crictical for a non-ramping firmware.
I'll probably go with a standard geometric ramp though and maybe modify the modegroups for that. If I force up mode 2, I 'd only have to drop one biking mode I think, and just tweak the mode numbers to match on the rest.
I have a feeling maybe what you did was just say, ok, 20 levels, three channels, so about 7 levels per channel so set all7135 at 14, one7135 at 7 and then made geometric progressions within the three segments. That would kind of make sense. I could probably do that, in three segments, and come up with something that matches what you have pretty closely. I've got my "program" for generating the sequences. I think it might handle the 7135 contribution to the fet modes a little better, but that's kind of academic since the LED efficiency change is bigger than any of that anyway. (oh, another reason the top end is overstretched, in reality, the brightness difference isn't even 16/5.6, it's less.)
Here is the current list I get to match up all7135 at mode 14
| 2 | 0.0165 | |
| 3 | 0.027452 | 1.663786 |
| 4 | 0.045675 | 1.663786 |
| 5 | 0.075993 | 1.663786 |
| 6 | 0.126437 | 1.663786 |
| 7 | 0.210364 | 1.663786 |
| 8 | 0.35 | 1.663786 |
| 9 | 0.55559 | 1.587401 |
| 10 | 0.881945 | 1.587401 |
| 11 | 1.4 | 1.587401 |
| 12 | 2.222361 | 1.587401 |
| 13 | 3.527779 | 1.587401 |
| 14 | 5.6 | 1.587401 |
| 15 | 6.670781 | 1.191211 |
| 16 | 7.946307 | 1.191211 |
| 17 | 9.465728 | 1.191211 |
| 18 | 11.27568 | 1.191211 |
| 19 | 13.43171 | 1.191211 |
| 20 | 16 | 1.191211 |
First column is level number, second column is current, third is ratio.
It's definitely flatter on top than on bottom, but it works.
The low modes match almost exactly with your one 7135 modes.
The middle modes are proportioned to get to 5.6A at mode 14
The upper modes are proportioned to get from there to 16A.
It's a bit contrived, but I'll probably use it.
It actually just kinda ended up like that. The ramp was actually made with TK’s ramp Script. I forgot the numbers I used, I think they are commented in the code IIRC. I then tweaked the ramp manually to get the one7135 and all7135 modes to line up on a single mode for true non-pwm regulation. Just so happened to work out to a 3rd’s setup between outputs.
The ramp was setup around the “normal” ~3A drivers as well, I was not going to change the whole ramp just for the 46mm boards, so they just kind of are along for the ride. Although the real world results turned out pretty good, the mode spacing was perfectly acceptable on the ones I built.
I personally think that the ramp should be setup around the largest percentage of drivers and the rest can simply adjust the particular modes they use in the mode group. In this case that means a ramp setup for the 2.5-3.5A range of all7135 and a turbo output of around ~6-8A.
The results are the same either way, just the path you take to get there so it doesn’t really matter.
Have you used TK’s ramp building script? It is fantastic! Takes a few tries to get the input numbers just right but does an amazing job of making a smooth visual ramp once you do.
The math is what it is. I'm not showing PWM ramps, just current, so most of the work of the script to deal with contributions of multiple channels isn't even relevant at that stage. YOu can just check that mode 3 is 27ma/350ma so a pwm of 20 same as your mode 3, so that's a good starting place (modes 1 and 2 are warped a lilte), and the rest just follows.
You can see for yourself in that list that you need ratios or 1.6 to get between those lower modes, and must stretch to 1.2 to get between the higher ones, so about 3 times flatter. That's just what it is.
As for getting the PWM combos, I have it worked out in a spreadsheet calculator, including minimum PWM corrections and 7135 contributions (which fade away with PWM overlap), so that's not a problem.
This works even worse for 6-8A turbo with 2.4 amp 7135s because ALL7135s and TURBO are even closer together. You need a turbo of about 90 amps to flatten that out.
Here it is for 7 7135s and 8 amp max I show PWM for the 1 7135 because there's no concern of how to calculate those.
Calculating the other PWMS depends on how you interpret contributions from the first channel, and I don't want to get into that.
But the 7135s match your modes perfectly exept for the 92 mode, which you have as 100, and I suspect you just tweaked it.
So the basic premise of the geometric progression is right. Again, I hit .350 at mode 8. And I hit 2.45 at mode 14, with constant ratios in between those, but again to do that the low modes progress 3x faster than the high modes.
| level | Amps | Ratio | PWM |
| 2 | 0.017 | ||
| 3 | 0.027 | 1.664 | 20.001 |
| 4 | 0.046 | 1.664 | 33.278 |
| 5 | 0.076 | 1.664 | 55.367 |
| 6 | 0.126 | 1.664 | 92.118 |
| 7 | 0.210 | 1.664 | 153.265 |
| 8 | 0.350 | 1.664 | 255.000 |
| 9 | 0.484 | 1.383 | |
| 10 | 0.670 | 1.383 | |
| 11 | 0.926 | 1.383 | |
| 12 | 1.281 | 1.383 | |
| 13 | 1.771 | 1.383 | |
| 14 | 2.450 | 1.383 | |
| 15 | 2.984 | 1.218 | |
| 16 | 3.635 | 1.218 | |
| 17 | 4.427 | 1.218 | |
| 18 | 5.392 | 1.218 | |
| 19 | 6.568 | 1.218 | |
| 20 | 8.000 | 1.218 |
It matches better for the Q8 type driver. You can only ever just put lipstick on the FET, but the middle modes at least match for the 16 7135s, not 7.
In the end, it's a bunch of levels between tiny and turbo, which is good enough, but it's a bit weird. So a small mystery.
Another small mystery is why you can cut and paste from excel to the post editor but it works on 1 attempt out 10.