STAR Firmware by JonnyC - Source Code and Explanation

1335 posts / 0 new
Last post
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 35 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

WarHawk-AVG wrote:
ToyKeeper wrote:
I run this on my EDC, and it provides five nice constant-output modes plus a bunch of interesting blinkies… with no need to cycle through the blinkies when not desired.
ooh interesting…are the flashy modes hidden?

Can you make a video on the function of the light


The flashy modes are “hidden” in the sense that it takes a bunch of clicks to get to them. I doubt a video is really needed… and I’m sick and coughing like crazy so I don’t want to speak today. The modes are:
  • Click once (or tap once if already on): Moon mode
  • Tap twice: low
  • Tap three times: medium
  • Tap 4X: high
  • Tap 5X: maximum output
  • Tap 6X: moon-med beacon (flash med in a quick stutter, then rest at moon, repeat once per second)
  • Tap 7X: low-high beacon
  • Tap 8X: med-max beacon
  • Tap 9X: heartbeat-style beacon — blinkblink, pause, blinkblink, pause
  • Tap 10X: 10Hz true strobe (1ms on-time, freezes motion)
  • Tap 11X: 24Hz true strobe (0.3ms on-time, freezes even fast motion)
  • Tap 12X: 60Hz true strobe (0.3ms on-time)
  • Tap 13X: ~7Hz to ~18Hz self-ramping strobe (1ms on-time)
  • Tap 14X: ~16Hz to ~100Hz self-ramping strobe (0.3ms on-time)
  • Tap 15X: Start over again at moon mode.

It uses short-cycle memory, so whenever it has been on for more than a second it will reset to starting at the first mode. To go from medium to low, for example, is a couple quick taps on the button (like half-pressing a camera shutter).

I find the solid modes are useful for general purposes, the dual-level beacons are useful while biking or signalling for assistance, and the strobes are just fun to play with. For example, point one of the self-ramping strobes at a spinning fan and it’ll gently rock back and forth, spinning one way then the other.

If you really want it to come on in a non-moon mode next time, it can be tricked into doing so. Basically just replace the last ‘tap’ with a full click (to turn it off), and then leave it off. Next time it starts it’ll be in the desired mode.

I included a .hex file for easy flashing, if anyone is interested. Use the ‘download file’ link here:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/view/he...

NightSpy
NightSpy's picture
Offline
Last seen: 4 years 5 months ago
Joined: 08/30/2011 - 18:24
Posts: 794

Now you got my attention.

Which driver; which pin?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 35 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

NightSpy, who (or which post) are your questions addressed to?

NightSpy
NightSpy's picture
Offline
Last seen: 4 years 5 months ago
Joined: 08/30/2011 - 18:24
Posts: 794

Crum… I think I got the X6 thread mixed up with this one.

Cereal_killer
Cereal_killer's picture
Offline
Last seen: 1 year 8 months ago
Joined: 07/22/2013 - 13:10
Posts: 4005
Location: Ohio

Guys quick question, does turbo timer not work if the mode order is reversed?

I’ve made my wife a new EDC (an HD2010, even I dont EDC a light that large, good for her!) but she wanted it to come on in turbo and go down but its having some issues, stepping down threw the modes when it shouldnt and just acting bad in general so I was wondering if that just wasnt possible to use the timer if turbo comes first.

Also I’m using the instant start turbo ramp down, not the timed single step.

 RIP  SPC Joey Riley, KIA 11/24/14. Now I am become death, the destroyer of worlds.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 35 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

Of course it’s possible to make it work as desired… just depends on the code used. I can’t say I’ve actually used turbo though. I haven’t even tested the low-voltage stepdown yet.

In any case, I kinda prefer to remove the star-soldering config options and simply build the code with the exact features I want. It provides more room and makes the code more straightforward for debugging.

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

Cereal_killer wrote:
Guys quick question, does turbo timer not work if the mode order is reversed? I've made my wife a new EDC (an HD2010, even I dont EDC a light that large, good for her!) but she wanted it to come on in turbo and go down but its having some issues, stepping down threw the modes when it shouldnt and just acting bad in general so I was wondering if that just wasnt possible to use the timer if turbo comes first. Also I'm using the instant start turbo ramp down, not the timed single step.

