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.”
Hey, I'm sorry I wasn't following this thread. Oh well, now I'm here.
Frankly, I don't really fully understand what I have done either with the 16 bit PWM hack. I tried to make it use less calculation time, but when you need to set the PWM level for literally every single PWM pulse, that's still a lot of time. I had to decrease BOGOMIPS to compensate for that chunk of CPU time missing. I'm not yet sure why candle and lightning modes are faster than they should be, but maybe it has something to do with them. Needs some investigating but I'm really slow with code so it's tedious.
As for the sunset timer, wouldn't it be better to rewrite it so it doesn't use minutes anywhere in the calculations but to just switch over to seconds altogether? That way we could just decrement a counter second by second, allowing an adjustment being done every second. Another issue with the set_level_gradually is, that with the 16 bit PWM hack I did, the PWM level numbers are in the thousands of course, so decreasing them by 1 every timer tick (I think that's how set_level_gradually does it?) won't work all that well at most brightness levels.
For my LT1 I’m tempted to find all the places the ramp levels are referred to as 8bit, swap those to 10 or even 16 bit, speed up the ramping, and add in a 1000 step ramp to really smooth it out. I’m worried that we’re nearing the memory capacity of the attiny85 though
Oh yeah, definitely. I'm surprised you got a 250-step ramp table in there, did you disable anything else? Especially with PWM levels >8 bit every ramp level requires two bytes of flash...
Calculations are done with two bytes in the integer domain. 255 minutes are 15300 seconds. Ramp table has a length of 150 entries. 15300*150=2295000. 32 bit calculations need a lot of additional memory. And because we have no floating point operations we can’t calculate the ratio beforehand.
I just meant that instead of counting down minutes (like the original code does) one should count down seconds, to be able to use every step available in the ramp table in the first place. Getting values in between ramp table steps is a different beast again of course...
Is it feasible at all to maybe include a transfer function in the code instead of a large (250ish steps) ramp table and calculate the needed PWM levels on the fly?
That’s what I meant as well. Using a single calculation with seconds overflows 16 bit and can’t be calculated easily. But one could manage just a single 16 bit counter for seconds and split it into minutes and seconds if required.
Doesn’t make sense when other firmware don’t behave like that though. Take the Sofirn SP36 with NarsilM for example, it steps down at it’s set temp and the BLF Anduril version doesn’t. Then there’s the Astrolux MF02S V2 with SBT90.2 where my thermal gun reads the same temp, more or less, as it shows in the manual. That light gets hot quick with a 30 sec step down
You did well coding NarsilM, if it had stepped ramping instead of mode sets, it would have been perfect.
Hhmm, yeah - actually I started converting NarsilM to stepped ramping but punted on it because I started my own improvements to Anduril. Actually one of the really big reasons why I stopped NarsilM mods was to see TK adopt some of my prefs:
voltage calib in the UI -- this really really bugged me having to do it at compile time
a quicker acting OFF -- NarsilM had a quick off but suffered from the dbl click flicker with the first click
having temp display immediately follow voltage reading