I just tested and discovered the same problem. My previous testing was only indoors, so I did not arm, and my own custom script runs slightly different logic.
Because my custom script uses some logic to rapidly update the LEDs while disarmed, I stumbled onto a potential short term fix and also likely still existing bug.
I found that if I repeatedly send the serialLED:send(led_chan) command, even when it’s logically unnecessary, I could force the LEDs to take a color update.
Here’s an updated script that should work with the present 4.5-dev master branch.
@andyp1per, I think further analysis of the ProfiLED signal timing is warranted. I suspect the data transmitted by the send() method is frequently mangled or missing.
Happy to lend a hand if I know what to look for. For example, wouldn’t have thought to dig so deep as ChibiOS timing for the root cause, but I can troubleshoot with a little guidance.
Are you able to test whether the problematic script works with NeoPixel (needs to be same number of LEDs)? That might give a clue as to what area of the code is responsible
I did a quick bench test on a CubeOrange+ with a strip of 8 NeoPixels on SERVO14, and I needed to apply the same workaround to get the script to work (repeatedly executing serialLED:send() to reliably effect a color change).
I used a lab power supply to emulate the level shifting circuitry recommended in the NeoPixel documentation, and I found that a supply voltage range of 3v3 to 4v5 made no difference in behavior other than brightness, as expected.
For sake of completeness, here are the very slightly altered scripts I used:
Script from master repo, single line altered to configure NeoPixels (solid red/green, no strobe effect on arming, but can confirm the logic is correct): Hexsoon_NeoPixel.lua (2.6 KB)
Thanks, so this is a different SerialLED problem rather than ProfiLED. Having it fail on NeoPixel makes it easier to test - I suspect its something to do with the LED threading.
AP_Notify updates the LEDs at 10Hz and does not appear to return early if there is no color change, so it very likely has the same effect as my 20Hz updates in the script.
I really appreciate you taking the time to look into this. While blinky-blink LEDs may seem trivial, there are very likely users who rely upon them for non-trivial notifications. They may be doing everything right in updating their firmware on a reasonable schedule, but a sudden, rather innocuous breaking change like this could really be detrimental in some use cases.
@andyp1per, tested successfully using the unmodified (except for single line as required for NeoPixels) AP applet script in the master repo. Both of the following configurations appeared to work as intended, with the “strobe” color reliably changing on time upon arming:
Benchtop CubeOrangePlus with WS2812 NeoPixels
EDU450 CubeOrange with ProfiLEDs
Used bdshot target for both tests, linked below.
@yoyocomputer, you might try one of the binaries below if it suits your needs.
I’m new to this, so my apologies if this is a stupid question or has already been considered, but is this current issue related to this issue opened in 2022 (and still open)…
This version has been tested on a flying drone and has fixed all of the issues with the Hexsoon sample script. It is working and it is also fast. Thank you so much for dedicating the time to fix this issue.
Has anyone tried these scripts on the main channels? I wonder if that is part of the problem. I can get the Neopix lights to work when on aux channels but the scripts fail to setup when on main. I have found this result in arducopter 4.4.4