It shouldn’t power the MCU, but it appears to do so anyway. The mem decay time goes from ~0.5s to ~4.0s depending on whether the OTC was charged when the light shut off.
Weirdness… And even more weirdness as that I have a 13A based driver where the memory decay time is about 10 seconds, and it doesn’t even have an OTC on it. It’s all this weirdness that has me back on OTCs but with bleed resistors. I use the memory decay trick for storage between short clicks, but no longer base on/off time checks on it.
The reason he went to the 22K instead of the 19.1K was simply because if you were using an attiny that you had pulled off of a 105C, the LVP values were close enough without having to reprogram. Unfortunately, it does seem to affect the OTC timing in weird ways...an unintended side effect. You'll find that on the zener mod drivers the LVP resistors affect the OTC timing very little, but on the 1S drivers (the newer ones with the cap on the battery side of the diode) it does make a big difference.
In short: if you can program your own MCUs, or are buying pre-programmed, just use a 19.1K instead of the 22K. If you are using a pulled MCU from another 105C driver, then you aren't using off-time memory and the 22K doesn't mess up anything.
I bought a pack of resistors from fasttech that includes 18K, 20K, 22K, no 19.1k. Since 22k can mess up the OTC which is a good alternative, 18k or 20k?
Each driver build seems to behave a little differently, especially if you change the components used to build it. However, the firmware should work if you do a little calibration on it. Or it might work without any changes.
I generally calibrate firmware for a few things on each light:
OTC values for ~0.5s and ~1.5s button presses.
Voltage detection hardcoded values for 4.2V, 4.0V, 3.8V, 3.5V, 3.0V, 2.8V, and 2.7V. Makes LVP and battcheck work.
Lowest usable PWM level, for moon mode.
Other PWM levels, if needed.
For the OTC, I flash offtime-cap.hex and measure a few button presses, then plug those values into my target firmware.
For voltage, I flash battcheck.hex and hook the light up to a variable power supply plus DMM, then adjust it to each desired level. It blinks out values I can plug into other firmwares.
For moon mode, I put my best guess into the target firmware, measure it, then adjust up or down and reflash until it’s how I want it.
For other PWM levels, I can usually just plug in some lumen estimates into level_calc.py and it’ll give me the numbers I need.
Stock store-bought drivers will probably “just work” with the default values, but custom-built drivers tend to vary more and need more calibration.
Wow…nice guide. Thank you! I will flash the driver tomorrow with offtime…maybe it works out of the box. If not, I do your hints step by step. But nice to know that there are different “tools” which help to customize the firmware.
If I recall correctly, this driver has an unused pin, pin 3 (a.k.a. PB4). At least, that’s the unused pin on wight’s FET+1 driver. I think he used the same pin layout here, except for not using the second PWM channel.
So, if you configure your firmware to put the switch on PB4, and solder the switch wires to pin 3 and ground, it should work without sacrificing the OTC.
In the OP, it shows pin 3 next to the “W” in “WELLS”.
Or, of course, if you don’t care about the OTC, use those pads instead. OTC isn’t normally used with e-switches, and this will make it a lot easier to flash the driver again later.