Anduril ... 2?

828 posts / 0 new
Last post
Bob_McBob
Offline
Last seen: 1 day 11 hours ago
Joined: 08/14/2016 - 04:53
Posts: 591
Location: Canada

I finally flashed one of my FW3As to Anduril 2, and I’m really liking it, other than the fact I can’t access turbo in simple mode. It seems like this should be a flag in the ramp config rather than permanently locked out, especially since you can still set the ramp ceiling to full turbo. Simple mode is almost exactly what I’ve always wanted Anduril to be from the beginning: a fully functional light with all the extras and config menus hidden in a way you will never access by accident. I just really wish I could set the ramp behaviour to be exactly the same as advanced mode. Has anyone tried a build like this? Reviewing the code, it seems relatively simple, but adding the extra flag to the menu would be more work.

Lux-Perpetua
Lux-Perpetua's picture
Offline
Last seen: 1 hour 27 min ago
Joined: 03/01/2018 - 04:39
Posts: 2898
Location: at the end of the light beam

Artiet59 wrote:
Lux-Perpetua - thank you, that is perfect! I will study it. I didn't see in the advanced UI the commands for basic on/off ramping, etc. Is that explained up too in the "simple ui" section, in light gray?(...)

Yes, the UI section in the top part displays both SIMPLE UI and ADVANCED UI. The light gray lines represent the access to turbo that is restricted to ADVANCED UI only. I am still working on a nicer chart in a scalable vector graphics file format (SVG). This one will probably divide SIMPLE UI and ADVANCED UI, hence hopefully it will be easier to read and understand (fingers crossed). I also try to emphasize how to handle configuration menus as it differs from Andúril 1.0, e.g. thermal configuration.

Funtastic
Funtastic's picture
Offline
Last seen: 21 min 38 sec ago
Joined: 06/26/2014 - 02:14
Posts: 1562
Location: New Zealand
ToyKeeper wrote:

Just wondering why there’s no setting to enable turbo in the Simple UI?

It makes zero sense to be able to change the max ramp to turbo and leave out a setting to just enable the regular turbo. Having to do this then eliminates lending the light to a muggle without having to reconfigure the max ramp.

There’s a heap of people that want to be able to use a flashlight in Simple mode and not lose max output, myself included.

Please consider allowing one to just enable the regular turbo

Texas Ace Lumen Tube calibrated with maukka lights

New Zealand store – https://www.piercingthedarkness.co.nz (NZ customers only)

YouTube channel – https://www.youtube.com/channel/UCIUWi2vYp4CWrRkOJM70t_w/videos (Demos for my customers, and reviews)

Bart07
Offline
Last seen: 3 days 10 hours ago
Joined: 01/04/2021 - 10:38
Posts: 16
Location: Polska

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.

Artiet59
Offline
Last seen: 3 hours 6 min ago
Joined: 02/25/2020 - 17:55
Posts: 1476
Location: CT, USA

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

trakcon
trakcon's picture
Offline
Last seen: 1 hour 51 min ago
Joined: 01/23/2019 - 15:50
Posts: 401

Bart07 wrote:
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.

Defaults:

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.

Sunnysunsun
Sunnysunsun's picture
Online
Last seen: 1 min 4 sec ago
Joined: 08/09/2019 - 12:51
Posts: 574
Location: Toronto
Sunnysunsun wrote:
Anyone else find sunset mode dims their light in steps that feel rather large? Compared to smooth ramping, sunset mode’s brightness decreases with my LT1 feel like rather large stepped jumps downwards

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 https://drive.google.com/drive/folders/1i6GvIwNpr5PXf5Od08nHnh8w3bfPZwnv...

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.

sbslider
sbslider's picture
Offline
Last seen: 1 day 4 hours ago
Joined: 01/22/2017 - 13:41
Posts: 1647
Location: United States

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

PocketSammich wrote: I don’t need this, but I want it. Please sign me up.

Tom E
Tom E's picture
Offline
Last seen: 9 hours 50 min ago
Joined: 08/19/2012 - 08:23
Posts: 14056
Location: LI NY

Tom E wrote:

gchart wrote:
Small heads up for the one or two of you (looking at you, Tom E) that this may impact... I'm relatively new to bzr and I didn't realize that I didn't have my anduril2 repo (with AVR 1-Series support, branched from TK's anduril2 repo) linked back to the main Flashlight Firmware Repository properly. So I updated the branch name/link so that it's now linked back to the main repo. The new url is: https://code.launchpad.net/~gabe/flashlight-firmware/anduril2 

Sorry, haven't checked this thread for a while. K - that's my new master Anduril2. I kind of have to meld in these updates with all my special cfg and hwdef files.

Thanks Gabe!

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
       *                  ---
       */
gchart
gchart's picture
Offline
Last seen: 1 hour 47 min ago
Joined: 03/19/2016 - 11:57
Posts: 2955
Location: Central IL

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.

Tom E
Tom E's picture
Offline
Last seen: 9 hours 50 min ago
Joined: 08/19/2012 - 08:23
Posts: 14056
Location: LI NY

I just made a local change, different than Sammy's shown here: https://github.com/SammysHP/flashlight-firmware/commit/68e36b3dd3d9cb1c49b20cc218c860940cd20550

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.

