The voltage used for the readout is also used for low voltage protection. Voltage calibration requires a lot of memory, but you can set the offset manually by changing the “fudge factor”:
2 Thanks
Thanks. I think I’ll not take it apart again. The cooling of the AMC7135s causes them to puddle in the thermal paste, and not easy to solder because of the design of the aux LEDs.
I don’t usually drain the batteries completely anyway. Better this way than overdischarging the battery…
So I have been experiencing flashing problems on android too if I use the serial updi for my wurrkos it works fine but when i do hank lights usbasp 1634 it says programmer not recognized i have 8 usbasp boards including original from hank what the hell is goin on does anybody have an answer it just stopped working one day maybe need new key header but dont know where to get on cam someone please help
If all of those USBASPs are giving the same error, it might be a driver problem.
Have you updated the app recently, or something like that? I’m not too experienced with android flashing, as I use avrdude from a PC.
1 Thank
You, me and almost everyone else. That’s what I would recommend to @NewGuy420: try and borrow a PC and use avrdude, at least for an initial diagnostic. Once you have at least one of these USBASPs confirmed as working, go back to Android and try to get more detailed info.
1 Thank
I tried it on all my flashlight and i get the same thing every time I’m wondering if the pogo key is no good but i test it and get continuity
1 Thank
Thats my other problem, kind of ashamed but I am not so cpu savy either been trying to do it but dont understand the commands I’m suppose to do
1 Thank
I would also like to add it works with the Updi but not usbasp i tried 7 different usbasp flashlight all give same error programmer not found
That’s what we’re all here for, no need to be ashamed 
been trying to do it but dont understand the commands I’m suppose to do
Here are the commands I use (on Linux, on Windows you should omit the sudo and replace /dev/ttyUSB0 with either COM3: or COM4:, depending on any other serial devices that might be present):
- To read the current firmware in the flashlight to a file on your PC (good to check whether the UPDI adapter is working, and also for making a backup of the original firmware the light came with, before writing a new one):
sudo avrdude -p attiny1634 -c usbasp -P /dev/ttyUSB0 -Uflash:r:firmware_backup.bin - To write a new firmware from a local file to the flashlight:
sudo avrdude -p attiny1634 -c usbasp -P /dev/ttyUSB0 -Uflash:w:new_firmware.hex
Try those (specially the first one) and tell us what you get; if you get an error, please post the entire output and we will try to help you fix it (or at least figure out what’s going wrong).
EDIT: just notiiced you are using USBASP and at1634. Changed the commands above accordingly…
I have similar experience with Zflasher,
ZFlasher, SerialUPDI, Wurkkos HD10 and TS25 (ATtiny1616) : Test, Read, Write OK, completed successfully.
t1616, SerialUPDI, it’s very nice and easy. Android device and ZFlasher work beautifully.
ZFlasher, usbasp, Mateminco PD90S (ATtiny85) : “Programmer not found”
I also tried “usbasp-clone” in the programmer option 
, same result : “Programmer not found”.
I thought my USBasp programmer was faulty, but same results with two USBasp programmers so it’s unlikely.
No idea why it’s like that. Maybe it’s driver thingy. Latest version of Android and latest version of ZFlasher. This is my first time flashing ATtiny85 (so far unsuccessful).
1 Thank
I then tried with my Windows 10 laptop with AVRDUDE (command line version), I’ve got to the point where AVRDUDE recognizing the t85 in my PD90S. Device signature and Fuses OK. I think this proves my USBasp programmer is good.
I tried again with the other USBasp programmer, same result, t85 was detected. Device signature and Fuses OK.
So yeah in my very limited experience USBasp programmer only kinda work with laptop with AVRDUDE,
doesn’t work at all with Zflasher, unfortunately.
1 Thank
Never tried USB-ASP. Resisted the Hanklight’s siren song for a long time until the D3AA came out (with UPDI) because I didn’t want to mess with USB-ASP, and then only got the T9R from FFL after confirming it was the new version with AT1616 and so UPDI. Now that (almost?) every vendor has left the old AVRs and USBASP behind, I guess I’m safe from it 
Agreed, IME if any AVRDUDE read command works, it means it’s able to talk to the UPDI adapter and, through it, to the MCU inside the flashlight – and then all should be good.
Yeah, IMO a PC with AVRDUDE is the gold standard in terms of MCU programming. All the rest (pycumprog on a Mac, zflasher on Android, etc) are more or less after-thoughts.
1 Thank
.
My flashing gone wrong?
Windows 10, AVRDUDE,
USBasp programmer,
jumper wires & header pins,
Mateminco PD90S SFH55 (ATtiny85)
My PD90S came with Anduril 1.
Before flashing I set the switch LED to “high” to make it easier to notice as an indicator of connection with the programmer.
I tried flashing new hex file “anduril.2024-04-20.mateminco-mt35-mini.hex”.
AVRDUDE recognizing the t85 in the communication test.
That’s the good part of the story. In total not that good, unfortunately.
When flashing new firmware it ended up with “verification error”
I retried flashing a few times, same results, process of flashing/writing seemed to be working but then ended with “verification error”.
After like five times trying, something weirder happened, it’s a different type of error,
AVRDUDE said this :
“avrdude: error: program enable: target doesn’t answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override this check.”
I noticed the swith LED no longer lit.
Subsequent flashing attempts failed completely with the same error :
“avrdude: error: program enable: target doesn’t answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override this check.”
Reinstalled driver retaining ring, battery tube, battery,
tailcap …
When tailcap was fully tightened flashlight turned on VERY BRIGHT. Switch LED was off.
No response when clicking the button, it’s just a single mode, very bright.
Loosening the tailcap turned it off, of course.
My Mateminco PD90S has become a single-mode-twisty-flashlight 
It was Anduril 1, I wanted Anduril 2, now it’s 0.
.
Did I brick my flashlight? T85 dead?
Replacing the microcontroller/driver-board is the only solution?
Or there’s still a hope?
Should I retry reflashing with different firmware?
Anyone has similar experience? And/or knowledge about this abnormal flashlight condition resulting from improper reflashing?
Please share and enlighten me.
.
Very wise decision
. I was in the safe zone of UPDI but then got interested in the big thrower PD90S, this is my first thrower, thinking it would be no problem I’ll update it later.
I have had my PD90S for a week and now it’s half-dead (maybe 3/4 dead. It’s a zombie)
.
Or is it a brick? I hope not.
Beware! I’ve had instances where the flashlight was consuming more current than strictly necessary, and that made the UPDI connection unstable. I would turn the switch light (and anything else you can control) to as low a level as possible.
This means the MCU accepted all the write commands and returned OK after writing them to the flash pages, but when these pages were read back by AVRDUDE, their contents were different that what he told the MCU to write. This also means you have a corrupted firmware on the light and should NOT use it with that firmware (think burning LEDs due to too much current, etc).
I’ve seen that before in my D3AA. Apparently the corrupted firmware gets the light stuck in a state where the main LED is being turned on at full brightness – and then the USB UPDI is unable to supply that much current, that’s why you get these “target doesn’t answer” errors on AVRDUDE, the MCU can’t work properly without proper power.
What I did was to rig 2 pieces of wire – one to touch the “ring” in the driver’s PCB inside the head (the same place the tube touches to bring in the negative pole of the battery), and another to touch the “tip” (where the positive pole of the battery makes contact) so I could power the head with enough current (by connecting them to a 3.7V 15A power supply – beware of polarity!) while being able to access its programming pins.
Once the head ‘stabilized’ with the power supplied by that rig, I was able to connect the UPDI programmer and proceed with the programming. Writing a good and verified firmware brought my D3AA back to life.
Hope you can revive yours too!
1 Thank
Thanks so much for sharing this. Your experience and explanations totally make sense and giving me a good reason and hope to retry reflashing.
That power supply stabilisation is really genius.
I’m gonna try that and I’ll report again the result later.
1 Thank
.
This is a very enlightening , thanks again
Glad to be of help! Good luck and please keep us posted!
2 Thanks
Nobody knows what driver model the d4k boost (2024) has? Same as d4v2 boost? (Then what is d4v2?). For some reason, the numbers did not coincide with any reference version 