search

heronarts / LX

Core library for 3D LED lighting engines
https://chromatik.co/
Other
41 stars 25 forks source link

Add LEDScape for RGB-123 boards #62

Closed jkbelcher closed 2 years ago

jkbelcher commented 2 years ago

Not polished but functioning with legacy RGB-123 boards on Joule.

There are two values hard-coded in here which need to be loaded from json... was a little fuzzy on how to do that. They are: 1) pixels per universe (to match user config on rgb-123 board) and 2) total number of universes (determined by the # of outputs on controller - 32 for the boards we are using.). It looks like JsonProtocolDefinition.universeKey and .channelKey can be used to specify two json keys for these two values?

mcslee commented 2 years ago

Had a look at this, it looks to me that this is actually just OPC. Appears to have the same port number and the same header structure. As far as I can see here, you'll get away fine just using the existing pre-implemented OPC protocol?

The only difference I see here is that you are passing this a fixed packet size upfront. Which seems problematic actually because at 4 + 170332 = 16,320 bytes which puts us into UDP Jumbo Frame territory. Does the packet really always want to be that big? Even if your IndexBuffer actually does not have all those points?

I don't see any other real issues here - if it's working fine for you then go for it, but I won't plan to merge this into the main branch since it seems basically redundant with the existing OPC implementation.

Is there documentation on these LEDscape boards somewhere?

jkbelcher commented 2 years ago

Ok, looks like you're right about that. I had bumped the control software side of this along since 2015 and never noticed it was standard OPC. The format that the LEDScape firmware wanted, at least back in the day, was 0 for the command and channel fields and all the pixels in one packet. I have not dug into it to see if that's still necessary, in fact very likely a new version of ledscape is more flexible. Yes it makes huge packets but amazingly has not been a problem. When using wireshark it looks like the packets may be getting split into multiple by the laptop prior to getting sent, and I guess then reassembled by the linux board on the receiving side.

Closing this pull request. I should be able to make it work with existing OPC implementation. Will experiment with it pre-BM.