STAR Firmware by JonnyC - Source Code and Explanation

Yes, you can. At least, on the very small few I’ve tried it on.

In general, it’s not necessarily lower, but just different. Like, on one 7135-based driver, I found the following available modes:

  • fast PWM=5, phase PWM=3: zero output
  • fast PWM=6: 0.07 lm
  • phase PWM=4: 0.5 lm
  • fast PWM=7: 1.1 lm

So, I went with phase PWM=4 for moon mode. The 0.1lm mode was just a little too dim, and the 1.1lm mode was too bright.

This is something which needs calibration for each individual light though, or at least each driver+LED combination. The lowest and most ideal level for moon varies with the hardware.

ToyKeeper, can you elaborate on how many 7135s the driver in your example had?

My favourite Med mode gradually went down from 750mA until I’m at 350 now… It’s PWM 6/11/40/255 which (at 18kHz/fastPWM) gives me measured 1/36/342/2830 mA. A very nice mode spacing. This screams for
1x7135 pwm255 + 7x7135 pwm255
1x7135 pwm255
1x7135 pwm~low
1x7135 pwm~very-low

Imagine how looking at the new STAR firmware with ALT_PWM made me smile. I thought about how this might work (using mode_idx for voltage stepdown) but I’m sure you’ll be quicker and your results are more reliable.

By the way, I still love the bi-directional mode change with short and medium press. I’ll never ever use anything else anymore. It’s fantastic to change direction without having to go through all modes, especially the high ones.

I should have guessed…

Moon has truly grown on me. It’s nice for a very dark environment and I use it all the time to look after the kids when they’re asleep or woke up at night.

I’m very sure her results are for 8x7135.
-This pretty much is the same that I measured (and saw) in my little writeup about PWM values at different frequencies

Especially the values where the lights start to light up.
But I’m not sure whether this is a matter of fastPWM vs PhaseCorrect, I believe this is a matter of the resulting frequency, as the comparison with 150 Hz suggests.

EDIT: Skip my answer. Any 7135 driver would light up at these PWM values, regardless how many of them are on it. Arghhhh. Just the lumens are different.

EDIT 2:
I just flashed a stock nanjg 105c with most recent STAR Offtime.

- Moon can’t (and does not) light up as it defaults to PWM-3 at the moment.

  • Moon at PWM-4 with dual PWM (phase-correct-PWM (~9kHz) for Moon) does light up, but turns off when the driver gets hot (took less than a minute). So the issue of losing a low Moon is persistent. ALT_PWM with a single (or maybe two) 7135 is hopefully the way to go.

Oh, that one was the 4x7135 driver in the CNQG brass 18650 light. It uses 350mA chips.

I have one with 5x380mA chips, and its best moon mode is fast PWM=6, for about 0.25 lm.

So, I just check a few settings on each light and pick whichever one I like the best.

I finally got around to trying out STAR offtime. I like it. Feels pretty intuitive.

What kind of behavior could be achieved with offtime “no memory”? I think Ideally the driver would always be next mode when the light is on, but from off it would always start on LOW.

That's correct. Or it can always start on high, if the mode order is reversed .

Offtime-no-memory is my favorite configuration. :slight_smile:

Basically, I set it up so that a short press goes to the next mode, a medium press goes to the previous mode, and a long press goes back to the first mode. It thus always starts in the first mode, and can navigate in two directions. If the user goes backward from the first mode, it enters some semi-hidden “negative” modes like turbo and battery check.

Just tried offtime-no-memory. It is exactly what I am after. The general public would probably appreciate that simplicity, I figure.
I’m using a low of “6” with fast pwm. Seems to work pretty good. Is there a limit to how low I can make low before there is some kind of issue?

The lower limit depends on hardware. Driver, LED, and [potentially] input voltage.

In general, for a nanjg driver with current-gen LED the lowest is about 6 (fast) or 4 (phase). For a FET driver the lowest is generally about 1 (phase) or 0 (fast, with some caveats).

