OwlCircuits
Personal Weather Station
A weather station based on the Raspberry Pi
3. Introduction to XBee and wireless links
The weather station will need a wireless link to allow us to transfer data from the outside sensors to the indoor base station. We have many choices of different wireless links from simple basic transmitters, to more complex network based wireless links. Each has its own advantages and disadvantages. Let's review the basic categories of wireless links to determine which type would be best suited for the home weather station.
3.1 A simple wireless link
Let's start by examining a simple wireless link used for data transfers. One of the simplest data transfer wireless links is called OOK which stands for on-off keying. It is also sometimes known as carrier present / carrier absent.
Figure 3.1: On-Off Keying (OOK)
On off keying uses a fixed carrier frequency. As shown in figure 3.1, when the carrier is detected, or present, it represents a logical one. The absence of a carrier represents a logic zero.
The fixed carrier used is usually a frequency in the ISM band. The ISM band is for industrial, scientific and medical devices. In most countries this band is unlicensed and free for anyone to use. The most common ISM frequencies are 433MHz, 928Mhz and 2.4GHz.
OOK is a simple protocol that is relatively easy to implement in hardware. For this reason OOK transmitters and receivers are quite inexpensive and sell for around $10.
3.1.1 Issues with the simple wireless link
One of the most common issues with the simple OOK wireless link is its susceptibility to noise from other sources. Any transmitter with a similar frequency can inject noise into the data stream that results in incorrect data being received. The receiver is simply looking for the presence of a carrier of the correct frequency to register a logical 1. If another nearby transmitter is transmitting its own data on the same frequency there is a strong possibility that the data your receiver sees ends up being a combination of your data and the data of the rogue transmitter. It is even possible for electrical noise from other sources to be close enough in frequency to the carrier frequency to be detected by the receiver as a logic one.
Consider our example of sending the data 0xA6 or 10100110. In an ideal environment we send 0xA6 and we get 0xA6. However, if another transmitter or even a source of electrical noise is nearby it is possible that additional carrier data can be detected by accident in the data stream. In figure 3.2 it can be seen that although we attempt to transmit the data 0xA6 (10100110) noise from a nearby transmitter is just strong enough to interject an additional one into the data stream resulting in the received data of 0xAE (10101110) which is incorrect.
Figure 3.2: Noise injected in the OOK data stream
There is nothing that we can do to prevent noise or other transmitters from interrupting our transmission. When using a simple OOK wireless link, we must be able to detect that our data is corrupted and recover from the corruption.
3.1.2 Error detection and correction
In order to receive reliable data using the simple wireless link we need to be able to detect and correct errors in the data.
There are numerous ways to detect errors but one of the simplest and most common methods is to use a checksum. A checksum is simply an addition of all the bytes of data in the data packet. The checksum is appended on to the end of the data packet and sent along with it.
The receiver adds all the bytes in the received data packet except the checksum and compares it to the checksum. If the computed checksum matches the received checksum, the data is considered good. If they do not match, there is an error in the received data. A simple example is shown in figure 3.3.
Figure 3.3: A simple checksum example
However, the checksum is not perfect. It can detect most data errors, but not all data errors. Since a checksum is a simple addition, if one portion of the data is off by a certain positive amount and another portion of the data is off by the same amount although negative, the two errors will cancel each other out. This is analogous to the fact that 6+2 equals 8, but 7+1 also equals 8. Consider the example in figure 3.4.
Figure 3.4: A simple checksum that fails to detect an error in the data stream
In figure 3.4, one bit was incorrectly detected as zero. However in the same data packet the same bit position was also incorrectly detected as a 1. These two incorrect values cancel out and the received checksum matches the transmitted checksum even though the data is corrupted.
Of course if we detect an error we need a method to handle the error. We can ignore the data packet with the error in it or we can request a re-transmission of the data.
If we ignore the error and throw away the data packet we must accept gaps in our data. If we decide to sample the temperature every five minutes and we detect that two consecutive data packets are corrupted, we throw away ten minutes of data. We can sample data more frequently to overcome this issue however this would result in more power consumption in our battery powered remote sensor. More power consumption will result in reduced battery life and more frequent battery changes.
We can also recover from a corrupted data transmission by requesting a re-transmission of the data from the remote sensor. By requesting a re-transmission when we get corrupted data we can recover without missing any data. If the data is corrupted a second time in a row we can continue to make requests for data re-transmission until the data is verified to be correct. The major drawback to this design is now we need both a transmitter and a receiver at both the remote sensor and the base station.
There are varying methods of detecting and correcting errors in our wireless transmissions but all of these methods require a substantial amount of work and hardware to implement. There is also a significant amount of software overhead to process each data packet, check its integrity and if necessary initiate a request to re-send the data packet.
One simpler solution is to use a prepackaged solution that contains all of the error detection and correction within a hardware module that also functions as a wireless transmitter. These all in one wireless radio modules provide a simple serial interface to send and receive data, while hiding all of the error detection and correction from the user.
