Thanks Hoop. I'm pretty much speechless. Just gotta say love the garage. 
I’ve run into a problem, I’m not sure why.
I built up one of these: DD driver w/ low parasitic drain for e-switch lights. I used 10uF for both input and output capacitors on the LDO (a 3.3v LT1761).
Then I flashed it with STAR_momentary w/ voltage-mon disabled. (how do I properly refer to the commit I used? Is there a concise way to communicate this information? ba5fb9efbd5ad11e0edd4008123301532ac0a277 ?) (for my own reference - 2014-12-20_STAR_momentary_v1.6+no-voltage-mon.hex)
The problem is that in the highest mode (Turbo) only a long press works. A short press doesn’t switch from Turbo to Off. I can step through the modes forward as expected - 0,3,14,39,125,255, but it does not loop from 255 to 0. I can step backwards 255,125,39,14,3,0 and have it loop from 0 to 255 as expected. Turbo does have an MT-G2 at >8A, but I don’t see how that would have an effect on my momentary input to the MCU, especially when we consider that it does recognize the long press. Any ideas? Thanks!
Crap, that sucks. When you are in turbo and a short press doesn't turn it off, will another short press bring you to the first mode? I remember there was an issue with the PWM output not getting set to 0 before going to sleep for some crazy reason that makes me hate AVR programming, which is why I added this stupid line of code...
_delay_ms(1); // Need this here, maybe instructions for PWM output not getting executed before shutdown?
That seemed to fix it, but maybe it isn't enough. Are you able to (I hope!) reprogram the driver with ease? Maybe you can try commenting out the "sleep_until_switch_press()" call when it shuts the light down for being at the 0 index mode and see if it works then. This is not a solution, but it will be a way to debug it.
Thanks JonnyC! Good question, I didn’t connect the dots on my own. This is such a high current setup I can barely get my thoughts together during my brief, brief tests.
Yes, two short presses takes me to the first mode. I can go back to “off” with a long press. It seems that the problem is exactly as you suspected.
Unfortunately the driver is in a difficult to reach position. (oops!) I’ll build another for testing. Once there’s a solution I can take the other out and flash it. 
I’m eyeballing the sleep_until_switch_press function now. I guess this is the sort of thing where the debugger that was recently discussed could be very useful; many important things happen in that function and in the WDT_off() function it calls.
I guess you suspect that a slightly longer delay could band-aid the situation?
Son of a beach!! It was an actual bug. On December 13th I added an extra mode but did not add the corresponding "FAST" to MODE_PWM. Not sure exactly how it manifested itself in this behavior because I don't know how the code would react to an array index out of bounds. Whatever the case, it broke it.
Please pull the latest copy or just add another "FAST" to the MODE_PWM list. Sorry to anyone that this affected!
I just ordered some 1uF 0805 caps for off-time memory but I also have a cap from a stripped nanjg of mine and I wonder if I can use it for this? What are the specs of the standard caps on a nanjg?
It’s been said that it’s a 10uF cap. I’m confident it’s >4uF. 10uF may work fine, but you’ll probably need to adjust your offtime value. EDIT: for some additional info, look in the first 5 pages or so of this thread for HarleyQuin’s post(s) on the subject. HarleyQuin tried much smaller values than 1uF and was able to get those to work.
Caps on my seven 105Cs (both 8x7135 and 6x7135 versions) are all in the 3.5-4.2uF range
Heh, maybe I should have been confident about a different number.
I tested somewhat recently to see when the ATtiny13A would start working properly. Now that you call me out, I think I tried 1uF, 2uF, 3uF, and then got tired and went directly to 5uF. Ahh, here we are: Phase Correct PWM So much for confidence! 
AK-47A 3x7135 with the same ATtiny13A has 1.6uF capacitor Guess it depends on the load for ATtiny to drive.
On the other hand, 101-AK-A1 4x7135 has 7.5uF cap…
BTW, it’s a good idea to use PHASE on the highest and lowest mode. This prevents the moon-like fast PWM=0 mode from sticking around while the switch is pressed, and helps the light to shut off entirely.
On the lowest mode, PHASE can usually get lower than FAST, so that’s a benefit. And on the highest mode, PHASE and FAST are no different so you may as well use the one which won’t trigger the moon-while-pressed bug.
Out of all the firmwares I’ve made, the Ferrero_Rocher.c one is the most similar to base STAR. It might be worth a look in case there are any improvements you’re interested in. The main things are UI (press-and-hold ramps down and shuts off) and a battery check mode (from off, short-press then immediately long-press).
Has anybody looked with an oscilloscope if PWM 255 is 100% on?
Edit: I found the answer by changing my search words. PWM 255 appears not to be 100% on: Test/Review of Qlite Rev.A 7135*8 Multiple Modes Circuit Board 3.04A
On the graphs there, I see a small dip in the PWM each cycle on the highest mode. The qlite runs in fast PWM mode though, which I’ve had a suspicion might do that. Just like it always turns on a little bit even when the value is zero, I had heard that it might not stay fully on in turbo. It’s hardwired to turn on at the beginning of each cycle and turn off at the end.
However, I think phase-correct PWM is better about that. It never turns on at zero, and I think at the other end it also never turns off when the value is 255. We could probably verify by measuring lumens on fast PWM=255 vs phase-correct PWM=255, but I’m not sure how big the difference would be.
Yes, Qlite is never 100% on because they must have used inverted PWM, meaning inverted output values...
0 = On
255 = Off
From the datasheet...
With fast PWM, a 0 PWM_LVL (OCR0A) means it is never fully turned off (there's 1 blip of being on out of 255 clock cycles). In Qlite's inverted PWM case, 0 meaning max output, it means it's never fully on, but it can be fully off. We are using non-inverted PWM, so it can be fully on, but it can't be fully off. This is taken care of with putting the driver to sleep so we don't allow the light to run with PWM_LVL = 0 (except as you noted ToyKeeper, it happens when you hold the button to move to the off mode, as long as you hold the button it will sit in this state). I believe this should only happen when the mode order is H-L, correct?
I took your advice and updated the 255 mode to be PHASE. I can't test it because I don't have a FET driver, but you already said it works. I could have also been done by changing the code so that it forces PHASE whenever PWM_LVL is 0, but this is an easier fix.
That's for the Qlite, not this firmware. I should bust out my nifty little pocket oscilloscope if I can remember how to use it. As I noted above it should be 100% on.
It happens at either end of the scale (and with either mode order), but it’s really hard to see after turbo unless the button stays pressed for quite a while. Regardless, using PHASE on both ends eliminates the issue.
I normally set PHASE as the default anyway though, and override it only for specific solid modes. This lets me turn the emitter off entirely during strobes and such, without having to mess with special zero-handling all the time.
BTW, I added a very simple firmware to help with calibrating voltage readings. It’s ToyKeeper/battcheck/*.
All it does is read out the raw attiny voltage value. When connected to power it’ll briefly blink once, then it’ll take several voltage readings (without load), then blink out the value one digit at a time. So, for 183 it would blink once, pause, blink eight times, pause, then blink three times. Wait a few seconds, and the cycle repeats with a new reading. It’ll keep doing this until power is disconnected.
It’s useful only for calibration. Measure a battery in a DMM, put it into the light to get an attiny reading, let it run a few times to get an average, then write it down for later reference.
So far I’ve only tried it on two drivers, and they get nearly identical values. One was a Ferrero Rocher (similar to BLF17DD) and the other was an AK-47 (one-sided nanjg variant).
Not a bad thing to do.
I did something similar but took values under load and wrote them to memory every 5 seconds. A long press reads out the latest stored value in a similar blinking fashion. Useful for checking voltage state under load.
Happy new year to you all! :party:
This is amazing. I’m busy for some weeks - heavy workload and some truly desired holiday - and everything’s different.
I feel like a toddler who is trying to keep up with a bunch of 5y-olds… he doesn’t stand a chance, but he truly has fun. 
On Nov 14th I downloaded what was supposed to be Star Offtime 1.3 (dont remember the source) but that one hadn’t the DualPWM parts.
Now I downloaded StarOfftime from JonnyC’s GitHub page (titled version 1.2 but changelog to 1.3) and #wham# major change.
I very much like the idea to use at least two different outputs, but there are some code changes coming with it, that I don’t understand. I hadn’t fathomed all of the previous code - only the parts I needed to adapt - but now I’m lost at some crucial parts. I already see that what I want to do (using one 7135 at 255-PWM as medium mode) will come into conflict with the DualPWMStart threshold, as I need full PWM in the ALT_PWM_LVL signal path. It seems the Voltage Monitor, who uses the ALT_PWM_LVL, might get a hickup too…
But before I start asking questions that are already answered:
Are the software changes to dualPWM discussed anywhere? I just scanned the last 400 posts of this thread - as well as some of wight’s driver threads - but the FAST_PWM_START / DUAL_PWM_START / ALT_PWM_LVL changes to the code either came completely out of the blue, or I missed it, or they are discussed elsewhere.
I’d be very happy if you could give me a heads up - or if I may ask one or the other question about the code in this thread, when I’m stuck…
Thanks a lot.