Anduril ... 2?

Hi

I changed the standard Anduril branch and added default values for .hex files, that I can use for my lights. In this case for my KR4 Dual Channel with Osram W1 and 519a.

I am not sure if there is a manual for configuring Anduril2 with personalised default values, then this post would be a bit obsolete.

I thought I list below how I adjusted the config files, which might be helpful for someone else as well.

I would appreciate it to get notified if someone spots something that actually shouldnā€™t be done or if there is a better way to do it.
I will then change / delete it from the list below with an edit.

** Files in folder /multi-channel/ToyKeeper/spaghetti-monster/anduril/ **

  • Change default Aux Led setting for normal off mode
    File: hank-cfg.h
I changed line 26 from
#define RGB_LED_OFF_DEFAULT 0x18 // (low, rainbow)
to
#define RGB_LED_OFF_DEFAULT 0x02 // (off, green)

The numbers after the "0x" can be adjusted.
The first number can be 0=off, 1=low, 2=high, 3=blink
The second number defined the colour / Blinky:
0: R
1: RG
2:  G
3:  GB
4:   B
5: R B
6: RGB
7: disco
8: rainbow
9: voltage
  • Change default Channel Mode
    File: cfg-emisar-2ch.h
I changed Line 25 from
#define DEFAULT_CHANNEL_MODE           CM_BLEND
To
#define DEFAULT_CHANNEL_MODE           CM_CH1 

Now the lamp starts up with Channel 1 first (the Osram W1 in my case)
  • Change default Tactical Light setting
    File: cfg-emisar-2ch.h
I changed line 80 from
#define TACTICAL_LEVELS 120,30,(RAMP_SIZE+3)
to
#define TACTICAL_LEVELS 50,100,150 

This is the light intensity for 1H, 2H and 3H in tactical mode..
The max is 150.
  • Change default max Temperature
    File: config-default.h
I changed Line 23
#define DEFAULT_THERM_CEIL 45
to
#define DEFAULT_THERM_CEIL 55

Maximum Temperatur is 55 degree now.
  • Change default Ramp Style
    File: config-default.h
I changed line 53 from
define RAMP_STYLE 0
to
define RAMP_STYLE 1

0 = smooth, 1 = stepped

I like stepped rampg, please don't blame me.
  • Add a default time to lock the light
    File: lockout-mode.h
I changed line 12 from
#define DEFAULT_AUTOLOCK_TIME 0 
to
#define DEFAULT_AUTOLOCK_TIME 10 

Now the light locks after 10 minutes
  • Change default Ramp Mode
    File: ramp-mode.h
I changed line 62 from
#define RAMP_STYLE 0
to
#define RAMP_STYLE 1

Maybe this wasn't necessary, because I already adjusted the ramp style to stepped in the config-default.h
  • Change default Manual Memory ā€œBrightnessā€
    File: ramp-mode.h
I changed line 147 from
#define DEFAULT_MANUAL_MEMORY 0
to
#define DEFAULT_MANUAL_MEMORY 70

This makes the light start at 70/150.
This is relatively bright, so might not be the right setting for everybody.
But I use Autolock.
And in Lockmode with 1H I get the lowest brightness and with 2H I get this 70/150.  
That's how it works for me.
  • Change default Manual Memory Timer
    File: ramp-mode.h
I change line 151 from
#define DEFAULT_MANUAL_MEMORY_TIMER 0
to
#define DEFAULT_MANUAL_MEMORY_TIMER 10

So after 10 minutes the default brightness value above will be restored.

**File in folder /multi-channel/ToyKeeper/ ***

Change default enabled Channel Modes
File: hwdef-emisar-2ch.h*

I changed line 50 from
#define CHANNEL_MODES_ENABLED 0b00011111
to
#define CHANNEL_MODES_ENABLED 0b00000011

The last 5 digits were all "1's". 
These 5 digit's seem to be enabling the channel when 1 is chosen and disable the channel, when it's 0.
The sequence is from left to right:
- First 1: both channels, auto blend, reversible
- Second 1: both channels, manual blend, max 200% power?
- Third 1: both channels, tied together
- Fourth 1: channel 2 only
- Firfth (last) 1: channel 1 only

