@Aprilis, a little smoothing goes a long way:
Looks good. :+1:
I will create an account on https://code.launchpad.net/ and upload my code once it’s a little more refined. I will also run the exact same tests with the old firmware and with my other Emisar (D4V2 Nichia, D4SV2 XPL-HI, D4SV2 Nichia) lights.
We also need to think about what should happen if you activate the turbo when the flashlight temperature is already above the defined temperature limit. We can’t just rely on the normal thermal regulation code, because it can’t react that fast, at least not on lamps like the D4.
Excellent! Will your code work on other Anduril lights? Or is it only for D4V2?
Great. :+1: Will it be a piece of source code or a ready to use firmware?
Could you please post graphs for other flashlights too? I am especially interested in D4v2 Nichia and D4sv2 Nichia.
Should work on any light, but I have to shrink the program code some more to make it fit into the attiny85.
Source code, but I can also send you the hex file, once I’m confident enough that its worth being tested.
I’ve quickly hacked some proper ADC oversampling and decimation code together and the results are amazeballs. Well worth the extra 200 bytes of code:
Can you please share how you enable this feature? Is there a list of the “easter eggs” so to speak? I did a search a few times but did not find. thanks
btw, first post here… just picked up this D4V2 recently. Coming from an olight s1r baton2, this is an eye opener!
You go into aux color config (7 clicks from off) and set it to volts, which is after the rainbow setting (the fast rainbow). It goes from Red,yellow,green…etc… then changing color slow , then changing color fast release the button here. Here’s a video Emisar D4V2 AUX Lights Walkthrough - YouTube
Thanks, I didn’t catch that last setting. Awesome
I managed to make the program size of the new code smaller than that of the old one. That means it will also fit into the ATtiny85. The only thing I’m still struggling with is the initial temperature overrun. I want it to be half as big: 
(The light came out of the fridge, right before I started the test. The room temperature was 22 °C.)
Edit: The regulation could become even better if we dedicate more program space towards it.
Too bad this forum has no “thank you” button! After Christmas I might have a look at the code.
It would be nice if the temperature regulation caused the output to decline to a stable level and then stayed there, even if it resulted in an initial spike in temperature.
One thing I don’t like is when temperature regulation causes output to dip drastically and then I have to run it for10 minutes for it to recover to a higher sustainable level. I’d rather it just go to that sustainable level after turbo wears off even if that means it takes longer for the temperature to get down to the target temp.
I agree, but a 10 degree overshoot seems to be unacceptable for me.
Exact same code and config on both lights. The D4S probably needs a small configuration change, but that should be it.
As far as I can tell, it’s fixed in fsm r464. At least, it works better now in my tests. It was updating thermal history twice as fast as it should, which meant it was measuring rate of change from half as long ago, and it kind of killed the “D” part of the “PD” algorithm it uses. So with one factor mostly removed, it was regulating too slowly.
Fixing it was actually pretty simple — just setting the timing back to how it was before. It was supposed to update itself automatically, but the old version had a kludgy workaround for something else, so its timing formula was incorrect. When I fixed the thing it had a workaround for, I didn’t remember to fix the formula too.
Anyway, if you can confirm that this restores behavior to how it was in r450, then we can rebase further improvements on top of the latest version instead of an old version… and that clears the way for merging upstream.
0-8-15 User
Thank you for the measurement. D4V2’s graph looks good. D4sV2 indeed needs some tweaking as its output power graph is not as steady and even as D4V2’s graph and it demonstrates lower or close power output which is a little bit unexpected considering their weight and size difference.
I think the unsteady output on the D4SV2 Nichia comes from the fact that the algorithm overestimates the temperature change due to the lower power to mass ratio, which I didn’t account for, because I wanted to see how much we need to tweak the configs for different lights. I’m pretty confident, that we are going to only need one external config for the new thermal regulation code. One that tells the algorithm the power to mass ratio of the light.
[quote=ToyKeeper]
Stays below temperature limit by a few Kelvin. Overshoots by 9K for a couple of seconds when firing turbo a second time.
Basically works like before, yes :+1:
What should happen if the temperature is near (or above) the thermal limit and the user enables turbo? I don’t think that the regular thermal regulation will ever be able to prevent the light from overheating well beyond the defined limit. Should we simply forbid the turbo in that case? Or should we add some kind of turbo timer (that only allows turbo for a couple of seconds in that case)? Or should it be solely based off the temperature and simply power down very quickly?
No timers, please. If the light is too hot it's too hot and should react accordingly.
The problem is that the light might not know that it is too hot. Due to the sensor delay.
Edit: When you say “it should react accordingly” do you mean it should simply ramp down 1 second after you enable turbo? If that is what is required to keep temperatures in control? Or should it not allow turbo at all in that case?