The intention is to record what data the WLED module has received, logging it to a microSD card for analysis.
This is in the context of being able to test reception accuracy of WiFi data sent to multiple displays in the yard via e1.31 or ArtNet (or TPM2.net).
I could send a fixed set of changing data for several minutes to all lighting displays distributed around the yard, from a PC (ie: the full speed WiFi data to all receivers which would be used in a light show), and then compare what a given display received to what was supposedly sent to that display, to see how often packets are missed or corrupted at various displays. (From there I might adjust the transmitting AP location, ESP/WLED receiver location, use an external antenna on the ESP/WLED, switch to ethernet for some displays, etc).
My thought was to capture what a given ESP/WLED receiver thinks it received, by sending the received data out a serial port (at a high baud rate), and attaching a serial datalogger to record it to microSD. Then I can analyze it with Python on a PC.
What I see is that I can send up to 512 channels (170 pixels) via DMX512; that’s not enough. It looks like WLED can sent TPM2.net data out over WiFi (but that would interfere with receiving the data via WiFi). And it may be able to receive TPM2.serial input on the serial port (but I want output).
In the Serial section, it mentions WLED receiving an L serial command which will cause it to send the current pixels data out the serial port via TPM2.serial - Yay. BUT - this is not syncronized with new data continuously being received via WiFi. That is, I don’t know how often or when to send the L command, and I’m guessing that this unsynchronized buffer might come from more than one WiFi delivered frame (ie: the buffer being sent via TMP2.serial might be asyncronously updated via WiFi e1.31 etc). That would obviously invalidate my testing.
I wanted to use WLED in the testing, since that’s what I will use in the light show.
Any ideas how to overcome the issues, or another approach?
(One would be having a datalogger which can receive, decode, and store WS281x protocol data, which could then be substituted for the pixels on any receiver/controller - but that’s a different project; Microchip does have an app note on doing this with a PIC microcontroller and I suspect that the RPi Pico’s PIO could be programmed to receive WS281x protocol, but it’s beyond my current ability).