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.
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.
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)
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.
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.
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?
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 
Without the capacitor, you could still do tricks with the total amount of time passed… but the UI will rapidly get harder to use with more than just “short” and “long”.
Like, you could say that if it has been on 0.0 to 0.5 seconds, step forward. 0.5 to 1.0 seconds, step backward. 1.0+ seconds, and it would stay at the same level. Easy enough to implement in firmware on stock hardware, but kind of hard to actually use the thing in practice.
Yes, that’s what I had in mind. But as you said, makes the ui complicated.