No problem; let us know how it goes!
Havenāt gotten to flashing it yet, so next question. Can I limit how far thermal stepdown goes in bistro? If it steps down 4 steps in a big ramp its not a big deal, but on my ~10 step ramp that means I went from turbo to low in 5-10seconds. So can I limit it to only 2 steps? If not, can I delay it significantly?
I haven't modified the full version of Bistro (yet!), but it looks like you should be able to control that. I'd say it steps down one level at a time (actual_level--), so it should be relatively gradual.
To limit how far down it will go, modify the (actual_level > (RAMP_SIZE/8)) check. If I'm reading that right, it'll go down nearly all the way - down to the first 1/8 of your ramp. Say, if you want to limit the step down to never go below half of the RAMP_SIZE, you should be able to change it to (RAMP_SIZE/2) ...I think ;)
if (temp >= maxtemp) {
overheat_count ++;
// reduce noise, and limit the lowest step-down level
if ((overheat_count > 15) && (actual_level > (RAMP_SIZE/8))) {
actual_level --;
//_delay_ms(5000); // don't ramp down too fast
overheat_count = 0; // don't ramp down too fast
}
}I'm doin same sort of thing in Narsil - limit the amt of drops from over temp detection, but I do drops much more radically - drop the ramping level in 1/2 each time, not level by level, but my over temp setting is pretty high - light gets uncomfortably hot in the hand by the time it hits the drop temp. Also I delay it 30 secs before doing another drop.
Good info, thanks. So simple I should have been able to figure that out myself, but nah. Once you explain it it makes sense, but otherwise Iām just reading greek.
Sorry, this is an old post, but for the life of me, I just can't find where these script files are located - can't find them under your toykeeper folder anywhere. I want to be sure I get the fuses correct. Looking at biscotti for now.
Iāve been using the typical 0x75 and 0xff fuses for Biscotti and variants.
The scripts are outside of TKās own directory. Perhaps because they can be used for anyoneās code, not just hers. Theyāre here (the bin folder).
Talking about Bistro, btw
I added the zero at the end of muggle mode group, and now Iām getting even weirder behavior.
Here is a paste of my code: /* * "Bistro" firmware * This code runs on a single-channel or dual-channel - Pastebin.com
If I go into muggle mode, it turns on both the red and white LEDs for no apparent reason. It doesnāt match up with my specified modes at all. The ānormalā mode groups function as they should.
Here is a demonstration video with the driver on my desk, Iām operating a normal omten off screen. I go through the third mode group a couple times, then enter config mode and go to Muggle mode. After a few seconds of it doing itās thing, I leave muggle mode.
edit: Iām not sure what changed, but I reflashed it and added input resistor and C2 from DEL findings, and now it seems to be functioning.
K, never thought of look'n there - thanx!! I'm using the 0x75 and 0xFF and it's working great!! The stock ThorFire BD04 driver uses a smaller value cap, bout 1.1 uF that I measured, and the mode switching was super tight/quick, very hard. Replaced the cap with a good 10 uF and now it's working real sweet!
PD68, try changing NUM_MODEGROUPS from 6 to 4. That number is supposed to be the number of regular mode groups (excluding muggle mode).
Though I canāt say how this would turn on both LEDs, I donāt see anything in your ramps that would allow for that. But I could see this causing some definitely unexpected behavior.
Today I spent multiple hours of troubleshooting one single driver.
Some weeks ago I modified a 105C into an 11+2 - AMC7135-dual channel driver and installed a Version of BLF-A6 on the t13.
In combination with 3x Nichia B-V1, I could easily tell that three AMC7135 werenāt working in highest mode. At first I thought I maybe left the second channel off - on purpose, running the Nichias 0,7 A lower, test a bit, get the light ready basically and maybe go with 0,7 higher anyways later onā¦
After I found the last of the three missing AMC7315 (defect) I rebuilt the driver and than found out that I had both channels full on at the highest setting, but TURBO-via-moon shortcut only enables channel 1.
I think thatās how the firmware behaves because it was mainly written for FET+n-drivers, right?
Would I have to tweak something in there for TURBO to enable both channels??
(EDIT: that should work, right? Will try that out tomorrow)
(EDIT2: For the record: āthatā does nothing good at all. What you want to do for Turbo to turn on both channels is this. Thatās BLF-A6 with Battcheck_VpT and a simple blink mode for FET+x*AMC7135 vs. n**+x**-AMC7135)
Itās funny, because I built very similar lights before and havenāt recognized this behaviour until today.
To get max output, max/turbo should be only FET, no 7135's at all. Goes for triples as well.
Hi Tom,
there is no FET on this driver. 11x 7135ās on one channel and 2x 7135ās on the other.
When I switch forward through the modes the highest mode turns on both channels when I set them both to 255, but when I go backwards from moon, Turbo only enables the 11 7135ās from the first channel. Iād like it to turn both channels on.
I think my tweak doesnāt work right. It enables both channels in TURBO, but TURBO timeout doesnāt work and the light acts weird sometimes (donāt know if this is related to the firmware or hardware)ā¦
Why not simply use a more modern driver with triple channels that does include an FET? Seems like a much easier option.
Even a typical FET+1 (dual channel) should accomplish the task, no? That is, unless youāre really dedicated to having a linear driver.
Sounds a bit like the Moonlight Special driver at Mtn, though Iām not sure why youād double up the 7135ās on the ālowā channel. Isnāt the point to have low output on that channel without relying on a crazy low PWM value (and being able to attain an even lower lumen output)?
Guys, I know, everyone has his opinion. Hereās mine:
I really like the new triple channel drivers from Texas Ace and PD and I will build some of them and put them to a good use.
Now, the point is, in this particular light Iām using 3x Nichia 219B-V1 in parallel. In my opinion itās just plain stupid to hook them up to a FET. This light is about light quality and practical usability. With around 4,5 A it makes enough lumens for my purposes and it doesnāt generate a crazy amount of heat AND the Nichias will live.
In fact, this is my favorite light, Iāve built maybe 4 or 5 of this type. All EE X6 triple Nichia 219B-V1, some at 5A but not more than that. I get around 1300 lumens, maybe a bit more, high CRI, very nice light quality at no more than 5A and I get that until the battery is empty, even a protected one can be used. That totally does it for me. Never had optics melted or cracked, Nichias turn blue, nothing of the whole Astrolux S41 story. With 219C R9050 Iād maybe want to go to 5,5A - 6A if I can get those chips stacked.
Speaking of more modern drivers, Iād love a driver specifically made for this purpose, 2 or 3 channels, all 7135, with proper layout, maybe stacked boards like PDās new design, but I havenāt got into creating my own drivers yet. Wouldnāt even know if all the new findings that DEL scoped out, would apply to 7135 drivers (R3, D1/C1 placement, additional C2 decoupling cap for the MCUā¦)
But thatās thatā¦
Right now Iām stuck with this stacked 105C that doesnāt go real TURBO. Well, now it does, but TURBO stepdown doesnāt work and the light does some other funny stuff. Will flash the non-tweaked firmware again, to see if this funny stuff is related to firmware or hardwareā¦
You can definitely tweak the firmware to do what you want chouster, making both channels turn on for Turbo is pretty easy. But you said the Turbo timer also isnāt working?
Yes, PD, the Turbo timer isnāt working since I made a little change to the firmware, but I donāt know much about that stuff.
Am I correct to assume that, with the standard Version of the BLF-A6 firmware, changing the highest mode of the 1x7135 channel from 0 to 255 would only affect the āsolid modesā highest mode, but not TURBO as a special mode that is reached with medium press from moon?
Sorry for spamming this thread again.
Ok, so I flashed the unchanged BLF-A6 version again, weird behavior is gone now, so that was introduced by me. But now itās the problem as described, highest solid mode, when both channels set to 255, does what it should and turns both channels on. Turbo as hidden mode however only gives me channel 1. Maybe Iāll leave it that way, if I canāt figure out how to change it properly.
@gchart
I doubled up the low channel, because I donāt care that much for a super low moon but I like having a 0,7 A PWM-less medium mode, instead of 0,35 A. Also for 3 Nichias in parallel they share the low current and I was thinking Iād maybe get a better tint for the low modes if they share 0,7A instead of 0,35A.
EDIT: Thought about it, I could just add 2 more chips to the first channel, making it 13+2 and leave the second channel at 0 for the highest mode. That way, I would add 2 chips more than I would theoretically need for my desired max current, but would have Turbo and the highest solid mode drawing the same current without having to fiddle around with the firmware. hmmmm, decisionsā¦
OK, just wondering. As long as you had a reason for doing it, works for me!
You havenāt changed the number of elements in the RAMP definitions, have you? Guessing you just changed the last RAMP_7135 value from a 0 to a 255. That should do the trick without any other changes.
TURBO is defined as RAMP_SIZE, which is 64. Thatās the same value that is used for the highest non-hidden mode, so there shouldnāt be any difference. Odd.