I was very close to doing just that, and then selling the one I didnt want…
Put me down for first dibs!
So you’d take either?
No updates on release date of XHP35 version?
Any BLF discount code available for the K1? 
Hank prices his products low, doesn’t do coupons that I’ve seen. Might have missed something…
Finally ordered a K1, dark brown with the green OSRAM - should be interesting...
Hopefully Hank is having a good Chinese New Year and will give us an update in the future.
I’m also awaiting news on the SBT 90.2, the FT03s has had a handful of issues so I’m hoping Hank can pull it off in the K1.
Is this actually confirmed to be happening, or just wishful thinking?
I’ve been undecided whether to get the W1 or W2, but I think if a SBT 90.2 was available I would get it instantly!
They are not confirmed. Hank said he was looking into them.
Please post some beamshots!
I'll try but can't promise anything - been too crazy for time.
Been wondering bout the driver - went back in the thread but haven't seen any pics or any real hardware design info. Curious who did the design for Hank. It sounds exciting though!! Would be interested if the driver would be made available, or if it's available now, and maybe in other common sizes. A true linear FET, if I understand correctly what that is, is a break thru for our firmware. Anyone know for sure what the MCU is?
TK's post #162 here says a tiny bit bout it: "No PWM linear driver"
If it's a K1 I'd take it.
I ordered a K1 in W1 and W2
Creamy colored body. I will most likely sell my second fave
It uses attiny1634.
About PWM, the attiny still generates a PWM signal… but that digital signal goes through a lowpass filter to produce an analog control voltage for the linear FET.
It uses 10-bit PWM for this, but I’ve been thinking about trying to implement a hybrid PWM-DSM signal instead, to increase the effective resolution. Inferion used this method on the Unicorn and it works really well. This would emit 8-bit PWM, but the duty cycle would change every cycle to allow for in-between steps. If my guesses are correct, effective resolution would probably be in the range of 12 or 13 bits, and it could still be used on traditional PWM drivers without making the pulses slow enough to be visible. Instead of 8-bit 16 kHz output, it’d be ~12-bit 16 kHz.
But to make that work, it needs really tight timing on a fast-cycling interrupt. So I rewrote all the interrupt handlers to make them as short as possible, and moved the bulk of their logic to deferred functions which can run later when timing isn’t so critical.
Mostly, that has worked out pretty well, but the ADC interrupt is tricky. ADC results are pretty noisy and coarse, so it needs some extra processing to improve the precision and stability of the signal. But… without using too many clock cycles. That’s what I’m working on now.
This in turn improves the thermal regulation response, which also needs some major rewriting.
A TLF member named 0-8-15 User has been very helpful with the ADC and thermal parts of this. He found and implemented solutions to both the ADC quality and the thermal regulation algorithm, and I’m adapting his work to be more compatible with the PWM-DSM concept I’m hoping to add.
Go ahead and put me as I'll-take-it. Sent you a PM.
TK - it sounds somewhat similar to what we did for the GT buck driver, if I'm understanding this correctly. Sounds like you were deeply involved in the hardware design, but did someone else do linear FET part?
Interesting idea bout getting the higher res PWM equivalent. Wish I had more time, but work'n 45-50 hrs billing/week recently and see no end in sight. I should be able to retire early, but at age 62, early is now... ?? 
I wasn’t involved in the hardware design, but you are correct that some aspects are similar to the GT driver. The linear FET is controlled the same way as the GT’s buck converter.
In terms of firmware differences, it mostly just means using 10-bit PWM and 16-bit ramp values instead of 8-bit and 8-bit.
A 16-bit ramp is a lot of extra data on these tiny chips though, especially for devices with multiple channels… and it only needs ~150 total steps. So I’ve been pondering a way to encode 16-bit values into 8-bit integers, with logarithmic resolution. Basically, the steps would be small at the bottom and large at the top. It would save ROM space, and it closely resembles the way perceptually-linear ramps are shaped. That’s a project for later though.
remember when your charging torches or batteries, put your keys away from the torch or batteries
take care of your torches!