I tried yesterday to use Hank pogo and a DuPont for backup firmware but it’s too complicated and after 20 minutes I see I do not have a male to male DuPont so I decided to buy new board and needle for for my third pogopin🙄
In the next few weeks I will know if everything will work
I also contact Ivy and I asked for driver help because now I know driver pin designs are by @Lexel and probably all the driver.
Thank so much to @geforce73 for his precious help
1 Thank
There’s this: OSH Park ~ (if you order it, make sure you get it in the 0.8mm board to be the right size)
I ordered some boards a while back that got here a few days ago, but I am terrible at soldering the pogo pins, so practising that before I make any production ones, but at some point I’m going to hopefully have some for sale. If you wanted to DIY I can sell you a board with the appropriate parts at cost, I guess.
1 Thank
Yes, I buy the same and yes I do for 0.8mm and is the only option available for this board.
When all will arrive I can do a video for solder method I use. I also buy a mini plate from Ali yesterday
You might have a bit of trouble doing it via a reflow as they go on both sides, but I’d definitely be interested in what method you use to hand solder, I tried a few and couldn’t get any consistently perfect.
Probably I can use plate for one side and hot gun for the other side with kapton. I repaired one needle of Hank pogo but i don’t remember how 
1 Thank
I guess I need to get a proper heat gun… Well, have an excuse now, I guess.
My hot gun is not bad but is not professional. Ksger with fan in the handle. A professional hot gun have fan in the base and not in the handle. But I have paid 63 euros. Now I have 2 identical station but the temperature is not correct. The first station has serious problem! When I use it my electrical circuit breaker in my house goes off😳
Let us know how it goes!
1 Thank
I just received some Hanklights which came with fairly old firmware builds, so of course the first thing I did was reflash the latest firmware. On one light I got a verification error on the first try and on all of the many subsequent tries a “target doesn’t answer” error. When using the force (-F) option I get a signature mismatch (the device signature sometimes changes for some strange reason).
My last few attempts look like this:
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: error: program enable: target doesn’t answer. 1
avrdude.exe: initialization failed, rc=-1
avrdude.exe: AVR device initialized and ready to accept instructions
avrdude.exe: Device signature = 0x656570
avrdude.exe: Expected signature for ATtiny1634 is 1E 94 12
avrdude.exe: NOTE: “flash” memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.avrdude.exe done. Thank you.
[…]
avrdude.exe: Device signature = 0x2e6176
avrdude.exe: Expected signature for ATtiny1634 is 1E 94 12
[…][…]
avrdude.exe: Device signature = 0x2e6176
avrdude.exe: Expected signature for ATtiny1634 is 1E 94 12
[…][…]
avrdude.exe: Device signature = 0x656570
avrdude.exe: Expected signature for ATtiny1634 is 1E 94 12
[…]
Did I brick my brand new light? Or is there some way to recover from this?
Ok here we go.
I solder new pogo from Oshpark, add dupont wires but I don’t know why ZFlasher popup says “programmer not found”
Set to ATtiny85 for Lexel connection and use READ function but nothing… any idea?
1 Thank
“programmer not found” means that your USBasp isn’t detected by ZFlasher, has nothing to do with the pogo pins or the connection. Have you selected the correct programmer in ZFlasher? Otherwise it might not be supported by your Android.
2 Thanks
usbasp protocol
now the popup says “chip inizialization failed. check chip connection”
Edit:
I have to check DuPont position. Probably I use good position in pogo but not in the flat cable, where the last use is for FW3X
1 Thank
Sorry for the delay in responding. I agree with @SammysHP, the error messages you’re seeing probably means a connection issue.
I would triple-check everything and perhaps use a ohmmeter to check continuity between each pogopin and the corresponding pin on the adapter. If its all ok connection-wise, then the most probable cause is an effed-up USBASP adapter.
1 Thank
Ok it was a big mistake with wires. Now it’s ok for the connections.
So… I try to backup firmware from E07 2021 and this happened…
The last firmware in ZFlasher that I use is your 814-8C for Lume1 (FW3X) and it stay in memory in ZFlasher before I use the READ option, so, after GO click in android phone now in download directory I have your file name with 19KB so I think I have to rename it?
Is your file name of 19KB the backup firmware of E07 now?
Is possible is only 19KB?
1 Thank
Do not fell bad, every single one of us have done that at least once before – to the point of a boss of mine from many years ago once stating, “it’s always the cable” 
I don’t have any specific ZFlasher knowledge (I have never used it), specially re: how it works with files, so I can’t really help you here. Perhaps someone who use ZFlasher will chime in?
But first, yes: better to rename it, as from your description it does sound like ZFlasher overwrote the previous, HEX file with a binary backup file resulting from that READ operation.
Now about that 19KB file size:
I just checked and the 814-8C HEX file I prepared is this one:
$ unzip -v 814+814-8C_quick_aux_switch.zip
Length Method Size Cmpr Date Time CRC-32 Name
-------- ------ ------- ---- ---------- ----- -------- ----
31800 Defl:N 12840 60% 2023-11-01 09:20 20c3ff07 814-8C_quick_aux_switch_-_anduril.fw3x-lume1.hex
The relevant parts are the first (file size in bytes: 31800, ie ~31 KiB), and the last (the name). This is an HEX file, so given the way it’s encoded, it’s always larger than a binary backup image read from the MCU, by an approximate factor of 2 – but this is not exact given that the HEX can skip certain areas that the binary image will contain anyway etc, so the binary tends to be at least half the size of the backup, but usually is larger. So yes, a 19KB binary backup file is not absurd when compared to the original HEX file.
Is possible is only 19KB?es and backs up (EEPROM, fuses, etc), plus file format overhead (headers, checksums, etc). 19KB is not absurd either.
OTOH, I just checked and the backup files I have generated for my lights (whose MCUs also have 16JB flash, but using AVRDUDE instead) are only ~11KB, not 19KB, so unless different formats are being used and AVRDUDE’s is more compact, then 19KB sounds a little too large if anything.
TL;DR: I don’t know 
but I tried to give you enough info that, combined with more knowledge about ZFlasher (which I don’t have) will allow you and/or someone with that knowledge, to reach the answer.
The file name is
814-8C_quick_aux_switch_-anduril.fw3x-lume1-_3C_during_3c_bug_fix_attempt.hex
Yes, for me your original firmware is 31.8 KB
1 Thank
Here’s what I have here re: that file:
Length Method Size Cmpr Date Time CRC-32 Name
-------- ------ ------- ---- ---------- ----- -------- ----
32172 Defl:N 12967 60% 2023-11-02 07:12 1173ca8f 814-8C_quick_aux_switch_-_anduril.fw3x-lume1_-_3C_during_3C_bug_fix_attempt.hex
Yes, for me your original firmware is 31.8 KB
$ echo 1 k 32172 1024 / p | dc
31.4
So 31.8KB looks about 0.4KB too large, but otherwise quite copacetic.
1 Thank
Ok I am so happy! After one month the E07 is upgraded with PL47G2 firmware.
Now I waiting for your 8C mod:grimacing:
1 Thank
So I gather it worked! Great! And thanks for letting us know!
Sure thing! But please, for confirmation only, tell me exactly what hex you used and want 8C added to, and I will provide it.
I see your list of firmware and the pl47g2 is not in the list for 812 revision so i download the last pl47g2 from ToyKeeper