TK, thanks for the crescendo update.
I was waiting for this firmware to flash many of my TA drivers.
I do like ramping firmware for small triples and quads flashlights.
Very nice! Does it still have the triple channel support or is it only for 2 channel drivers?
TA, it seems that the firmware code do have triple channel support.
Later night I will try it on TA driver.
quick question can i just swap the attiny13 with attiny85?
The 13 and 85 are a bit different and need some code changes. You can flash a tiny25 hex to a tiny85 though without an issue. Done this many times myself.
TK, flashed a TA triple channel with crescendo on a Convoy M1 with an XM-L2, and it is working perfectly.
I changed many compilation parameters in the firmware to config it to my needs.
Every mode is working flawlessly.
Liked the goodnight mode.
Will keep this combo as my EDC.
thanks.
TK, appreciate the fact that crescendo can use memory in any mode, including the special ones. Thatâs useful in many situations, like using strobe as the first mode in tactical setup, or bike-strobe (I enabled both the low and hi bike modes) etc.
TK, is it possible to add similar function in relation to voltage instead? I am thinking about low vf leds that ate overdriven in direct drive when the battery level is 3.9-4.2. But could handle direct drive when the voltage drops.
It was talked about before but I donât think snyrhkng ever came of it. It was suggested that a beginning duty cycle could be set to 75% or so then as the battery drains the duty cycle would be aloud to transition back up to 100% when a safe battery level is reach.
I realize there is a lot of factors involved and it would differ with every setup but even a generic setup would be useful.
Itâs complicated and fiddly, as you say. Itâs far better handled in hardware instead of firmware â basically, by using a constant-current driver, preferably with a boost or buck circuit to match the emitter voltage. Doing it via firmware on a FET PWM light is going to be âmehâ at best.
Thermal regulation is far simpler, and itâs still pretty bumpy.
It would not have to be fancy in the firmware to get acceptable results with PWM.
A simple table that would bias the desired duty as compared to voltage would do the trick.
So for example if it is asking for 100% duty it would output 60% at 4.2v, say 75% at 4v and 90% at 3.9v and finally reach 100% at 3.8v or so (obviously just guessing on exact numbers).
This way LEDâs like the 219C or xhp35 that canât handle 100% duty with a fully charged battery could at least take advantage of the extra duty as voltage drops. Plus it would offer some very basic regulation.
That said a truly regulated driver is best but also a fair ways out at this point and will never be an option for some of the monsters we build on here, just canât make high current buck drivers that small.
I need some help here, i want to make an A6 with 2 modes, turbo and low. Is possible to adjust the firmware so in low mode, 350mA are supplied by 7135 and not from fet?
Yes, the blf-a6 should make it pretty straightforward to have those two modes. Set the 7135 channel to â255,0â and the FET channel to â0,255â. This way, there are only two modes: 100% power on the 7135 chip (by itself) and 100% power on the FET (by itself).
I will try, thanks TK!
Yes. Just something basic would help as fet drivers are what we have around here. Iâve been fighting the need for stacking 7135s but I may have to give in. Iâve seen a 7135 driver pull twice the amps while cool than at 60seconds. The output throttles even when the head is cool. This is worst case scenario with floating 7135 board but even potted the problem remains. Much better but still remains. Even the proposed voltage throttling fix to save the led will not address the problem over the middle modes.
I understand though. We have been needing to use bandaids until better drivers become available and affordable. (I should say more appropriate not necessarily better)
So fix this-break that-fix that-break this. Not a place of motivation for those writing the firmware.
TA, have you still been pulling down the max duty cycle for these lvf leds? Or have you found a better bandaid?
Oh ya, the gbx17-20 boost driver has promis for the 6v variants. Itâs still pricy though.
It could actually compensate for any mode if coded right, not just max power.
I have not built any lights recently but there is nothing better to be done without moving to newer driver tech like a buck, boost or more advanced linear regulator.
PWM works just fine, it is just not as efficient as a buck or boost would be.
I face some difficulties building a 2 mode A6 dual channel firmware.
I have put the .h files in project folder, also shown in lidrary folder.
Can you help me on how I choose I/O layout in attiny.h?
Silly question but I have tried without result.
Severity Code Description Project File Line
Error MakeFileGenFailureException captured - Value cannot be null.
Parameter name: source GccApplication1 C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets 5
any ideas?
Each type of driver has its own layout definition in tk-attiny.h. Unless, of course, the particular driver type isnât in there. The file really is quite a messâŚ
To select one, put a â#define FOO_LAYOUTâ in your .c file before the line which includes tk-attiny.h.
You may also need to â#define ATTINY 25â or similar too, if your build system doesnât define that at compile time.
I still havenât actually tried building any of this stuff in Windows though, so I donât really know where to hit it to make it work.
In completely unrelated news, I have a new code foundation in progress for e-switch lights. Itâs nowhere near ready yet, but I do at least have it running a momentary single-mode UI with low-voltage protection, as a simple first example.
Itâs an event-driven stack-based finite state machine, basically, and each UI file only needs to implement a few relatively simple things to get a working firmware.
The first working example is here.
I havenât really decided on a name yet. Originally it was going to be RoundTable, since it all would revolve around a big state transition table, but it turned out to be a better idea to use simplified code instead of a big table. I might go with something related to finite state machines instead⌠like FSM or SpaghettiMonster.
Anyway, the upshot of all this is⌠it makes e-switch UIs dramatically easier to write.