I recommend something like this:
It’s a RGBW setup with some additional channels (indicator, ultra low moon …) though, a dual channel setup as in the stock D4 is much simpler. I recommend 1 through hole LED per channel (7135 and FET), driven with resistors directly by the mcu. It helps to see what’s going on.
Got any suggestions for a test/dev setup for thermal regulation? That’s pretty much the only thing I find is obnoxious to develop, since it seems to need a fully-assembled host for testing.
Maybe it wouldn’t be so bad if I had a driver with pads/vias on the spring side for flashing without disassembling the host.
great Idea, thanks!
I will add this…the happiest day of my flashing life is when I threw out my cheap clip and bought the Pomona clip. Worth every cent and then some.
I designed a D4 driver with vias for programming pins for my RGBW mod (see below), but the driver is made for Attiny841 in QFN package, so I guess this won’t help here.
If it’s sufficient to have a fully assembled head, you could try this approach with the stock driver:
drill a little hole through the driver (next to the 7135 is no copper) and connect the programming wires through this hole to the mcu, GND (and probably BATT+) might also be connected at spring side.
Should also work with tube if you use strong wires to connect the cell through the tube.
Just an idea though, I haven’t done this by myself.
Well, my experience was just the other way around. I started with 3M (not good), switched to Pomona (not good) and I’m using now this cheap ebay clips. In the last two years I flashed hundreds of times with about 3 cheap clips (which together are still much cheaper than a single 3M or Pomona).
that’s good news, as I bought one of the cheap ones. I don’t imagine I will use it hundreds of times, likely just a handful.
Really, maybe not all cheap clips are the same, mine started to start slipping off the chips and just got progressively worse and it would not stick to anything. The metal pins became misaligned. The Pomona clip fits way more square so it is so much less prone to doing this. The 3M clip looks like it suffers the same design flaw as the cheap ones.
So the adventure of flashing has begun. I have worked through a couple small issues and appear to have connectivity to the ATTiny85. I have not tried to erase yet, as when I look ahead to the next command (to flash) it appears I need to know some
when I search the .c file for “fuse”, no hits. Is this fuse mapping required to reflash my D4? If so, where do I find that info?
Don’t bother with the erase step. It’s not necessary at all.
I’d suggest using bin/flash-85.sh or copying the commands from that file. It has the fuse values and other options most projects use, and is known to generally “just work”.
to reveal a bit of my knowledge on this subject, I have no idea where to find the file flash-85.sh Is this a command somewhere in the programming line, like
avrdude -p t13 -c usbasp -u bin/flash-85.sh ?
The flash-85.sh file is located in ToyKeeper’s flashlight firmware depository inside the /bin folder. Its avrdude command reads:
Change FILENAME.hex to your .hex file’s name.
Note the ‘t85’ option. This sets the chip model to ATtiny85. Your example shows ‘t13’, which is erroneously specifying an ATtiny13.
I mentioned in your other thread that before sending your new firmware, you can test your connection between the ATtiny85 and your programmer with this command:
If the connection test is unsuccessful, you may need to fiddle with your clip. I have a cheap one that sometimes needs a couple of tries. 
It looks like you’re getting close to a successful reflash. Keep at it, and keep us posted! :+1:
Hey goshdogit, thanks for all your help. I guess I really should have kept all this in one place, it would have helped me keep track of it. 
I was able to connect using the ‘t13’ command, but got some minor errors. using the t85 came out a bit cleaner it seemed. I still get a warning about ‘cannot set sck period. please check usbasp for firmware update’, but the device signature comes out ok and I get the safemode Fuses ok message, much better. :+1:
I have been practicing with a demo board with a t85 chip on it before disassembling my D4. I connected the clip backwards to the demo board yesterday :person_facepalming: but it seems like it survived that.
After a couple of false starts on gettting ‘filename.hex’ correct, it looks like I successfully flashed the demo board. 
Next step is my D4 . . .
Nice! :partying_face:
I put a small dot of silver marker on my clip to mark pin 1’s location, and another on the ATtiny85 chip. It makes it easier to attach the clip correctly.
I get that ‘cannot set sck period’ error, too. I’m not sure what it means, but it doesn’t seem to cause any problems. I’ve flashed over a dozen lights several times without issue. Perhaps someone with more experience can chime in about it.
It’s my understanding that these USBASP boards set SCK automatically and the error is really just a advisory.
Perfectly normal. Just ignore it.
After reading this thread, I managed to disassemble my D4 and flash Anduril successfully, but got in a hurry when attempting to flash my Q8 and used the wrong fuse vales :person_facepalming:
The only led that still works is the green button led, and the ATtiny 85 isn’t responding. Any ideas on the best and/or cheapest way to fix this?
From what I’ve read it seems like my only options are either building a high-voltage avr programmer (which I do not think I have the knowledge to do) or get a hold of a completely new Q8 driver…
Thanks! One’s on the way, $10 is quite a bit cheaper than I thought a q8 driver would be :+1:
OMG! I CONNECTED!!!
Cheaped out and bought the pre-wired clip from wherever, have never been able to connect.
Did all of the driver signing stuff with Win10, been at this for a while.
Finally desoldered the wires and did it myself and I just got the most beautiful response to avrdude -p t13 -c usbasp -n
There’s still a lot to be done, but I’m happy to be past that.
Thanks to all who’ve contributed!
Robert