Hhmm... I really like the low-ness (is that a word?) of the 2 value. Stupid me didn't fully test it out before assembling the X6R, so might be stuck with no moon mode for a while. Too many other lights to update. Great though I can simply re-configure it to eliminate moon mode. Want to do a lot more of course - endless # of ideas. Also need to install TK's bistro and play with it.
I'm finding the 85 mod upgrade is going pretty smooth. Here's what I do for the FET+1 13A drivers to upgrade:
use my slow hot air gun (stamp heat tool) to remove the 13A MCU
bend the 85 pins in, try to keep them even - they bend quite easy
clean up the pads: use solder wick w/extra flux to remove old solder, clean up with isop. alcohol
dnld the firmware to the MCU (MCU is air clipped in)
use a decent amt of solder paste on the pads, then use my stamp heat tool to reflow the MCU on
I continuity check every used pin (6 of them) - sometimes find a poor pin contact, and touch it with the iron with solder on the tip to fix it up. Even with the bent pins, it's a real tight fit on those pads.
After getting a driver into a light & messing with testing it for the last few days, I decided to pop it back out & re-flash with a Moon value of 2. The LED is an XP L HI. It was brighter than I expected, but still a very nice usable Moon. I reckon I could have used a value of 1 & it would have been fine.
Ahhh, that PD68 looks real good, in sizes of 17, 20 , and 22 with the 20 and 22 to fit 45/85's. Gotta order some - they will do for sure. Looks like no pads for zener or LDO, but zener should be do-able, not sure how to jury rig up a LDO - have to research/look around.
Just searched for this discussion as I’ve just come across a few things.
I’m working on my dual switch firmware that has multiple UIs and other stuff, and use a few noinit variables extensively. I’ve just spent the last three hours re-writing code to weed out bugs, but they just wouldn’t go away, like loosing E-switch, strange UI changes and so on. I’d only get these bugs if I was rapidly switching modes with off button, and as I have E-switch, off time cap and voltage monitoring on the same pin I naturally thought the bugs where related to this setup.
Then I remembered that I’d turned off the brownout detection fuses, so I turned them back on… and all bugs vanished. Notice that I did not get the bugs under normal operation, noinit variables where working fine, it was only when I started to stress test the mode changing a little that I started to get really weird behavior. So, depending on what you are doing, the brownout fuses can make a difference. Just thought I’d give you some heads up, because I was tearing my hair out until I figured this out.
That’s actually really handy to know about. I had also been trying to figure out whether brown-out detection was necessary. I’ve occasionally seen really strange behavior that I couldn’t trigger again on purpose, and I wonder if this might be why.
Wait, I'm confused. Even with OTC is it standard to turn on brownout detection? I' thinking I've seen flaky probs also with NOINIT, using th power switch to change modes but with my e-switch firmware, but really haven't tested it much. I got it on a X6R and a Y3 now.
Totally unrelated - Dale reported in TK's firmware thread I believe, a problem with high amps and a 25 MCU, think with multi parallel LED's. I'm having problems now with an 85 MCU with high amps in a FET+1 based driver in a SupFire M6: 4P cells with 3P LED's. I haven't narrowed/isolated the problem down, but seems to work fine on a poor cell like a TrustFire. I gotta begin to isolate it - could be anything to do with this driver at this point. It was fully working 100% with an older FET driver, and I replaced it with a 22mm FET+1. Did my usual careful continuity tests on this driver and all looked good. Also the driver tested fine on the bench with 1 LED. I could try:
wire up only 1 LED, not 3
replace FET (SIR800DP high performance)
85 MCU? Maybe the firmware?
Dunno - symptoms when it flakes out seems to be problems with FET PWM modes, and seems like the MCU goes out to lunch - gets stuck in blinking state, etc. Maybe I should try turning on brownout detection...
To clarify, I’m using the noinit variables for variables that I’d like to keep track of during short to medium off presses (like mode programming and voltage under load). I do not use noinit variables for off time detection at all any more, I found it too unreliable (was getting 10 second decay periods on some drivers). I use the noinit for short term memory storage only, and found that I certainly need to enable brownout detection fuses for stability, atleast when stress testing.
If you are getting brownout errors during normal operation (i.e. cells are good/charged) you have more serious problems hiding in your driver/firmware/hardware.
Did you un-edit your post just because I quoted the original version instead of the edited one? … the timing just worked out that way — I hit quote, got distracted, finished my post, then found I had an out-of-date version. But now it seems to be re-edited back to the original.
Just curious. There are, of course, plenty of other explanations which have nothing to do with me.
I don’t think I saw that post, but I’ve seen issues sometimes under high load. The symptom I see is different though — the MCU appears to suddenly reset or reboot and acts like I did a short-tap on the button. And the issues only happen with a full high-amp cell on a high-output mode; it works fine with weak or low-voltage cells and on lower modes.
I don’t know if it’s at all related to brownout detection. Like, maybe the sudden emitter draw pulls enough power that the MCU briefly starves or overloads? I really don’t know. The easiest way to trigger it is to go to a strobe mode with a full 30Q cell.
Oh shoot, thought Dale said you were look'n into it. He was doing a triple quad mod on I think a sample X5 (maybe?) with the 25 driver, and ended up swapping the driver, then it all worked fine. It might have been in the big X6/X5 V2 thread, not sure now... Darn should try to find it...
Haven't had any glitches with the 85v & Tom's eswBrOutCfg 10-28 firmware, but I haven't tried it with a multi-emitter high-amp setup yet.
After reading the few posts above on my 'phone today at work, I thought I'd open up my 5* XML2 SRK with the BLF DD driver in it, & swap out the 13 for the 85v when I got home.
... in my haste to try it out, after doing the swap & re-flashing, I realized that it wasn't a Fet+7135 driver... I'll have to go through the code & change all the values to suit the single channel FET, & see how it goes.
No. It’s the use of variables in the “ attribute ((section (”.noinit”)))” variables that survive short/medium off-time presses that can cause issues if brownout detection is disabled.
If I removed “noinit” variables, resorted to EEPROM writing and disabled brownout detection: No issues.
Or if I kept using the “noinit” variables but turned on brownout detection fuses: No issues.
It’s the combination of using “ attribute ((section (”.noinit”)))” variables without brownout detection that caused weirdness under some conditions. I’ve now stress tested both of the above working combinations with no issues what so ever. So no, no serious problems at all.
Yep, that’s typical me… I write a post, and then edit several times, hoping no one quotes me in the meantime. I wasn’t fast enough this time, so to keep consistency I just copied back the original text.
Funny how it usually looks good in preview.