Anduril ... 2?

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:

  1. 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
  2. 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?

Sorry - replied.

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.

Can you ask him to post the code?

Here it is. https://www.dropbox.com/s/psqekvhr41t01ax/LT1%2016%20bit%20v0.2.zip?dl=0

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

I'm sure there's more, can't think of them all.

Not sure if this will stir up things but I wonder if TK or anyone else were open for some food for thought in terms of changes on Andúril 2:

  • Advanced UI: Revert turbo mode activation to the classic Andúril 1 style (2C from ON = Turbo, level 150) as the new style (2C+2C from ON) seems to bug many people.
  • Simple UI: No offense but I wonder if anyone here has really used Simple UI as it is yet. How about exchanging Simple UI by a "stripped-down" UI that follows both the essential functionalities of Andúril Advanced UI but also includes some of the best parts that we know and like from proprietary "classic" UIs such as Wurkkos FC11 or Sofirn SP33 V3? With the new AVR-1 chips like 1616-MNR there would be enough memory for two individual UIs that are both based upon the FSM code. BTW: Thermal calibration could become obsolete as these next gen chips have factory calibration. @TK: gchart has made some cool tests with this chip already (see our PM discussion about the "BLF SP10S project").

Example:

I see some benefits here: Users who like a very basic and straightforward UI can remain in this new Simple UI, e.g. ramping mode for default. Classic stepped modes could be accessed by 10C. Most commands could follow the usual Andúril style. Maybe 7C for cycling AUX/switch button illumination can be incorporated here as well. According to some feedback I have gathered in the past months it seems that many people like the basic UI that Wurkkos FC11 or Sofirn SP33 V3 offer. With some hidden command it could be possible to change the UI and switch from this Simple UI to the actual Andúril 2 UI (with Advanced UI only). Since both UIs are based upon the same code, updating or bug fixing should cause a few more efforts only. Manufacturers on the other hand could reach much more customers by offering their flashlights to both less experienced and well experienced people.

  • I do not know if this was feasible but with more and more flashlights using constant current regulation (see Fireflies E12R/T9R/T1R/NOV-Mu, Astrolux MF02S V2, Noctigon K9.3, ...) it would be nice to set ramped modes not according to a brightness level (n of 150) but according to certain currents, e.g. 0.01A (moonlight), 0.5A (low), 1.5A (mid), 6A (high) and no limit for full direct drive (FET). I saw that Neven's (Led4Power) new driver generation will support this cool feature.