Hmm, crap, it is definitely supposed to work.  Are you using just the latest standard STAR program with the instant turbo ramp down change?  PM me and I can give you my email address if you want to email the file you're using for me to debug.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 35 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

JonnyC wrote:

I finally put together a Github repository.  Here’s a link to the “dual pwm” branch where so far I’ve added the PWM features to STAR and STAR_momentary.


Thanks!

I got the updated versions added to my repository, under a dual_pwm/ subdirectory.

Additionally, I fixed the broken wires on my SRK and tried the new STAR_momentary on it. I made a few small changes for my own use, and put them in the repo too. It’s available here:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/h...

The changes are:

  • Six output levels (plus “off”) instead of four.
  • Short presses will cycle from high to low.
  • Long presses will cycle from low to high.
  • If you keep holding the button, it will cycle on its own (low to high). So, from off, simply press, hold, then release when it hits the desired level.

I tried to measure the output too, and got the following. I don’t trust my light box at the highest two levels though, and I had to estimate the highest level via ceiling bounce:

  • Mode 1: 1.0 lm
  • Mode 2: 12 lm
  • Mode 3: 62 lm
  • Mode 4: 315 lm
  • Mode 5: 1148 lm
  • Mode 6: 3100 lm (turbo)

This setup allows the SRK to go a lot lower than the “SRK Special” firmware RMM is currently using (it started at 43 lm). The slower PWM seems to have helped a lot! It actually emits a useful amount of light with the PWM set to 1. Thanks for implementing the per-mode PWM timings! Smile

comfychair
comfychair's picture
Offline
Last seen: 5 years 4 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198
#define MODE_PWM 0,PHASE,PHASE,FAST,FAST,FAST,FAST // Define one per mode above, 0 for phase-correct, 1 for fast-PWM

Very slick solution Silly

Adding a 0.8 or 1.2uH inductor between the B+ & LED+ pads will drop it even lower (it attenuates the PWMed levels, with greater effect the lower the value - lots of reduction in the lower modes, very little in the upper and nearly none at all on the 100% high). It also smooths out the rising/falling edges of the output sent to the LEDs, without affecting the nice square wave the FET likes.

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

comfychair wrote:
#define MODE_PWM 0,PHASE,PHASE,FAST,FAST,FAST,FAST // Define one per mode above, 0 for phase-correct, 1 for fast-PWM

Very slick solution Silly

Whoops, that comment in the code is wrong Wink

Richard asked for a feature for STAR_Momentary where a press-and-hold for x number of seconds would put the light into momentary mode, then press and hold to switch back.  I made the (pretty simple) change and he's going to test it out.  If it works out well I can make whatever tweaks are needed and then push it out in a new version.

comfychair
comfychair's picture
Offline
Last seen: 5 years 4 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

Ooh... if the switch is pressed & held continuously, like accidentally in your pocket or the bottom of a bag, it ramps thru all the levels and then turns off. Even if you don't use the ramping that's a neat safety feature.

(I changed the default mode order, and shortened the long press time from 40 to 17) Smile

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 35 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

comfychair wrote:

Ooh… if the switch is pressed & held continuously, like accidentally in your pocket or the bottom of a bag, it ramps thru all the levels and then turns off. Even if you don’t use the ramping that’s a neat safety feature.


Yes, it only ramps through once. I’m not entirely sure why though, since I didn’t program that behavior on purpose. But it’s a happy accident, so I left it as is.
comfychair
comfychair's picture
Offline
Last seen: 5 years 4 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

It's also useful for turning off without doing multiple clicks. With the mode order reversed, no matter what level you're at, hold the button and it ramps down and turns off.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 35 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

I prefer it with press+hold for low-to-high and tap-tap-tap for high-to-low. It’s what I’m used to because of Zebralights.

In any case, I’m trying to add a voltage readout. However, I’m getting some odd readings. I don’t know what values to expect from the ADC at different voltages.

ADC_CRIT is set to 120, and ADC_LOW to 130. I’m assuming the maximum value 255. But what voltage does 255 represent? And within that range, is it a linear relationship between voltage and ADC value or is there some sort of curve? Any idea what value 4.2V would be?

