Remember the eye sees light intensity not on a linear scale but closer to a logarithmic one(what looks half as bright is actually closer to 1/10 actual output).
Interesting, I didn’t know that but it makes sense.
I’ll stop at the shack on my way home again tonight and grap a green LED and higher ohm resistors and and try running it at a lower current.
if you use uv led and gitd boot, it will glow green(or other color, depending on the boot color), brighter than led alone.
I mean the trick alexvh published:
I have this implemented in my s7/* firmwares and it works very well. However, it’s possible the parasitic drain might interfere or make the timing not the right duration.
My guess about what happens is … when the light is off, the circuit reverses and suddenly the driver is processing negative voltage as if the battery were inserted backward. Most drivers have a diode to protect the MCU from this, I think, but the rest of the driver is probably passing the negative voltage through. I’m not sure how components would react to that, or if any parts might get damaged over time.
Anyway, if the MCU is indeed fully off, its memory should remain intact for a short time before it goes blank… and you can use that effect to simulate an off-time measurement if you only care about “short” versus “long” presses and aren’t too pick about how long the duration is.
Hmm what is an easy way to test if the flow is reversing?
……………………
The main reason I think the MCU isn’t turning off is because of the behavior i saw with the blinking led. With the blinking led, instead of it having next-mode memory, it appeared completely random what mode it would come on. After a while, I realized the driver was changing modes each time the led blinked. If I turned off the light, waited 3 blinks from the tail led, then turned the light on, it would be 4 mode levels further in the cycle (3 led blinks + 1 switch click = 4) than when I turned it off. It was repeatable with 4 blinks, 5 blinks, etc.
If you can use a momentary firmware, I already have something you could drop in. The Ferrero_Rocher/* firmwares already know how to control a couple of battery status LEDs which give realtime status while “on” and stay dimly lit while “off”. There are three different interfaces available, depending on whether you want something like an improved STAR UI, smooth ramping UI, or an Olight Baton-like UI.
With the setup I’m using, the parasitic drain with standby light only uses 0.36mA, so it should last about a year on a 3100mAh cell. Or with the status indicator light in “bright” mode it’s 1.23mA or about 100 days.
The firmware is at the link in my sig, and hardware build details are here:
It’s a nice setup; it’s too bad more lights don’t work this way.
Use a DMM and measure the voltage to see if it goes between positive and negative depending on the switch position.
I’m really thinking about getting an F6, and I would probably try to find one with the indicator window. With that one I could use your FW, but my bedside light is a P60, and that’s really what I want this for.
BTW, another theory… maybe the circuit doesn’t reverse, but simply changes its maximum amperage dramatically depending on the rear switch state. The attiny can run at 0.33mA, so it’ll probably be able to boot with less power than the tailcap LED uses.
With a blinking LED, the circuit gets cut while the tail LED is off, so the attiny is booting every time the LED comes on… but it doesn’t have enough power to light the main LED.
With a solid LED, the circuit may get cut briefly every time the switch state changes, but would supply power to the MCU in both the “on” and “off” states. This would mean every click will be interpreted as a short click, because it’s only powered down for a split second. The difference is that there isn’t enough current to light the main LED with the switch “off”, but the MCU probably still tries to do it anyway.
If this is true, neither an OTC nor memory decay trick would work, because it never gets a chance to discharge. On-time memory would, but you’d be getting two click events every time you tap (half-press and release) the switch.
This would be a lot easier for the MCU to handle if it had some way to tell if it’s in regular full-power mode or tail-only mode.
Thanks TK, this theory lines up perfectly with what I’m observing. So you can’t think of any way to get around that issue? I suspect voltage is also dropping along with current when the switch is ‘off’, maybe the FW could recognize that low voltage and somehow……? Or do you think if I can get enough light while limiting the current to under 0.3ma that would shut down the mcu and work properly?
I also have a firmware which does nothing but dump out the raw voltage reading… you could use that to check what level it’s running at in “off” mode versus regular operation. And if the “off” mode is lower than the usual LVP cutoff, it’d be easy to detect which mode it’s in.
Look under ToyKeeper/battcheck/ to find that. There’s also one to show the OTC values, which would answer any questions about whether OTC is going to be usable.
I’m thinking the Batt Check FW won’t work because the main LED doesn’t light in ‘off’ mode so there won’t be any blinks, right?
The tail LED leads are exposed currently, would measuring voltage across those give an accurate reading?
Oh, duh. It’s too early in the morning to think. 
Yeah, it wouldn’t work because the main emitter won’t light up. But using a DMM might be close enough. (though measuring at the driver might be better than measuring at the tail LED, if possible)
The battcheck thing at least can be used to get the normal ADC operating range though, and anything below that would be considered “off” mode.
Using the number above I calculate the voltage at the driver to be ~0.4V much too low for operation.
Given: 1k in series with the LED and 1k across the driver = 2.2mA
Voltage across driver = Battery voltage - red LED Vf@2.2mA - series resistor voltage (R x I).
Voltage across driver = 4.2V - 1.6V - (1kOhmx2.2mA = 2.2V) = 0.4V
Of course all this can be measured with a meter.
It certainly looks like the charge on the OTC may be the reason. When the switch is turned OFF the voltages on both the MCU and the OTC begin to decay. This extra led current seems to be messing up the critical timing between them. (or something else entirely...)
Lowering the resistor at the driver to 500 or even 330 ohms will drop the driver voltage down lower, but I'm not sure that is the right approach. Using a blue or white LED (higher Vf) and a higher series resistor (lower current) may be a better approach. Obviously, the driver works when there is no tail LED, so reducing the tail LED current as low as possible seems like the right direction.
...but I've been wrong before too...
Ok I grabbed a blue led and a green one, and i now have 3 values of resistors: 560, 1k, and 4.7k. I’ll play with those later tonight.
I measured the voltage across the tail led with the two 1k resistors: 1.6v. I’m not sure what that means, but maybe someone else does.
When you say "two 1k resistors", where are they? One in series and one across the driver? or...
The 1.6V is exactly what I would expect to measure across the LED itself.
Yes, 1 on the driver, and one in series with the led. I haven’t changed it (yet) from my results in my previous posts.
I’m very curious to know what the OTC reading says after the light has been off for a while, compared to after just a short tap.
I’m not sure how to measure exactly, but I let it sit overnight in medium mode and in the morning it came on in high mode.
PZL driver, Nichia 219b, green 5mm 2.1v led in the tail. 560ohm resistor on the driver, 4.7kohm in series in the tail.
I don’t know why it works, but it does.
Driver is behaving normally. Off-time, no memory, always starting on moon.
The green led is a little dim, so I’m going to swap in the red ones with the same resistors to see if it still works.