Hardware FAQ

I'm not receiving from another radio, what could be wrong?

This condition most often manifests itself when an ASTi system is communicating with a non-ASTi system. DIS radio connectivity is based on the publication of transmitter pdus, the scanning and examination of those pdus by the receiver objects and the resolution of in-tune and in-range transmitters. The receiver object retains a list of possible in-tune and in- range transmitters for a period of time. If audio, signal pdu, is received that belongs to a known in-tune and in-range transmitter then the receiver object can process the audio without delay.

The DIS standard requires that status pdus are issued periodically on a timeout or movement basis (by default every 5 seconds when stationary, or every 2 seconds when moving, or when the position changes by more than 500m), or on a change of status. However in some DIS radio implementations, the transmitting radio only publishes transmitter pdus when it is actively transmitting audio. This means that the transmitter and signal pdus arrive at the receiver at the same time. The receiver must first resolve if it can hear the transmitter and then process the audio of that transmitter. In the time it takes to resolve the in-tune and in-range issue the beginning portion of the transmitted audio is missed because the signal pdus are not buffered.

A quick side note: I can hear the consternation from here "...the signal pdus are not buffered"! Cries erupt - "why, oh, why not just buffer the signal pdus?" This is where a deeper understanding of the realtime nature of networked radio comms would come into play. Any buffering of pdus introduces latency, and latency translates into delay. A very small quotient of delay can become very noticeable and distracting in a communications situation.

I am sure most people reading this have suffered the transatlantic phone call delay syndrome. You know the one where it takes half a second for your speech to reach the other end and both people end up taking over each other, and not knowing whether one person has stopped talking. Well this is the very same latency that we are striving to avoid introducing. A well executed system should keep latency to less than 120mS for acceptable communications (based on numerous human factors research papers and articles into the issues of communications and delay). An ASTi DACS talking to another ASTi DACS on a LAN network will introduce no more than 70mS delay from microphone to speaker end-to-end.