Thank you, it’s a cool idea but I don’t want to buy another pogo…I can try to do the same with gchart pogo but I have to find the right way to connect the dupont wire or use Hank pogo (directly with dupont)
Where I find the last firmware for SP36 Pro?
The actual controller part of Hank’s adapter won’t work, it’s a usbasp which speaks the wrong protocol. The pogo pins theoretically might if you used 3 out of the top 4, but I would be extremely careful (well, I wouldn’t try it, my hands are too unsteady) not to short anything while flashing and potentially damage the adapter, driver, or both (the outer two pins of the row of 4 are on the very inside edge of the outer pads, then the middle two pins are on both edges of the inner pad, and there’s about 0.5mm tolerance between everything. Might work, but if it slips then it could short and destroy something.
Also, gchart’s adapter isn’t rewirable and the pogo pins are too close together. Don’t try it, it’s possible to destroy the adapter if you short the pins on it (happened to me with one); the usbasp seems to have some level of short protection but not the UPDI one.
If there’s interest I could make the Sofirn adapters. Probably about $25 + shipping for one if I give myself about $2 for my time in making and testing it, I’d guess, or $5 without the programmer, but honestly that’s a bad deal even in my opinion compared to maybe $30 total to make your own and have lots of useful parts left over…
SP36 build is currently broken due to the refactor, I’ll see if I can get it working.
1 Thank
Thank you so much for advertising me about possible trouble moment.
I want to try directly with dupont female to male and I asked to Hank what the pin do in his usb adapter(the usb part not the pogo). For upgrade emisar Noctigon we use 6 pin but there are 10 in usb adapter and we don’t use all.
With gchart pogo is not possible because pin point are too short.
Thanks for the very detailed explanations of the ins&outs of these adapters!
But ouch, what an effing mess… IIUYC we have at least three ‘flashing standards’ (USBASP, UPDISerial and JTAGUPDI), plus a number of layouts even for the same ‘standard’, with gratuitous differences in pin order and spacing…
Hey, Sofirn and other manufacturers, COME ON… I don’t have enough space for all the flashlights I want, don’t need to add multiple flashing kits plus pin adapters etc… 
We have ISP (6 pin) and UPDI (3 pin). Each of them has a large variety of programming devices. In the flashlight world most common are USBasp and SerialUPDI.
6 pins have a lot of permutations. 
Every designer had his own “standard” because there wasn’t enough space to fit a standard ISP 6 or 10 pin header. Before the introduction of these little pads it was common to use a SOIC clip (which worked only for the larger package of the t13 and t85). With the t1634 having pads was kind of mandatory. I have a collection of various pogo-pin adapters to fit all of my flashlights.
3 pin UPDI is simpler. gchart introduced it to the flashlight world and recommended center as ground. That way nothing bad should happen when you flip the adapter around.
As you can see it’s not that complicated.
4 Thanks
I don’t understand why it’s so difficult to have a standard. If in this moment T1616 is the best choice (and they used in SP36Pro) why you don’t put a standard layout of 3 pin like thefreeman do or Loneoceans do… Nooooo always different with many complications for customers.
Uff…
Agree! I think also @Hank_Wang can do this upgrade. It’s an idea
1 Thank
As SammysHP said, jtag2updi vs serialupdi is just what protocol is used between avrdude and the adapter, and needs to maintenance or work from anyone here as that protocol support is maintained by the avrdude project.
Agreed re: maintenance, but I think not re:work – as when we flash, we still have to indicate which one to use on the avrdude command-line, and as every one of us have multiple flashlights requiring different adapters, the variation can be annoying and error-prone – and totally unnecessary if only them flashlight manufacturers could decide on a single standard and stick to it. Just as an useful analogy, imagine how hellish driving would be if every car had the brake/accelerator/clutch pedals in a different order and/or place. It’s bad enough that Englishman and their copy-cats put the driving wheel at the wrong side 
So @Hank_Wang , @Simon_Mao, @Sofirn and others – please please PLEASE just do as Wurkkos does and use the AT1616 and @gchart’s flashing pad layout already! 
Yeah, but you can’t really get literally dozens or hundreds of companies dwesining UPDI adapters to decide on a single protocol as wasily. Certainly, t1616 (3216) is the future for the MCU side but all of the different adapetr speak UPDI. In some cases, the protocol the adapters use because the adapters speak protocols other than UPDI as well. Worst case just put a note with each adapter for which it uses.
…technically, more people are right eye dominant so the left is statistically slightly safer
A better example would be building storeys (ground/1st/2nd vs 1st/2nd/3rd - I really do not mind which if the world could just agree on one…
Who needs dozens/hundreds of companies? 
If just the 3 I mentioned could get their act together and follow Wurkkos into the 2020s, the flashlight world would become a much better place already. And then all the others would have a much stronger incentive to follow suit or be left behind (or just go eff themselves in the lake for all I care )
…technically, more people are right eye dominant so the left is statistically slightly safer
You mean in terms of better seeing the other (possibly incoming) lane, right? But then, driving on the right (ie, having the wheel on the left of the car) will give the right-dominant-driver a better position in terms of seeing right in front of the car (as his dominant eye and its FOV would then be nearer the center and more aligned with the front of the vehicle). And it would give him/her a better view of the curb and sidewalk areas, so it would also be safer for the more defenseless traffic participants (people on foot and bikes) as they would also tend to be to the right of all drivers instead of to the left. I’m pretty confident that these two effects would more than compensate (in terms of overall safety) for the “better view of the other lane” effect (unless I’m missing something).
A better example would be building storeys (ground/1st/2nd vs 1st/2nd/3rd - I really do not mind which if the world could just agree on one…
Agreed. But that’s just a variation of the old “count from zero” vs “count from one” theme… I myself always try and count from zero as old Brahmagupta taught us, but I confess I’m not always consistent and for some things I still count from one… :person_facepalming:
Salut!
I’d need a PM for buying a flashing adapter as well
Hi, unfortunately I’m out of stock at the moment, ETA about 3 weeks.
2 Thanks
Thanks for the info!
Would you mind sending me a PM once you’re back in stock?
Yes I’ll let you know.
1 Thank
It shipped with 0715 (TS25) originally, but then Wurkkos sent me several of their lights and I made additional builds which are better suited to the individual lights. 0716 (FC13) and 0717 (TS11) are new. They can run on 0715 hardware but work better with the more specific newer variants.
1 Thank
I’m not sure, but I think Hank is planning to switch to UPDI compatible MCUs with the 3-pin flashing layout. Probably attiny1616, but there are also others which have good features and can be flashed the same way. The exact MCU choice is less important than making sure it’s easily flashable using common tools.
Switching to a new MCU with a new flashing method is a pretty huge cost for manufacturers… so it’s not a decision Hank takes lightly. However, it has enough benefits that I think he’s about ready to do it. The chip itself is smaller, and the 3 pads are much easier to fit than 6, so there’s more room on the driver for other things. The new MCU also has additional features built in, which can reduce the amount of other components needed, and also make the layout easier… while simultaneously increasing the amount of things the firmware can do.
I had hoped for an attiny3216, but it’s not produced in the right chip size. So I think attiny1616 is the most likely. It does almost everything right, and the main drawback is that it has only 16 KiB of ROM. That’s plenty for now, but it’d be nice to have more room to grow. After years of being neurotically obsessed with smaller code size, I’d love to be able to just write the code and not worry about how big it is.
6 Thanks
…my point was about the UPDI adapters themselves, not the light. The protocol avrdude uses to talk to UPDI adapters made by hundreds of different designers. What’s implementable on one MCU used for the flashing adapter protocol-wise on the host (computer) side might not be in another, and it’s a good thing to have more software options, doesn’t create any extra dev burden on users at all…
In terms of more size, I think RGB is going to be what will really add the most code size, and the 3216/3217 would be a lot nicer for that if nothing else.
1 Thank
Write code the way you like and then ask chatGPT to optimize it
That sure would reduce the work involved. And by that, I mean it would really reduce how much time the light spends working. It may even reduce the work so far, it doesn’t work at all.
That’s okay, right?
2 Thanks