The plan is, if the user uses rapid short taps to cycle from off through all modes and back to off, the light should blink to indicate the remaining battery charge — zero to four times, for ~0%, ~25%, ~50%, ~75%, and ~100% remaining charge.

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

You can use the equation from the comments at the top of STAR to determine voltage values - http://www.jcapsolutions.com/wp-content/uploads/2014/03/STAR_1.1.c

comfychair
comfychair's picture
Offline
Last seen: 5 years 4 months ago
Joined: 01/12/2013 - 05:39
Posts: 6198

Luxdrv already has that blinks-for-voltage feature, dunno if the code is compatible or not. But at least you could see one way it's done.

http://budgetlightforum.com/node/5411

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 35 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

Thanks, I didn’t notice the voltage equation in the base version of STAR.

Based on my very very rough measurements with cells at 3.84V, it looked to me like 4.2V should be somewhere around 180. The equation says it should be 192 though, so I used that.

The actual values need some tweaking based on real measurements, but for now I’ve at least got it working well enough that it seems to work on my device. In the repo, I published a new version with the following changes:

  • It now blinks once briefly when power is first connected.
  • If you quickly tap from off through all modes and back to off, it will measure the voltage then blink a few times to let you know how full the battery is.

In theory, it should do something like the following:

  • 4 blinks: 3.98V or higher
  • 3 blinks: 3.70V to 3.97V
  • 2 blinks: 3.41V to 3.69V
  • 1 blink : 3.13V to 3.40V
  • 0 blinks: under 3.13V

But I haven’t been able to actually measure/verify this yet, and it’d be pretty difficult to do with the equipment I currently have. Also, I’ve noticed that the first time I do the battery check, it blinks one time less than it does on subsequent checks. Probably a bug somewhere. So it currently needs to be done twice to get an accurate reading.

The link, again, is:
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/h...

Edit: I just realized that, due to the way I implemented it, there’s a shorter way to get to the voltage reading. Long-press to get to the first mode, then immediately short-press to go back to off. It’ll then check the voltage and blink a few times based on the result. Is this method of accessing it a feature or a bug? (if using high-to-low long-press order, probably a bug… otherwise a feature?)

Edit 2: Since I still had a few bytes left and was worried about how one would tell the difference between “zero blinks” and “didn’t work”, I made it strobe the moon mode while it’s reading the voltage. Then it’s easier to tell something is happening, and if the strobe simply stops with no flashes it’s more clear that the battery is really low.

Also, to get an accurate reading, it is sufficient to leave the light on (in any non-zero mode) for a few seconds after connecting the batteries. Or you could just do the battery check mode twice. It seems the voltage measurement code simply needs to run twice before it gets a good value.

vex_zg
Offline
Last seen: 3 years 2 months ago
Joined: 08/10/2014 - 11:08
Posts: 420
Location: Sweden

Hi,

I’m using this in my reverse clicky convoy s3, however it does not work the way I expected.

I’m a bit puzzled as to go back to the previous (lower) mode in the modes list? If is keep the switch half pressed for more, it just goes back to the first mode.

Also for me, once the mode has been used for more than few seconds, short press does not make the mode advance, rather it goes back to the first mode.

Is it even possible to program it the way that you can go mode back with longer press of the reverse clicky switch, and forward the mode with shorter press?

Thanks.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 35 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

vex_zg wrote:
I’m using this in my reverse clicky convoy s3, however it does not work the way I expected.

Is it even possible to program it the way that you can go mode back with longer press of the reverse clicky switch, and forward the mode with shorter press?

Nope. The Convoy S3 switch cuts the power entirely, and it has no capacitor or anything to keep track of how long it has been off. So, it can’t distinguish between a short press and a long press.

To detect how long the button was held down, it either needs to have an electronic switch (like in the Skyray King) or a specially-added capacitor (custom, usually, and requires special “off-time” firmware).

In the firmware I posted, it uses short-cycle memory. So, each time the power is cut it will do one of two things — advance forward one mode, or go back to the beginning. It decides which to do based on how long the light has been on, since it can’t measure the off time. Another popular option is on-time memory, where it will keep the same mode from one session to the next (unless you tap quickly enough to make it go forward in the mode list). The on-time memory approach has no shortcut back to the beginning though.

