STAR Firmware by JonnyC - Source Code and Explanation

1335 posts / 0 new
Last post
JW980
Offline
Last seen: 4 years 5 months ago
Joined: 01/12/2014 - 11:15
Posts: 45

“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

JonnyC
JonnyC's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

Looks like you got it!

JW980 wrote:
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.

Yup, correct.  

WarHawk-AVG
WarHawk-AVG's picture
Offline
Last seen: 2 years 7 months ago
Joined: 01/04/2014 - 06:47
Posts: 5071
Location: H-Town

JW980 wrote:
“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

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!

Tom E
Tom E's picture
Offline
Last seen: 5 months 1 week ago
Joined: 08/19/2012 - 08:23
Posts: 15065
Location: LI NY

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

JW980
Offline
Last seen: 4 years 5 months ago
Joined: 01/12/2014 - 11:15
Posts: 45

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

JonnyC
JonnyC's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

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.

RMM
RMM's picture
Offline
Last seen: 2 years 11 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

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! Sealed

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 6 months 2 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 588

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

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

RMM
RMM's picture
Offline
Last seen: 2 years 11 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

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.

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

AlexTG
Offline
Last seen: 1 week 5 days ago
Joined: 10/29/2012 - 08:40
Posts: 203
Location: Kiev, Ukraine

HarleyQuin wrote:

Can someone give me a hint please?

Use “pre” and “/pre” tags around the pasted part (substitute quotes for angle brackets, of course)
HarleyQuin
HarleyQuin's picture
Offline
Last seen: 6 months 2 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 588
AlexTG wrote:
Use “pre” and “/pre” tags around the pasted part (substitute quotes for angle brackets, of course)

That works fine, thx!

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 6 months 2 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 588

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

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

JonnyC
JonnyC's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

Harley,

You discovered the same issue I did Smile  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.

JW980
Offline
Last seen: 4 years 5 months ago
Joined: 01/12/2014 - 11:15
Posts: 45

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

JW980
Offline
Last seen: 4 years 5 months ago
Joined: 01/12/2014 - 11:15
Posts: 45

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.

WarHawk-AVG
WarHawk-AVG's picture
Offline
Last seen: 2 years 7 months ago
Joined: 01/04/2014 - 06:47
Posts: 5071
Location: H-Town

JW980 wrote:
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?
JW980
Offline
Last seen: 4 years 5 months ago
Joined: 01/12/2014 - 11:15
Posts: 45

I was hoping someone else might confirm/dispute my findings. I could easily be wrong…

-JW

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 6 months 2 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 588

JW980 wrote:
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

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

JW980
Offline
Last seen: 4 years 5 months ago
Joined: 01/12/2014 - 11:15
Posts: 45

…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

JonnyC
JonnyC's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

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.

comfychair
comfychair's picture
Offline
Last seen: 6 years 8 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

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.

JW980
Offline
Last seen: 4 years 5 months ago
Joined: 01/12/2014 - 11:15
Posts: 45

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

DrJones
DrJones's picture
Offline
Last seen: 6 years 8 months ago
Joined: 01/05/2011 - 13:30
Posts: 1044
Location: Frankfurt, Germany

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.

 

 

 

 

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 6 months 2 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 588

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 0×65
2.4 kHz 9.6 MHz :8 0×6a 4.8 MHz :8 0×65
4.7 kHz - - - 9.6 MHz :8 0×6a
9.4 kHz 4.8 MHz :1 0×75 - - -
19 kHz 9.6 MHz :1 0×7a 4.8 MHz :1 0×75

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 = 0×23”, where 0×23 is FastPWM and 0×21 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 = 0×01”, where 0×01 gives :1; 0×02 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 = 0×23”. 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 0×75 (or change both) This fuse calculater is extremely handy to understand the fuse settings.

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

RMM
RMM's picture
Offline
Last seen: 2 years 11 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

Star momentary also uses 0x23 by default.  

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

Microa
Offline
Last seen: 5 hours 12 min ago
Joined: 06/29/2011 - 21:20
Posts: 253

Thanks HarleyQuin, You clarify my confusion of the prescaler and the divider.

JonnyC
JonnyC's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 01/14/2011 - 19:12
Posts: 1148
Location: Green Bay, WI - USA

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).

comfychair
comfychair's picture
Offline
Last seen: 6 years 8 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

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.

HarleyQuin
HarleyQuin's picture
Offline
Last seen: 6 months 2 weeks ago
Joined: 03/29/2013 - 04:47
Posts: 588

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.

Oshpark Boards:
HQ ProgKey: Universal Driver Programming Key . Boost: HQ 15mm/17mm programmable boost driver with ATtiny13A
46mm Triple-Channel: BLF SRK FET v3 . 17mm Linear: HQ10D / HQ4D / HQ4S . Contact Boards: 22/24/26mm

comfychair
comfychair's picture
Offline
Last seen: 6 years 8 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

From another thread...

comfychair wrote:

http://75.65.123.78/blf-srk/Dsc07592.jpg

PC = phase correct (9.4kHz, 'TCCR0A = 0x21'), FP = fast PWM (19kHz, 'TCCR0A = 0x23'). Levels for both are 0,2,6,18,54,130,255. Both turn on and off and change modes exactly like they should. The phase correct board makes a slight whine on level 4, moderately loud whine on level 5. Fast PWM board is silent.

Pages