gchart
gchart's picture
Offline
Last seen: 1 hour 47 min ago
Joined: 03/19/2016 - 11:57
Posts: 2955
Location: Central IL

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

SammysHP
SammysHP's picture
Offline
Last seen: 1 hour 36 min ago
Joined: 06/25/2019 - 14:35
Posts: 784
Location: Germany

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.

Sunnysunsun
Sunnysunsun's picture
Online
Last seen: 1 min 4 sec ago
Joined: 08/09/2019 - 12:51
Posts: 574
Location: Toronto
sbslider wrote:
does the dimming work the same when you start out in a relatively low output level?

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.

sbslider
sbslider's picture
Offline
Last seen: 1 day 4 hours ago
Joined: 01/22/2017 - 13:41
Posts: 1647
Location: United States

Thanks for the response Sunnysunsun. Thumbs Up

PocketSammich wrote: I don’t need this, but I want it. Please sign me up.

Tom E
Tom E's picture
Offline
Last seen: 9 hours 50 min ago
Joined: 08/19/2012 - 08:23
Posts: 14056
Location: LI NY

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.

SammysHP
SammysHP's picture
Offline
Last seen: 1 hour 36 min ago
Joined: 06/25/2019 - 14:35
Posts: 784
Location: Germany
Sunnysunsun wrote:
Sunnysunsun wrote:
Anyone else find sunset mode dims their light in steps that feel rather large? Compared to smooth ramping, sunset mode’s brightness decreases with my LT1 feel like rather large stepped jumps downwards

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 https://drive.google.com/drive/folders/1i6GvIwNpr5PXf5Od08nHnh8w3bfPZwnv...

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.


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

https://github.com/SammysHP/flashlight-firmware/commit/499489bfbc0d0e750...

Sunnysunsun
Sunnysunsun's picture
Online
Last seen: 1 min 4 sec ago
Joined: 08/09/2019 - 12:51
Posts: 574
Location: Toronto

SammysHP wrote:

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

https://github.com/SammysHP/flashlight-firmware/commit/499489bfbc0d0e750...

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!

SammysHP
SammysHP's picture
Offline
Last seen: 1 hour 36 min ago
Joined: 06/25/2019 - 14:35
Posts: 784
Location: Germany

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.

Funtastic
Funtastic's picture
Offline
Last seen: 21 min 38 sec ago
Joined: 06/26/2014 - 02:14
Posts: 1562
Location: New Zealand

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

Texas Ace Lumen Tube calibrated with maukka lights

New Zealand store – https://www.piercingthedarkness.co.nz (NZ customers only)

YouTube channel – https://www.youtube.com/channel/UCIUWi2vYp4CWrRkOJM70t_w/videos (Demos for my customers, and reviews)

Tom E
Tom E's picture
Offline
Last seen: 9 hours 50 min ago
Joined: 08/19/2012 - 08:23
Posts: 14056
Location: LI NY

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.

 

ChibiM
ChibiM's picture
Offline
Last seen: 10 hours 31 min ago
Joined: 05/09/2011 - 10:25
Posts: 6602
Location: Holland

Tom E wrote:

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?

Tom E
Tom E's picture
Offline
Last seen: 9 hours 50 min ago
Joined: 08/19/2012 - 08:23
Posts: 14056
Location: LI NY

Sorry - replied.

SammysHP
SammysHP's picture
Offline
Last seen: 1 hour 36 min ago
Joined: 06/25/2019 - 14:35
Posts: 784
Location: Germany

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).

https://github.com/SammysHP/flashlight-firmware/tree/smooth-sunset-v2

Sunnysunsun
Sunnysunsun's picture
Online
Last seen: 1 min 4 sec ago
Joined: 08/09/2019 - 12:51
Posts: 574
Location: Toronto

SammysHP wrote:
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).

https://github.com/SammysHP/flashlight-firmware/tree/smooth-sunset-v2

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

SammysHP
SammysHP's picture
Offline
Last seen: 1 hour 36 min ago
Joined: 06/25/2019 - 14:35
Posts: 784
Location: Germany

Sunnysunsun wrote:
Neat, reset to the full minute, not the original time right?

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.

Sunnysunsun
Sunnysunsun's picture
Online
Last seen: 1 min 4 sec ago
Joined: 08/09/2019 - 12:51
Posts: 574
Location: Toronto

SammysHP wrote:
Sunnysunsun wrote:
Neat, reset to the full minute, not the original time right?

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.

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.

https://budgetlightforum.com/comment/1713668#comment-1713668

SammysHP
SammysHP's picture
Offline
Last seen: 1 hour 36 min ago
Joined: 06/25/2019 - 14:35
Posts: 784
Location: Germany

Can you ask him to post the code?

Sunnysunsun
Sunnysunsun's picture
Online
Last seen: 1 min 4 sec ago
Joined: 08/09/2019 - 12:51
Posts: 574
Location: Toronto

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.”

Streamtronics
Streamtronics's picture
Offline
Last seen: 23 hours 13 min ago
Joined: 01/02/2019 - 19:14
Posts: 83
Location: Germany

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. 

Pages