Skip to main content

Catching a Bus: Basic Serial Communication Part 6, Wireless

Click_Remote_10_3593447d1ce279e8eff38ece59b8a18adcca53e6.jpgUnderside view of the remote-control unit showing the nRF T Click wireless transceiver module.

After five articles covering the protocols and practical implementations of wired serial bus systems: UART, SPI and I2C, I’m finishing up with a serial wireless (radio) link for my remote-control mobile robot.

Cable and Wireless

All three digital serial communication protocols described thus far in this series share one thing in common: they were designed to work over short cables (or PCB tracks) up to a maximum of a few centimetres in length (SPI, I2C) or a few metres for UART/RS-232. Before the arrival of the ‘Internet of Things’ these relatively simple cable links sufficed for most applications. Wireless communication has been around on the domestic scene for a long time though, in the form of key-fob operated car door locking and motorized garage door opening. The hardware required for these applications was, and still is in many cases, very simple because communication is one-way over a short range at low speed. High speed is not needed because the data largely consists of single code word sent over and over again for as long as a button is held down. In fact, chips designed for this sort of basic application are frequently referred to as Cable Replacement devices as they lack on-board processors implementing complex wireless protocols such as Bluetooth or Wi-Fi.

Nowadays, literally every electronic gadget needs to be in constant communication with the Internet (for some reason) and so hardware has progressed from the humble and non-intelligent transceiver to the sophisticated System-on-Chip (SoC) wireless devices we have today. Back in 2015, I wrote a series of DesignSpark articles on RF Communication and the Internet of Things, intending to take some of the mystery out of designing Radio Frequency (RF) links for IoT applications. Most of the information is still current, but since then even more powerful products have appeared on the market.

Clocks and Timing

If you’ve read the previous articles in this series, it should be obvious that a critical task in any serial communications system is ensuring that data ‘clocked out’ of one end is correctly ‘clocked in’ at the other. SPI and I2C solve the problem by having the sending end supply a clock signal to the receiver along a separate wire. This is great for short links but impractical and expensive over long distances. The early telegraphic systems described in Part 1 used extra ‘redundant’ bits added to each character code sent out. This provided a simple, but not very efficient form of synchronisation at the receiver only possible because of the very slow data rates in use. It did the job though until computer networks arrived requiring megabytes of data to be sent in seconds over long-distance radio communication channels. A whole new approach to clock signal recovery from the data signal itself was required.

Design considerations

Getting back to my robot project, what hardware/protocol would be best from the vast range available covering everything from simple cable replacement to very high speed or long-range (as in miles) applications? Here is a list of my requirements for this project:

  • Uni-directional initially, but with the capability of being made bi-directional later for robot status feedback to the operator.
  • Two bytes of data to be sent regularly at relatively long intervals in the order of milliseconds: each byte representing the position of the left or right joysticks.
  • Error detection system built-in so that a corrupted two-byte data ‘packet’ is automatically ignored and not passed on to the robot controller.
  • Loss-of-signal should bring the robot to an immediate halt.
  • Operating range only needs to be about 5 metres, so RF power output can be low. Even so, given that both transmitter and receiver will be running off battery power, a means for turning off the RF signal when not actually sending data would be advantageous.
  • Finally, the wireless device must be available on one of the MikroElektronika ‘Click’ peripheral modules.


After perusing the extensive range of Click wireless modules I settled upon the nRF T  (136-0698) which features the nRF24L01P  (885-5748) device from Nordic Semiconductor. The T signifies a PCB antenna which is perfectly adequate for this situation.

Packets, Preambles and Unique Words


Recovering a data clock from the data signal itself is not easy: a sort of chicken-and-egg situation. The data must be known in order to deduce the clock signal, but the data can’t be known without an accurate clock signal. Fortunately, this apparent paradox can be resolved by adding special synchronising bits to the front of the message data (Fig.1). Notice that of the 72 bits that make up a complete message packet, only 16 are payload!


