Mini Review - TheStar v0.1, a FW created by BLF Member _the_

_the_ asked me if I would like to check out TheStar FW as I have a Send Nits B-650 and there is a group buy in the works that may include this FW.

Here is some high level info from _the_:

  • Modes - LL->L->M->Turbo
  • Has memory that kicks in after 1 second on.
  • 2min turbo timer that ramps down to about 2A (from 2.8A) by default.
  • Grounding stars:

- star 2 to disable turbo timer
- star 3 to change mode order (T->LL)
- star 4 to disable mode memory

  • Hidden blinky modes. Accessed by tapping through all modes twice (without having >1s pause with any mode), then after turbo mode comes strobe, 1s beacon & 10s beacon. Also these modes are remembered if memory is active.
  • Low voltage protection starts at about 3.0V, and the light is turned off at <2.9V.

I just hobbled together an Ultrafire C12 with XML2 U2 1A, and Nanjg 105C with 8 chips to put the FW in. No stars ground. I'm early into using it, but so far, I really like it. Some notes from my experience:

  • After about a second of inactivity, you need to half click twice to change to the next mode. Seems like a good feature as it helps prevent accidental mode changes.
  • I really like the mild ramp down from turbo. Very hard to see the difference in light, but the light does cool down after the step down.
  • The moon light is very nice to have. I like to use moon light in the house when my eyes are totally dark adjusted. It seemed a tad bright for this, but I may be off as the light has a xml2 U2 1A emitter in a throwy type light.
  • I checked tailcap current but got some weird results. I will need to try another driver. Here is what I got:
    • LL .01- .02 amps
    • L .00 - .04 amps
    • M .44 - .047 amps
    • T 2.50 - 2.65 amps
    • Step Down from Turbo 1.50 - 1.60 amps

I will continue to use this FW and also try out the voltage protection and report back soon.

BLF has become a great place for our passion.

I hope its ok to come with suggestions in this thread.

I find this quite annoying. Can it be fixed?

Why cut of at 2,9v and not a bit lower?

If not 2,7V, why not 2,8v?

HKJ runs all cells down to 2,8v in his tests.

Id personally would want to change the 1second beacon with SOS if possible.

SOS have a far higher chance of being life saving. Or add SOS to the others.

You have to cycle through the modes two times in order to get to blinky modes. That is 9 clicks if you start in low right?

Click 1 - Turn on flashlight, say into Low mode (/unlock mode change if light have been on for more than 1 second in low)

Click 2 - M

Click 3 - H

Click 4 - T

Click 5 - L

Click 6 - M

Click 7 - H

Click 8 - T

Click 9 - Blinky mode

Lets say you are in high, and you want to get to blinky modes. You still have to do 9 clicks right?? or??

Either way, why not access blinky modes after 5 clicks? If you need to cycle through all modes in order to get to a mode that is one step lower, you will not do more than 4 clicks. Why not have quicker access to blinky modes with 5 clicks? (no matter what mode you are in)

If you get rid of the "mode lock" that happens after one second, you can get access to blinky modes with 4 clicks instead. With normal use there is no reason to do more than 3 clicks (say you want to go from high to medium), so blinky modes are still hidden. Yet blinky modes are quicker and easier to access.

Thank you IA4W for testing the driver! Glad you like it. :)

Sure. Suggestions, opinions & feature requests are more than welcome.

This is normal functionality for "on"-time memory.

Both "on"- and "off"-time memories have advantages, so we need to do some kind of compromise.

The main reasons I opted for "on"-time memory (instead of "off"-time memory) are:

1. No hardware changes required

For a modder it's not a problem to hack drivers to be compatible with off-time memory, but it would be quite difficult to get a manufacturer to manually solder in capacitors to all GB light drivers.

2. Losing the contact for split second won't change to next mode

Consider the situation when you are bicycling, hit a bump, have a contact problem -> "oops", from turbo to (low)low mode. You hit a tree. Ouch.

It's somewhere between 2.8 & 2.9V.

Couple of reasons for this:

1. The voltage testing routine is not dead accurate. It may show like +-0.1V results.

2. Even if the light is turned off and driver in deep sleep mode, it consumes some (small) amount of current. Of course I power off everything I can (or am aware of), but still.. There is a risk that a non-flashaholic (proverbial grandmother) will notice that the light is off and leave it there for some days before recharging the cell. As we know, even protected cells can be drained to serious under voltage in this situation and you would not want the cell to be ruined (and potentially turned into dangerous!)

There's not enough space for SOS at the moment. I will see if I can still squeeze out a couple of bytes for that..

More than 9. It's always 8 clicks + whatever it takes to go to turbo and then blinkies.

5 clicks was too little in my (usability) tests. It's not once or twice a test person is trying to change to a specific mode, goes accidentally one over, and loops again to that mode. Looping all modes twice was considered to be a good compromise between "not hidden well enough" and "too hard to access".

All in all, good comments, and something for me to think when developing next versions.. Please keep the comments coming. :)

