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.
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.
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.
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.
So… this has been bugging me for a while. Every time I edit the STAR sources, I have to fight the urge to fix this so as to avoid cluttering up the diff and the revision history, and also thus making cross-tree patches break… but it’d be really nice to agree on one and then make it consistent:
I flashed in jonnys dual switch firmware and put in a few more modes like your driver toykeeper. That moon is really really low I can see why this is so addicting- but I need to move the laptop over and use that so I can flash/mod and test without running across the house like an idiot
I couldn’t get comfys beta to come on, still working on that. Now if I can get the e-switch working.
edit Ugh it looks bad… PB4 is acting like it’s grounded all the time. I found it’s fine with the ohmeter and the switch is working. I might have to switch over to PB3 and hope that one isn’t fubar
Oh the joy
That’s probably why I couldn’t get comfys to work too… The eswitch was acting down the whole time.
Anyone every have issues with STAR Momentary locking up?
I'm trying to determine if its a hardware or FW issue. I think it may be where I'm connected the PWM output, but am wondering if others are having this issue before I do surgery on the light.
I'm using the version that Tom E modified to include strobe. It generally locks up in the 3rd mode (going up or going down). I have 7 modes (1,3,9,27,81,130,255), Turbo, and voltage monitoring. Cell voltage does not seem to matter. Lock does not happen often and I have seen no pattern to when it happens yet.
Driver is HX-1175b, two R33 resistors added for 9 amps current, 4 cells driving a MT-G2. Original MCU has been removed. No heat issues appear to exist. Using 81000 and 4700 ohm resistors for voltage monitoring.
Interesting. I haven’t seen it lock up… then again, I don’t generally leave the power connected while it’s not in use.
I’ve seen some bugs in my own STAR-momentary derivative, but I haven’t noticed any in STAR itself. I don’t think I’ve ever seen it lock up, in any case.
Do you have any of the hardware for reflashing an attiny13? It’s possible that maybe the flash was incomplete or the ROM got corrupted… but I really don’t know.
Thanks wight and ToyKeeper. It locks up when on. If I disconnect power for just even an instant, the FW works normal again.
I'm thinking its a hardware issue. Maybe a weak connection to the switch. Or, it may be that I'm tying PWM directly into the Buck Converter. There is a resistor to ground on the Buck Converter PWM input pin, but I could go downstream.
Now if I can get the e-switch working.
