RGB aux lights briefly flash red when switching to lockout mode on the 2023-12-03 release.

[maru801]

All the flashlights that I have with any RGB aux lights have this bug. The aux lights briefly flash red when entering lockout mode.

I'm assuming this affects all lights with any type of RGB, but if not, here is a list of the modules that I have this bug on:

1. 0135 attiny1634 hank-emisar-2ch
2. 0253 attiny1634 hank-noctigon-k1-boost
3. 0273 attiny1634 hank-noctigon-dm11-boost
4. 0716 attiny1616 wurkkos-fc13

[Light-Veteran]

What level you use before lockout?

[maru801]

This behavior happens on all levels before entering lockout (manually or automatically). I tested all ramp levels and the behavior still occurs from moonlight to turbo. Changing from stepped to smooth ramping doesn't fix this.

[Light-Veteran]

The red blink is low or high?

[ToyKeeper]

What version of the firmware is installed?

A short red blink was fixed a few months ago, and I don't see it in current versions.

[maru801]

@Light-Veteran The red blink will follow the same brightness as you set for lockout mode. So if you set the lockout rgb to be low, flash will be low, high will make the flash high.

@ToyKeeper I've installed the latest hex files from your release some days ago. The version should be 2023-12-03. I've included the models I used in my first post for this issue.

I think I actually narrowed down the problem to two things:

1. This happens when lockout is set to have rgb show the battery voltage. When I switch the aux lights to show anything else than battery voltage during lockout, this issue is fixed.
2. I also found out that when you do 7C to switch between low-high-blink-off for aux lights (regardless of lock state) with battery voltage mode, going from low to high also shows a short red flash.

To clarify, this only happens when going into lockout. Leaving lockout (when the unlocked rgb state is to show battery voltage too) does not produce a red blink/flash.

[ToyKeeper]

I've been trying to reproduce the issue, but haven't had any success yet, even when using some of the same exact firmware builds. Do you have any other configuration which might be relevant?

[maru801]

No, a straight flash with your hex files (and also resetting the eeprom) still produces this for me. Maybe it's an issue with how I'm flashing it onto the flashlights?

I've been using avrdude v7.0 (64-bit) for windows along with Hank's reflashing kit. I've installed the drivers for the usbasp kit using zadig v2.4. As for the attiny1616 flashlights I own, I've been using this kit from jlhawaii808 which doesn't need any drivers to install (at least on my computer) to work.

I'll include here the output that I get when I flash two of my lights along with the hex files read after the flash:

Command prompt output when I flash the k1-boost hex: avrdude-output (D1K XHP70.3).txt Firmware and eeprom hex files read from light (after flash): 0253-test-flashed-firmware.hank-noctigon-k1-boost.zip

Command prompt output when I flash the fc13 hex: avrdude-output (FC13).txt Firmware and eeprom hex files read from light (after flash): 0716-test-flashed-firmware.wurkkos-fc13.zip

If you need output from my other two lights that have this issue, I can provide them as well. I can also make a video showing the bug happening on the lights too if you want to see it.

[dirtydancing]

Issue reproduced: I have checked with 3 lights with RGB Aux LED/RGB button, all running Anduril 2 Release 2023-12-03, and I have observed the described red blink when switching to Lockout Mode on all 3 lights:

1. 0273 attiny1634 hank-noctigon-dm11-boost (Emisar D4K boost, on both Aux LED and button)
2. 0135 attiny1634 hank-emisar-2ch (Emisar D2, no RGB button, so only on Aux LED)
3. 0125 attiny1634 hank-emisar-d1v2-nofet (Emisar D1K, no RGB Aux LED, so only on button)

Easiest way to reproduce: In Lockout Mode, set Aux LED color to Voltage and Aux LED pattern to High. Switch out of Lockout Mode and then back into Lockout Mode, and when switching to Lockout Mode, a very visible red blink will appear.

Furthermore (maybe related), also on all 3 lights, as reported, in Voltage color, when switching from Low to High pattern with 7C, both in Lockout Mode and in "Off" Mode, a (somewhat shorter and thus less visible) red blink will appear.

In case that the flashing method is of relevance: I used Hank's reflashing kit and ZFlasher AVR on mobile phone.

[dirtydancing]

Just an additional observation: On all of the 3 lights I checked, the same very visible red blink that appears when entering Lockout Mode, also appears when entering Tactical Mode, 6C from Off. This might not come as a surprise, as the Aux LED settings from Lockout Mode also apply to Tactical Mode, but maybe this additional observation is helpful in the context of this issue.

[SiteRelEnby]

IIRC, either this is a very similar but unrelated bug, or it's an effect of the eswitch affecting the battery voltage reading, and the post-off voltage. Are you testing with that enabled?

[maru801]

@SiteRelEnby I'm able to reproduce this bug with post-off voltage being on or off.

Forgot to mention this, but a third place where I found this bug is when switching rgb colors (7H). When you switch and let go on battery voltage mode, the aux lights turn red for a bit too. However, I'm not able to reproduce this bug with 7H each time I do it, more like half the time I do the 7H to voltage mode, it shows up, and the other half of the time it doesn't.

