Ahh, no problem. Sorry, didn’t understand - what was the impact/effect of the slow cap charging?
Quick short presses just after turn on where measured as long off presses, and my normal long off presses where being measured as cold starts. I had to wait a short moment before doing mode changing. It was annoying enough for me to attempt solving.
Maybe I’m being slow this morning but with both higher voltage and higher R1, shouldn’t you end up with roughly the same current and charge time?
Ohhh, ok. I’m not a fan of OTC’s use for short/long presses. Just don’t see enough consistency. e-switch’s solve all of that.
That’s what I thought when I decided to go with 2M7 R1 resistors… but it gave me issues. Maybe because 2M7 is a little more than double 1M2? Issues are solved anyway, and now I don’t have to have a stock of separate R1 resistors.
Short and long are fine for me. Perhaps more stable because I have calibrated the voltage readings and use actual voltage levels as short/long off times? I don’t know, but I have consistency with both fully charged and almost depleted cells, and heat doesn’t have much of an impact on the components I have used.
E-switches don’t solve anything if the light doesn’t have an E-switch.
Another question, can I reflow this one
Attiny85
onto and replace the original mcu on
BLF X6 driver
Or
BLF A6 driver
And then flash Narsil onto it?
Is there any difference on the two drivers after the mcu reflow, besides lighted tailcap options on the X6?
No. That version of the tiny85 is physically too large, won’t fit.
That eBay one is a thru-hole, you need a surface mount, and specific size like this one: http://www.mtnelectronics.com/index.php?route=product/product&path=25_104&product_id=601, and note Richard's instructions about bending the pins.
Page 206 here: http://www.atmel.com/images/atmel-2586-avr-8-bit-microcontroller-attiny25-attiny45-attiny85_datasheet.pdf, you want the 8S2 package, and then have to bend the pins to fit.
I've used those from Richard, and these: ATTINY85V-10SU
Unfortunately you may have problems upgrading the BLF A6 with it's inferior components - might have to piggyback another 10 uF cap onto C1, or add a 0.1 uF cap across the grnd and Vcc pins of the MCU. The BLF X6/X5 driver is better, but not great. The BLF X6/X5 driver uses a 12 uF C1 cap, not 10 uF, so in theory should work with a 85 without adding anything else.
Thanks for the quick replies!
If I cut the trough-hole paws on the 85 and bend them over, maybe it can work?
Yes, I already ordered them before I posted :person_facepalming:
So X6 would be best for upgrade compared to the A6.
Do you guys build these drivers from scratch, using Oshpark boards? Even mtnelectronics or 3tronics doesn’t sell anything close…
Yes - I usually build from scratch with OSHPark. Sometimes though I've used Richard's boards that he sells bare. However I've also upgraded boards, such as Richard's fully populated SRK 7135 based drive. I swapped the two voltage divider resistors out to 220K and 47K (to lower parasitic drain), and swapped out the MCU. I didn't need to touch caps or add one - it just worked fine as-is. Here's some pics:
Those double stacked chips look like a work of art. For that matter the whole driver does. 
I know, right? …I bet Ouchyfoot cried when he saw that :weary: 
I thought of Of at the time and thought to myself dont go there.
Almost worth it - I got bout 15A out of it now, but not the 17-18A I was expecting. Still, I got 5300 lumens in mostly a 3D tint. Adding a UCLp gave it a nice bump 
.
Is this the right thread for comments regarding Bistro firmware?
If yes: please forgive if I am asking dumb questions which have been answered before, the thread is far to long to read completly in reasonable time.
I am currently testing a bistro driver with cpu clock lowered to 4 Mhz, built into a S2+ triple, and so I also checked temperature control. It didn’t work as suspected, first I assumed a dependency to the clock change, but there was another reason in code: when over temperature is detected, the output level is ramped down 1 step each 8 seconds!
This means, coming from highest level it lasts 80 seconds to reach a FET output of 50% and even 160 seconds for 25%. My triple will be melted then.
Is this solution really expected to work with any smaller light pulling more than 3 amps?
Mike - this might be the correct thread. As far as I know, Bistro has no dedicated thread, so it's either this thread or the firmware thread: https://budgetlightforum.com/t/-/32545.
The bottom line would be asking the author - ToyKeeper, and her firmware thread would be the better of the two since she created the other one.
I just looked the code over and it seems you are right - 1/2 second delay in the main loop, then the "overheat_count", incremented by 1, has to be greater than 15 to do an adjustment, and when it does an adjustment, "overheat_count" is reset to zero.
So it doesn't adjust for 8 secs, then only will adjust every 8 secs or so thereafter.
Also be aware it adjusts one "level" per drop-down adjustment, and there are 64 levels defined for the full range of brightness/output.
All I can offer for my explanation is that Bistro was written for single LED DD lights in mind, for the BLF SS/Cu X6 or Cu X5 class running at 4-5A. Also I can say others have seen this problem and tweaked the algorithm. You can bump up the decrement factor or bump up the frequency of checks, and/or add intelligence to do it smarter. Dr Jones got his own PID algorithm implemented for temp monitoring, but has not released it to the public. I heard Atmel has a sample PID in source code as well, but will probably not fit in to a 25's 2K.
Yes - you are right about the 80 seconds. Here's the top 11 levels for FET PWM values:
129,137,146,155,164,174,184,194,205,216,255
I agree, a triple in a thin tube light is a crazy design when it's fully max'ed out. I would never put one in the hands of someone who is in-experienced with these sort of things. Bistro is just the firmware, and not designed for this intended use, accept for the fact it's given out open and freely in source code, so the designer of a flashlight can mod it as they like.
You also might want to consider a turbo timeout - set the timeout to 30 secs, and it drops one full mode, which could be down to 35-40%, depending on you mode definitions, but of course temp monitoring has advantages for more circumstances.
In my lights I’m using my own driver software anyway but this driver is used in mass production lights meanwhile, and perhaps it might be safer to implement a configurable turbotimer than a temperature regulation which won’t work with many lights.
Oops, was still editing, repeatedly.... Again I put responsibility squarely on the manufacturers. TK has not made a penny on the use of Bistro by the Chinese manufacturers. The BLF group buys are one thing - buyers know or should know, but when the manufacturers turn that into a commercial light, it's all on them.
I agree regarding the responsibility of the manufacturers but often I doubt they know what they are doing …
Made some progress over the weekend on implementing/adding a ramping mode to Narsil. Testing it in a SupFire M6. The ramping is pretty much fully implemented, but it breaks all the other UI stuff for now, til I work it all out, like the lock-out, entering configuration modes, displaying battery voltage, toggling the locator LED, etc.
I used posts on BLF by ToyKeeper and blueb8llz as a guide for implementing how it works. I'll be providing more details.
One note is I'm currently using 64 levels spread over 3 seconds to fully ramp the range. I tried 2 seconds at first, but could not stop at moon mode. With 3 secs, it's fairly easy now, but just not sure if 3 secs is too slow. Maybe 2.5 or so is bout ideal -- not sure. Certainly it's all touchy/feely issues, probably a lot of personal preferences thrown in.