Well if the light is at/over the programmed thermal limit it should not allow turbo. If it's still below allow turbo for a very short amount of time - basically the way Zebralight does it, though these lights have the advantage of having the sensor right on the same PCB.
Make sure to test the thermal algorithm at non-standard ambient temperatures too, e.g. with the light taken out of the fridge/freezer or after pre-heating with a hair dryer.
I appreciate the work you're doing for all of us on the thermal regulation :-)
We might be able to use the internal voltage reading for the thermal regulation. Higher voltage -> more heat -> higher phase shift -> faster thermal regulation response.
I can only strongly advise to not use anything newer than r453. The thermal regulation is almost completely broken in my eyes. It’s pure luck if it works.
Yeah, the regulation looks pretty good for this light (and even the D4Sv2). But it wasn’t tested on other flashlights and is based on a older version of Android Anduril. I think we need ToyKeeper now for review, testing on other flashlights and possibly cleanup of the code (although it’s already clean, but maybe not what ToyKeeper likes).
Ok, I made FW3A build from code and it seems its working. Will need to test it outside, its about zero degrees celsius now.
Anyone else tested it on ohter models? I am waiting for TK comment on this new code too…
As a follow-up to my earlier post, I just received the new aux board from Hank and soldered it in. Worked for a few minutes and I had my hopes up, and then went dead just like the old one. So there’s something else going on… must be in the driver.
I initially suspected the old aux board had a bad resistor for the blue, but I measured it while running and it was dead on with how it was labeled (0.9k). So then I assumed it must be the driver but tried the new aux board anyway. It was worth a shot I guess.
