Anduril ... 2?

[Bart07]

From ON, 2C gives max (no turbo), then 1H decreases.

[Garik_F]

Can someone explain me what key USE_VOLTAGE_LOWPASS actually do?

[Garik_F]

What happens if I set memory timer larger than autolock timer? I think autolock should reset level to memorised, but what happens when memory timer time is up? Level will be reseted once again?

[Getkong]

@Scallywag

@d_t_a

@mgflax

@Tom E

Sorry, you are not going to change my mind about it. It’s a user setting, user’s responsibility. It’s not a factory light, it’s my mod. I’ve cranked up the max limit in order to get through 30 seconds and had no problems being able to touch handle of the light to turn it off.

Publishing your source-code and config-file modifications seems reasonable to me. But I do wonder whether it is a good idea to publish the .hex file as well. It is hard to imagine that someone would have the skills to use the mods safely but wouldn’t also have the ability to build their own .hex file — especially now that Windows has a Linux Subsystem mode.

Re: publishing hex files… I have been able to flash .hex files on several lights (Emisar/Noctigon lights with the flashing pins ; or the BLF/Sofirn Q8 that just need to unscrew the board) that don’t require soldering or need to pull out the driver board (sample is SP36 or FW3A or early D4v1), but I currently haven’t tried to learn how to build my own .hex files… Thus I appreciate it if there are pre-built hex files, that have a clear description what changes are incorporated in the hex files. (I think Tom E’s hex file description is clear enough, including the thermal limit change, which affects the default behavior — so I think that’s great for people who can flash, but are unable to not yet willing to invest time to learn how to build their own hex files)… Anyway, just my opinion. (I haven’t tried using Tom E’s hex files yet, but I might in the future… I don’t have an HK90, but I think there is a Tom E version of the BLF Q8/Sofirn Q8 hex file…)

I agree. There’s some significant obstacles involved in getting your own customized hex file.

• You need to be able to grasp the code at least enough to make your minor modifications

• You need to either be able to deal with linux or Atmel Studio well enough to get the hex file built

This is why we frequently see requests for features that should really be customizations. I also know Lexel frequently got requests for tweaks to Anduril on the drivers he sold - some that he could do, others that he could not. Installing a new driver can be easier than flashing a new one if there’s no flashing pads. For other drivers, flashing them is quite simple because of available flashing pads.

All this said, I think it’s great if/when someone is motivated enough to learn how to do everything required to modify Anduril and flash their own driver. But it’s definitely getting into a very small group of people that are willing/able to jump through the extra hoops to do that themselves rather than use someone else’s hex file.

I was pretty intimidated early on by this, too. When I created my fork and put it on github (GitHub - mkong1/anduril), i wrote a couple quick bash scripts to simplify the build, and flashing. I only have Emisar/Noctigon lights, so the `flash_light.sh` only has a couple preconfigured Emisar/Noctigon lights, and currently hard-codes `-p t1634`, but the goal was to make it a bit more approachable to anyone on a Mac.

Would love any feedback that could improve upon it!

I’ll also say i have never used Bazaar for anything else, and i have a basic config option that i think would be useful to allow compile-time option to unlock to off state, but i spent 5 minutes try to suggest a merge, and definitely did it wrong twice. ~mkong1/flashlight-firmware/anduril2 : revision 580

[Tom_E]

@gchart

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: anduril2 : Code : Flashlight Firmware Repository

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!

[ArtieT59]

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.

[Lux-Perpetua]

Artiet59, did you already notice my chart here?

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

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

[gchart]

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

[Rayoui]

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.

[ArtieT59]

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!

[Bob_McBob]

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]

@Artiet59

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.

[PiercingTheDarkness]

@ToyKeeper

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

[Bart07]

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]

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

[trakcon]

@Bart07

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

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

[sbslider]

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

[Tom_E]

@Tom E

@gchart

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]

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.