Skip to main content
Electronic Theatre Controls Inc

Guide to remote operation of EOS via WAN

Preamble

This guide aims to highlight the various options for remote operation of an EOS console via a WAN (for example the internet).
Pros, cons, and design considerations will be outlined.

The best option for the environment will be based upon time, cost, and requirements. The final design should be evaluated for suitability before final deployment and ETC technical services are always available for advice.

 

Overview of methods

Method Pros Cons
Native multiconsole
  • Very high level of programming/operating interface
  • 100% EOS experience
  • Requires no extra 3rd party hardware
  • Requires high bandwidth, low latency, high QoS; connection
  • Suffers poorly with network dropout and jitter
  • Requires at least two consoles
  • Security dependent on external encapsulation methods 
KVM over IP
  • Medium to high level of programming/operating interface
  • Simple to implement secure connection
  • Requires medium to high bandwidth, medium latency connection
  • Requires extra 3rd party hardware
Remote Desktop
  • Medium to high level of programming/operating interface
  • Simple to implement secure connection
  • Variable level of hardware support
  • Requires extra 3rd party hardware
OSC
  • Low bandwidth requirements
  • Medium to high level of customisable operating interface
  • Low level of programming interface
  • Requires onsite personnel to change showfiles
  • Security dependent on external encapsulation methods 
 

Details of methods


Native multiconsole

Details

The best and fullest user experience can be obtained by using the native multiconsole features of EOS.

The remote site would operate an EOS in primary mode, with a local fully synchronised client.

 

Flowchart Placeholder

Network requirements

EOS multi-console operation was designed for Ethernet operation, and as such expects high bandwidth, low latency, minimal packet loss.

Discovery is based upon SLP (RFC 2608), and synchronisation via ACN (ANSI E1.17); these are mutlicast protocols so a single broadcast domain/layer 2 link is required.

To save bandwidth, DMX over ethernet protocols (sACN, ArtNet, et cetera) should be prevented from traversing the WAN

Minimum bandwidth

Variable - Show complexity dependent
Typically: 1.5 Mbps  

Maximum latency

Variable - Show complexity dependent
Ideal: <30 ms 
Typically: <50 ms

QoS DSCP CS4

 

Hardware requirements

  • At least two EOS Consoles
  • (Optional) External VPN encapsulation hardware

Security

EOS multi-console operation is based upon ANSI E1.17 (ACN) which offers no native network security options.
Untrusted networks should employ external tunneling hardware, for example L2TP/IPsec

Flowchart Placeholder

KVM over IP

Details

There are many commercial KVM over IP (Keyboard, Video, Mouse) devices available on the market. 

A KVM over IP would connect remote monitors and USB devices (for example an EOS programming wing) to the EOS via IP
To ensure only a single facepanel is detected by the console, the use of an EOS RPU would be required when using an EOS Programming wing

Care should be taken to ensure the KVM maintains the USB connection when switched. Rapid connection/disconnection of lesser spec'd KVM will cause issues with interfacing hardware.

Flowchart Placeholder

 

Network requirements

Minimum bandwidth Consult KVM supplier
Maximum latency Consult KVM supplier
QoS DSCP Consult KVM supplier

Hardware requirements

  • EOS RPU
  • 2x KVM over IP Gateways
  • Monitor
  • EOS Programming Wing

Security

Many KVM over IP devices offer built in security options, the level of required security should be specified at procurement stage.


Remote Desktop

Details

The EOS console would be connected via Multiconsole1 to a local PC, this PC would be running a remote desktop server.
The local PC, running the remote desktop client, would have a local control surface (for example EOS Programming Wing).

There are many remote desktop solutions available to suit different budget and environmental requirements.
It is recommend that the solution includes support for USB pass through. 

1Some remote desktop solutions will disable the EOS dongle required for client mode. Please check compatibility 

Flowchart Placeholder

Network requirements

Minimum bandwidth

Variable - Consult remote desktop supplier
Depending on video size/refresh requirements: 1.5 Mbps - 15 Mbps

Maximum latency

Variable - Consult remote desktop supplier
Typically: <100 ms

QoS DSCP Consult remote desktop supplier

Hardware requirements

  • EOS Console
  • 2x PC with remote desktop software
  • EOS Dongle for "remote PC"
  • EOS Programming Wing

Security

Most remote desktop solutions offer built in security options.
This can be supplemented with VPN software on the PC or VPN gateways.


OSC

Details

Most of the EOS functionality can be access by Open Sound Control (OSC).
An application specified control surface can be created 

There are many OSC controllers available in both dedicated hardware, or in software. A popular example would be TouchOSC (https://hexler.net/products/touchosc)

Flowchart Placeholder

Network requirements

Minimum bandwidth Very Low
Typically: <512 Kbps
Maximum latency Typically: <100 ms
QoS DSCP CS3

Hardware requirements

  • EOS Console
  • OSC Controller 
  • (Optional) External VPN encapsulation hardware

Security

OSC offers no native network security options.

Untrusted networks should employ external tunneling hardware, for example L2TP/IPsec

Flowchart Placeholder

  • Was this article helpful?