Anduril ... 2?

Flashlight Modding and DIY Parts
686

All -

I have a problem, it’s a ME problem. I have become very used to Anduril, and all of the functions I use on a normal basis(ramping, stepped mode, battery check, thermal setup, and maybe a couple of others).

I am a little afraid of learning Anduril 2.

And it is inevitable because I have two new Hank lights and I think they have Anduril 2, but never the less I will order more lights with it. I know my all copper kr1 doesn’t respond to some commands the same as my other Anduril lights.

I have tried to follow this thread but it is obviously lengthy and I don’t know where to start…

Can some one suggest a diagram that has been made that shows Anduril 2 in somewhat of a simple or straight forward way. I just feel like with the two options for basic and advanced, and I don’t even know what changes have been made, I am going to get lost in Anduril 2. Anduril “1” took me a whole 3 days to figure out enough to be happy when I was green to this stuff last February, is Anduril 2 as “straightforward”? I am just worried because now I am forced to learn it and everything new is, well… new. And sometimes intimidating for boneheads like me.

Thanks everyone, in advance.

687

Artiet59, did you already notice my chart here?

https://budgetlightforum.com/t/-/62656/591

I could not manage to make it "straightforward", though. :-))

688

To me, it’s pretty similar in it’s day-to-day usage as V1. A few notable differences:

  • Simple UI is enabled by default. If you want to get into config menus, access Turbo, or use blinky modes, you’ll need to switch to the Advanced UI.
  • While the main sequences (on, off, ramp up, ramp down, lockout, etc) are all the same, accessing Turbo is different by default unless configured differently at compile time. Momentary Turbo is a 2H from Off. “Normal” Turbo mode is access by getting to the top of the ramp and doing a 2C. But like I said, when compiling the code, you can enable “2C Turbo” in which case it’ll act pretty similar to Anduril V1… so this may vary by manufacturer according to their requests.
  • Blinky/utility modes have been reorganized: sunset mode has moved, Temp Check now follows Batt Check
  • Button press sequences for config options have changed
689

You can also access momentary turbo directly from on with 3H, provided the light doesn’t have tint ramping or two channels (like the K9.3), as that also uses 3H.

690

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?

GChart- thank you as always, I appreciate the highlights and that will be a good starting point for 90% of my use. Only thing that kinda is a bummer is accessing turbo… outside it is often nice to go from “midramp” or so to turbo and back easily. Not a huge problem, just not ideal I guess. Especially since I have no knowledge whatsoever on how to compile files and honestly I don’t know what that means…

Thanks Rayoui!

691

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.

692

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.

693

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

694

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.

695

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

696

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.

697

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.

698

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

699

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
       *                  ---
       */
700

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.

701

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.

702

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

703

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.

704

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.

705

Thanks for the response Sunnysunsun. :+1: