Thank you! I will give it a try. Does every Nanjq compatible firmware (for example NLITE) work with this driver?
Yes I think so. Because it isn’t open source.
No 
I like to know if every firmware build for Nanjq Drivers (for example the 105c) also works for the A17DD-SO8
I only found the download links for nlite there 
I dont think there is a download for guppydrv at nerd camp. As far as I know the only open source codes DrJones has are the ones found in ToyKeepers repository.
The OTC shouldn’t power the MCU because it’s not on the VCC. As far as I know, the MCU cannot be powered by any other pin than the VCC. The input capacitor would keep the MCU alive, but I can’t see the OTC doing it. On the other hand I’ve had to deal with some OTC weirdness myself, so I wouldn’t bet my savings on it…
In any case, if you want to shorten the measurable time of an OTC, put a so called bleed resistor on top of it. I’ve used values of about 360K for mine. I’ve had to deal with bleed resistors enough to incorporate a dedicated resistor spot for them on my driver boards. You just put them in parallel to the OTC, which basically means on top of it if there isn’t a dedicated spot.
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?
just order a bunch of them they are cheap
http://www.aliexpress.com/item/Free-shipping-500pcs-RES-ORIGINAL-SMD-Resistor-1-0805-19-1k-19-1K-chip-resistor-1/32268559656.html
I’m not sure if RMM carries extra resistors, but if so I’d like to add some to my next order.
Just add a note and I'll throw some in for you. They are pretty cheap.
What specs for the SOD-323 Diode (D1) are allowed?
Does this ones work:
or do I need this fixed specs: 10V 570mA
EDIT:
Or maybe this ones:
Is the Star off_time firmware useable without any changes on this driver?
I have seen 19,1kOhm is used for the calculations. Or is there a better open source firmware?
Thanks!
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.
I’m using star off-time with stock adc values and a 22k ohm resistor, need to set a lower adc value or use 19.1k should work better.
This driver also works with star momentary? Where I have to solder the e-switch then?
Solder it to the OTC pads
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.