Yeah, it’s supposed to work like that.
Although you can change it, just not that easy…
Easiest way would be to remove the following code from the EV_enter_state of steady_state:
nearest_level(arg) caps the output when entering the mode at max. ceil level.
There may be side effects when disabling that, but for now it seems as it would work.
Maybe with stepped ramping there could be a small glitch.
Off + double click = Ramp Ceil
On + double click = Turbo
Ok, with the newly compiled firmware I tested the thermal regulation again and it did basically the same thing.
I turned the light on turbo and then put it on my sphere and watched the lumen output and temp.
First it climbed up to ~43c and then started down regulating perfectly. It dropped down to ~2k lumens or so and the temp stabilized for a little bit.
After a minute or so it started ramping up again, it went up to around 8k lumens and then ramped back down to the minimum level of around ~1k lumens.
It then went into the same “loop” or “wave” pattern where it would ramp up and back down, each time getting hotter. I left it for a little bit and when I came back it was 102c.
Needless to say I don’t think that is supposed to happen.
I have positively no idea what would be causing it but it seems like some tuning of the thermal regulation settings could help it a lot. There are not many defines for this though that I can find.
If there are any other settings that can be tweaked to help tune the thermal regulation I would love to know what the defines are so I can add them to the “base config file”.
Good to know, there very well might be a case where I would want to disable that, it would be cool if I could use a define in the config file for this purpose but that goes over my coding abilities right now.
Basically comment out that line and it should act like Narsil with double click going directly to full turbo no matter the starting state?
I think I will try it as TK has it setup for now and see how it is once I get used to it. It is not a bad idea.
What I would like to change is the delay as the firmware waits to see if you will double click before it does anything (aka, you press the button to turn the light off but it waits half a second before turning off). That bothers me more then I want to admit lol. I personally prefer the light turning off for a moment before going to turbo if you do double click.
So it is unlikely there will be anyway to fix this anytime soon?
I am confused why it seems to have an issue in this light when it works on the D4. I bet the D4 actually heats up faster.
I guess I can always fall back on Narsil if the thermal regulation is some time off luckily. I burnt myself slightly when picking this light up and I knew it was hot lol.
If this is a PID controller based temperature control, That sounds like too much P or not enough D causing an oscillation. Its just really odd that it works fine on a Q8, fine on a D4, but not your light.
Great, I will make a note of that line. Is there a simple way to remove that line with a command in the config file, it is hard to remember these things months down the road, which is why I like having all the options in font of me in 1 place when possible. If not it is no big deal, I am not super worried about this, just a nice to have option.
Yep, I would like the Immediate off option for sure. The Immediate on option would be great to have as well, although I am not as bothered by that.
I figured the thermal regulation would be a TK item since she is the one that is working on the new algorithm.
I wish I spoke C better, I know enough to “order a hamburger”. I can understand defines and grasp the basic concepts and what is possible and what is not but that is about it.
It works perfectly at first, then after 30 seconds - 1 minute is goes into the loop and seems to ignore the temp sensor input as it is way above the range it should be raising the power.
I suppose there is a chance that the MCU temp sensor is damaged, I wish Anduril had a way to read out the temp reading like Narsil, it is very handy for troubleshooting.
I might try putting Narsil back on the light and seeing what it reads the temperature as but seeing as anduril starts thermal regulation exactly when it should, I am guessing it reads correctly.
I am sure this is a silly question but is there a simpler way to update the code for anduril besides making a whole new copy of the repository and then manually copying the driver config files over and making all the edits to the main files again (such as adding the new driver hwdef / cfg files)?
Anduril has a tempcheck, (battcheck~~2clicks(sunset)~~>2clicks(beacon)->2clicks(tempcheck))
Im starting to wonder though, whats the thermal path to your driver look like? Im having some temp regulation issues on a H17Fx S2+ build I made and i traced it back to what appears to be bad thermal conductivity to the driver board itself. I covered the driver in thermal potting compound and all of my regulation issues went away. Went from a 25C+ difference between head temp and driver temp to about 7C.
Im looking at updating my own tweaked repo, and after looking at the edits in the changelog, it doesnt look that way. Considering how the hwdef and cfg files interact now, and the event handler changes it looks to be a manual transition.
May not be the best one, but I have my own repo plus a flashlight-firmware-ref repo. External changes go to the -ref repo and I use Beyond Compare to get the changes.
Thanks for the tip on the temp check, I totally missed that when looking up the UI. Once the cells recharge I will test it again when hot and see what it is reading the temp as.
The thermal path to the MCU is not great but it is basically the same as any other driver. I put the MCU fairly close tot he edge of the light and then put a ground pour under the MCU to help it detect the heat. On narsil it is usually pretty close to the actual temps.
I am not real worried about the exact temp is regulates to myself, as long as I can keep it below a reasonable temp (say 60c).
In this case the temperature offset should not be the problem as over time that offset should balance out as the light heat soaks.
Also when the light was 102c, I am positive that the MCU was well over the 45c temp it was set to regulate but it was still ramping it up and down. Like it was ignoring the temp sensor completely or something.
No, as this is not possible for a production light.
Like I said I am not worried about a temperature offset or the normal temp readings variation between MCU’s. I build that into the firmware by setting a lower max temp then I normally would so keep it from getting dangerously hot.
I just can’t let it enter a thermal runaway state like it is now. 100c+ tmep is no bueno.
I just tested the thermal regulation again, this time it was even worse, dropping down to a minium of ~7k lumens.
I also ran the temp check once the light was hot and it correctly read it was ~73c when the actual temp was ~67c (about the same offset it had when room temp).
So it is reading the temperature correctly, it just for some reason is turning the power back up even when well over the set temperature of 45c.