STAR Firmware by JonnyC - Source Code and Explanation

Use “pre” and “/pre” tags around the pasted part (substitute quotes for angle brackets, of course)

That works fine, thx!

As a workaround I comment out turbo and activate WDT by default. Voltage Monitor still works that way.

// #define MODE_TURBO
...
// Don't even bother turning on the WDT if turbo is not enabled
// #ifdef MODE_TURBO
WDT_on();
// #endif

I just tried removing all parts with turbo and turbo timeout - at the moment I don’t need both - which seems to work, but I don’t understand this segment:

ISR(WDT_vect) {
    static uint8_t ticks = 0;
    if (ticks < 255) ticks++;
#ifdef MODE_TURBO   
    if (ticks == TURBO_TIMEOUT && mode_idx == (mode_cnt - 1)) {
        PWM_LVL = modes[--mode_idx];    // Turbo mode is always at end
    }
#endif
}

What function has the ISR-part (first 3 lines (and last bracket))? If I don’t need turbo and turbo timeout, I can remove lines 4-8, but if I remove the ISR-part as well, the voltage monitor is again gone.

Thx for your kind help.
HQ

Harley,

You discovered the same issue I did :) See the "sleep_mode()" at the end of the file? That will trigger the driver to power down until the WDT wakes it back up (within .5 seconds), which is set up with this code:

// Enable sleep mode set to Idle that will be triggered by the sleep_mode() command.
// Will allow us to go idle between WDT interrupts
set_sleep_mode(SLEEP_MODE_IDLE);

If the WDT or associated ISR is disabled, then it will never wake up and never check the voltage level. We really could remove the "sleep_mode()" at the end, but then there would be no waiting between battery level checks - it would do 8 in rapid succession. What I just realized now is that it might take up to 4 seconds for the initial low battery check, which actually might be good so that if you turn the light on it won't ramp down immediately. I guess I didn't intend this, but it worked out. I never even tried it without the sleep_mode to see what would happen.

Throughout all the testing (experimenting) I’ve been doing with Star1.1, if you turned the light off once low battery rampdown had started - it would always come back on in whatever the last memorized mode was, then rampdown would begin again.

Then I started thinking about this part of the code…

// See if we should change the current mode level if we've gone under the current mode.
                if (PWM_LVL < modes[mode_idx]) {
                    // Lower our recorded mode
                    mode_idx--;

…and added a line…

// See if we should change the current mode level if we've gone under the current mode.
                if (PWM_LVL < modes[mode_idx]) {
                    // Lower our recorded mode
                    mode_idx--;
                    store_mode_idx(mode_idx);

Now, if you turn the light off once low battery rampdown has started - it comes back on in a lower mode.

FWIW- a single used CR123 works well for testing the low battery rampdown and warning functions.

-JW

Tonight, I went back and loaded the original (unmodified) Star1.1 firmware onto my test driver, tested low battery operation, and confirmed that while the low battery ramp-down functioned properly, the low battery cut-off did not. Output just remained steady at the minimum level.

Below is part of the original code…

// Wait until we hit the critical level before flashing 10 times and turning off
                while (!low_voltage(ADC_CRIT));

I removed the NOT condition (!), so the same code looks like this…

// Wait until we hit the critical level before flashing 10 times and turning off
                while (low_voltage(ADC_CRIT));

That appears to have fixed the problem.

-JW

PS-
FWIW - I have also successfully modified the code for a single level light (capable of signalling), but retained the low battery ramp-down and cut-off features of the original program.

So that needs to be fixed in all of the V1.1 then?

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.