Daktronics RTD within Docker (remote data feed)

[robere2]

Running within a Docker container with Daktronics RTD sync enabled is, from what I can tell, not easy outside of on Linux Docker hosts with a Linux container. I think the best solution for this is to have a way to supply a remote data feed. This could have a variety of other applications as well, such as:

• transmitting from across the room via a Raspberry Pi
• Running graphics completely remotely
  • This would likely require some sort or time code mechanism for anything outside of longterm graphics like bugs.
• Backup data feeds in the event of failure

[ifrog800]

Docker is not longer part of the stack to run the graphics module. However remote transmission of Daktronics RTD is becoming important especially with the limitations of RS232. Perhaps transmit the serial data over a websocket?

[asquared]

I would suggest opening a TCP connection as a way to get the serial stream from elsewhere. Once it's open it should look the same as a serial port to the rest of the code. In the past I've done this in a pinch by using `socat` commands. You'd have to decide which side is the TCP client and server - probably the biggest consideration here is where firewalls and NAT are. You'll probably also want to look at the TCP_NODELAY socket option. Websockets could also work but may be kind of overkill and may introduce excessive delay. They'd also require more code on the Pi or whatever other device receives the serial data. If you make the Pi a TCP server you could probably use something like xinetd; if it's a TCP client, socat could work. IIRC you can buy something called a "device server" off the shelf. It has a serial port and an Ethernet port (or WiFi), and lets you make a TCP connection to the serial port. Another thing that crossed my mind in the past was to do the RTD stream parsing on a Pi or other remote device, and convert it to high-level requests like "update clock", "update score" etc that would be sent over the network. Again, added latency would be my biggest concern here. Last but not least, note that RS232, if done properly, should be able to go ~thousands of feet, especially at the very low speeds we're talking about here (19,200 bits per second). In the 80s and 90s you'd see it used to connect old terminals to a computer in a back room somewhere. It's possible that the voltage levels off the Daktronics signal converter are out of spec, or that the USB-to-serial converters we have aren't very good at handling weak signals. Or if the cable is really really long, cable capacitance might be a problem.

…

On Tue, Jun 25, 2024 at 9:13 AM Edward Chan ***@***.***> wrote: Docker is not longer part of the stack to run the graphics module. However remote transmission of Daktronics RTD is becoming important especially with the limitations of RS232. Perhaps transmit the serial data over a websocket? — Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXPL6ATVNADUDCAZFP7ITZJFUIZAVCNFSM6AAAAABJ32SCWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBYHEZDENRUGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[robere2]

Can you clarify more about what limitations you're running into?

Originally this issue was because Windows Docker simply didn't allow us to pass through serial feeds, meaning we were building locally on the graphics machine instead of just pulling a container. Complete remote control (that is, hosting graphics entirely from the union) was a spitballing idea but latency for things like timers was a concern I hadn't thought about until later.

To give Andrew some context, the underlying graphics framework we're currently using (NodeCG) uses web sockets to communicate data from the controller and web interface to the HTML-rendered graphics, which are overlayed onto the video stream. This does seem to introduce some latency somewhere in the pipeline (at least when I was still actively working on this project) but it's small enough that it's pretty much been dismissed for now due to the flexibility and lower barrier to entry for new contributors. That's all to say, hooking into the existing WebSocket interface may be feasible without introducing even more latency.

My concern is more with the reliability of wireless data transfer for such a critical component. Where would you be transferring to/from? Would it be peer-to-peer or over the RPI wifi network? If you're concerned about cable runs and simply want to do this across the room, I believe Daktronics now sells direct wireless transmitter systems, but again, reliability scares me a bit if this is going to be "Plan A". There's no complete elimination of the serial connection, since you're going to need to hook into the RS232 output of the Daktronics AllSport or HFH control room repeater anyway.

If you go down to the transport layer over internet, I'd be tempted to say UDP would be better than a TCP connection.

[robere2]

Correction, I suppose UDP would work for the clock but maybe not for more static information like the score. If latency is a big issue and you can get around the latency we've had in the past, you could split it into two streams, or I suppose rely on Sidearm as a backup for things like score if the packets get lost...

[asquared]

One more note on RS232's apparent distance limitations: it may be ground loop issues. You could solve that with optical isolation and/or converting the signal to 20mA current loop. IMHO the easiest thing to try there would be an isolated USB-to-serial converter... those look like they're available for <$50. For the score and the other information that the Daktronics controller only sends occasionally, if you wanted to use UDP for everything, you could keep track of that on the sending side, and resend it along with every clock update. Lots of tradeoffs here between latency, reliability, and how much work you want to do to implement it :)

…

On Tue, Jun 25, 2024 at 1:03 PM Erik Roberts ***@***.***> wrote: Correction, I suppose UDP would work for the clock but maybe not for more static information like the score. If latency is a big issue and you can get around the latency we've had in the past, you could split it into two streams, or I suppose rely on Sidearm as a backup for things like score if the packets get lost... — Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXPLYZNPUTPUSCAB5GG3LZJGPGBAVCNFSM6AAAAABJ32SCWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBZGQ3TONRWGI> . You are receiving this because you commented.Message ID: ***@***.***>

[ifrog800]

The remote RS232 reading end would be like a PI that's connected via ethernet to the production network switch in the control room. The "remote" reading is incase the new RS232 connection point from the ECAV TV Room over a CAT cable wouldn't reach the control room. The run is something like 100'.
Adding a remote reader could also help score sync basketball in the future. Depending on where that connection point is located it.

Andrew, you mentioned a long cable could bring capacitance problems.
Which CAT cable would you recommend to try first out of our stock:

• Southwire 56917949
• Belkin A7J304-1000-H
• West Penn D439GY1000

Random information, the new Daktronics system supports an IP connection for data which I do not know much more about.

[asquared]

I'd guess you'd be fine with the Southwire Cat5E you mentioned. You can do some experimentation here: use a length of the cable to connect two USB to serial adapters together (you may need a rollover or null modem adapter to make this work). Any unshielded Cat5E cable should be pretty similar to what you have on the spool. Use PuTTY or screen or tio or your terminal emulator of choice to connect to the ports on each end and see if you can type characters on one end and receive them on the other consistently. I'd suggest trying this with a short cable first, to make sure you have the setup right.

…

On Tue, Jun 25, 2024, 18:55 Edward Chan ***@***.***> wrote: The remote RS232 reading end would be like a PI that's connected via ethernet to the production network switch in the control room. The "remote" reading is incase the new RS232 connection point from the ECAV TV Room over a CAT cable wouldn't reach the control room. The run is something like 100'. Adding a remote reader could also help score sync basketball in the future. Depending on where that connection point is located it. Andrew, you mentioned a long cable could bring capacitance problems. Which CAT cable would you recommend to try first out of our stock: - Southwire 56917949 - Belkin A7J304-1000-H <https://www.belkin.com/cat5e-stranded-bulk-cable/P-R7J304.html> - West Penn D439GY1000 Random information, the new Daktronics system supports an IP connection for data which I do not know much more about. — Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAXPL5KZG3YGCS73BPAGMTZJHYOPAVCNFSM6AAAAABJ32SCWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJQGEZTKMZVHA> . You are receiving this because you commented.Message ID: ***@***.***>

[ifrog800]

The new RS232 serial feed is in the TV Truck format 9600-8-N-1. Has fixed packet sizes and sets the data per commit.