STAR Firmware by JonnyC - Source Code and Explanation

I had to re-run the test, as I was interrupted…

It now does the stepdown sequence four times, then gives the Critical warning(10 flashes), but does not power down???

Current code.

Well, I can't figure out why the power-down sequence isn't working....

We're reaching the critical voltage routine, getting the 10 flashes, but no power-down?

while (!low_voltage(ADC_CRIT));

i = 0;
while (i++<10) {
PWM_LVL = 0;
_delay_ms(250);
PWM_LVL = modes[0];
_delay_ms(500);
}
// Turn off the light
PWM_LVL = 0;
// Disable WDT so it doesn't wake us up
WDT_off();
// Power down as many components as possible
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_mode();

Come to think of it, I saw the same behavior recently in what I think was an unmodified firmware. I actually just assumed I’d made a mistake in my observing my test. I’m not sure what the problem is.

Back to plan “A”…

I ended up commenting out the Next Mode routine, as suggested by Mike C. :beer:

Works fine, steps down a few times before hitting Critical voltage, then shuts down.

Thanks to everyone who gave some input, & especially wight for persevering with me.

Oh, & thanks to JonnyC for letting his baby out into the wild! :bigsmile:

You’re welcome, although my help never got you very far.

I’d still really like to know where we went wrong. The code looks OK to me…

I have finally updated the feature lists of the different firmwares and changed it so that it now resides on my GitHub page...

I'll message Richard to update the link in the OP.

Sorry that version numbering is off, and that I did a horrible job of managing my Git repository so it makes downloading previous versions more difficult. However, I believe that all of my feature changes so far have been additive, and each feature (for the most part) can be commented out. Don't want dual-PWM? Just comment it out at the top. No need to find a previous version of the code.

I’m pretty sure we almost had it. I might re-visit this during my holidays in a few weeks, but for now what I needed has been achieved.

Hey guys, need some help here. Yesterday i successfully flashed my 1st nanjg driver with the standard STAR On-time memory v1.1 for clicky switch but my mode cycle is a bit weird. it goes like L-M-T-off-L-M-T-off…how do i remove the ‘off’ from the cycle to just L-M-T-L-M-T? i have test the turbo stepdown and it works accordingly. Thanks

There should be no off in the cycle. My guess is that you just have a mode defined that is too low for the light to turn on. Could you please share your C file with us?

This is what i flashed into my driver.

Thanks

That appears to be a project file, not the source file.

sorry guys for beginning a noob here. i think this should be the .c file

Thanks for all the help

  • Looking at RolandF’s problem, my first assumption is what RMM mentioned: a low mode isn’t lighting up the LED. (EDIT: but that’s incorrect, based on the now-posted code.)
  • The stock firmware has DUAL_PWM_START turned on, so there is no star to disable Moon mode. MODE_MOON must be commented out in order to prevent Moon mode from being in the modes list.
  • Looking at the posted code, MODE_MOON is defined and so is DUAL_PWM_START. Since the Moon mode value is below dual PWM start, it’s outputted on Star2 rather than the normal PWM pin (a dual PWM feature). Even if ‘3’ was high enough to light up an LED with a 7135 (I don’t think it is) there still wouldn’t be any light because Star2 is probably not hooked up to anything on RolandF’s driver. To fix the problem DUAL_PWM_START needs to be commented out.
  • I’m having a lot of trouble parsing the #ifdef and #ifndef statements pertaining to moon mode in the ‘// Load up the modes based on stars’ section. Either I need someone to hold my hand or the code is broken? I re-read it very carefully and I understand it now. It’s definitely very compact and I now see that it’s written that way to avoid repetitive sections of source. That said, the code below is easier for me to understand and I assume (?) that it compiles to the same size.

/* Enable/disable moon mode based on STAR2 if dual-pwm is turned off & MODE_MOON is defined */
#ifndef DUAL_PWM_START 
#ifdef MODE_MOON
if ((PINB & (1 << STAR2_PIN)) == 0 ) {
modes[mode_cnt] = MODE_MOON;
}
#endif
#endif

/* Always enable moon mode if dual-pwm is turned on & MODE_MOON is defined */
#ifdef DUAL_PWM_START
#ifdef MODE_MOON
modes[mode_cnt] = MODE_MOON;
#endif
#endif

IMO at the current level of complexity in STAR users need a setup guide. JonnyC has stated that the point of STAR is to be able to change a few defines and then compile without understanding the code. In order for users to successfully do this they must understand what the defines achieve and how the defines interact with one another. DUAL_PWM_START automatically enabling Moon mode is a great example: previous to the dual-pwm feature Moon was “off” by default, now it’s “on” by default.

My bad Roland, I pushed changes to STAR, STAR_off_time, and STAR_momentary that disables these advanced features so it's easier to configure for a basic driver. Just download the latest release from the link in my signature or the OP in this thread. All of the requests for features come from advanced users, so I just made a mistake in keeping the configuration setup for the last test I did (which was testing all of the added features). And really the only feedback I get is from people looking to modify the code themselves to add their own features.

