Packet Capture for Gen 2 750 Light Tree about xled HOT 4 CLOSED

My 250 lights Gen2 Special edition sends almost the same format, only difference is the color is sent as 4 bytes, starting with white, and because of that the pages are smaller, only 225 lights per packet. So packet one is 912 bytes for 225 lights, packet two 112 bytes for the last 25 lights.

here are the header bytes for white light packets one and two, and header bytes for red light:

 1 start - 8 token - 3 offset - 4 WRGB 4 WRGB
03 30b6ebfc4243a7f8 000000 ff000000 ff000000 ff000000
03 30b6ebfc4243a7f8 000001 ff000000 ff000000 ff000000
03 30b6ebfc4243a7f8 000000 00ff0000 00ff0000 00ff0000

Edit: I've also traced a movie upload, it goes like this:

GET /xled/v1/playlist

POST /xled/v1/led/mode  {"mode":"off"}

DELETE /xled/v1/playlist

DELETE /xled/v1/movies

POST /xled/v1/movies/new
{"descriptor_type":"rgbw_raw","fps":30,"frames_number":2,"leds_per_frame":250,"name":"Red","unique_id":"1b93643d-716f-4f1c-a81a-45a9bb12d6e0"}

POST /xled/v1/movies/full
2000 bytes of data (2 pages of 250 lights 4 byte per light)

POST /xled/v1/led/mode 
{"mode":"movie","shop_mode":0}

from xled.

New versions of RT modes have been documented - https://xled-docs.readthedocs.io/en/latest/protocol_details.html#real-time-led-udp-packet-format and now they are supported by the library since a8e8036 .

I'm closing this out as done.

from xled.

Regarding the realtime UDP packet changes, I observed the following after comparing multiple captures:

• There appears to be a 12-byte header for each packet
• There are up to 300 RGB light definitions in each packet. For my 750 lights, this means 3 packets to send the info, with the following sizes:

912 (12 + 300*3)
912 (12 + 300*3)
462 (12 + 150*3)

The header structure looks like this across 3 different captures:

01 02 03 04 05 06 07 08 09 10 11 12
-- -- -- -- -- -- -- -- -- -- -- ----------
03 be c3 81 b1 e4 fe f4 db 00 00 [00|01|02]
03 2c ec 9d b2 fa 9a 2b 81 00 00 [00|01|02]
03 dc 92 f9 cb e5 0e b6 42 00 00 [00|01|02]

I am guessing that this corresponds to the following:

• Byte 1: Total number of packets in the message (in my case, always 3)
• Bytes 2-9: The 8 byte Base 64 decoded authentication token
• Bytes 10-11: Always 0
• Byte 12: Offset for the light definition. For example, 0 means the packets describes lights 1-300, 1 means lights 301-600, 2 means lights 601-900, etc....

from xled.

Just looking at HTTP and TCP - there seems to be something missing at the very beginning of the authentication handshake - between 4th and 6th packet.

And then later when modes are switched - packets 12 and 13.

from xled.