Other people have done interesting things with firmware for this type of light too, particularly DrJones, but I’m less familiar with those.

vex_zg
Offline
Last seen: 3 years 2 months ago
Joined: 08/10/2014 - 11:08
Posts: 420
Location: Sweden

ToyKeeper wrote:
vex_zg wrote:
I’m using this in my reverse clicky convoy s3, however it does not work the way I expected.

Is it even possible to program it the way that you can go mode back with longer press of the reverse clicky switch, and forward the mode with shorter press?

Nope. The Convoy S3 switch cuts the power entirely, and it has no capacitor or anything to keep track of how long it has been off. So, it can’t distinguish between a short press and a long press.

To detect how long the button was held down, it either needs to have an electronic switch (like in the Skyray King) or a specially-added capacitor (custom, usually, and requires special “off-time” firmware).

In the firmware I posted, it uses short-cycle memory. So, each time the power is cut it will do one of two things — advance forward one mode, or go back to the beginning. It decides which to do based on how long the light has been on, since it can’t measure the off time. Another popular option is on-time memory, where it will keep the same mode from one session to the next (unless you tap quickly enough to make it go forward in the mode list). The on-time memory approach has no shortcut back to the beginning though.

Other people have done interesting things with firmware for this type of light too, particularly DrJones, but I’m less familiar with those.

Got it, thanks.

With the added capacitor, would it be possible to do it (go back in the modes with the longer press on light with only one reverse clicky switch such as my convoy s3) ?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 35 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

vex_zg wrote:
With the added capacitor, would it be possible to do it (go back in the modes with the longer press on light with only one reverse clicky switch such as my convoy s3) ?

In theory, yes.

There is a STAR off-time firmware to use as a basis for this, but you would need to modify it to change how it works. The default is short press = move forward one mode, long press = stay on same mode. This is because it assumes a long press means it has been off for a while and you already put it on the mode you want.

You might be able to change it so that a really short press moves forward, a medium press moves backward, and a long press stays where it was… but I haven’t actually seen that done before and you might have to choose a different capacitor in addition to modifying the firmware.

Personally, I find it easier to use a relatively stateless UI… one tap for moon, two taps for low, three taps for medium, etc… regardless of what the light is currently doing. It works reasonably well so long as your favorite modes are at the beginning of the list.

vex_zg
Offline
Last seen: 3 years 2 months ago
Joined: 08/10/2014 - 11:08
Posts: 420
Location: Sweden

ToyKeeper wrote:
vex_zg wrote:
With the added capacitor, would it be possible to do it (go back in the modes with the longer press on light with only one reverse clicky switch such as my convoy s3) ?

In theory, yes.

There is a STAR off-time firmware to use as a basis for this, but you would need to modify it to change how it works. The default is short press = move forward one mode, long press = stay on same mode. This is because it assumes a long press means it has been off for a while and you already put it on the mode you want.

You might be able to change it so that a really short press moves forward, a medium press moves backward, and a long press stays where it was… but I haven’t actually seen that done before and you might have to choose a different capacitor in addition to modifying the firmware.

Personally, I find it easier to use a relatively stateless UI… one tap for moon, two taps for low, three taps for medium, etc… regardless of what the light is currently doing. It works reasonably well so long as your favorite modes are at the beginning of the list.

Thanks, I’ll look into making it possible, it’s a bit annoying that you can’t advance to next mode once you have missed the window.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 35 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

Next mode, prev mode, reset to first mode, remember current mode for next time. Pick two. Or be prepared to do a lot of customization.

By combining a capacitor and on-time tracking and perhaps rapid cycle counting, you could probably do some pretty interesting things. Then the issue is how much you can fit into the tiny firmware.

vex_zg
Offline
Last seen: 3 years 2 months ago
Joined: 08/10/2014 - 11:08
Posts: 420
Location: Sweden

I get it. I’ll see what I can do with my limited time.

How is code distinguishing longer off time period and short-off time periods used to advance in the modes array? (in the use case of reverse clicky with only one button)

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 35 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

