Sending Tracking Data Wirelessly

overview 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 wi fi 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 requirements 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 workflow 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 datastream options 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 ncamsdk lite this is the preferred method if available, it is designed to be as efficient as possible freed freed offers good compatibility with a majority of renderers 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 rf 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 datastream options 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 remote control 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 case study 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 hardware vislink hcam silvus streamcaster 4400 usb to rs232 converter moxa nport 5100 serial to ethernet adaptor software ncam reality 2022 0 5 ross voyager 4 27 0416 ross lucid 6 4 2487 workflow 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 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 alternatives 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