STAR Firmware by JonnyC - Source Code and Explanation

1335 posts / 0 new
Last post
FmC
FmC's picture
Offline
Last seen: 7 months 1 day ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU

Thanks wight for taking the time to explain.

I've spent a few hours with this today, but I'm not quite there yet....

I was certain it was stepping down visually, but to be sure, I charged my test cell back up to about 3.4v & hooked up an ammeter in series;

Starts out at 0.6A, ---> 3*flash/stepdown to 0.3A, then ~6 mins later, at 0.12A, another 3*flash/stepdown to 0.05A, then a few seconds later, another 3*flashes, & back up to 0.14A, then 3*flash & down to 0.02A   ......./end of test...

Yep, just like you described above.

-

I replaced  PWM_LVL = modes[0]; with  PWM_LVL = STEPDOWN_MINIMUM , but we still don't see the Critical routine.

It now steps down as before, but doesn't jump back up & start over, just continues with the 3 flashes, maintaining the lowest current, in a loop.

Without a Babel fish, I'm still unable to properly follow what's happening to some of the variables Sad

I took a couple of wild stabs ;  PWM_LVL = STEPDOWN_MINIMUM -1  which done nothing, & also tried removing the line under that   mode_idx = 0;  which again achieved nothing.


wight
Offline
Last seen: 1 year 6 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

Hmm. Please go ahead and post up your full code in some unmolested way (upload a TXT file some where or use Pastbin or a similar website). Some sites like pastebin also have a highlighter, which is nice. Smile

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

FmC
FmC's picture
Offline
Last seen: 7 months 1 day ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU

Here’s the latest test code, minus the couple of “stabs” I took at it.

Beer
wight
Offline
Last seen: 1 year 6 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

It appears that our current problem is "wrapping" the unsigned variable 'modes_idx' from zero up to it's maximum value. With what I think we have currently I guess the problem manifests immediately after the first stepdown.  Here is the problem section:

// 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--;
}

