Hey Tom, the thing isā¦ My branch is a copy of TKās, just with 1-Series support. I could probably merge SammyHPās fix in there too though next time Iām in front of the computer. You (or someone) might need to verify it though. I have to see if I have any lights with their layout.
I'm not sure I understand what Sammy is exactly doing with those changes - it seems to be doing the register init. needed for pin #3 PWMing unconditionally. I prefer checking each PWM pin assignment and if any are assigned to PB4 (pin #3), then do the additional register assignments. I'll test it out soon.
The issue is that the third channel is using a different port with different setup. But itās still a two-channel driver, so there was no way to set up the output with the existing code. I simply swapped the channel setup so that the second channel sets up the output of the third channel. I didnāt invest any time to make it work with all layouts and it will work only for the different layout found in Mateminco drivers.
It supports 1 channel, 2 channel, or 3 channel driver configurations. I only tested with a 2 channel configuration and it worked. The cfg and hwdef files I used are included in that folder as well.
That implementation changes the meaning of āsunset_timerā and breaks the special code for the ābump the timer if itās almost expiredā feature. But he did a great job keeping it in the integer domain without overflow.
So I wrote my own code with a similar approach to increase the resolution. Would be so much easier with floating point calculation, but I think my implementation of using a second step to calculate in-between levels works mostly fine (havenāt checked all cases of rounding) and is 36 bytes smaller.
Hmm I didnāt use the ābump the timerā so I never noticed it not functioning.
When you say ā second step to calculate in-between levels ā is my understanding correct that does this result in levels in between those defined by the 150 steps in the ramp table in the config file? Aka it can step down to a brightness between 120 and 119 for example, a 119.5 that is not defined in the steps table?
If so, an between step is an improvement but still not quite the perfect replacement for the smoothness of āset_level_graduallyā. Iām running streamtronicās 16bit pwm build and even when I increased the ramp to 250 steps, the dims between steps is unfortunately still noticeable.
To make the dimming truly smooth, it might be necessary to create 4 or more fractions of a step between each current step. The more āin between stepsā the better. Do you reckon this can be done?
It can only select levels that are available in the ramp table, so one of the 150 levels. The original sunset timer updated the output only once a minute which skipped some of these levels. In my implementation the output is updated every second. Itās not very smooth, but much better than the big jumps once a minute.
Every second is enough because the shortest timer is five minutes. Starting from 150/150 the output decreases 30 levels each minute or one level every two seconds.
Can someone tell me why the thermal stepdown behavior on Anduril 1 drops output way before the set limit? This happens on every single Anduril light I have which includes the latest revisions.
Sofirn SP36 Pro (calibrated) for example
Room Temp - 25Ā°C
Limit - 70Ā°C
Step Down - 55Ā°C
Is Anduril 2 any different because Iāve about had enough as a reseller. Iād rather a hard step down like NarsilM exactly at the limit, then you actually get a decent run. The gradual step down is of course better, but only if it triggers nearer the limit
I thought TK explained that in great detail. There's 2 causes I know of:
when the light is cool (room temp), the inside at the driver heats up quicker than what (I guess?) you are measuring on the outside
all these lights are doing way too many amps/heat for their size, so the only way the firmware could possibly work to thermally control it is by anticipating the temp, so when the increase rate is crank'n, Anduril throttles it back before the set temp is reached.
Tom E, not sure if you're not receiving notifications, but I sent you multiple messages in the past 3 weeks about my calibration light, can you please reply?
Iāve also implemented a fix for the misbehaving ramping in sunset mode. Previously it just started to ramp down pretty fast if you tried to ramp up or down while the sunset timer was active. This is fixed now (with the slight downside that the timer is reset to the full minute when you ramp).
Neat, reset to the full minute, not the original time right?
Back to that other topic, ultimately to make the LT1ās sunset appear smooth, weāll need to figure out how to get set_level_gradually to work with tint ramping or to find some kind of replacement that allows the firmware to dim to levels between the steps like set_level_gradually does
Correct, it resets to the next full minute (up, longer duration). Ideally it would not change the timer at all, but the way I implemented the two-step adjustment of the level it would add too much code to handle the second step. So I just set the seconds to zero and start with the last minute again.
Iāve never used set level gradually before and donāt know why it doesnāt work with tint mixing without diving into the code. I assume it is related with the non-linearity of the steps that are involved in the tint ramping. Or in other words: The tint would change while the brightness is adjusted.
But: In high levels you donāt really notice the steps at all. It is very visible in low steps and there the resolution is already at its limit. So gradual steps wouldnāt make any difference. We need higher resolution PWM.
A good solution. An extra minute doesnāt make a difference imo so itās solved as far as Iām concerned.
I am running the brilliantly made higher resolution pwm software written by Streamtronics. Shoot him a message if you want to try it out. I donāt quite fully understand how it works, but it does work great and you get tint ramping even at the lowest levels. The only downside is that the timing of some modes like candlelight and lightning mode is a bit off, rending them unusable.
Streamtronics says ā itās a work in progress and definitely not a plug-and-play solution, and that itād probably make much more sense to use a ĀµC with higher resolution hardware PWM instead of this hacky solution.ā