To distinguish the duration the light has been off, the code measures the voltage of a tiny capacitor. The capacitor gets charged while the light is on, then drains while the light is off. So, on boot it uses an ADC pin to check the capacitor and that value gives it an estimate of how long the light was off.

vex_zg
Offline
Last seen: 3 years 2 months ago
Joined: 08/10/2014 - 11:08
Posts: 420
Location: Sweden

But if it is checking that voltage through ADC, is it not then possible to distinguish between two “off” times, shorter and longer? or?

just to be clear: without any modifications to the driver hardware, such as adding a capacitor – the firmware can distinguish between longer and shorter “off” times – if it is doing that by checking the voltage on a capacitor through ADC, is it not then possible to detect a medium duration off time?

viperbart
viperbart's picture
Offline
Last seen: 8 months 4 weeks ago
Joined: 07/22/2014 - 15:17
Posts: 446
Location: Toronto ON CA

vex_zg wrote:
But if it is checking that voltage through ADC, is it not then possible to distinguish between two “off” times, shorter and longer? or?

just to be clear: without any modifications to the driver hardware, such as adding a capacitor – the firmware can distinguish between longer and shorter “off” times – if it is doing that by checking the voltage on a capacitor through ADC, is it not then possible to detect a medium duration off time?

I know nothing about electronics, but maybe the cap is also powering the chip when battery power is cut? How else would the chip be able to calculate off time?

I hope I don’t confuse anyone as I am just wondering myself how this all works together too.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 35 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

While the light is off, the capacitor gradually drains. The off time can be estimated by measuring the capacitor’s charge immediately after the driver boots. The lower the charge, the longer the light was off. It can thus distinguish between a short off time and a long off time by looking at how low the capacitor was immediately after boot. It does not do any measurements while it’s actually off.

Without physically modifying the driver, it has no way of measuring the off time. Instead, it makes all decisions based on how long it was on.

The idea is that, usually, a short on-time also means it had a short off-time. So, on boot, it sets the memory to “next mode”. After being on for a second, it sets the memory to “current mode” or even “first mode”. That way, if you turn it on then quickly tap it, it will advance to the next mode. But if you turn it on and leave it, the next activation will start at the same mode or perhaps the first mode (depending on the UI style).

On-time memory can tricked though. If I want my light to start on max (mode 5) next time, I can turn it on (mode 1), tap quickly three times (to advance through modes 2/3/4), then immediately turn it off. This leaves the memory set to 5, so when I turn it on later it’ll start in mode 5.

Is this making sense?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 2 hours 35 min ago
Joined: 01/12/2013 - 14:40
Posts: 10732
Location: (469219) 2016 HO3

I just glanced through STAR_off_time.c to find out the details.

At boot, it sets the capacitor pin for input only, then takes a reading. It discards the first reading because it’s unreliable then tries again. If the reading is high enough (short press), it advances to the next mode. Otherwise, it leaves the mode the same. Then it turns off the ADC circuitry and sets the capacitor pin to output only, to charge up the capacitor for next time.

It would be a simple matter to give it short/medium/long press detection. It merely needs to check against two reference values instead of one, to split the measurement range into three sections instead of two. But it still requires a capacitor between the MCU pin and ground. This doesn’t work on a stock nanjg/qlite driver.

vex_zg
Offline
Last seen: 3 years 2 months ago
Joined: 08/10/2014 - 11:08
Posts: 420
Location: Sweden

ToyKeeper wrote:
I just glanced through STAR_off_time.c to find out the details.

At boot, it sets the capacitor pin for input only, then takes a reading. It discards the first reading because it’s unreliable then tries again. If the reading is high enough (short press), it advances to the next mode. Otherwise, it leaves the mode the same. Then it turns off the ADC circuitry and sets the capacitor pin to output only, to charge up the capacitor for next time.

It would be a simple matter to give it short/medium/long press detection. It merely needs to check against two reference values instead of one, to split the measurement range into three sections instead of two. But it still requires a capacitor between the MCU pin and ground. This doesn’t work on a stock nanjg/qlite driver.

thanks for explanation, I got it.

now I’m thinking about what’s possible to get mode step back without the cap. Already posted twice, then deleted Smile

Pages