If someone else wants to write up a configuration guide, please feel free! And if someone wants to take over the development of these STAR programs and do a better job of documentation, go right ahead!

I think you’re taking my comments the wrong way JonnyC. [EDIT: or I’m taking yours the wrong way :wink: ] I actually thought you’d left that define in place on purpose, so a lot of what I said goes away by just commenting that out.

I still think that the current STAR is much, much harder for neophytes to understand than earlier versions were. That’s an unavoidable problem, not something to complain about: you did a great job adding the features and the firmware is now harder to understand because it is able to do more. Setup is also harder to understand because there’s more to control. Unfortunately we need a several FAQs/guides around here and nobody’s volunteering to write them, myself included. <shrug>

Just a side note… I’m thinking of changing the thresholds for battery check modes to more accurately reflect capacity instead of voltage. Currently it does one blink for every 0.3V above 3.0V. Most of the capacity is toward the top of the voltage range though, so this doesn’t map well to capacity.

Instead, I’m thinking of setting the thresholds to 3.0V, 3.5V (maybe 3.6), 3.8V, 4.0V, and 4.2V. Do you think these would get somewhere near 25% capacity for each blink?

Edit: I’m basically talking about fitting it better to curves like hkj measured, but different batteries have rather different discharge curves so I’m looking for a happy medium:

ToyKeeper: that chart gets a little busy, maybe the signal to noise ratio is high. Let’s see, if we eliminate the lowest 3 lines (Yellow/Blue/Red - I think that’s an old IMR cell (AW IMR1600), an old Redilast 2200, and either an old Redilast 2600 or old Solarforce 2400???) that cleans it up a lot. Next if we eliminate the highest line, the uncommon-and-impossible-to-account-for-with-this-system (IMO) 4.35v cell, we clean it up further.

Now most lines stay together until around 3.70 or 3.75 volts. Around 3.7v seems to me to be the lowest voltage where we can assume that none of the graphed cells (other than the excluded 4) are on the wrong side of their discharge “knee”.

That said, discharge current may not be 0.2A, so there’s a lot to think about in that area. Basically we know that voltage depresses a lot under load, but here are two links to SilverFox and HKJ threads which are at least mildly related:

HKJ demonstrates approximately a 10minute recovery from (for example) 3.6v under 1A load to 3.7v under no-load. Recovery time seems to be similar for 3A, just with more voltage depression: about double I think. So in my example we’d be at 3.5v under load and it would take us 10min or so to rebound to 3.7v no-load.

Please also scroll down to the “Tables” section at the bottom of HKJ’s OP in that thread.

I guess what I’m getting at is that the user is going to have to have a ‘fair’ amount of knowledge to interpret the battery measurement output blinks. Also I’m probably saying that fairly high output resolution is necessary.

OTOH looking at HKJ’s data… if the output was just a binary >3.8v vs <3.8v indicator… that might be both useful and easy to understand? HKJ also makes some great observations in that post: “In the above curves, notice the difference in volts between the 10s and 1 hour trace, this is always below 0.1 volt, i.e. if measuring 10 seconds after load is removed, the error is not more than one 0.1 volt step wrong. Waiting two minutes makes the voltage close to the one hour value, especially at 3A load this wait will improve the precision.”

Thanks for the links. I thought I had seen those at some point but I couldn’t find them when I searched earlier today. It definitely answers my questions.

The measurements are being done at no load, so I initially used hkj’s lowest-amp discharge curve. His no-load data is better though. My readings get taken only a few seconds after the cell was last loaded, but it looks like the recovery curve is pretty steep.

If the curves were normalized so that they were all the same width, I’m basically looking for the average Y-axis values (voltage) which correspond to X-axis values (capacity) of 25, 50, and 75%.

The main difficulty I see is the high-amp cell curve vs the high-mAh cell discharge curve. High-amp has a well-defined “knee” around 3.55V while high-mAh cells seem to discharge more linearly (less-defined knee at 3.2V).

So, yes, the user will need to know what type of cell they’re using, in order to understand how low is “low”. At 3.7V (resting) a high-amp cell is almost empty, while a high-mAh cell still has about half of its power left.

In any case, the data we both found suggests that I should definitely raise the thresholds from 3.0/3.3/3.6/3.9/4.2 to something more like 3.3/3.6/3.8/4.0/4.2 if I want to accurately represent capacity (and the “recharge me please” value would be just one blink).

The thresholds under load are, of course, lower. I think I’ll stick with the 0.3V increments for that (for realtime indicator lights), since it means it will be green for most of its life and won’t go yellow/red until it’s genuinely low (or under very high load).

Sure thing. I think your thinking sounds pretty solid, but I’ll make one mild counterpoint. You indicated that the high capacity cells tend to lack that “knee”, but I think that’s actually just Panasonic’s cells: the NCR18650A, NCR18650B, and NCR18650BD. Most other cells of all types tend to have a knee I think.

Normalizing the graphs on the X-axis did not occur to me, that makes a lot more sense for comparison purposes.

Hey guys, i have downloaded johnnyc latest code from his signature and now it works accordingly. Thank you so much :bigsmile: