Wireless Sensor Communications Network – IoT Case Study
Given the explosion of Internet-of-Things (IoT) capable products, I wanted to go into more detail on how to add wireless sensors to your new product.
This article describes a simple system, and a communication protocol, that can be used to implement a two-way, low-speed, polled star network. While not suitable for all applications, there is a surprising range of applications where this setup could be used.
For example, temperature and humidity readings typically do not send a large amount of data. Turning on a fan or a heater is another example with similar requirements. Also, they can both tolerate a few hundred milliseconds of latency.
The overall system block diagram is shown below (figure 1). As you can see, the system has one Master and many Nodes. Each Node, in turn, can have many Slaves. The Slaves can be either sensors or actuators.
Sensor Slaves send data back to the Master through its coordinating Node. Actuator Slaves receive data, in the form of commands, to carry out an action such as turning something on.
Figure 1 – Overall system block diagram
How the Master is controlled is application dependent. It can connect to a desktop application through a wired link, or through wireless link such as WiFi, BLE, LoRa, or GSM.
Otherwise, it can be an independent, stand alone platform that is pre-programmed to run a specific application. Figure 2 shows more details about each Node.
The basic blocks of a Node are:
- The microcontroller. Depending on the number of sensors or actuators it interfaces to, and how much data processing is needed, this can be something as simple as a low-end 8-bit microcontroller.
- An Address Select DIP switch, or maybe a dual-row header with shorting jumpers. This sets the address of a given Node. Each Node in the system should have a unique address.
- Sensors and actuators. Again, the types of sensors and actuators, as well as the way to interface with them, will be application specific.
- A two-way RF transceiver module. The choice of RF transceiver is not specifically defined. It will depend on the application and various cost/performance tradeoffs.
For example, a very inexpensive RF transceiver with a range of about 150’ is shown in this link. Here is another one with a range of more than 1000’, but it is also more expensive.
Note that the choice of RF transceivers is not limited to the above examples. You can use many others as long as the microcontroller can successfully interface with them to send and receive data.
Also note that the frequency band at which the RF transceivers communicate should be chosen depending on local regulations. In North America, for example, the 915MHz ISM band or the 2.4GHz band should be considered.
When choosing a suitable RF transceiver, here are some characteristics to look for. These can be either directly implemented by the RF transceiver itself or by the FW driver running in the microcontroller that interfaces with the RF transceiver:
- It should be able to send and receive data bytes.
- It should be able to encode and decode the data according to whatever modulation scheme it is using.
- Data should be sent and received in the order it was sent and received, i.e. there should be no out of order bytes.
- Data should be received with no errors. That is, error detection and correction should be part of the transceiver operation, or implemented in the transceiver FW driver.
Figure 2 – Generic Node block diagram
In operation, the Master will poll each Node at suitable intervals. Data destined for the Node being polled is embedded in each polling frame. The frequency, as well as the sequence at which each Node is polled, is totally dependent on the Master, and is only limited to the RF link setup times and data transmission speed.
Also, as shown, there is no fixed limit to the number of Nodes in the system. As long as the polling latency is acceptable, as many Nodes as required can be added to the system.
AirLink Communication Protocol
The structure of the Master to Node frame, named AirLink here, is shown below in table 1. Each frame consists of multiple fields, and the structure of the frame is the same whether it is sent from Master to Node, or the other way around.
This simplifies things quite a bit, and also means that the same set of functions, or library, can be used in both the Master and Node application code. Table 2 gives a brief description of each field.
First note that a CRC (Cyclic Redundancy Check) is not included since the RF transceiver, or its driver, ensures that only validated transmissions are received, and presented, to the Master or Node processor. If needed, an additional CRC field can be added to the frame.
Note also that some fields are not relevant to the Master to Node transmissions. They are still to be included to make the AirLink protocol consistent both ways.
For example, the STAT field can be any random number for Master to Node transmissions: the Node simply ignores this field. The responding Node, on the other hand, sets the STAT field in its reply frame to the Master to indicate the status of the command execution requested by the Master.
Another one is the D_SUBADDR field. It is only relevant for Master to Node frames. For Node to Master frames, it can be anything; the Master simply ignores this field.
|Size (bytes)||2||1||1||1||1||1||1||Variable (< 255)|
Table 1 – Structure of the AirLink communication protocol
|SEQ_Number||The sequence number of this frame to this Node|
|D_ADDR||Address of the destination|
|D_SUBADDR||Address of the Slave of the destination Node.|
|STAT||Command execution status. Only relevant in Node to Master frames.|
|S_ADDR||Sender’s address. Only relevant in N to M frames.|
|LEN||Size of the data field, including 0.|
|DATA||Data payload. May be absent if LEN is 0.|
Table 2 – Description of each field in the AirLink frame
As stated previously, this is a polled network and the Master always initiates a poll to a selected Node. It then sets up a timeout for the Node response.
If the Node does not respond within this timeout period, then it can be assumed that either the Node is not working anymore, or it is out of RF range.
Continuing with the frame, the SEQ_Number is a sequence number that the Master keeps a separate copy for each Node in the system.
Each Node also keeps a copy of the SEQ_Number of the last frame addressed to it. That way, a Node can tell if it missed any commands as there will be a mismatch between what it expects as the next SEQ_Number, and what the Master actually sent.
When SEQ_Number has reached the top end, it simply rolls over. It is shown as being two bytes in size, but this can be changed as required.
The SEQ_Number can also be used to provide some degree of encryption of the data if this is not already done at the RF transceiver level. The idea is to send the SEQ_Number unencrypted, but to use it to encrypt the rest of the frame.
The encryption key can be algorithmically derived from the SEQ_Number, and the actual encryption process can be anything from simply XORing, to shifting and XORing, as well as other options. This process is not defined in this protocol. Of course, increasing the size of SEQ_Number will provide more encryption keys.
Also, with regard to encryption, the SEQ_Number also protects against replay attacks. Simply capturing and replaying a frame with valid data encryption is not going to work, since the receiving end will know this SEQ_Number has already been used, and will not act on a stale SEQ_Number.
Finally, it is up to the application to decide what happens if a Node misses a SEQ_Number. This may happen, for example, due to the Node being out of RF range, or maybe because there was some kind of interference. If the Node has only actuators, then it can simply take itself out permanently since it will then be out of sync with the Master.
If the Node has only sensors, you could decide that missing a few sensor readings is still OK. In this case, the Node can then accept SEQ_Numbers that are ahead of its own count by, say, ten or twenty, and re-align its count then.
The D_ADDR is the destination address. The Master’s D_ADDR is always 0. Node addresses start from 1. Only the addressed Node will respond, and, of course, it will set the D_ADDR to 0 when responding so that only the Master will process the reply.
STAT is the status byte for Node to Master frames. The actual interpretation of this byte is not specifically defined here. For example, the Node might define a code of 0 for reporting that everything is fine.
Additionally, it can further define various codes for sensor not responding, or for sensor reading out of range. If the T Node can monitor the action of an actuator, and even reply back to that actuator, such as when a light bulb isn’t working.
The D_SUBADDR is the slave of the Node. When a Node replies back to the Master, this byte is ignored and can be set to any value.
For each Node, it is assumed that the Master knows beforehand what kinds of slaves are connected to a given Node. Otherwise, the Node can reply back with a code that says the slave is simply not present for this Node.
The CMD byte is the command byte. The exact meaning of each command is undefined in this protocol; it is application-specific. For example, there can be pre-defined commands to turn ON or OFF something, or command codes to read different attributes of a sensor given by its SUB_ADDR such as its temperature, humidity or pressure.
The LEN is the actual length of the data field. If there is no data, then LEN is set to zero, and there are no further fields in the frame.
The DATA field is the actual data size in bytes defined by LEN. The actual interpretation of the bytes in the DATA field is again implementation-dependent.
AirLInk Protocol – Features and Limitations
As described, the AirLInk protocol provides a flexible way to network many sensors and actuators in a star network over a wireless link. Several aspects of the protocol are purposely left undefined. These are left to the application to provide meaningful implementations.
Error reporting duties are distributed between the Master and the Node. The Master can detect if a Node is not responding by timing out for a response. The Node, in turn, can report if any of its sensors or actuators are not working.
The main limitations of this protocol are:
- Since this is a star network, the Master and Nodes have to be within RF range of each other. Unlike a mesh network, there are no redundant paths between the Master and any Node. This may not be an issue since there are some inexpensive RF transceivers with reasonably long ranges.
- It is not a high speed network. Depending on the total number of Nodes in the system, the latency may be quite high.
- It is not low-power. The Master has to be regularly transmitting, and each Node has to be in receive mode all the time to determine if they are being addressed or not.
For example, assuming a transmission speed of 9600 Baud and an average of sixteen bytes per frame, then the time to send a frame is about 14 ms. If the Node turnaround reply time is neglected, it will also take 14ms to reply back with a sixteen-byte reply.
So, addressing just a single node will take 28ms. Leaving a guard band of 2 ms between polling each node, this rounds off to 30ms per Node.
If there are, say, ten Nodes in the system, and assuming that they are polled continuously, then the fastest update time for each Node is 300 ms. Of course, the larger the number of Nodes the longer the latency time, if all Nodes are to be regularly polled.
In this article we’ve looked at a simple communications system that can be used to implement a two-way, low-speed network.
While likely not sufficient for more complex applications, for many applications with low data rate requirements this can be a viable solution.
Written by Shawn Litingtun who is just one of the many experts available to help you develop your new product inside the Hardware Academy. If you need development support, coaching, training, and connections to help develop your new electronic hardware product and get it to market then be sure to check out the Hardware Academy.