Anduril ... 2?

TIFisher · June 25, 2023, 3:45am

Thanks for the elaboration. I’m not a “coder”, and understand very little about the intricacies. I understand there are degrees of variation in application amongst the increasing number of manufacturers utilizing the firmware. Kinda thought it was an accommodation of sorts to account for that, but wasn’t sure if there might be a continued evolution of v2 or a restructuring to a new version (ie; An-3). Again, just a curiosity.

wolfgirl42 · June 25, 2023, 4:22am

Yeah, there isn’t really a hard cutoff for what’s considered “version 2” (or really any formal version scheme past commit numbers); it sort of became the name for a new version when a few big refactors happened at once, it seems to me, so there isn’t really a sort of schedule or intended release of a “new version” per se.

Light-Chris · June 25, 2023, 5:22am

Hi @nick779

Using directly the multi-channel branch from Toykeeper solved the ramp down issue for me.

After I managed to compile directly from that repository, i didn‘t have the issue anymore.

Light-Chris · June 25, 2023, 5:31am

I think Anduril 3 or Anduril 2.1 would make sense.

Something like Anduril MC (Multi Channel) could be an Option as well.

I would call it Anduril 3, because it‘s a bit different than the previous versions (6c, channel mode settings). Then it‘s a clear separation and can have a dedicated manual and flow chart.
Just a personal opinion

Light-Chris · June 25, 2023, 5:31am

Does anyone know, what Anduril revision (Date), will be in the now sent out M44‘s?

Light_Veteran · June 25, 2023, 8:23am

Maybe 2.1 is not bad
I think is not properly anduril 3 because there is not completely new interface
But now I am imagine new Anduril 3 and I am a little bit confused
Maybe Anduril 3 with Bluetooth module?

nick779 · June 25, 2023, 11:23am

Well, can’t hurt to try again.

SammysHP · June 25, 2023, 4:45pm

wolfgirl42:

ToyKeeper:

Oh dang, it didn’t have grep? Sorry about that, I’ve generally been able to assume that certain core utilities are available, like grep.

It has grep, just it’s based on alpine so by default it’s BusyBox grep (which doesn’t support long args, also seems to have no equivalent to --text), unless you install GNU grep. Firmware still builds without it, just the .cpp generation fails. I wrote my own preprocessor script a while back to debug some stuff and it didn’t result in as clean output, so it’s a good feature to have.

As it is, when busybox grep it outputs a usage summary into the build output, one way around that would just be to redirect grep’s stderr to /dev/null, since it’s something most people will never use, you’re right there (and I’ve actually broken builds of stuff my making similar assumptions about tool availability and version before ).

You can use -a, the short form of --text, which is accepted by GNU grep as well as BusyBox grep. It even mentions it in the source:

#define OPTSTR_GREP \
	"lnqvscFiHhe:*f:*LorRm:+wx" \
	IF_FEATURE_GREP_CONTEXT("A:+B:+C:+") \
	"E" \
	IF_EXTRA_COMPAT("z") \
	"aI"
/* ignored: -a "assume all files to be text" */
/* ignored: -I "assume binary files have no matches" */

Owenm03 · June 26, 2023, 10:16am

Hi @ToyKeeper
Hi @wolfgirl42
I was asked to post this here:
I think I found a new issue with anduril.2023-05-30.noctigon-kr4.hex and anduril.2023-06-25.noctigon-kr4.hex (Wolfgirl42) if used in a D4K (non-boost-driver) … there is no thermal stepdown even on very high temperatures. I described this here
It’s really dangerous because the D4K might get very hot.

wolfgirl42 · June 26, 2023, 12:53pm

I’m wondering if this is related to the previous calibration bug in some way (relating to specific MCUs where the uncorrected temperature reads high instead of low). I don’t have enough time to test extensively, but so far tested 3 including a D4K running the latest and they all step down for me. I guess first I need to find out if I own an affected light. ToyKeeper has more of an idea about this bug than me, but if I find time I’ll have a look later.

Owenm03 · June 26, 2023, 1:53pm