It also depends greatly on the number of 7135s (the higher the number, the higher the stable PWM value), the batch of 7135s (they vary from batch to batch, and even within batches), and whether the 7135 is a 350mA or 380mA (350mA can generally run at a lower stable value).

Is reverse polarity protection something that is physically built into the circuit or something that is handled via firmware? Doing a S2 build for my wife with a 105c and STAR and wanted to make sure that it stayed in.

Thanks

It’s physically built in. It’s a diode.

Many thanks.

Is this version posted in your repository? Think I went look'n - not sure I could locate it. So... Are you saying you are using 3 level values for reading the cap to determine the short/med/long press's? If so -- is this reliable? Standard value OFF time cap used, etc.? If it's reliable, wouldn't JC incorporate it into this? Maybe he doesn't feel confident, or maybe just no time to do it yet, or maybe he doesn't care for this feature?

If it's a mod of JC's OFFTime, is it based on his latest 1.3 version?

This sort of seems like it works like the "werner" style e-switch firmware. I make the long hold do a strobe typically. I think the OFF time style med and long press's though would be a little more tricky/finicky then a simple button hold for an e-switch, maybe?

Only a couple of questions.... SmileInnocent

I haven’t used it, but I just can’t see the short/long press navigation being half as user friendly as an e-switch. With the e-switch you do a long press by holding the button until something happens. You do a short press by hitting it and letting go. Both pretty straightforward actions. Now when it comes to “how do I turn this thing off?”… the clicky may have an advantage. :wink:

I’ll still give this business a try, I want to see what it’s all about.

wight - yes, agree: think the e-switch would be more user friendly. In "my special" e-switch version, once you lock in a mode (like 1 sec or so), one short click turns the light OFF - best solution I could come up with Smile. I had to have a 1 click OFF UI and this seemed to be pretty easy to implement. VOB loves it - got maybe a couple other BLF'ers using my e-switch version around... I really though it was super clever/cool/nifty, and I don't say that bout much I do lately... Smile

A side effect function of this, is if the light is ON and locked in and you do a button hold, the previous mode switch will still work, then you can go fwd in modes with short clicks until you pause/delay again to lock it in. So, even thoug you got a simple 1 click OFF, you can still navigate through all the modes without turning the light OFF (unless you are already at the first/lowest mode already).

Edit/Update: Dang wight - forgot... Just built a S2+ shorty (18350) using a triple XP-G2 3C and your 17mm DD driver (A17DD-S08) with JC's OFFTime latest driver - came out really sweet!! Love your DD drivers for having the clean spring side - simple with the Convoy tube lights. I even scraped off around the spring pad to widen it so I could use the stock spring the S2+ host (from RMM) came with -- again, simple and sweet! Thanks Again for these great driver designs!!!

I haven't given it a shot yet. Sounds pretty cool, but for me I only ever have 3-4 modes, so it's not needed. I'm at max capacity on STAR_off_time, so features would have to be disabled in order to enable this. I think just having ToyKeeper's custom offshoot is the way to go, unless it really is that intuitive that everyone would want it.

Ohh - I used your latest STAR-Off_time verison for the 1st time and got a bit confused over "DUAL" PWM support. I finally figured it out after seeing how the conditional compile switch's were being used, but would have saved me time if I could have understood it better from the descriptions/docs. I was thinking DUAL PWM mode was phase controlled and fast, as opposed to DUAL outputs, so had me going for a while...

Also, maybe it wasn't so clear to me, but finally understood it by again, going through the code. I think in the prior versions TURBO would knock down to the previous mode in the mode table, but now, it knocks down to a set value, not in the table. I definitiely prefer the way you have it implemented now. I always thought the TURBO step-down setting should be an accessible mode and take up another mode setting. Think the BLF SE X6 driver works the old way which I can't stand - seems a waste of a mode, more clicking, etc.