By Myk Dormer, Senior RF Design Engineer
First Published in 'Electronics World' Magazine
Radio modules aren’t as simple as they used to be. Ten years ago, virtually all ‘low power wireless devices’ had the same, very limited, user interface. A clipper (and some simple baseband filtering) on the modulation input, and a squaring circuit for the demodulator output. Beyond that it was up to the user to supply pretty much all of the necessary bit, byte and frame coding and decoding, as well as buffering and providing correctly timed control signals to turn the transmitter circuits on and off.
Matters have developed somewhat. Now, many modules (and even a few chips) incorporate some form of local ‘intelligence’ to make the user’s job a bit easier. This varies from simple bit-level coder/decoder functions, right up to complete modem or networking support, while the awkward interface of the past is now more usually a serial port (of some kind: RS232 or SPI are common, USB or Ethernet are becoming more so).
But now, when you’re attaching a radio module to your target design, you aren’t always sure of what you’re dealing with. Every manufacturer claims their designs are simple to use, seamless in operation and have functions that will satisfy every imaginable contingency … but very, very rarely is this true.
Considering the three interface types mentioned above, we can immediately discount the SPI type (modules with this interface invariably require the user to program and control their RF circuitry, which is far more awkward than just handling a baseband link) and the USB/Ethernet units (because these can communicate only with high level applications running on a powerful host cpu: more in the arena of wireless LANs, which is outside the usual applications area for simple low power radio devices ).
Which leaves ‘serial port’ devices.
These units are intended to allow the user to use existing familiar asynchronous serial interface techniques (RS232, or rather, a simpler, logic level implementation thereof), allowing the radio link to connect to a microprocessor UART or a pc serial port. In an ideal world, such a device would exactly replace a serial cable, providing identical communication over the wireless link as over the wire.
This is not an ideal world. Before happily surging ahead and using a wireless module that claims to offer a ‘cable replacement’ link there are a few very important details to consider. Remember that all ‘intelligent’ wireless modules put a degree of processing in the way of your data stream, and that this processing has limitations:
The link will be set to operate at a fixed baud rate. You will either need to select a unit with the correct rate to start with, or be prepared to re-program the module yourself. Very few units allow non-standard baud rates, or deviation from the industry standard “1 start bit/8 data/1 stop bit ” asynchronous format.
Not every module is capable of supporting a continuous stream of data. Some simple units have limited (one packet’s worth) size buffers which, once filled, will accept no more data until the data has been processed and transmitted. Sometimes, an end of file character, or a separate ‘transmit now’ strobe signal, are needed.
Even relatively sophisticated units will allow the user interface to be set to a speed much higher than the actual ‘over the RF path’ data-rate. Either the average throughput must be limited to the unit’s basic transmission speed (while also ensuring that the buffers don’t overflow), or a flow control protocol (using a CTS connection, or an X on/X off method) must be implemented.
There is often a considerable latency involved in receiving a byte, formatting it into a packet, powering up the transmitter circuits, sending the packet, decoding it, buffering it and finally outputting the byte at the receiver. For a complex, narrow-band radio modem this latency can easily reach 50-100 milliseconds, while even simple wide-band ‘intelligent modules’ rarely better 10-20mS.
If your system architecture involves bidirectional transfer of data, then this link latency or ‘communications delay’ needs to be designed into all your response time estimates and timeouts.
Many data communication modules are transceivers. These units offer half-duplex operation. Almost none (with the exception of one or two very sophisticated radio modems) are actually full duplex.
They cannot transmit and receive data simultaneously, and there is always a transmitter turn-on (or off) time to consider, along with the communication delays mentioned above.
Despite the fact we all try to ignore the fact, RF links are not perfect media, and are subject to all kinds of interference or range related failure modes. Rather than causing bit errors (as would be seen over the baseband path), these more sophisticated modules incorporate error checking (and in some cases, limited correction), and will lose entire packets of data, rather than corrupting individual bytes.
Some units can implement acknowledge/re-transmit operation to prevent data loss, but of course this then impacts the transmission throughput, and results in an indeterminate communication delay under poor link conditions.
The upshot of these considerations is: