ooh interesting…are the flashy modes hidden?
Can you make a video on the function of the light
Way cool!
yes i removed it.
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/head:/ToyKeeper/s7/precompiled.hex
Now you got my attention.
Which driver; which pin?
NightSpy, who (or which post) are your questions addressed to?
Crum… I think I got the X6 thread mixed up with this one.
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.
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.
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.
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/head:/ToyKeeper/STAR_SRK/
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! 
#define MODE_PWM 0,PHASE,PHASE,FAST,FAST,FAST,FAST // Define one per mode above, 0 for phase-correct, 1 for fast-PWMVery slick solution :p
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.
Whoops, that comment in the code is wrong ;)
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.
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) :)
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.
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.
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.
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
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.
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/head:/ToyKeeper/STAR_SRK/
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.
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.