Anduril ... 2?

[Light-Chris]

Anduril 2 MC

(For multi channel)

[wolfgirl42]

@ToyKeeper

Maybe bluetooth or an optical dongle to reflash or configure it.

One thing I was exploring the possibility of with a friend (who I need to remind to get on here / IRC…) was of being able to reflash firmware via USB, and building a charge controller into the driver as a more integrated component, so the driver is aware of USB charging state etc.

[ToyKeeper]

@Reader9

I only have single-channel A2 lights so after much reading (hence username) I got the impression that the UI was going to have big changes—but it sounds more like nothing is breaking and instead new optional functionality is being added for lights that support it?

Pretty much, yes. For single channel lights, there are some new features… but no significant backward-incompatible UI changes. User-visible things have been added, but not broken or removed.

[dmenezes]

@wolfgirl42

being able to reflash firmware via USB, and building a charge controller into the driver as a more integrated component, so the driver is aware of USB charging state etc

That would rock! Would make things both more useful and customizable, and much simpler for beginners to get started with (and easier for us more experienced folks, as there would be no need to even open up the light to flash it, to say nothing of aligning pogo pins, etc). And I don’t think it would be that much harder than the things Anduril already does.

If/when you get down to that, please tag me as I wouldn’t want to miss it for the world!

[ToyKeeper]

@SammysHP

@ToyKeeper

a ramp-linear animation or an analog-rise-time shaped animation curve.

Could you explain the difference?

It’s just the shape of the curve, if the brightness of the individual frames was put on a graph.

After testing a few options to see what looks best, I ended up with different curves on the way up and down:

• When going up, it rises by a percentage of the remaining distance each frame, with a constant frame rate. So it adjusts quickly at first, then slows down as it nears its destination.
• When going down, it drops by just 1 ramp step at a time, in a way which is linear in terms of ramp steps… but it adjusts the frame rate to get a constant total time.

Using a ramp-linear solution going up made it look weird, because the brightness would accelerate and then suddenly stop. It seemed like an unnatural motion. Using a percentage-remaining solution on the way down looked weird too, because it would drop rapidly at first and then slow down so far it seemed like it got stuck, before finally turning off.

However, two different curves together look much closer to what it should be.

[Owenm03 (Wolfgang)]

Hi @Toykeeper,

I’ve seen that with introduction of set_level_zero() in hwdef-wurkkos-ts10.c and hwdef-wurkkos-ts25.c revision 763 (maybe some revisions earlier, I didn’t check) one line of code disappeared from set_level_main():

level --; // PWM array index = level - 1

Is this by intention?

[ToyKeeper]

@Owenm03

one line of code disappeared from set_level_main():

level --;

Is this by intention?

Yes, that’s removed on purpose. I changed the API a bit, to make the hwdef code smaller and simpler, and to reduce overall code size.

Before:

///// FSM:
set_level(lvl) {
    set_level_func = channel_modes[cm].set_level;
    set_level_func(lvl);
}
///// HWDEF:
set_level_a(lvl) {
    if (0 == lvl) {
        turn_off;
        return;
    }
    lvl --;
    channel_a = ramp_a[lvl];
}
set_level_b(lvl) {
    if (0 == lvl) {
        turn_off;
        return;
    }
    lvl --;
    channel_b = ramp_b[lvl];
}

After:

///// FSM:
set_level(lvl) {
    if (0 == lvl) {
        set_level_zero();
        return;
    }
    lvl --;
    set_level_func = channel_modes[cm].set_level;
    set_level_func(lvl);
}
///// HWDEF:
set_level_zero() {
    turn_off;
}
set_level_a(lvl) {
    channel_a = ramp_a[lvl];
}
set_level_b(lvl) {
    channel_b = ramp_b[lvl];
}

[Owenm03 (Wolfgang)]

Thanks a lot for the explanation … I didn’t see that the decrement of level switched from hwdef to fsm. Now it’s clear!

[tri4ng1e]

Tried out the soft start feature, and it’s just beautiful, thank you for implementing it!

