STAR Firmware by JonnyC - Source Code and Explanation

RMM posted his google spreadsheet for setting ADC value a while back:

Voltage varies per driver, even with identical components. Identical ones have very small variation, like 0.05V, but with different parts the ADC values can be very different. So, I don’t even try to guess at the values any more… I just measure it.

Ok so I decided to give the battcheck a try. I flashed the driver with it an using a 4.17V cell I got 255. Using a 3.06V cell I also got 255 :( Did this on 2x 1S FET drivers and got the same result so I tried it on a Qlite. The 4.17V cell gave me 182, and the 3.06V cell gave me 13.

So my problem with the FET driver is a component issue? Layout maybe?

Do the readings I got for the Qlite seem right?

Are you sure you got 13 at 3.06V, not 113 or 103? If you keep the power connected to the driver it’ll keep measuring and blinking forever, so you can read the value more than once.

Some example measurements are in readings.txt and readings/*.volts, if you’d like a reference for what to expect.

For example, on two nanjg drivers I got these results:

  • 4.09V - 179
  • 3.15V - 136

… other driver:

  • 4.17V - 182
  • 3.00V - 125

So, it’s typical to see values from about 80 to 210 with a single cell.

If you get 255, that’s the highest possible 8-bit value and it means your voltage dividers are probably the wrong resistance… so the voltage being measured is outside of the attiny’s range.

In general, you probably want to adjust the resistors so that a full cell will measure 224 or less, with a really empty cell being 32 or greater. Measurements aren’t as accurate near the edges of its range.

I think what happened is that I was getting 130 for the low voltage. I see that the battcheck will do a "low blink" for the "0", maybe I just did not catch the low blink? I tried it again with a 3.15V cell and got 134.

On the FET driver there are 2 resistors. I have a 4.7K and a 19.1K. I assume the 19.1K is the voltage divider?

Assuming I change that to something higher what other effects is this going to have on the way my board functions?



That’s what RMM’s spreadsheet is for. Check seasam’s link above for the recommended resistor values for various cell configurations.

The attiny needs its VCC pin to get an input between 0.1V and 1.1V. Anything outside of that range is unusable.

Is simply connecting my DMM leads from pin 8 to ground with the battery hooked up the correct way to measure that voltage?

If so this is my problem. I had the same resistors RMM shows in that sheet, but am getting Vbat (3.06v) Even after I jumped the resistor values up much higher there was no change.

The only thing I can think of now is maybe I have another dirty or incorrect trace?

I think that would do it, but I haven’t tried… It’s possible that maybe one of your resistors is bridged or maybe fried. Hard to say. In any case, you can check the correct behavior on your qlite driver… and get a baseline for comparison on others.

For that matter, you could probably measure resistance on each component on the qlite, then check the same components on the other driver(s), and maybe identify which part isn’t working.

Hello ToyKeeper, It tried your Ferrero Rocher firmware with alt-pwm modes and it does not work. It works only with single pwm. When I have for example first three modes only on second output (pwm on first output is zero) it stays off untill I press the button several times over these modes. It would be great if you get to fix it. Otherwise I really like this UI and everything. Thanks.

I haven’t actually tried Ferrero Rocher on a two-channel driver. The only development driver I have with an e-switch is a FET-only driver, so I’m not surprised that doesn’t work. However, I’d like to set up a two-channel dev driver soon. I need to order some things from RMM as soon as I get back home.

Hi, I want to modify star firmware to low-medium-high (or turbo) modes.
I tried to commend out moon mode but I face a step down after 3 blinks, after some seconds on high, of course with a fully charged battery.
Should I change anything else in firmware?

Sounds like it’s hitting low-voltage protection and stepping down. Which it shouldn’t do on a full cell.

You may want to flash the battcheck.hex firmware to check if your voltage readings are sane, and to get numbers to plug into STAR.

Hello everyone, I have read through this thread but have not seen this question answered. Does anyone know if there is a version of STAR with the short cycle mode memory similar to luxdrv? If not, is it possible and how difficult would it be? This is the only feature missing keeping me from using the STAR firmware.

Thank you,

Frank

I don’t think there is, but could you describe a little more about what you mean by short-cycle memory? It seems to get used to mean more than one different thing around here.

I think that style has mostly been abandoned ever since people found ways to measure the amount of time the light was off. So, instead of short-cycle memory, people mostly use a long-press or short-press to tell the light whether to go to the next mode or back to the beginning.

By short cycle I mean upon switching from a locked mode, the light defaults back to the first mode in the mode list instead of the next mode in the mode list. I hope I’m explaining this correctly. It was always a great compromise between having mode memory with many modes and not having to scroll through all of them to use the first few modes.

Will this method also work with regular clicky style lights? It would be great if so!
Thank you very much for your input ToyKeeper.

Frank

Yes, offtime memory works only with clicky-style lights.

With short-cycle memory, it uses on-time. The light comes on, then if you tap the button (cut power) within the first second or so, it knows that it should go to the next mode. Then if you leave it on longer than a second or two, it locks in and the next tap will go back to the beginning of the sequence. I used this interface on several of my lights, such as early versions of s7.c or brass-edc.c.

I think you might be looking for “off-time no-memory”. With that, it doesn’t care how long the light was on. If you tap the button for a short time, it will go to the next mode. But if you leave it off for a longer time, it will go back to the beginning of the sequence. So you can easily jump to the next mode, regardless of how long the light was on, and you can also get back to the beginning pretty quickly too.

I normally set the boundary between “short press” and “long press” at about half a second.

In addition to that method, I’ve also become fond of a 3-way split instead of just 2 ways. So, it has a short press, medium press, and long press. Short goes to the next mode, medium goes to the previous mode, and long resets to the beginning. This allows navigating the mode sequence both ways, and additionally allows having an entirely different sequence if you go “backward” from the first mode. Here is a diagram showing that interface on a popular BLF light:

Why is there a dual switch version, the tail cap click switch would just kill power to the whole driver. I can see where one could take out the mode selection that puts the driver to sleep… Is that the whole point of that version?

Thanks matt

Sure, one switch is a hard power disconnect while the other is just a little electrical blip… but with two buttons you can do a lot of stuff which isn’t possible with just one button.

For example, when turning the power on (via hard power switch), you could make it do different things depending on whether the e-switch was up or down at the time. Or use the clicky switch for momentary control while the e-switch ramps brightness up and down.

Are the PWM channels reversed from the BLF-A6 firmware to STAR? To clarify, “star 2” controls the 7135 in blf-a6, and in STAR, that leg is the “ALT PWM.”

I tried STAR firmware on the A17DD-L FET+1 driver but I am only getting one mode.

Edit: I think I’ve determined the answer is yes. I swapped some values and I get modes:

In STAR, I swapped values of lines 108 with 113, and 119 with 120.

default 108: #define STAR2_PIN PB0
default 113: #define PWM_PIN PB1

default 119: #define PWM_LVL OCR0B
default 120: #define ALT_PWM_LVL OCR0A

Edit: #define CAP_THRESHOLD in STAR seems to be having no affect on the offtime function. I am not sure why. Tried values from 110 to 255 and it always took some 7+ seconds to reset the modes.
The stock “OT” labeled cap on my board looked bridged across the top with a very conspicuous blob of solder. I wasn’t sure if this was intentional from the factory so to troubleshoot I removed the “OT” cap from the A17DD-L and the board does take way longer to reset the mode to low; 10+ seconds. I then stuck on a 1uF cap that I bought from mtn and it performs as the stock one did as far as I can tell; 7+ seconds before reset.

Update: Actually, with the cap removed the modes don’t revert. It is always next mode from the last used mode.

That doesn’t sound like a match for what flucero28 is asking about. I was under the impression that short-cycle would work with either ontime or offtime, it doesn’t depend on the method of memorization.

Let’s go with offtime for an example though:

  1. Out of 5 modes we switch to 4 and memorize it by turning the light off for a period of time.
  2. We turn the light back on, it is now in mode 4 (as memorized).
  3. Now we do a “short press”. The light should cycle to mode 1.

That’s how I understood short-cycle.