OSC Inconsistently Fires - From ION to OSCRouter to QLab(s)

Hey all,

 

I'm having a issue where OSC works inconsistently. From time to time, OSCRouter doesn't get the string it's looking for (the crucial "eos/out/event/cue/xx/yy). The best we've been able to reproduce this is by waiting longer than 5 minutes before firing the next light cues, causing the next OSC lined cue to not fire (lights fire, but Q Lab doesn't fire). Even this is not consistent.

I've attached a log file from OSCRouter, and scroll all the way to the bottom. The time code 21:15:54 is where OSCRouter failed to receive cue 7 in this case

Cue 7 didn't fire.txt

 A bit about our system. We're a small performing arts center, and this is in our main theatre.

The OSC Signal path is;

ION -> Q Lab Audio Computer - > Q Lab Video Computer

I'm using OSCRouter on both Macs, running Sierra and Q Lab 3.2.9, as OSC Translation. I've attached Screen shots of both OSC router setups.

All of these devices are on a stand-alone network dubbed "ShowNet." It is managed by a Luxul XWR1750 gigabyte wireless Router, but all the lines are cat5e with a 16 port gigabyte network switch. The wireless is for our iPad only.

ShowNet has all of our show related computers, lighting gear (Console, DMX nodes, & Dimmer Racks), Network Switches and 5 Projectors. Its about +25 devices on the network.

 

My working theory is that we have too many devices on ShowNet, and it is causing issues with UDP transmission. I would hate for this theory to be true, since it's fantastic to have all our devices on ShowNet.

Thank you all for any help or ideas you may have.



Fixed Formatting
[edited by: dorfman2 at 3:55 PM (GMT -5) on Fri, Jul 14 2017]
Parents
  • After a bunch of troubleshooting, I've come to the conclusion I was having UDP transmission loss. The string OSC Router was looking for was "eos/out/event/cue/xx/yy," and this would not always be received by OSC Router. As far as I know the Ion does not support TCP OSC transmission, which would allow us to use a TCP server approach to have error checking to our two Q-Lab Machines. Our work flow at our venue is not served by having Q-Lab as the MASTER, which would allow us to use OSC Router as a TCP server with the ION being RX TCP capable.

    It seems with either v2.3 or v2.4 of the Eos Family upgrade you can add output strings and utilize the {*} and {%1} variables. Using this feature seems to have guaranteed the output of a predictable string on every "GO." Here are my settings;

    /cue/%1/start

     

    I've used this feature for several shows now, and it seems to have stabilized OSC. I still use OSC Router as an OSC Repeater given our multiple Q Lab Machines, but If you're only using a single Q Lab machine you shouldn't need OSC Router at all.

     

    Hope this helps anyone with a similar problem!

  • Eos family does do OSC TCP. TCP port 3032 is the port for EOS TCP based OSC. There are settings in OSCRouter for TCP as well.
  • The literature on the Eos family I've read imply that this was for TX out of the Eos only. However as I write this down, and TCP being two way in nature, that logic of mine seems flawed. Thank you for pointing this out, I shall experiment further. When setting this up, do I use port 3032 for both transmit and recieve?

    Best,

    -Jeff
  • Jeff,

    TCP does not need port settings in the Eos software. It is setup in the shell and is either OSC 1.0 or 1.1 which changes the encoding of the messages but not the port settings. TCP does not use multiple ports just the one. The port settings in the eos show control section are for UDP only.
  • Andrew,

    Thanks for clarifying. I'm traveling until after the holidays, but will be sure to implement thesis changes to TCP. It was this portion that confused me in the "Eos Family Show Control User Manual."

    From page 47

    TCP

    The preferred method for transmitting and receiving OSC packets is over a TCP connection. Eos will listen for incoming TCP connections on Port 3032. TCP communication still requires that {String RX} and {String TX} is enabled in the Show Control section of Setup.

    In the ECU>Settings>Network>Interface Protocols, there is an option for changing the OSC TCP mode. By default, OSC 1.0 is selected. There are two TCP modes available – OSC 1.0 (packet-length headers) and OSC 1.1 (SLIP). Check the documentation for the OSC device you wish to use over a TCP connection to see which mode it supports.

     

    It was the line "Eos will listen for incoming TCP connections on Port 3032," that threw me, because it doesn't list what port number is used for transmitting. Feeling foolish now, but at the time I took this to mean the EOS wasn't capable of transmitting TCP. I wish the line read "Eos will listen for incoming and transmit TCP connections on Port 3032."

    Thank you for taking the extra time to explain this - lesson learned.

    -Jeff

  • Eos acts only as a Server for TCP connections.

    You can't establish a TCP connection from Eos, acting as a Client, meaning that Eos only listens and responds on the same port that a connection made to it. Transmit would infer a connection could be established via Eos.
  • Sam,

    Thanks for responding. It may be still UDP, but for some reason the system has been much more stable using port 3032 to TX from the Eos. It has also been RX on 3032, from Q Lab via OSCRouter. I'll post my screenshot of OSCRouter later today.

    I know this must feel like to you I'm coming at this a$$-backwards as I learn about different connections in the transport layer. However, learning more about networking has be a interesting and enlightening experience as I try to read and understand what's going on. Thank you for your patience.

    -Jeff
  • I have another blog post coming out in the next week or two regarding UDP and TCP. Keep an eye out on the ETC Blog (https://blog.etcconnect.com/)
Reply Children
Related