Anduril ... 2?

The code fix is very simple. I have described here:

Now I want to find the settings of the default values so that auto-lock, floor and ceiling levels are set and enabled after the reset.
Another thing to do is set the blink to any level. I want to check the optimal light level for each flashlight, the one in which there will be a constant light without the temperature regulation. A wink would indicate this level.

Turbo access in simple UI would be awesome, and I would stick with that on 9/10 of my lights.


autolock time: lockout-mode.h (just change the 0 to the desired autolock time in minutes)

floor/ceiling levels: these are stored in model specific cfg files. For example, KR4 defaults are in cfg-noctigon-kr4.h.

A friend of mine helped code in a smoother sunset mode to anduril 2.

His changes work for the LT1 but I’m not sure how the set_gradually feature might affect it (It probably shouldn’t)

Here’s a link Sunset mode smoothening - Google Drive

Instead of dimming by several steps once a minute, these changes cause sunset mode to dim by about 1 step at a time, once every x_seconds.

does the dimming work the same when you start out in a relatively low output level?

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
  • From NarsilM:
      /* S42 FET+1 driver for TA:
       *                  ---
       *    Reset PB5 1 -|   |- 8  VCC
       *   switch PB3 2 -|   |- 7  PB2 Ind.LED
       * 7135 PWM PB4 3 -|   |- 6  PB1 Not Used
       *      GND     4 -|   |- 5  PB0 FET PWM
       *                  ---

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 just made a local change, different than Sammy's shown here:

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.

Ok, just lemme know and if everything’s good I can merge it into my branch.

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.

Unfortunately this method only gives you the resolution of the number of steps you have in your ramp.

The reason the LT1 has choppy dimming is because it uses tint-ramping which is incompatible with set_level_gradually .

I stepped up my ramp to 250 steps but the dims are still noticeable.

Thanks for the response Sunnysunsun. :+1:

Here's a link to the files for the Mateminco style drivers, or any driver using a PWM output channel on pin #3:

google drive share - Mateminco Updates

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. :wink:

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?

Good work!

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.