I did find some strange behavior with Wurkkos TS10, though. When using smooth ramping mode and smooth starting from off to some level, first 90-95% of the way the brightness is ramped smoothly. But last 5-10% or so it jumps instantly. This happens for any target brightness level, but it more noticeable on high outputs. When switched to stepped ramping, soft start is smooth all the way up without any jumps, on any brightness level. Smooth transitions between different levels in stepped ramp mode are working perfect as well.

On Emisar D4K boost, this is not reproducible: smooth start is working, well, smoothly, in both ramping modes without any issues.

I used self-built binaries of r763 with original configs (except for moving some code from set_level_main to set_level_zero in hwdef file for Emisar, so it will compile), and did reset the settings after flashing.

[ToyKeeper]

@tri4ng1e

When using smooth ramping mode and smooth starting from off to some level, first 90-95% of the way the brightness is ramped smoothly. But last 5-10% or so it jumps instantly. This happens for any target brightness level, but it more noticeable on high outputs. When switched to stepped ramping, soft start is smooth all the way up without any jumps, on any brightness level.

Ah, thanks for catching that. I think I know exactly what’s happening…

It uses soft steps in stepped mode, but not smooth ramping mode… because smooth is already smooth. But this could make it jump if it changes from Off mode to Ramp mode mid-animation. Like, it’d do most of the animation in Off mode, then time out and switch to Ramp mode, and then try to set the level again… which would cause it to jump the rest of the way up.

I’m guessing it’ll be a pretty easy fix, but I didn’t notice it before because I was mostly testing in the stepped mode. The animation works fine, even when interrupted halfway through by a state change, in most cases… but it probably needs to make sure an animation isn’t already in progress, instead of checking only the ramp style.

[nerulight]

Hello, I picked up two of the new D4K-3Ch and seeing an odd behaviour. I made sure I updated to 763 first. The first channel doesnt seem to ramp at all. If I manually set a ramp floor of 1, it enables moonlight. When i turn on to moonlight, as soon as I ramp up it just goes straight to max output. Ch2 and Ch3 on both lights seem to behave normally with both smooth and step ramping. (One has Cree Pink/Cyan/Yellow, the other SST20 Red/W2 Green/W2 Blue). Putting Ch1 on stepped takes away moonlight (ramp floor 20) so it basically has only max output.

Interestingly, in Bike Flasher, both Pink and Red Ch1 do not pulse properly. It is just a single blink (and also the same seemingly narrow ramp).

[ToyKeeper]

@nerulight

The first channel doesnt seem to ramp at all

That’s strange. It should be able to ramp normally, though the low modes on channel 1 don’t have as much resolution since it’s 8-bit instead of 16-bit.

On both lights, what LEDs+channels were specified when ordering, and what order do they appear in when changing channel modes?

[nerulight]

When I turn on at moonlight, it also goes up a bit, then comes back down a bit.

PCY Light How I Ordered:
Ch1 Cree XP-E Pink (2)
Ch2 Cree XP-E Cyan
Ch3 Cree XP-E Yellow
Channel Order: Pink > Yellow (closest to light switch) > Cyan > All 4 > 2+3 … Looks like Hank put Yellow on Ch2, no biggie.

RGB Light How I Ordered:
Ch1 Luminus SST20 Red (2)
Ch2 Osram W2 Green
Ch3 Osram W2 Blue
Channel Order: Red > Green (closest to light switch) > Blue > All 4 > 2 + 3

[nerulight]

I just posted two videos on r/HankLights (subject Pink Moon/Red Moon). With each light I turn on to moonlight 3 times then show a ramp up (straight to max), then a ramp down (straight back to moon)

[ToyKeeper]

@nerulight

Looks like Hank put Yellow on Ch2, no biggie

Dang, I’ve been trying to get confirmation about the order those go in… and this shows both ways!

I have a RGB model, with red on ch1 (2 LEDs). The red channel ramps up and down normally. I don’t have a pink model, but I hear the response curve on the pink LEDs is a bit different than usual.

