I was hoping someone else might confirm/dispute my findings. I could easily be wrong…
-JW
Hi JW,
I tested it and cutoff works. You might just not have reached cutoff-voltage.
I downloaded STAR ontime v1.1 (as of today, 03/29/2014), flashed it and tested with an 18650 2250mAH cell that has a resting voltage of ~2.8V. Ramping (#define ADC_LOW) starts immediately, but as the lowest level of ramping is reached, voltage sag is minimal. So it took a while until cutoff level (#define ADC_CRIT) was reached. That was at 2.77V in my case.
Perhaps the cell you used just has too much power left. For testing the voltage monitor you could change the values for ADC_LOW and ADC_CRIT to higher values, say 145 and 135. Thats what I do when I fiddle with the code and want to confirm the cutoff still works. I frequently test this, so I have this abused cell at hand all the time. Cutoff is crucial to me, that’s one reason I am so extremely happy with this firmware.
Hope that helps, and thx for your own work in this.
HQ
…I was hoping I’d missed something (didn’t want to be opening a big can of worms for anyone).
That’s what I get for doing all my tinkering late-night when I’m really tired.
Since my 30-year old bench supply gave up the ghost, I’ve resorted to using a partially depleated CR123 primary for testing low battery operation.
I have - as you suggest - been setting ADC_LOW and ADC_CRIT values accordingly for function testing, but I must have missed something due to being tired.
I’ll repeat my testing again over the weekend (hopefully) and see what happens.
Thanks for setting me straight,
-JW
Sorry, I was away from a computer for a few days. The original logic is correct, as you want to wait until you hit the ADC_CRIT low voltage level. Taking out the "not" (!) will cause it to skip the loop. If you want it to function that way, just set ADC_LOW and ADC_CRIT to be the same.
I'm gonna ask some utterly silly questions, which will probably make about as much sense as asking 'how much does the color blue weigh?'
What's the relationship between CPU speed and the PWM - is fast PWM only available with 9.6MHz clock, and phase correct only with 4.8MHz? Is that set by the 'F_CPU' line in the code and the lfuse used has to match what's in the code, or is it controlled by which fuse settings you use?
I'm just confused because it seems like the comments in the code are contradictory, I don't know enough about it to tell if it's a mistake, or if it doesn't make sense only because I don't understand it.
Messing around with the FET drivers that like everybody else I assumed only worked with the phase correct PWM, but finding that they do work with fast PWM (both the momentary & clicky versions are by default using fast PWM, right?), I want to make sure it's doing what it's supposed to.
Tested again today and low-voltage shut-off did in fact work correctly with original code (smacking self on forehead repeatedly…).
I apologize for causing any unnecessary concern on the subject.
@ JonnyC-thanks for the clarification.
-JW
CPU frequency and PWM mode are independent, PWM frequency depends on both.
In fast PWM, PWM frequency typically is CPU_frequency / 256, in phase correct PWM it's half (CPU_frequency / 510 actually).
CPU frequency is determined by the fuses. The F_CPU just tells the compiler that frequency so it can do some timings right, mostly the delays.
comfychair, I tested several variations and made a table, which might be of some assistance:
| PhaseCorrect | FastPWM | |||||||
| kHz | CPU freq | divider | fuse | CPU freq | divider | fuse | ||
| 1.2 kHz | 4.8 MHz | :8 | 0x65 | |||||
| 2.4 kHz | 9.6 MHz | :8 | 0x6a | 4.8 MHz | :8 | 0x65 | ||
| 4.7 kHz | - | - | - | 9.6 MHz | :8 | 0x6a | ||
| 9.4 kHz | 4.8 MHz | :1 | 0x75 | - | - | - | ||
| 19 kHz | 9.6 MHz | :1 | 0x7a | 4.8 MHz | :1 | 0x75 |
CPU freq is set by the fuse (Low Fuse bit 0 and 1) and “#define F_CPU” should be set accordingly.
PWM is set by “TCCR0A = 0x23”, where 0x23 is FastPWM and 0x21 is PhaseCorrectPWM
The divider is set by the fuse (Low Fuse, bit 4) and can be :1 or :8
And you can combine them all.
This way you can reach 19 kHz with Phase correct PWM and Fast PWM.
In addition you have the prescaler (“TCCR0B = 0x01”, where 0x01 gives :1; 0x02 gives :8 …) which is not the divider you set with the fuse. You can combine divider and prescaler and set them differently.
Both clicky firmwares (Star ontime and Star offtime) as of now use by default Fast PWM “TCCR0A = 0x23”. I can’t tell for the Star momentary firmware. Never used it, yet.
Both clicky firmwares are set to “#define F_CPU 4800000UL”, so I use fuse 0x75 (or change both) This fuse calculater is extremely handy to understand the fuse settings.
Star momentary also uses 0x23 by default.
Thanks HarleyQuin, You clarify my confusion of the prescaler and the divider.
Excellent info Harley!
I think Fast PWM vs Phase Correct confused the issue. For our purposes, it shouldn't matter which one we use, it's just a matter of what PWM frequency we want in the end. Fast PWM allows us to almost double the speed without any CPU of clock changes. I believe the whine we hear from switches and other components is strictly related to the PWM speed, not relative to whether there is phase shift in the signal (which doesn't happen at a constant PWM value either way).
So, both STAR clicky & momentary are using 4.8MHz CPU clock, and 19kHz fast PWM, when using a lfuse of 0x75.
Anybody else tested fast PWM on the FET drivers, specifically the momentary version? It seems to do everything properly for me. I think originally the momentary firmwares were all using phase correct PWM because they were being used on 7135 drivers (master/slave stuff in SRKs, replacing the original driver), and the 7135s don't turn off completely in the 0% mode when using fast PWM.
I have two new BLF-SRK drivers assembled (using only the bare minimum parts, so no inductor/flyback diode/capacitor), planning to test them both side by side, one using the default fast PWM and the other changed to phase correct, just to see what they do different in actual use.
Sorry, can’t say anything to the FET drivers, following with much interest, though.
Concerning the PWM-whine: I tried all these frequencies in hope for finding one I like better. I had high hopes for the 9.4 kHz one, but it also whines. The lower frequencies do whine as well, as was expected. I can confirm that the whine does occur in the driver and in the switch.
I tried an even lower freq by using divider “:8” and prescaler “:8” (I think that gave ~150 Hz) just to have tried it… doesn’t look too good.
Both 19 kHz variants, PhaseCorrectPWM or FastPWM, are silent - at least to my ear. The high frequency has the disadvantage of dropping out of regulation early (especially in mid and low modes), as HKJ has stated when testing the Qlite driver. He measured 16.5 kHz, by the way.
But when I have to choose between the devil and the deep blue sea, I prefer my driver to be silent.
From another thread...
Now that’s a looker, two to be precise…
I think I posted about this in another thread but I can't remember which! I haven't tried it lately but when I was first testing out the STAR momentary with an FET it worked just fine with fast PWM but the low mode was about twice as bright as what I get with phase correct. I haven't tried it with the resistor in place to see what that does, although the 200 ohm resistor I'm using now does seem like it may make the lower modes slightly lower than without it.
Both those SRK drivers are using no extra resistors anywhere, tested with only the Nanjg parts plus the FET. (I added inductors and the big diode to both before installing them... oh, and also went back and flashed the noisy one with the quiet FW)
I don't see STAR momentary posted anymore, anywhere? Thought JonnyC find an issue/bug, maybe posted here, but Richard's OP doesn't have the link anymore, and JC's website doesn't have it. Any ideas? Got to add strobe to this driver and just want to make sure I got any possible bug fixes.
???
Ohh - was wondering if this SRK driver is the STAR Momentary driver... Just a confusing name I guess, or STAR_mom was confusing... hhmmm... 
Would be interesting to see what JC comes up with for dual switch support. I have ideas, but no time of course... Adding strobe to STAR_mom is a little challenge. Have to convert what was in luxdrv as a forever loop to a state machine. Shouldn't be too bad, but no way am I as efficient as the doc, but still have plenty of program space left, so can afford to be somewhat wasteful.
Update: Actually it's easier than I thought. In the while(1) loop for strobe, all you have to do is add a check if the user changed the mode via a click, and if so, exit the while (1) loop. Bottom Line: 2 lines of code to add, add a variable "mypwm", and use a special value of PWM to indicate strobe (254 for example).