STAR Firmware by JonnyC - Source Code and Explanation

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.

Oh, yeah. Short-cycle with memory is weird, especially if it’s ontime-based. Does anyone like it that way?

I’ve never tried it. Conceptually offtime + no-memory sounds better to me for my uses. With that said, offtime+no-memory can probably be a huge drawback on a light with lots of modes. I tend to run only a few modes, but if I had 20 modes I might want memory + quick access to the first few modes. Short-cycle fits that description.

I haven’t had good luck with the short+medium+long-press stuff. If I was able to use that reliably I think that would be a better solution to the same problem.

If the button timings aren’t calibrated well, it can definitely be a pain. The X5/X6 aren’t calibrated well, since they used hardware three months newer than the firmware and there was no opportunity to calibrate it.

I use offtime no-memory on most lights, including basic nanjg drivers with no physical mods. I prefer to have an OTC though, for a deeper UI with faster ways of getting to the modes I want. It’s nice being able to reach moon, low, med, and turbo all within one second. I almost never use any other modes (except blinkies).

The main exception for me is e-switch lights. On those I like smooth ramping with memory and shortcuts to min/max.

I face a problem with lvp in a zener modder 105c driver. On driver there are the 2 standard resistors plus a 2000 resistor replacing the diode aside led+.
After suggestions from this thread, I used 141 & 151 values for 2s setup.
Unfortunately, after checking with my power supply, I have no lvp, xhp50 is dimming till 5v, without mode step down.
Any ideas?

… flash battcheck.hex onto it and let it tell you what the attiny sees at different voltages?

Measuring is far more effective than guessing. :slight_smile:

The battcheck/README file explains how to measure the voltage range, among other things.

I did this, both in a Attiny25 version (over 1KB code) with more advanced features like luxdrv has - strobes and batt check, and a 13A version without strobes and battcheck. Not posted yet anywhere, but love the 25 version of it - have it in a BLF D80 and a NiteFighter F30B and it works great! Should post it up somewhere - well tested at this point.

I was always a fan of short cycle memory, specially for 3-4 mode levels - phrase probably coined by Dr Jones. 4 mode levels is my favorite for this setup.