In any case, the moon level uses PWM of 0/255, so it’s the absolute minimum the regulator will allow. Above that, the next level is 1/255, which should be pretty dim, but if the response curve isn’t right, it could be significantly brighter than intended. There isn’t much I can do about that in firmware though.

[nerulight]

If I turn on either light at moonlight, ramp up and let go -immediately-, i get full brightness, and it lets me doubleclick to bump to turbo. So its like moonlight > full > turbo is all they have.

[nerulight]

By putting Cyan onto Ch3 he at least made my two lights ‘consistent’ hehehe. Basically I am using Ch2 and Ch3 for all mode memories to taste, and Red and Pink are the secret super power of these lights for now

[wolfgirl42]

Sorry I’ve been so inactive on the development (and general activity here…) side recently, life getting in the way. Here’s something nice for everyone:

With the 3 channel lights, USE_AUX_RGB_LEDS_WHILE_ON is now set for all lights, enabling the voltage to be displayed on the aux while the light is on, but I’ve seen a few people who don’t like it, especially as it can interfere with tint mixing on the 3ch, so I present my solution.

I built a modded version of anduril with a few extra options. Added to the end of the 9H menu from off, there are 3 new options:

• Enable/disable voltage aux while on (1C = disable, 2C = enable)
• Set threshold for low aux brightness for voltage - this is the brightness that the aux LEDs will come on at. 1C for 0 (i.e. aux are always on at at least low (could be high instead of low, depending on the next config item)), otherwise sets the threshold to n-1 (e.g. 11C sets the threshold to level 10)
• Set threshold for high aux brightness for voltage - this is the brightness that the aux LEDs will come onto high mode at. 1C for 0 (i.e. aux are always on at high), otherwise sets the threshold to n-1 (e.g. 11C sets the threshold to level 10). This threshold will override the low one, e.g. if you set your low and high thresholds to 10, the aux will be high at level 10.

(i.e. for 2ch/3ch: tint ramp steps, jumpstart, RGB on/off, RGB low threshold, RGB high threshold)

In addition, when in ramp mode (edit: and advanced UI - see below), 8C can be used to switch the voltage aux on/off directly without exiting to off mode and going through a config menu.

This is based on the latest version at the time of writing (763).

This is a mod I’ve been using for a few months and have done builds for other people but not posted a general release so far because I’ve been busy - one thing I’ve been working on is a system for automating builds of anduril with different sets of modifications.

Release with hex files: Release aux-control-20230910 · SiteRelEnby/anduril2 · GitHub

At the moment only built for emisar-2ch, emisar-2ch-fet, emisar-3ch, noctigon-kr4, and noctigon-kr4-nofet as there are some recent breaking changes in anduril and other build targets don’t work yet, but more should be available soon.

EDIT: 8C to toggle on/off only works in advanced mode, which wasn’t intentional (some of my modded lights don’t even have simple UI (waste of MCU space if I never use it) and the ones that do default to advanced UI rather than simple) but I’m interested in opinions on whether this should be included in simple UI or not, I guess.

Edit 1: Added KR4 FET and noFET builds

@ToyKeeper

Dang, I’ve been trying to get confirmation about the order those go in… and this shows both ways!

I think that with the complexity of 3ch, especially if people start emitter swapping them, having multiple build targets for it is probably inevitable, maybe needs a bit of thought as how to best implement that and describe the difference to the user… I have one straight from Hank where I’d prefer the 8-bit PWM to be on one of the two single LED channels as the 2-LED channel overpowers the others otherwise (but I am capable of making that changem yself, but a lot of people aren’t…)

[wolfgirl42]

If anyone was looking for the d4k-3ch hex, I have now actually added the right file to the release , also edited the post to clarify a few things.

Edit: Added KR4 and KR4-noFET as well by request.

[tri4ng1e]

Happy to inform that with r767 the soft start animation on TS10 is smooth all the way to the target level! Thank you very much for your work.