The flow chart of Fig.2 does not describe any firmware that needs to be run by the controlling MCU. It roughly illustrates the automatic operation of the receiver circuits in the wireless chip. All this packet detection, data capture and error checking is entirely transparent to the user.

The first 8 bits consisting of alternating 0’s and 1’s form the Preamble, which signals the start of a packet. This sequence is also used to synchronise the receiver bit clock.

The next 40 bits make up the transmitter address which, although not required here, enables a receiver to take data from up to six transmitters via internal digital channels called ‘Pipes’. In my single-channel application it merely acts as a ‘Unique Word’ confirming that a packet is being received correctly and that the payload data follows immediately afterwards.

Next, come the two bytes of actual data containing numbers in the range from 0 to 63: 0 representing servomotor full-speed ahead, 63 full-speed reverse and 31 bringing it to a stop. The nRF24L01P chip can be programmed for up to 32 payload bytes if required.

Bringing up the rear comes the Cyclic Redundancy Check (CRC) byte. This is generated by an algorithm from the address and payload data. At the receiving end, address, payload and the appended CRC byte are put through the same algorithm. Any result other than zero indicates an error during transmission and the packet is abandoned without setting the Data Ready flag. The system then returns to waiting for the next packet to arrive. If the CRC check result is zero, the RX_DR flag in the chip’s STATUS register is set allowing the MCU program to proceed with downloading the two bytes of joystick position data.

A glance at the datasheet for this wireless chip reveals that it’s capable of rather more than just detecting and ignoring faulty packets. If the Enhanced ShockBurst features are enabled, then a new packet is only sent after the transmitter receives an acknowledgement from the receiver that the previous one arrived error-free. A failure will trigger a re-send of the packet. There’s no need for such sophistication here: it really comes into its own when sending large blocks of data. In that instance, a damaged packet cannot just be ignored. Each packet in my simple remote-control application is independent of the others and if one or two get lost, the effect won’t be noticed.

Losing control

Wireless communication can have a reliability problem, as anyone who has ‘upgraded’ an Ethernet-based cable LAN to WiFi will testify: especially where the signal is required to pass through thick walls. For fixed installations, I would always stick to cable. In a mobile situation such as my wheeled robot with a battery-portable remote-control, wireless is the only choice. An essential safety feature of any radio-control system is the ability of the robot to detect that it has lost communication with its controller and it’s on its own. In other words, some sort of autonomous behaviour must take over. The wireless chip does have a built-in carrier-loss detect function, but it relies on the carrier signal being continuously emitted by the transmitter. As I’m using the ShockBurst power-saving mode here, the carrier is only switched on for the duration of a message packet, so this carrier-loss feature won’t work.

Instead, it’s handled by the MCU program using a software ‘watchdog’ timer that times-out when no packets have been received for a long interval. Not much autonomy has been implemented – it just stops the motors until the signal appears again. Still, at least it won’t run amok. Of course, a drone would require a rather more elaborate recovery procedure! The updated robot control source code is available for download below.


I hope this series on serial communication has offered some insights and dispelled a few myths. I have not covered Bluetooth, WiFi, USB and a whole host of other ‘heavy-duty’ protocols simply because tinkering around with them at machine-level is of little value when most System-on-Chips have all the necessary firmware (or ‘stacks’) built-in. At the same time, don’t automatically go for the fastest, most powerful solution just because all the work has been done for you. Sometimes, ‘cable-replacement’ may be just what the application needs, involving lower cost and less development time.

If you're stuck for something to do, follow my posts on Twitter. I link to interesting articles on new electronics and related technologies, retweeting posts I spot about robots, space exploration and other issues.

Engineer, PhD, lecturer, freelance technical writer, blogger & tweeter interested in robots, AI, planetary explorers and all things electronic. STEM ambassador. Designed, built and programmed my first microcomputer in 1976. Still learning, still building, still coding today.
DesignSpark Electrical Logolinkedin