STAR Firmware by JonnyC - Source Code and Explanation

Excellent work HQ, and thanks for sharing your experience!

“How do you access turbo, or does it always turn on to turbo and step down until the next time you turn it on?”

Turbo is accessed just as with the original code, so yes - always turns on in turbo and steps down until the next time I turn it on.

Here’s what I did with the code:

Set the modes as follows:

#define MODE_LOW 25
//#define MODE_MED
#define MODE_HIGH_W_TURBO 135
//#define MODE_HIGH
#define MODE_TURBO 255

Under “#ifdef MODE_TURBO”, changed the line “PWM_LVL = modes[—mode_idx];” to “PWM_LVL = 175;”

So, in effect - it cycles through 25-135-255-25-135-etc. normally, just like a normal 3-mode driver.

BUT - if left to time-out at 255 (turbo), it drops to 175. Following an off/on cycle it returns to 255 and starts the timer again. Otherwise the 175 level is skipped when cycling through modes. This is with memory enabled, of course.

I suppose that with no memory and L-H mode order, an off/on cycle following turbo time-out would cause it to go to low mode, and cycling through modes would be the same as with memory.

I’ve been using my EDC set up this way for about a week now, and I think I like it (so far).

Thanks,
-JW

Looks like you got it!

Yup, correct.

So it’s a low, med, turbo w/timeout fallback to high…low, med, turbo w/timeout fallback to high
9.8, 52.9, 100% w/ fallback to 68.6%, that is of course having star 4 soldered down, I kinda like the Hi -> Lo function myself (of soldering down star 3), but yours is quite nice too!

fyi, I'm using Atmel Studio 6.2 BETA now, no probs, here: http://www.atmel.com/tools/atmelstudio.aspx

Well, I’ve managed to get single-mode operation (capable of signaling) with 1-minute turbo step-down and ADC_CRIT warning/cutoff, but can’t seem to get ramping-down on ADC_LOW.

Still trying, though.

I just thought a configuration like this would be good for a hard-driven C8 that doesn’t normally need to be multipurpose like an EDC.

-JW

Whoops, major bug in the off-time firmware that disabled low battery detection when compiled without a turbo mode (disabled WDT which caused it to never wake up from its sleep state). Will have the fixed code up on my site soon in case anyone downloaded it yet.

Cool. STILL haven't gotten around to trying it! Been trying to catch up on everyone's orders...those take priority over tinkering time these days. I will also share my multi-group code, different turbo stepdown code, etc. once I get it cleaned up so that it doesn't look so...um...crazy. I don't really know what I'm doing but sometimes I get lucky and make something new work!

How do I post code?

When I try copy/paste, several parts will disappear with save/preview:

  • some brackets and what’s inside,
  • double ‘=’
  • line breaks missing

Can someone give me a hint please?

Thx
HQ

Probably best to upload the file to google docs or something similar then share it, that way we can all see the exact same thing you see. I also think that pastebucket is a good solution.

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