So in my default confiig, I have Channel 1 (only the W1's) and Channel 2 (Only the 519a) enabled.
2 Thanks

Nice one!

I have some info in my anduril repo (which is currently halfway through being updated to the multichannel branch, so right now the config reference is a bit out of date, but itā€™ll normally be on the main README) here: GitHub - SiteRelEnby/anduril2: modded anduril2, although right now I need to go through and finish documenting the changes, but in general I will note which config works on the standard unmodified anduril as well.

Hereā€™s a permalink to the config reference for the older, non-multichannel branch, because Iā€™m probably only going to maintain multichannel moving forward: GitHub - SiteRelEnby/anduril2 at main_pre_multichannel

None of those changes will break anything, so good in that way - but one thing to be aware of, in the actual codebase itself and not the light config file, if you change defaults in the header files there, if they are set in the light-specific header than that will always override the default. In general for most stuff itā€™s better to define it in the light-specific file where possible - even the definitions like CHANNEL_MODES_ENABLED, because theyā€™re defined by default in the hwdef, you can override them in the light-specific config, which is applied after the basic hwdef is. Youā€™ll get a warning if you redefine something that was already defined, but this isnā€™t a bad thing, itā€™s just telling you in case it was accidental and unexpected, and you can squelch the warning likethis:

#ifdef SOMETHING //if SOMETHING is already defined
  #undef SOMETHING
#endif
#define SOMETHING whatever

@ToyKeeper interested in your thoughts about channel modes and simple UI - do you think it would make sense to have another bitmask and configuration menu for removing channel modes from the simple UI rotation, but keeping them on for advanced? Interface-wise, you could reuse the existing channel mode menu like this: 0C = disabled, 1C = enabled, 2C = advanced UI only.

The use case here is e.g. disabling aux channels or ones like auto tint in simple UI. Alternatively, just having all aux-based channels unavailable for manual selection in simple UI would be simpler to implement, in my version I already have a method I added to check if a channel uses the aux or not (in my case, added it to prevent aux channels from being interfered with by RGB battery status while on), it adds a method similar to channel_has_args() called channel_uses_aux() (example use case pseudocode: wrapping RGB battery while on with if(!channel_uses_aux(CH_MODE){ <RGB battery status>) - if you were interested in implementing that I canā€¦ make a patch file, I guess, since I donā€™t know bzr well :sweat_smile:. I tend to use RGB battery status a lot (even on lights with forward facing aux - I just hacked it to have a threshold so they turn off for moon and on low for low ramp levels) and right now, if you are in ramp mode and select an aux channel, the two both try to control the aux at once which makes Weird Things happen.

2 Thanks

Thank you! That explains and lists a lot of the possibilities!

And that would have made it much easier :joy:

Basically most of the defintions, I could have just added to the file cfg-noctigon-kr4-2ch.h, and thatā€™s it :slight_smile:

This file is sort of a hint for how people can apply their personal preferences to a bunch of different lights. Make a .h file for your preferences, and #include it in the builds you care about.

Itā€™s not a complete solution, but it at least reduces the amount of duplication required.

Long-term, I want to reorganize things to make personal builds easier to create and maintainā€¦ but itā€™s yet another big refactor and Iā€™m still halfway through a different one. I see some really good ideas in the way QMK manages builds, so Iā€™ll probably try something similar. This also would clean up a lot of other files, allowing each lightā€™s files to stay together in one place, and each vendor to have their own directory.

The downside of this re-org is that itā€™ll be harder to build multiple different UIs for the same hardware (like anduril, darkhorse, baton, etc)ā€¦ but there has been very little interest in that anyway, so that feature hasnā€™t been maintained and doesnā€™t seem to matter much.

For being just a flashlight interface, thereā€™s an awful lot of rewriting and refactoring which needs to be done.

2 Thanks

Anduril 2 flashing on iOS. I lost my notes and Reddit is blacked out. Can someone remind me where the most current guide is?

Or I have:

avrdude -c usbasp -p t1634 -u -Uflash:w:anduril.2023-05-30.emisar-d4v2.hex

but I forgot how to designate the downloads folder to flashā€¦

Like this:

avrdude -c usbasp -p t1634 -u -Uflash:w:/yourfolder1/folder2/FILENAME.hex

1 Thank

Thanks! I was forgetting the backslash after :w:

1 Thank

Hi
Do you run this on ISH?

I tried to connect the flashing device to my iPad with an Apple USB-C to USB-A adapter and used the above command with ISH, but it seemed it didnā€™t recognise the flashing device.
The red light on the flashing device did light up though.

Edit:
I get this error message:

--> avrdude -c usbasp -p t1634 -u -Uflash:w:anduril.noctigon-kr4-2ch.hex
--> [1]    1841 segmentation fault  avrdude -c usbasp -p t1634 -u -Uflash:w:anduril.noctigon-kr4-2ch.hex

Unfortunately I just ham fist my way through this stuff, it is not my background.

What is the response when you:

avrdude -c usbasp -p t1634 -n

Also, shouldnā€™t your line be something like:

avrdude -c usbasp -p t1634 -u -Uflash:w:anduril.202X-XX.XX.XX.noctigon-kr4-2ch.hex

unless you renamed your file.

Hi,
You can scroll to the right where I pasted the code. I think our lines match.

Do you use ISH or what App do you use to type in the code?

I use avrdude on a Mac.

Do you get a response to this?

avrdude -c usbasp -p t1634 -n

Ah ok, no worries then

On my Mac it works as well.
I understood you use it on iOS.

If someone uses it on iOS or iPadOS, I would be interested to know how that works :slightly_smiling_face:

Hi Toykeeper,

Iā€™ve just started to know Anduril 2 in a past 2 months and Iā€™m loving it. It is now hard for me to buy a flashlight without it, just because I like to make my flashlight personal. :stuck_out_tongue:

Some suggestion for Anduril improvement (Iā€™m not sure if it is even easy to implement or not, but I hope I could give an idea).

  1. Keep simple and advance mode separated as is.

  2. Currently in advance mode there are too many clickies to set up/enter a certain mode. Would it be possible to create a sub-level command thingy? for an example:
    To set/change settings, it should always from OFF state.
    OFF state:
    1 x Click = turn ON
    2 x Click = highest brightness or turbo (depends on the settings)
    3 x Click = go to strobe/beacon
    4 x Click = lock
    5 x Click, Hold = enter Settings. Then you will have a certain sub-level / categories ( click and hold will cycle through the option)
    ā€“ 1 x Blink and release: brightness settings.
    ā€“ click and hold:
    1 x Blink and release: floor settings
    2 x Blink and release: ceiling settings, etc.
    ā€“ 2 x Blink and release: setting for light mode type
    1 x Blink and release: stepped mode
    2 x Blink and release: ramp mode
    ā€“ 3 x Blink and release: thermal settings
    ā€¦ etc.
    With the most used settings should be in the first row. (I think it shouldnt be more than 5 options per sub level, since it will be hard to count)

  3. Implement click and hold for increment 10 Click where it makes sense.

Iā€™m sorry if someone already suggest this kind of UI, since I didnt read all the replies yet :slight_smile:

Is the thermal ceiling set the same way as it is for Anduril 1?

Thx.

Not completely. Menus were redesigned and you have to hold the switch to select an entry. But then itā€™s the same. Look at the manual for details.

1 Thank

That would indicate the program crashed. Iā€™d try it on another platform, since apple loves to change things and break backwards compatibility. I didnā€™t even realise there was an Apple Silicon version of avrdude, there isnā€™t an official one (see issue here), unless youā€™re running an older version of one, in which case I still know almost nothing about that particular walled garden.

Wouldnā€™t be at all easy to do as an option vs the current style (since youā€™d need to be adding extrra states etc as well as a whole load of conditionals for whether config is available in the current set of states or not), but is definitely implementable within FSM (youā€™d just be adding extra states with corresponding sets of events) if you wanted to do it yourself.

1 Thank

Thanksā€¦ I seem to find the answer while Iā€™m waiting for the answer. I found a thorough video, about 31 min. and he explained everything.

It works on my MacOS Intel, no issues.
I just hoped there was a solution for iOS as well, thatā€™s all.

Would you share the link to that video? :blush:

Sureā€¦ at 9 minutes or so he talks about temperature check and thermal configuration.

1 Thank