I did however find something interesting with the bug being reproduced with 7H onto voltage check mode. I think the actual battery charge has an effect on this. I'm able to affect what color is briefly flashed when 7H to voltage mode is used by changing the battery voltage presented to the software. Furthermore, this 7H bug ONLY appears when the light is not locked-out. If I attempt to reproduce this on lock-out mode, the 7H switch doesn't show the bug (or maybe it's too fast to where I can't notice it).

So, if I insert a fully-charged battery, the 7H switch will make red briefly appear before showing the actual voltage color. However, on my other light that had a battery around 50%, green would be flashed before switching to the actual voltage color. And on a battery that was nearly depleted, increasing the voltage read with "3C -> 7H -> 13C" makes the 7H to voltage mode blink blue before switching to the actual voltage color.

Once again, for some reason, this 7H to voltage mode bug doesn't happen each time I switch to it.

[maru801]

I have a question. How is the code implemented for switching aux colors with 7H? The reason why I ask is related to my previous comment about the 7H bug. It seems that the timing of when I release the switch affects if the bug will show or not. Also, it appears that when you let go after 7H, the light remembers your position of the previous 7H switch to one of the three special light modes (disco, rainbow switching, & battery voltage) and resumes there. As in, if you let go half-way through one of those modes last time, next time you do 7H, you will resume half-way through that mode leaving you with that amount of time before it switches to the next color for you to choose. Could this be related?

[SiteRelEnby]

You can check it here: https://github.com/ToyKeeper/anduril/blob/f8dfd6c01f71d753b313f61c2786618ecbba5750/ui/anduril/off-mode.c#L310-L325

I don't think it is possible for it to resume at halfway through the timeout, because arg is just the number of ticks since the event (i,e. that individual hold) started, there's no state persisted across separate hold event calls other than the initial aux mode it starts from.

Any more info on reproducing would be helpful, I need to update a light to test this. Is this the latest commit you are running, or a particular release?

[maru801]

I currently flashed all my lights to run ToyKeeper's 2023-12-03 release.

Other than making a list of how I exactly installed the flashing software on my OS, listing what hardware I'm using to flash to the lights, and providing a hex file of the firmware on my lights post flash, I can't really do much else to help with reproducing. It just appears with a straight flash of the new release (with no settings changed and a reset done afterwards too with 13H). I could also make a video showing the bug happening, but looks like @dirtydancing also confirmed to be able to reproduce this.

The previous release (2023-10-31) didn't have this bug when switching to lockout. I've flashed that old firmware and this new one to all of my lights in the same way too on my computer.

Also, for that resume halfway through an aux mode, I suggest you try it out for yourself too. I noticed that I can't get it to resume from an ordinary color (next 7H will start on the next color from current), but I'm able to quickly let go on one of the special switching color modes and have it resume on the next 7H. I swear I experienced this action before in previous releases too. Don't know what could be causing it (especially looking at that code snippet since it looks alright to me). The easiest way to see this would be to attempt it on voltage mode since it's the last aux mode that switches colors like crazy. You will know that it resumes on it since the next color is supposed to be red.

[dirtydancing]

Just to confirm: I am able to reproduce this issue consistently, also using ToyKeeper's 2023-12-03 release, and nothing I have checked changes anything about it (for example 13H reset, physical reset, disabling post-off voltage, disabling smooth steps).

[dirtydancing]

@maru801 Are you sure that this issue (when switching to Lockout Mode) did not exist in the previous release, 2023-10-31?

The previous release (2023-10-31) didn't have this bug when switching to lockout.

I checked and flashed ToyKeeper's 2023-10-31 release to a D1K, version check 0125-2023-10-31, and I observed the same very visible red blink (on the D1K's RGB button, no Aux LED available) when switching to Lockout Mode (with Aux LED in Lockout Mode set to high and voltage). I have not used these Lockout Mode Aux LED settings before, so I simply might not have come across this issue before because of that.

[maru801]

I re-flashed the 2023-10-31 release onto my D1K (model 0253) and it also happens with that firmware. I also re-flashed the hex files for that release that I previously saved as a backup and those have the same issue.

I don't remember this issue happening when I first flashed the 2023-10-31 release when it came out. It could be me not paying much attention to this though, especially since I have lockout RGB be on low mode which hides the red blink in most situations.

[dirtydancing]

Interesting, thank you for checking back, and yes, agreed that this is easy to overlook. Anyways, I was trying to figure out at what point in time this issue came up, and I compiled a couple of builds going back several commits from release 2023-12-03, but this issue was still present, so I checked release 2023-10-31, and it was still present.

What I now did is to go all the way back and re-flash the build that the light originally came with, version check 202207290125 (with this build, e.g. the Lockout Mode default Aux LED settings are disco and blinking). I set the Lockout Mode Aux LED settings to voltage and high, and now, when switching to Lockout Mode, there is not the very visible red blink, but rather an almost invisible very short red blink. If I had not specifically looked out for it, I would not have noticed it. So this issue might have been around for a long time in one way or another.