By Myk Dormer - Senior RF design engineer, Radiometrix
We engineers are simple creatures, and like to work in a world of absolutes. When a signal is applied to one end of a cable, it appears at the other. When a datastream is transmitted from one device, we anticipate that it will be received exactly as sent. Any deviation from this, and we look for faults, for software errors and faulty connections. But most of all, we consider these to be exceptions from the normal.
Radio links aren’t like that. When planning to use a wireless data link, the engineer must accept that a certain incidence of data error is unavoidable. For usable links this can vary from a few ppm, to a few percent. But it is never zero:
A radio path is: Noisy. As signal strength falls away with increasing range the signal to noise
ratio of the baseband path falls (and so the error rate of the digital stream rises) Subject to interference. RF energy from interfering sources (from other radio systems, and from the natural environment) can swamp the wanted signal, causing single errors, or whole bursts.
Unpredictable. Even when well ‘in range’ the signal strength can fall radically (by 20dB or more) due to fading. (Nulling of the wanted, direct path signal by out-of-phase echoes reflected from obstructions, geographical features, and even moving vehicles)
At this point it must seem like I’m implying that wireless links aren’t usable at all (and most ISM band module manufacturers will gloss over what I’m describing, and do frequently make some sort of ‘seamless cable replacement’ claim for their products) but I’m not. What it is important to realise is that, while data errors are not frequent in a properly designed link operating within it’s specified range, they will occur, and the design of the overall application must take this into account.
How to deal with data errors depends greatly on the amount of data being transmitted, and most importantly, what it is being used for. Techniques include:
1.Ignore the error: In applications using ‘feedback-via-operator’ (the user is observing the controlled device, and continues to activate the control until the desired occurrence) then a lost wireless instruction burst is at worst a mild annoyance.
Typical examples include remote controls and remote actuators, wireless keys and similar functions. In such cases, although no overt error correction is implemented, error detection is still important, as spurious operation of the controlled function is usually unacceptable (either during transmission of a command, or during idle). Sufficient burst identification data (‘framing’, ‘synchronising’ or ‘addressing’ words, combined with error detecting checksums, CRC or parity schemes) needs to be sent in addition to the actual command data, to allow a decoder to reliably discriminate between random noise in the absence of signal (or in the presence of interference) and the wanted command burst.
In extreme cases, a fail safe approach can be taken, where the cessation of reception of the datastream (after a given time-out period) is taken to indicate the alarm condition.
A significant sub-class of this approach is the provision of forward error correction, where a relatively small amount of extra data is added to the message, which allows a suitably sophisticated decoding algorithm to correct for the effects of a limited number of bit errors. These ‘FEC’ techniques have attracted a huge amount of effort in recent years, and are now found in the Reed-Solomon coding schemes in CD recordings, and in the Viterbi algorithms used in cellular telephony.
This powerful technique is frequently used in high-end radio- modems, and is a feature of file-transfer software (such as Z- modem). Where the data must be received entirely intact and error free (such as when data logger files are downloaded, or
computer binary files are transferred) then this is a preferred
It is not problem-free, however, as it requires a bi-directional (transceive) link, combined with good error detection algorithms and, in the event of significant errors in the radio path, can deliver a very low overall data rate and require large data buffers at the transmitter.
There is no absolute ‘correct’ approach. Even the best error handling technique will fail when the radio environment is compromised (such as during electrical storms), or when the path loss is too high (= out of range).
It is up to the engineer to understand the imperfect nature of the wireless link, and design around it. Good luck!