Gabe: I updated my Anduril 2 installation to your version, link above. Problem is it seemed to be missing the Mateminco/Astrolux FET+1 support that has SammysHP fix for the 7135 on pin #3. Just downloaded Anduril 2 to a Mateminco MT01 (same as EA01) and the 7135 channel doesn't work.
I don't know, can't recall exactly what I did, but apparently I had SammyHP's version of fsm-main.c, or had my own custom version, and lost it. Strange because I usually make a backup, but might have deleted it thinking all was working well with the first couple lights I used it on.
History on this issue:
Mateminco apparently likes doing things their own way and is using an oddball pin assignment for FET+1 drivers. So instead of having the AUX LED on pin #3, they put the 7135 on pin #3 and the AUX LED on pin #7 (FET on pin #5), leaving pin #6 unused.
The lights I know of using this pinout config is S42, FT03 (think so anyway), FT02S, Mateminco MT01/Astrolux EA01. There's probably more, not sure.
NarsilM supported this configuration way back because of my working with TA on the drivers for the Astrolux S42 (S42_PINS). I think TA was objecting to this too, but Mateminco already committed to the layout.
standard Anduril, and I guess Anduril2, never supported this. The driver and pin assignment support was hard coded for certain usage
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.