@wolfgirl42,
has your D4K a non-boost-driver and did you test with KR4 firmware?

pairofdice23 · June 26, 2023, 5:42pm

Does anyone have a hex for the LT1 based on the latest TK revision? Does it include the new channel modes?

jon_slider · June 26, 2023, 7:16pm

here is the full list:
https://toykeeper.net/torches/fsm/anduril2/

this is the newest LT1 hex in that list
anduril.2023-05-30.sofirn-lt1s-pro.hex

Light-Chris · June 26, 2023, 7:29pm

There is actually a newer version from 30-05-2023

maxpower4738 · June 26, 2023, 7:52pm

I got a new D4SV2 and DM1.12 recently that both came with 2+ year old firmware versions. I didn’t see newer builds for either of their model codes (0261 - noctigon-k9.3 and 0136 - emisar-d4sv2-tintramp-fet respectively). Are there different model codes that should be used on these now?

jon_slider · June 26, 2023, 8:09pm

thank you… I edited my post to give that link

wolfgirl42 · June 27, 2023, 2:43am

Dual channel. I have a DT8K that is single channel linear+FET but not able to reproduce it on that.

Use d4sv2-tintramp-fet for the DM1.12 as well. Looks like there aren’t any newer official builds, but here’s the latest main branch version that I built: 1.42 MB folder on MEGA - version 657, with tactical mode.

maxpower4738 · June 27, 2023, 12:26pm

Thanks. That worked for the DM1.12 with the d4sv2-tintramp-fet build. The D4SV2 used the noctigon-k9.3 build which wasn’t in the folder. I tried building it myself and it looks like a few of the k9.3 builds are just deliberately broken #error This build is broken.. Should I just be using a d4sv2 build there too? Maybe emisar-d4sv2? It’s a single channel with W2 emitters.

wolfgirl42 · June 27, 2023, 6:47pm

@ToyKeeper another small bugfix here. Lights with USE_AUX_RGB_LEDS_WHILE_ON defined but without a value (e.g. the D1) don’t build on multichannel specifically because of this line. I haven’t pushed it to github yet but I fixed it by using:

    #ifdef USE_AUX_RGB_LEDS_WHILE_ON
    // compatibility hack: if USE_AUX_RGB_LEDS_WHILE_ON is defined but has no value, set it to something sensible
    #if (!(USE_AUX_RGB_LEDS_WHILE_ON + 0)) // if USE_AUX_RGB_LEDS_WHILE_ON is an int, passes. If blank, evaluates to `(+0)` which evaluates to false, inverted for convenience.
      #undef USE_AUX_RGB_LEDS_WHILE_ON
      //not sure what's the most sensible default here...
      #define USE_AUX_RGB_LEDS_WHILE_ON 0 //always on?
      //#define USE_AUX_RGB_LEDS_WHILE_ON 1 // disable for moon only?
    #endif

    // display battery charge on RGB button during use

If you’re interested, I have another patch (on github) that allows separate thresholds for low/high, e.g. having the LED be off for level 1-10, low for 11-50, then high for 51+, as well as making those values user-configurable. Seen a few people recently on Reddit asking about a version with low or disabled RGB voltage while on, so might be worthwhile to consider merging. (Personally I like the feature so much I do the opposite and enable it at high levels on lights with forward facing aux instead.)

PS. If there’s a particular way you’d prefer for me to send small patches (preferably that doesn’t involve me learning bzr ), let me know.

ToyKeeper · June 28, 2023, 10:49pm

Hi, sorry about not being around for a while. I had a residential move scheduled for later this year, and then suddenly found out it had to be done by the end of the month… so I’ve been a little preoccupied with that. Things are about done now though, so I hope to get back to projects again.

Maybe. I’m not sure how often it would be useful.

However, I’m planning to refactor some things about how multi-channel stuff works, to move things from random globals into an array of structs, to keep channel data more organized. This would also make it easier to add other channel-related things.

So that’s the top of my list at the moment. Seems like I should do the structural code changes before I convert any more builds or add more channel-dependent code.

Er, that, and catching up on stuff here on BLF.