I am getting similar behaviour as reported by @Hoehenarbeit on a Pixhawk 2.4.8. I am using level shifting and a separate 5.1 volt supply to the WS2812’s.
For example, when the internal LED in the Pixhawk is flashing yellow, the WS2812 will flash yellow, but irregularly. It will not flash in synch with the main LED, but misses some flashes as if it sometimes doesn’t get the correct data.
I haven’t finished investigating if it is a hardware issue with the level shifting, the particular WS2812 or the 5.1 v supply, but given @Hoehenarbeit’s similar report, it sounds like a firmware issue?
Cant see anything obvious in the params, you do also have SERVO10_FUNCTION set to 120 can you try with that at zero (or test with defualts and set it to 120).
Other than that you could try on the latest firmware, it could be a bug that has already been fixed but not made it to the release, dont fly unless your happy using less tested firmware, might be other bugs ect.
Could just be there is more going on so the timing gets abit loose.You also try turning changing a few params at a time and see if you can narrow it down abit. Maybe try servo functions and serial ports first.
I am using the latest beta of both AP and MP and I cannot find this new parameter, mainly because I am not sure where to look - could you please tell me what it is labelled?
BTW, I have tried all different hardware (LEDs, level shifter, flight controller) and installed the latest AP beta and I still get the erratic flashing, so it does look like it is a software timing issue …
I even have the recommended 330 ohm resistor in the date line to the WS2812B and a 2200uF capactor across the 5v at the LEDs, but still no improvement.
It would be a pity if we can’t get this to work reliably as it would be very useful to have some bright LEDs at the rear of the drone to display its status from a distance.
OK, I have installed AP ver 4.0.3-dev for a Pixhawk1 from here and I can now find the parameter NTF_NEO_LEN and have set it to 12 (for a ring of 12 WS2812B LEDs).
However, the problem of the NeoPixels not flashing in synch with the internal LED remains.
I did some further testing and the problem seems to be related to serial communication. If I disable Serial1, the LEDs blink normally. If I enable it, but reduce the SR1 rates I observe much less irregularity/missed commands.
Is it possible, that the CPU gets overloaded by the Neopixel feature, or is this only a software issue?
Since we can’t get access to the video to see what you mean, could you please describe what you see? Are you referring to the colours being wrong or to the flashing being erratic?
We have discovered that not all WS2812B NeoPixels follow the RGB sequence - some are GRB and thus the displayed colours will be different.
Also, what flight controller are you using the NeoPixels on?
OK, so the colours are correct but sometimes the flashing is out of step with the main LED, or the NeoPixel LEDs stay on and dont flash when they should. All those different symptoms happen all in just one boot up.
The flashing being out of step with the internal LED is a known issue and has been reported by both @Hoehenarbeit and me and is described in earlier posts in this thread. It appears that the data stream that should be sent to the NeoPixel LEDs gets “lost” at times, thus leaving the LEDs in their last state - either ON or OFF - for one or more cycles of flashing.
@Mallikarjun_SE@Hoehenarbeit and anyone else who has this issue, can you add the firmware version you were using and any more information I have missed to the issue.
Its just a matter of a single line change in the script to do this with NeoPixels, although the update rate is not so good as ProfiLEDs, I doubt it would make much difference for this example.
I don’t understand how the releases of AP versions work, so when does “master/latest” become a release that we can safely upgrade to - an official/stable version?
Also, the parameter NTF_NEO_LEN was in AP ver 4.0.3-dev, but did not make it into the V4.0.3 official/stable version. How do I know when it will progress to an official/stable version?
I’ve been trying to write my own LUA script with neopixel leds and a Pixhawk black cube. Did Tridge use any kind of program to write the LUA script? I have found that taking out the micro sd card and writing code and then putting it back in the cube is basically trial and error and very difficult to find bugs in the code. I’m really just looking for an easier way to debug the LUA script controlling the neopixel leds.
if you flash to latest there you can use MAVftp to upload the script via the usb connection. You will also need beta mission planner, its ctrl +x on the main page or a tab on the config page somewhere. You can also reboot with ctrl + f -> reboot pixhawk. Speeds it up quite a lot. On latest you also get extended messages in the messages tab so you can see the full error.
