Anduril ... 2?

1038 posts / 0 new
Last post
Lux-Perpetua
Lux-Perpetua's picture
Offline
Last seen: 1 month 1 week ago
Joined: 03/01/2018 - 04:39
Posts: 3196

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: 1 day 15 hours ago
Joined: 06/26/2014 - 02:14
Posts: 2218
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: 1 month 2 weeks 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
ArtieT59's picture
Offline
Last seen: 1 hour 51 min ago
Joined: 02/25/2020 - 17:55
Posts: 3164
Location: CT, USA

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

[FLF] Five Light Friday https://budgetlightforum.com/node/78749

Check out some of my new lights (picture heavy) and quick first impressions of them here: https://budgetlightforum.com/node/77180

My Sft40 beamshots / comparison thread: https://budgetlightforum.com/node/78100

trakcon
trakcon's picture
Offline
Last seen: 4 hours 8 min ago
Joined: 01/23/2019 - 15:50
Posts: 452

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
Offline
Last seen: 14 hours 53 min ago
Joined: 08/09/2019 - 12:51
Posts: 763
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 week 1 day ago
Joined: 01/22/2017 - 13:41
Posts: 1649
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: 35 min 54 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
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: 3 hours 7 min ago
Joined: 03/19/2016 - 11:57
Posts: 3173
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: 35 min 54 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
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: 3 hours 7 min ago
Joined: 03/19/2016 - 11:57
Posts: 3173
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 14 min ago
Joined: 06/25/2019 - 14:35
Posts: 1036
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
Offline
Last seen: 14 hours 53 min ago
Joined: 08/09/2019 - 12:51
Posts: 763
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 week 1 day ago
Joined: 01/22/2017 - 13:41
Posts: 1649
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: 35 min 54 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
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 14 min ago
Joined: 06/25/2019 - 14:35
Posts: 1036
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
Offline
Last seen: 14 hours 53 min ago
Joined: 08/09/2019 - 12:51
Posts: 763
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 14 min ago
Joined: 06/25/2019 - 14:35
Posts: 1036
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: 1 day 15 hours ago
Joined: 06/26/2014 - 02:14
Posts: 2218
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: 35 min 54 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
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: 4 hours 3 min ago
Joined: 05/09/2011 - 10:25
Posts: 6775
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: 35 min 54 sec ago
Joined: 08/19/2012 - 08:23
Posts: 14978
Location: LI NY

Sorry - replied.

SammysHP
SammysHP's picture
Offline
Last seen: 1 hour 14 min ago
Joined: 06/25/2019 - 14:35
Posts: 1036
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
Offline
Last seen: 14 hours 53 min ago
Joined: 08/09/2019 - 12:51
Posts: 763
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 14 min ago
Joined: 06/25/2019 - 14:35
Posts: 1036
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
Offline
Last seen: 14 hours 53 min ago
Joined: 08/09/2019 - 12:51
Posts: 763
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 14 min ago
Joined: 06/25/2019 - 14:35
Posts: 1036
Location: Germany

Can you ask him to post the code?

Sunnysunsun
Sunnysunsun's picture
Offline
Last seen: 14 hours 53 min ago
Joined: 08/09/2019 - 12:51
Posts: 763
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: 2 hours 47 min ago
Joined: 01/02/2019 - 19:14
Posts: 98
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. 

Sunnysunsun
Sunnysunsun's picture
Offline
Last seen: 14 hours 53 min ago
Joined: 08/09/2019 - 12:51
Posts: 763
Location: Toronto

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

Pages