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.
Yes, both from off and on, double click brings you to turbo
As for the instant action, there is a bugtracking item open for it: Bug #1803001 âanduril: immediate on/off optionsâ : Bugs : Flashlight Firmware Repository
If you have a bit of patience, I think I can do that.
Sadly, no timeline. But TK is probably your best bet.
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âs not a PID. Itâs more like: guess what the temperature will be in a few seconds and react based on that.
Allthough there are some knobs to tweak:
I agree, I was also very surprised.
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 canât explain why it acts this way at all.
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.
A much simpler question: did you calibrate the temperature sensor for your particular light? You have to do that after each flashing procedure.
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.
That should be no problem for a production light.
In anduril, the calibration is done by letting the whole light reach room temperature and then telling the light what temerature is currently is on
Thanks for the rundown.
While that is simple for the end user, it would be nearly impossible to convince a manufacture to try to do that on the production line, particularly when I could not give a convincing argument as to why it should be done and it would have a noticable increase to the cost of the light (time is money on an assembly line).
98% of people will not notice the difference between the MCU temperature offset variations. Those that do are generally going to be capable of calibrating the light themselves.
My goal for the from the factory settings are to keep the light under ~60-65c. As long as it stays under that, I am not particularly worried about if it is 45c or 60c. It is more a safety feature then a practical one IMHO.
Then if people want to calibrate it to a custom setting after they get the light, the options are there to do that.
Although if I had to guess, less then 1-2% of the Narsil lights that have been sold so far have had the thermal settings calibrated since most simply do not care as long as it does not get hot enough to hurt someone.
All of that aside, I can try calibrating the light although I see no reason why it would effect what is happening here since the temp readings are pretty close already.
In this case I know that the temperature was well over the set limit but yet it still turns the power up. I cant figure out why they would happen.
Maybe there should be a limit added that will not allow increasing the power when the temperature is ~20% over the desired setting to prevent this endless thermal runaway?
I doubt it was ignoring it, I think theres something in the code that might be causing this weird oscillation.
Id try a few things:
If there is another prebuilt Anduril target with the same driver layout as yours I would flash that and just compare output and regulation with the pre-set ramp and stock code.
If it still behaves janky, id play around with the thermal control algorithm parameters Zeroflow quoted above. Most likely the attenuation value for a more aggressive stepdown.
Possibly test with this code borrowed from the D4S
Good idea, I will see if I have time later to do that, might be tomorrow. I think that the D4 driver uses the same basic pinout except for the auxLEDâs
I have the #define THERM_FASTER_LEVEL (RAMP_SIZE*9/10) in the code for sure, not sure about the hard drop part.
The part that is really confusing me is the fact it will raise the power when it is double the temp target that is set. That should not happen under any circumstances I am aware of.
If I wanted to buy a 17mm driver to run anduril what are my options? Can I do it on a mtn17ddm with tiny85 and maybe use the blf gt mini config?
That should work fine Hoop. Not sure about the lighted switch though.
[quote=nick779]
I doubt it was ignoring it, I think theres something in the code that might be causing this weird oscillation.
Id try a few things:
If there is another prebuilt Anduril target with the same driver layout as yours I would flash that and just compare output and regulation with the pre-set ramp and stock code.
If it still behaves janky, id play around with the thermal control algorithm parameters Zeroflow quoted above. Most likely the attenuation value for a more aggressive stepdown.
Possibly test with this code borrowed from the D4S
Ok, I flashed the stock D4S firmware from here: Index of /torches/fsm
It did basically the same thing, although it seemed to mostly float between ~3k and 8k lumens instead of 1k and 8k. Also it dipped down to ~150 lumens a few times which I think is under the minimum level but canât say for sure.
It is really very strange, I wounder if the larger host could be the issue? With the extra mass vs the D4S it takes longer for the changes the MCU makes to be seen in the temperature.
Maybe it sees the temperature start to drop and then starts to raise the power and by the time it sees the temperature going up again it is too late?
Although this only explains the first increase in power, after that the temperature is always above the setpoint, I would not think it should raise the output under those conditions.
I am thinking that outside of tweaking the thermal control scheme a very important failsafe to add would be a hard limit of say ~20% over the set temperature it will not increase the power over the minimum output level, no matter what.
Right now it can work its way up to well over 100C which is instant sever burn territory. There needs to be something in place to prevent that first and foremost IMHO.
Anyone know what file those thermal settings were in?
Does anyone have an idea what they do outside of the comments?
This settings seems to be some kind of temp limit from the above post, but it does not seem to be working: