The project is made up of 3 physical parts: a sensor station, a hub and a display. The reason why it is split in those parts, is discussed earlier. It would have been possible to reduce this number from three to two by for example merging the sensor station with the hub, but we would still face the same issue: how do we communicate between multiple devices? A communication link between the devices is needed to transfer data from one to the other. It is not necessary to exchange all the information because the receiver is probably only interested in some details. They can communicate with each other using either wired or wireless technology. Both have advantages and disadvantages. Table 1 sums up the most important ones.
It appeared to us that the disadvantages of a wired connection could cause frustrations for the participants of the competition while the con’s of choosing for wireless communication would only affect the mood of the designer. Frustrations could influence the experiment and this was not desired. The difficulty to set up a wireless communication link was estimated as feasible because some research about that was already done during the search for a final subject. Price was a very important aspect from the beginning but the price difference wouldn’t be that big due to the existence of low-cost radio frequency modules. On the contrary, cables aren’t cheap either so that depending on the quality of the cable and the total distance, it could turn out to be more expensive than the wireless option. The biggest advantage of working with wireless technologies is that it allows greater freedom to place the device wherever you want and that it supports the aesthetics.
The reasons mentioned above led us to choose for radio signals that pass invisibly through the air. This would make it possible to create a neat and tidy test environment. One step further in the decision-process, a specific wireless technology had to be chosen. The considered options were Zigbee, Wi-Fi, Bluetooth and RFM12B. It are four protocol standards for shortrange wireless communications with low power consumption. In a “Comparative Study of Wireless Protocols” the first three are compared with each other. One of the findings is that Bluetooth is the most complicated protocol and ZigBee the simplest one. It also appears that ZigBee and Bluetooth both consume much less power than Wi-Fi. These findings indicate that Zigbee would be a good choice to use, also because it was by far the cheapest module. Xbees (using the Zigbee protocol) were already used in some small projects prior to this which is an extra plus. The fourth one on the list was the RFM12B. It is a fairly simple transceiver module that can operate in the 433/868/915MHZ bands. Arduino users are not really familiar with this wireless module but it is on the rise since Jean-Claude Wippler from Jeelabs began using this module in his Jeenodes (Arduino IDE compatible) and wrote comprehensible libraries for it. It is cheaper than an XBee because it lacks entire communications protocols for 802.15.4 or error correction but it is still more than capable enough to send and receive small data packets.
The OpenEnergyMonitor project had tutorials available for both the XBees and the RFM12B modules. The deciding factor for choosing the RFM12B was that the upcoming emonTx, their sensor station, would be provided with such a module and that the OpenEnergyMonitor project was willing to sent up two samples for this thesis. Learning to work with this module would cost as much time as building and programming a sensor station with an XBee module on our own.
Most of the thinking was already done by the people from OpenEnergyMonitor and Project Nanode. They found a way to connect the chip with their sensor-station and internet-hub. The circuits were integrated in their PCB’s and only needed a little bit of solder to work. While this was easy, the connection between the hub and the display had to be done completely by ourselves. Because printing a custom-made pcb would have been too expensive, a compact breakout board for the RFM12B radio module from Jeelabs was used to facilitate the connection with the Arduino. Figure 1 shows the parts that were utilized for this board. Table 2 indicates how the headers of the board should be connected to the Arduino in order to work with the accompanied sketches. The radio module supports a power supply level of up to 3.8V. Instead of using a voltage regulator, we directly connected it to the 3.3V output on the Arduino.
The wireless modules come pre-configured for a certain band. Producer HOPERF gives the option for a 433Mhz, 868Mhz or 915Mhz configuration. The 433Mhz band was chosen because it is the only frequency of the three that is allowed worldwide. The use of the 915Mhz band is only permitted in Australia and the USA while the 868Mhz band is only allowed within Europe. The frequency of the modules can be changed in the software, but it should match the intended hardware frequency of the module to get the best performance. The antenna for the RFM12B measures 165mm which is in our case approximately one quarter of the wavelength.
In contrast to XBees, these wireless modules don’t need to be programmed through a terminal program. Everything can go through the Arduino IDE. The configuration options are limited but sufficient enough for the purpose we have in mind. The hardware was tested using the RF12demo example sketch which is available after installing the RF12 Library in the Arduino IDE. With this sketch, it is possible to see if two Arduino’s equipped with RFM12B’s are configured correctly and if they can ‘chat’ with each other.
The configuration parameters are initialized at the beginning of the Arduino code, an example of this is given in Figure 4. First we need to include the Jeelib library that combines the Ports and RF12 libraries from JeeLabs. Those contain classes that facilitate the instructions needed to control the wireless module. The most recent version of the library can be downloaded from http://www.github.com/jcw/jeelib.
‘MyNodeID’ is defined next and gives the wireless node a name that is recognized over the network. The number should be unique in a group and must be between 1 and 31. They can be used to send or receive data from specific other nodes that reside in the same group. ‘freq’ is used to determine the frequency range in which the wireless module will operate. In this example, it is the 433MHZ band and has to be written down as ‘RF12_433MHZ’. Other possible frequencies are 868Mhz and 915Mhz. Nodes in the same group should use the same frequency band. The ‘network’ parameter is optional and could be used to separate groups from each other.
The structure and the content of the packages that are being sent, must be defined as in Figure 5. In this case, two integers are being stored and saved as ‘emontx’. The receiving node should be familiar with this structure in order to decode it properly. This is why we see the almost exact same lines on the other side.In Figure 6 you can see the setup function that initializes the RFM12B at startup and the loop function that keeps running consecuttively and is responsible for the actual communication. This code snippet is taken from the sensor station which is powered with two LR6 batteries. To save energy, it is put into sleep when it is idle. So, at the beginning of the loop, it has to wake up from his sleep. When it is awake, it searches for other nodes and starts to send the data packet that was saved as ‘emontx’. It will then wait 2ms to allow the while loop to succeed in veryfying that the package was received. After this, it will go back to sleep. The receiver is in this case our hub and defines everything similarly as the transmitter, only myNodeID is different. This device is always on so that it can receive packets whenever they are sent. The code that does this, can be found in the loop in Figure 7. The variables are easily extracted by typing the name of the packet structure together with the name of the sought variable, eg ‘emontx.power’.The hub also sends data wireless to the display. The intention was to send a char datatype using the same method as described before, but this didn’t work. The display did receive something from the hub but instead of letters, only numbers (from 0 to 9) were shown. We tried to decode those numbers back into letters but did not find the appropriate key. A solution was found by omitting the typedef struct and immediately sending the char with the rf12_sendStart function as Figure 8 illustrates. Receiving the data at the display went as expected.