Loading

Beacon sync broadcast and interference

Starting from Firmware 722, a Beacon broadcasts a synchronization signal on the chosen radio channel at a fixed rate of 25 Hz. Pulsars use this signal to lock to the Vicon system frame rate, and turn on marker LEDs only when the camera shutters are open, increasing battery life.

The sync signal is also used to time communications: Pulsars may only send data to a Beacon in a defined period relative to the sync signal, to avoid interfering with it. The Beacon-Pulsar communication protocol also uses a Carrier-Sense Multiple Access (CSMA) scheme to avoid interference between Pulsar transmissions. Before sending data to a Beacon, a Pulsar tries to detect any other Pulsar already sending data on the current radio channel. If another transmission is in progress, it waits for a randomized interval before attempting to send again. If no other transmission is detected, it begins sending data.

Important
The Beacon radio channels are in the 2.4 GHz ISM band. Using other radio transmitters on the same frequency causes disruption of Beacon/Pulsar operation. Note in particular that Bluetooth® and many Wi-Fi devices operate in the 2.4 GHz ISM band. To prevent interference with the Beacon, where possible, switch Wi-Fi devices to the 5 GHz ISM band.

In Evoke, you can use the Radio Channels dialog box to find an unused radio channel with minimal interference.

To open the Radio Channels dialog box:

On the System tab, right-click the Beacon and select Radio Channels.

Other general guidance for Beacon installation:

Place the Beacon as close to the middle of the volume as possible to minimize the transmission distance.
Place the Beacon high up, to minimize reflections from the ground and masking of the RF signal by participants.
Do not place RF-blocking materials between the Beacon and Pulsars.
Do not re-use a channel number within a site or a co-located group of sites.
Do not place multiple Beacons closer together than four meters.
Do not use more than two consecutive channels within a site or adjacent sites.
If channel n and channel n+2 are used in a site, do not use channel n+4 in that site or adjacent sites.
If using multiple channels, try to use widely separated channels.

Beacon allow list

By default, a Beacon accepts any pair or connect requests it receives from Pulsars. If you are using multiple Beacons on the same or adjacent installations, it may be beneficial to enable the Beacon Allow List to control Pulsar pairing.

To access the allow list:

Open the Radio Pairing dialog box by right-clicking on the Beacon on the System tab and then clicking Radio Pairing.
To specify which pairing requests are accepted, in the Radio Host section at the top of the dialog box, select Allow List Enabled for the required Beacon.
When the allow list is enabled, only Pulsars on the allow list can pair or connect. Other Pulsars are displayed only as requests in the Radio Pairing dialog box.

Pulsar pairing

An unpaired Pulsar scans radio channels until it finds a Beacon sync signal that indicates that it is in pairing mode. After a randomized delay (currently 1–16 seconds), the Pulsar attempts to send a pair request to the Beacon. If rejected, the Pulsar continues scanning until another channel with a pairing Beacon sync signal is found. It does not attempt to request pairing again to the same Beacon, until the Beacon indicates that its allow list has changed.

If the request is accepted, the Pulsar stores the Beacon Radio Host ID and PAN ID on its file system. After it is paired, the Pulsar always attempts to connect to the same Beacon. To pair to another Beacon, you must unpair it (via Evoke or button press) or transfer it (via the Radio Pairing dialog box or via the Pulsar Reprogramming Tool).

Pulsar connection and disconnection

A disconnected Pulsar scans radio channels until it find the Beacon sync signal with the radio host ID to which it is paired. After a randomized delay (currently 1–16 seconds), the Pulsar attempts to send a connect request to the Beacon.

When the Beacon receives a connect request, it first checks whether the Pulsar is on its allow list (if the allow list is enabled). If connection is allowed, it starts a short handshake process to establish communications with the Pulsar. When this process is complete, the Pulsar is displayed in Evoke as a connected device.

If the Pulsar is not on the Beacon allow list, it is displayed in the Radio Pairing dialog box as a connect request only.

A connected Pulsar sends 'heartbeat' packets to the Beacon with a randomized interval (currently 3–5 s). These packets include battery and other status information, and if the Beacon does not receive a heartbeat or command response packet from a Pulsar in a defined period (currently 30 s) it assumes the Pulsar is powered off or unresponsive and disconnects it. If the Pulsar subsequently attempts to resume communication, it must complete the connection handshake process again.

Evoke sends all the current Pulsar settings on connection, ensuring that the hardware is kept in sync with the settings in Evoke.

Pulsar commands

All commands are sent from the Beacon in serial (one at a time). However, if multiple commands are queued to a single device, those command packets are coalesced into a single larger packet, reducing transmission packaging overhead. Commands are guaranteed to be sent to each Pulsar in first-in first-out (FIFO) order.

The time taken to send a command to all the Pulsars is directly proportional to the number connected to the Beacon, so it is important to balance the number of Pulsars paired to each Beacon. Take care also to avoid pairing too many Pulsars to the same Beacon. A maximum of 80 Pulsars per Beacon is a good rule of thumb.

While commands are queued to a Pulsar or a command is awaiting a response, Evoke displays an 'updating' icon on the Pulsar in the System tab, to indicate it hasn't yet received all the latest settings.

If the Beacon does not receive a response to a command, it re-sends the command a number of times. If no response is received, it assumes the Pulsar is powered off or unresponsive and disconnects it. If the Pulsar subsequently attempts to resume communication, it must go through the connection handshake process again.

Browser not supported