I hope you bought 1uf for the OTC, that’s the one that handles switch timing, not C1.
Hi pilotdog68,
Thank you for your heads-up! Actually, I bought a bunch of Samsung CL21B105KBFNNNE (0805, 1µF, 50V, X7R) capacitors. If you hadn't told me I would have swapped the C1 caps -- oooops. But instead, I'll need to change the one next to the red cable, correct?
Thanks again! This forum is great! :-)
(BTW, isn't the cap next to the positive wire larger than 0805?!)
they should all be 0805 sized. Some of the BG driver boards are mislabeled though, so they might have the OTC labeled as “C1” or vice-versa. You want to change the one that connects to Pin2 of the MCU. C1 is only connected to Pos+ and GND.
edit: I looked at some pictures in the other thread, and it looks like BG switched the OTC to be 0603 sized. Your 0805 size will still work, but it will be bigger than the one you are replacing.
You want to change the one next to the 7135 chip, not the LED+ wire.
I change out the OTC cap on all the BG drivers, all of mine have had horrible issues. As was said they are 0603 but you can use 0805.
Thank you guys for the quick answers and the clarification! :-)
To sum it up (in case somebody bumps into the same problem again -- which I assume will happen sooner or later as those BG drivers are absolutely not usable for medium presses imho...):
- You need to desolder the off-time capacitor which is (falsely!) labeled as "C1" on some (at least all of my) boards in order to be able to use high voltage programming for the fuses (which are messed up so that normal programming does not work.). This cap is connected to pin 2 of the Attiny25.
- The removed capacitor can/should be exchanged for a less temperature sensitive one. I chose a 1µf, 50V, 0805 size capacitor with X7R temperature rating.
- The capacitor which is soldered directly next to the red wire does not need to be touched!
Thanks again and best regards! :-)
Wow, thanks! I should definitely read all your posts (and probably step up my searching game in this forum). It seems you already have thought about all questions I asked and found solutions/answers to them months ago. ;-)
I'll give the "high quality" caps a shot and if they don't work to my satisfaction, I'll try your solution as soon as I find the time to incorporate it in the Bistro code.
What FW are you using at the moment?
I’m using selfbuilt firmwares.
Yep, I have flashed a flashlight firmwares before and got the tools. Many thanks!
This is the modified bistro I am using in my X6R build. (feel free to use it for your own projects, of course.)
paste link
For some reason I am getting my hidden modes mixed up in my muggle mode group. Like, still not reversing through them, they are just part of the mode group. What could be causing that?
Muggle mode does not have reverse modes, hence the point of muggle. lol
I know, but it’s not supposed to integrate your Normally hidden modes into the mode group, is it? That’s what it’s doing. My muggle mode is supposed to be 2 red modes and 3 white modes, but it is ending up as those 5 with two more red modes, batt check, and ‘off’ all in the normal rotation/whatever. It only happens on muggle mode
Very strange, no idea why the hidden modes would do that. Most likely a syntax thing in the mode group section if I had to guess.
Like TA said, that’s very strange. I don’t know for sure, but I do have a conjecture.
In count_modes, it looks like we always add hiddenmodes to the modes array. As long as solid_modes is correct (5 for your muggle mode), next_mode should wrap before hitting the hidden modes. But if solid_modes gets off somehow, it’ll scroll through the hidden modes. When counting solid modes, we stop whenever we hit a zero value in the modesgroups array. The muggle set is the last line, the one we’ve been treating special (leaving off the extra zeroes). It works as long as you end the line with a zero. But in you modegroups, it ends in a 9… so it keeps on incrementing solid_modes.
TL;DR - I bet if you add a 0 to the end of your muggle mode array, it’ll work just fine
(unless that 9 was a typo and supposed to be a 0)
No, it was supposed to be a 9, but I’ll try adding a zero after it. That makes sense, thanks.
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.