This page discusses the various methods for operating the Ncam system in a wireless configuration. It does not provide information relating to the wireless transmission of the main camera signal and it is assumed the user has an existing method in place for transmitting the video signal wirelessly

Two distinct methods are covered, Wi-Fi and RF

Sending tracking data over Wi-Fi between the Mk2 server and a renderer is a simple, low cost option for working wirelessly, there are some limitations to be aware of however.

• Mk2 server must be mounted on the camera body
• A strong/robust 5Ghz 802.11ac network
• As little network traffic from competing devices or other SSID's as possible
• A portable wireless access point is recommended but not necessarily required

It is recommended to configure the Mk2 server to connect to an existing Wi-Fi network, as opposed to using the wireless hotspot generated by the Mk2 server itself. The renderer should, where possible have a wired connection to this same network.

In an on set or studio environment, the use of a wired access point on a c-stand or similar is helpful. The renderer can connect via wired ethernet to the access point, which can be positioned close to the camera position. The Mk2 server can then connect wirelessly to the access point. This approach reduces the risk of network interruption/packet loss by easily allowing the access point to be moved around the stage for optimum connectivity.

Ncam Reality has a number of different protocols for sending tracking data, the amount of data each protocol uses can be dramatically different and some lend themselves to wireless operation far more than others. The choice of protocol used is also dependent on what is supported by the renderer, but in terms of suitability for wireless transmission we recommend the protocols in the following order:

1. NcamSDK LITE - This is the preferred method if available, it is designed to be as efficient as possible
2. FreeD - FreeD offers good compatibility with a majority of renderers
3. NcamSDK - This is the least preferred method but can work. If using this method be aware that streaming the Key or main camera image will not be possible

In Outdoor Broadcast (OB) scenarios or when needing to transmit data wirelessly over large distances, using Wi-Fi becomes impractical. In these situations using RF is significantly more reliable.

Pros

• Greater range
• More reliable transmission of data
• Serial or UDP ethernet transmission options available

Cons

• Requires 3rd party RF transmitter/Receivers
• Very limited bandwidth, the RF link can not be used to remote access the Mk2 server, it will only have enough bandwidth to send tracking data
• Not possible to use the full NcamSDK datastream

For critical operation at live events, we recommend using the RF method to ensure successful results. The Case study below outlines a hardware configuration that we have proved as a reliable solution. If using different RF hardware we strongly recommend prior testing to ensure optimum results

When Using RF transmission, it is not possible to use the Full Ncam SDK datastream. Be aware that the renderer receiving the tracking data must be compatible with either the SDK LITE or FreeD tracking protocols.

A single RF link does not have the network bandwidth to send tracking data and allow for the control of the Ncam server via remote desktop software.

If needing to operate the Ncam server then ensure an alternative connection is available, in the example below, a 2nd, separate, RF device was used. However, operating locally to the camera via a Wi-Fi hotspot is also an option.

The following equipment and workflow was used successfully to operate Ncam on a wireless Steadicam at a large OB sporting event recently. This can be considered a tried and tested workflow and provides a known working configuration.

• Vislink HCAM
• Silvus Streamcaster 4400
• USB to RS232 Converter
• Moxa NPort 5100 Serial to ethernet adaptor

• Ncam Reality 2022.0.5
• Ross Voyager 4.27.0416
• Ross Lucid 6.4.2487

The hardware was configured to operate in the following way:

• Ncam Mk2 server Configured to send tracking data via serial and use the NcamSDK LITE datastream.
• USB to RS232 Converter Connected between the Mk2 server and Vislink HCAM device, configured with the following settings - Baud rate 115200, Data Bits 8, Parity None, Stop Bits 1, flow control none.
• SDI signal from camera Connected to Mk2 server and Vislink HCAM device.
• WebUI Control Remote desktop software to control Ncam, connected via network connection using Silvus Streamcaster 4400, connected to ETH1 on Ncam server.
• Moxa Nport 5100 Converts RS232 tracking data to UDP prior to being ingested by the 3D renderer, this may be optional depending on the renderer being used. If the render engine is expecting UDP data to be encapsulated into a single datagram (https://en.wikipedia.org/wiki/Datagram), the Moxa converter should be configured to detect control byte 1 to 0xFF and control byte 2 to 0xFF.

As an alternative to using a 2nd RF link (Silvus Streamcaster) for the WebUI control, an operator could be based in the vicinity of the camera and control Ncam via the Mk2 server wifi hotspot

The FreeD datastream protocol could be used instead of Ncam SDK LITE. This has not been tested in production yet however.