Do you see the problem?  Of course the conditional is true, PWM_LVL is now below modes[0].  So we subtract 1 from mode_idx.  Since it's already zero and it's unsigned (can't be negative), the value wraps to the maximum value, I guess that's 255?  After that we probably subtract one from that value every 3 seconds or so... so eventually maybe "if (mode_idx == 0 && PWM_LVL <= modes[mode_idx])" will be true, but not any time soon (13 minutes maybe?).  

I think deleting that whole section is fine.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

FmC
FmC's picture
Offline
Last seen: 7 months 1 day ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU

wight wrote:
Do you see the problem?  Of course the conditional is true, PWM_LVL is now below modes[0].  So we subtract 1 from mode_idx.  Since it's already zero and it's unsigned (can't be negative), the value wraps to the maximumvalue, I guess that's 255?  After that we probably subtract one from that value every 3 seconds or so... so eventually maybe "if (mode_idx == 0 && PWM_LVL <= modes[mode_idx])" will be true, but not any time soon (13 minutes maybe?). 

I think deleting that whole section is fine.

That's the problem on my end; I don't know enough/forgotten too much to follow what's going on.

I taught myself Basic on a CPC464 by reading through the user manual - even got to the stage where I was able to write up some games to give to friends to try out..... but that was over 30 years ago now....

...back to now, & I've re-flashed with the updated code, so far, so good - just waiting for the battery to run down....

 

wight
Offline
Last seen: 1 year 6 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

FmC wrote:

That’s the problem on my end; I don’t know enough/forgotten too much to follow what’s going on.

I taught myself Basic on a CPC464 by reading through the user manual – even got to the stage where I was able to write up some games to give to friends to try out….. but that was over 30 years ago now….

…back to now, & I’ve re-flashed with the updated code, so far, so good – just waiting for the battery to run down….

 

Oops, I meant to include this link in my post: http://stackoverflow.com/questions/7221409/is-unsigned-integer-subtracti...

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

FmC
FmC's picture
Offline
Last seen: 7 months 1 day ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU

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.

FmC
FmC's picture
Offline
Last seen: 7 months 1 day ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU

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();

 

wight
Offline
Last seen: 1 year 6 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

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.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

FmC
FmC's picture
Offline
Last seen: 7 months 1 day ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU

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:

wight
Offline
Last seen: 1 year 6 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

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

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

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

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

http://jcapsolutions.github.io/blf-firmware/

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.

FmC
FmC's picture
Offline
Last seen: 7 months 1 day ago
Joined: 03/31/2013 - 05:23
Posts: 2197
Location: Brisbane, AU

wight wrote:
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’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.

RolandF
Offline
Last seen: 6 years 4 months ago
Joined: 11/14/2014 - 23:17
Posts: 23

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

RMM
RMM's picture
Offline
Last seen: 1 year 6 months ago
Joined: 07/23/2013 - 13:47
Posts: 4006
Location: USA

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?

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

RolandF
Offline
Last seen: 6 years 4 months ago
Joined: 11/14/2014 - 23:17
Posts: 23
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 43 min ago
Joined: 01/12/2013 - 14:40
Posts: 10736
Location: (469219) 2016 HO3

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

RolandF
Offline
Last seen: 6 years 4 months ago
Joined: 11/14/2014 - 23:17
Posts: 23

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

https://drive.google.com/file/d/0B_liSBT3jLqlQTRQa2hXNDNOLVE/view?usp=sh...

Thanks for all the help

wight
Offline
Last seen: 1 year 6 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA
  • 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.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

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

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!

wight
Offline
Last seen: 1 year 6 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

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>

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 43 min ago
Joined: 01/12/2013 - 14:40
Posts: 10736
Location: (469219) 2016 HO3

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:

wight
Offline
Last seen: 1 year 6 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

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:
http://www.candlepowerforums.com/vb/showthread.php?345795-Estimating-rem...
http://www.candlepowerforums.com/vb/showthread.php?115871-Li-Ion-State-o...

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 “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.”

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 1 hour 43 min ago
Joined: 01/12/2013 - 14:40
Posts: 10736
Location: (469219) 2016 HO3

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

wight
Offline
Last seen: 1 year 6 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

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.

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

RolandF
Offline
Last seen: 6 years 4 months ago
Joined: 11/14/2014 - 23:17
Posts: 23

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

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

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

Awesome, thanks for making us aware of the issue!

Hoop
Hoop's picture
Offline
Last seen: 3 days 17 hours ago
Joined: 12/20/2012 - 05:33
Posts: 1036
Location: Spokane, WA

I am trying out the Dual Switch version of the software and I get an error during the compile to hex:

“variable ‘modes’ must be const in order to be put into read-only section by means of ‘__attribute__((progmem))’
line 115 column 18

Anyone know the issue?

wight
Offline
Last seen: 1 year 6 months ago
Joined: 11/27/2013 - 16:40
Posts: 4969
Location: Virginia, USA

Hoop wrote:
I am trying out the Dual Switch version of the software and I get an error during the compile to hex:

“variable ‘modes’ must be const in order to be put into read-only section by means of ‘__attribute__((progmem))’
line 115 column 18

Anyone know the issue?

IIRC syntax changed between versions of AVR Studio. What version do you have?

Still fine, still on a break. One day I’ll catch up with you folks! previous wight catchup Wink
list of my drivers & variants (A17DD, FET+1 stuff, WIP stuff, etc)

Hoop
Hoop's picture
Offline
Last seen: 3 days 17 hours ago
Joined: 12/20/2012 - 05:33
Posts: 1036
Location: Spokane, WA

6.2 build 1502.

The actual line of code related to the error is: PROGMEM uint8_t modes[] = { MODES };

I also edited the line at the beginning of the program to change mode spacing: #define MODES 12,70,255

Pages