Thanks for detailed and well thought out reply.

I still think 9+ clicks is a bit too hidden for the blinky modes, but that's me.

Id guess most prefer off-time memory, but due to reasons you mentioned, not the ideal solution. Im not into the technical bits, but why not use regular on-time memory like Qlite etc, etc?

You mentioned cycling as a reason to have the "mode lock". (its not really mode lock.. but..) If I were into cycling in an environment where light is really important, and I were only using one light on the bike. And I was not using a proper dedicated cycle light. Id rather just use DrJones Mobydrv, Mobydrv Q, lucidrv with mostly higher modes or a taskled optimized for cycling (those are the ones on the top of my head that is nicely suitable for cycling or specially made for it). Personally Ive never had accidental mode changes in normal use on my lights that uses a normal rearward switch. I make sure the battery is a nice fit though.

On a side note. Forward switches are a pretty much idiot proof when it comes to avoiding accidental mode changes.

I just really don't like doing that extra click on a general use driver. :p I know, its just a personal preference... And Im picky.

But this is regular on time memory, and works just like Qlite, doesn't it?


On a side note. Forward switches are a pretty much idiot proof when it comes to avoiding accidental mode changes.


Fully agree.


I just really don't like doing that extra click on a general use driver. :p I know, its just a personal preference... And Im picky.


It sounds way worse than it really is. Until about last month it was the standard way to change modes in NANJG 105C drivers. Now everyone suddenly wants off-time memory with capacitor.. :)

I have to second RaceR86 on the SOS comment. I was in a situation one time where it would have been very useful and potentially could have saved lives. We got stranded in a boat late one evening and through the night. We had 2 diabetic kids with no tester/kits on board. There were homes within signaling distance but we had no lights to signal with. It wasn't until day light when were able to signal for help.

I don't find the hidden modes hard to get to, but I understand RaceR86's comment. It's very difficult with a single switch. I think I often click more than 6 times when changing modes due to over shooting the desired mode. It would be obnoxious to accidentally be thrown into the hidden modes.

I have mixed feelings about the 2 half clicks after inactivity. I lean towards wanting the feature, but am ok without it.


I added some current measurements. I'm wondering if there is something in the FW that would cause current to oscillate (not in a bad way). Probably something in my setup, but could it be the FW?

My readings indicate one of the AMC7135 chips is not working. Would anything in the FW cause lower than max current?

There shouldn't be anything in the FW that could cause it. The FW gives out a steady 2.8A in my test driver.

My guess would be that another 7135 chip is about to fail for some reason(?)

Ps. v0.2 is waiting in your mail box. :)

Could you make the moonlight mode any lower?

Yes Qlite and all its typical siblings use on-time memory, but they do not do a "simple mode lock" so that you have to do an extra click every time you want to change mode. That is the annoying bit. Not the memory (sorry if that was not clear) Ive had drivers with that feature.. HAD, is in, no more.. :p

Pretty much all flashlights change mode with one half click, then you pick a light with a UI like this, do the half click, only to find out, nope, have to do it twice in order to change up one mode. Its against all logic that the majority of lights use.

I look at it like this. Could be useful 1 out of 1000 times. Annoying 999 out of 1000 times. Its kinda like having blinky modes that are not hidden. Annoying 999 out of 1000 times. Could be useful 1 out of 1000 times.

Occasionally I have seen people request proper mode lock for signaling purpose and such. But this? How often do you see people request a feature that makes you do a double click just do to a simple mode change?

I think people in TheStar thread should be warned aware of this feature if it becomes a part of the final firmware. I hope it doesn't.

I had to go and fetch a light with original Qlite driver. Getting old, can't trust my memory any more..

But it works just like my FW: Turn the light on, wait for the memory to engage, half-click -> same mode.

Ps. I agree, it's not logical, but that's how on-time memory works.

Yes, but not much lower. At least my test sample Convoy S2+ w. XM-L2 T5 5A1 led doesn't want to turn on reliably with PWM levels less than 7.

Just tested the TC currents, and they were (v0.2, with a notch lowered lowlow): 0.003A->0.03A->0.66A->2.82A

Parasitic drain when the light is turned off by low voltage guard is now about 110uA (0.0001A)

I recently made a light with on-time based memory… but no memory. And the result turned out to be pretty nice. I actually like it a lot better than regular on-time memory.

In short, to reach a given mode, you always have the same number of half-presses, regardless of what state the light is in. LL = one press, L = two presses, M = three presses, H = four presses. If the light was initially off, the first press will be a full click instead of a quick tap.

This doesn’t protect against momentary power loss like from a hard bump, but otherwise I prefer it over the traditional on-time memory approach. Since it’s basically stateless, it’s a lot more predictable.

Im getting retarded... Just overlook me.. You are right..

I agree. It's good for many purposes, and that's why TheStar FW allows you to select that configuration simply by shorting star #4 (with pencil, conductive paint, solder, or..)