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.
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) ?
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.