No it’s not for my lighted tailcap. I’m very sure it’s 1uf. I already replaced it twice with 1uf to be sure but still the same problem.
If you try the calibration does it ever drop below 255?
It is possible there is a short somewhere keeping it charged.
Another option is you could try putting the C2 0.1uf on the OTC to see if that gets it working.
This is why I want to get the OTSM setup working in bistro so we can do away with all of these issues. I am fed up with all the OTC issues, no matter how good the components you have to pick between it working correctly cold or hot, both doesn’t seem to be an option with any of the half dozen caps I have tried.
Yes it drop below 255 but only after 3s.
I don’t have 0.1uf.
I have the same hardware used with my fet+1 driver but with blf a6 firmware and the med tap is working normal. The only difference is the additional resistors (R3, R4, R5 on TA driver)
Maybe because I used 10uf on C2? I don’t have 0.1uf and I read here “If C2 is not used, C1 should be moved over to its position.” I’ll put back later the 10uf from C2 to C1 and see what will happen.
Well seeing as that is the only difference from a hardware standpoint I would do that. Since C2 is after the diode it could very well be dumping it stored power into the OTC and thus extending it’s time.
We really need to get the OTSM working on bistro, that fixes all these issues.
Problem solved! The culprit is indeed the C2 10uf. I put it back to C1 and now the med tap is working normal 0.5s.
Looking forward to that OTSM.
Thanks
LightRider - that "stuck in low mode only" behavior sounded familiar. I believe it happened and was reported on with Biscotti in the Clear C8 thread.
Found it in Post #669 in this thread: https://budgetlightforum.com/t/-/41544e, but he describes it as a sub lumen mode.
Come to think of it, I had a stuck in moon mode issue at one point, it turned out that I had put the diode on backwards. I have no idea how the MCU was getting power at all in this case but it gave me a very low moon mode only.
Hmm… ya, idk? In the middle of configuring turbo it just locked up. But it reflashed with no problems and is working now:) I tried to repeat the problem after the reflash but was not able to.
What could be the issue if I did not use C2 on my TA driver with bistro firmware? I will be using it in my triple led flashlight.
The signal will not be as stable and there is a possiblity of the voltage spikes reaching the MCU and causing reset issues. I have never tried it to know for sure but it should work ok but better to have the cap in place.
Where the brown out detection fuses set or not set when you flashed it the first time?
Well… I don’t even really know what that means. 
No worries 
When you flash the firmware, there are so called “fuses” that get set. If you are using avrdude the fuses look like this in your flash bat file (on the line that starts with avrdude):
-U lfuse:w:0xe2:m -U hfuse:w:0xdf:m
In the above case the low fuse (lfuse) is set to e2, high fuse (hfuse) is set to df. What are these l and h fuses set in your bat file? Just paste in your avrdude command line and I’ll be able to see for myself.
These are the fuses I used when flashing through avrdude. They are straight from tks bistro tripledown .c file. So not sure if it’s correct or not?
Low: 0xd2
High: 0xde
Ext: 0xff
Thanks. The brown out detection at 1.8V is enabled with those fuses. In that case my guess about what your issues could have been are probably incorrect.
I don't know. It's not clear that we've established that 1.8V is a valid BOD level for non V chips. It seems to me corruption could be possible on random chips at that level if that's what you're getting at.
Are there different fuses that you would suggest using instead?
Not sure who you're asking. I think Mike C was getting at the possibility that if BOD is not turned on the chip can run at voltages where it starts to operate unpredictably and anything can happen, including I guess (not sure) corrupting some memory (my guess of his idea). I guess your fuses are pretty typical.
My point, and we discussed it earlier, is that it is very unclear in the documentation if the 1.8V brown out detection is actually guaranteed to prevent this for the chips that are not rated to operate that low, ie the standard non-V chips. I guess the fuse to suggest then could be the one corresponding to the 2.7V BOD. I'd have to plug it into a fuse calculator. The BOD threshold has a loose tolerance and this could marginally impact how low you can take your battery. More importantly it would limit the ability to run at low voltages for this new off-time trick, OTSM or whatever we're calling it.
Still, it's just not clear (to me at least) that setting BOD at 1.8V is really "legal" or entirely safe. I don't think there's wide spread evidence of any problem with it. But that doesn't mean there aren't occasional problems with it either.
Yeah, you are both right, it’s corruption I was thinking about. When working with the OTC less design I had some intermittent issues while stress testing that I couldn’t explain or weed out, no matter what I did. I saw erratic behavior maybe once in 20 or 30 continuous off presses of different durations. I finally managed to figure out that it was flash corruption after one of my mode bytes got corrupted from 10 to 255 (or close). During this test I was not using EEPROM at all, all modes where hard coded, and having the light off for extended period didn’t reset it. So that particular mode byte in the FLASH memory had been corrupted while everything else was OK. Other times the light wouldn’t start, wouldn’t change modes etc etc, even after having it off for ages, and I couldn’t figure it out. That single corrupted mode byte was the key.
So I enabled brown out detection at 1.8V (I am using 85Vs) and have stress tested it for ages, and all those weird issues I’ve experienced are a thing of the past. Now I’ll get a brown out induced reset as soon as the voltage drops too low. Brown out detection does draw power though, so I’ve had to increase cap capacity. 100uF can give me a second or so, but almost all of my driver designs can actually fit 1206 caps so I can go higher. Only one driver couldn’t fit a 1206, but it could fit another 0805 so on that one I’ll be using 2 x 100uF 0805 caps.
In a normal flashlight when you switch the voltage off, the MCU looses power rather quickly. With the OTC less design the MCU lingers a lot longer in that low voltage danger zone, increasing the chances of these kind of issues, but it got me thinking that the corruption probably still can happen on a standard OTC driver with 2.7V MCU, perhaps with near drained cell, turbo mode and/or multiple off clicks after the other. The chance of corruption issues with a normal OTC driver is much smaller than with the OTC less design, but still possible I think.
Depends on the firmware, and I haven’t looked into the other firmware versions that are out there. If the above is what happened to your driver, than you would have to be using the standard 2.7V MCU. You could set brown out detection at 2.7V instead of 1.8V by setting the high fuse to 0xdd. I’m guessing that there won’t be any changes to overall functionality of your driver, but I won’t guarantee it so you’d have to do some testing.
I’ve been listening in and even though I have no clue, trying to learn a bit. So basic question, are 1.8 and 2.7 minimum opporating voltage for different mcu’s? Then the fuses should be set according to the minimum mcu voltage? Speaking in general. As it sounds it’s not always that simple…