Hello Everyone
Its been ages again. Happy New Year and all the best for the year to come. I personally hope to be able to do a bit more posts this year in comparison to the previous one.
So as mentioned in the previous two posts, I am busy creating a NRF24L01 network to be used for automated farm irrigation system. The problem with farm irrigation is that the valves tend to be pretty far away from the farm house which is where the base station will have to be. To overcome this you will have to relay the signal through relay nodes to which ever node you which to send it to be able to open or close a specific irrigation valve at that specific node.
This lead me to decide to make use of the NRF24L01+PA+LNA (NRF24L01+Power Amplifier+Low Noise Amplifier) which has a proclaimed range of 1000 m or 1 km. However looking at the range tests that iforce2d did (See first test here and second test here) it seems that a safe maximum distance is around 715 m which is perfectly fine for my application.
Here is a little example of an approximation of the distances that I did for my application using Google Maps which I will revise again once I get closer to the finish line.
So initially I was hoping to be able to make use of an existing network or a mesh library to address my needs but unfortunately all the libraries that I looked at wasn’t able to do what I needed which was to hop a signal or to relay a signal more than 6 times. Luckily for me I stumbled upon Bob Lynas’ video of how he relayed a signal over a few nodes. He posted his code to the Arduino forum which can be found over here. So I’ve based my code on his with a few changes. The changes includes the base station sending a payload containing a structure of data (A guide on how to implement this can be found here). In this structure I have the “transmission pathway” which is the relay node addresses through which the signal must be hopped. Each node receiving the signal is then able to detect whether it is the next node in the pathway and whether it must relay the signal or not based on it’s own address and the information received in the payload.
The maximum payload of the NRF24L01 is 32 bytes and my transmission information required to send the transmission to where it needs to be is 18 bytes. This left me with 14 bytes of information which could be sent. I’ve decided that I would like to be able to use each node as a independent node that must be able to either just relay the signal, be implemented as a sensor node or a switching node to open or close a valve or a combination of both. So to be implemented as a sensor node the node will make use of three arrays for a maximum of three sensors per sensor node. The three arrays will be a “sensor type” byte array, a “unit of measurement” byte array and an integer array with the RAW measurement data (0-1023 RAW values). The sensor type and the unit of measurement will be determined by a lookup table at the base station and the measurement will then be able to be displayed correctly based on the sensor connected and the desired unit of measurement (As programmed into the sensor node). The processing of the RAW sensor data only takes place in the base station as this eliminates additional specialized code required at each wireless node.
This results in 12 bytes of sensor data ((3 * 1)+(3*1)+(3*2)), this leaves an additional 2 bytes of space available (32-18-12 = 2) in the payload should I wish to do something else. This is the worse case scenario where I almost have no space left in my payload size.
If the node is to be implemented as a switch node then I only want to be able to switch 4 solenoid valves so I only need to sent a 4 byte array or a 4 variable array with the transmission information to trigger the solenoid valves open or closed. The solenoid valve type that I’ve chosen is a latching solenoid valve. The reason for this is because these nodes will be self powered using a solar panel with an internal battery and this kind of solenoid will consume the least amount of energy when compared to a non latching solenoid. The downside to using a latching solenoid valve is that you have to drive it using a H-Bridge circuit which uses 3 digital output pins for each solenoid so in total you will use 12 digital output pins to be able to drive all four latching solenoid valves. In comparison to a non latching solenoid valve which will only require 1 digital output pin to switch the solenoid valve.
The last option is a combination of both a switching node and a sensor node. This means that I can have two sensors connected with the switching outputs since the switching node uses an array with 4 bytes and each sensor uses 4 bytes of data. This again results in a total of 12 bytes of data. The network size is limited to 255 addresses since I had to utilize a byte array to store the addresses. Initially I wanted to use an integer array to store the addresses to be able to accommodate a larger network size but once again the total payload size of 32 bytes limited me to using a byte array to store the node addresses and limiting the network size to the mentioned 255 addresses.
I would like to reserve address 0 for the base station address and addresses 1 – 4 (Like a secondary master) for future use. This means the address range of all the other nodes would be from 5 – 255 meaning that the maximum amount of nodes in the network would be 250 excluding the base station and the other reserved addresses.
Example of the modules that I intend to use. Far left is the low power module with the two on the right being the high power modules.
But enough explanation of the concept of the system, I’ve finally managed to relay the signal 6 times and I believe that I will be able to relay the signal 12 times which I’ve implemented to be the maximum number of signal relays / hops. Unfortunately I ran out of Arduino Nanos to test it with but to relay / hop the signal 6 times are good enough for me 😉
The current state of affairs are that the transmitter has a green LED which is on constantly when it is OK to send a transmission i.e. there are no other active transmissions currently. The transmission is initiated by pressing down on a push button. Before the signal is broadcast, the state of 4 dip switches are read and this is transmitted as the state of the solenoid valve. The signal is then broadcast.
DIY Dip Switch module, LED module and push button module implemented in testing phase
At this stage the green LED switches off to indicate that it is now NOT OK to broadcast any other signals and if attempted to do so then nothing will happen. The first relay node receives the signal and evaluates whether the signal is intended for “this node” and if it needs to process the signal and broadcast it again. Once it determined that the signal is intended for “this node” and it needs to process and broadcast it again then “this node” switches a red LED on. This process is repeated by the following relay nodes in the transmission pathway.
Green LED = Good to GO for a transmission
When the recipient node receives the transmission then it follows the same procedure where it first determines whether it is intended for itself and whether it received the signal from the intended source. It also tests whether it is a relay node or the recipient node (The last node in the chain). Once it determines it is the recipient node then it processes the data and switches the solenoids accordingly. The solenoids at this stage are just four red LEDs. Once the outputs have been triggered (LEDs switched on or off) according to the received data then an “acknowledge bit” is triggered in the transmission information and transmitted back to the transmitter or the base station.
The first relay node back towards the base station (In the transmission pathway) now receives the signal and again evaluates whether the signal is intended for “this node” and if it needs to process the signal and broadcast it again. Once it determined that the signal is intended for “this node” and it needs to process and broadcast it again then “this node” switches a red LED that it previously switched on, off again.
Relay nodes with triggered LEDs indicating that the signal was relayed forward.
Should the signal be sent and not received at a specific relay node then the previous nodes as well as the base station will not receive the “acknowledge bit” and will then time out the transmission. When a time out event occurs then this is signalled by flashing the node’s LED multiple times and then switching off before resetting all the required variables back to its default states enabling the node to receive a signal again.
The base station similarly has a time out timer but a longer one and instead of switching the LED off after the flashing sequence is completed it keeps it switched on signalling that it is OK to transmit the next signal or to retransmit the signal. Something that I also had to figure out was the radiation pattern of the antennas since the antennas didn’t receive the signal when it was angled at certain angles. The rubber duck antennas that I’ve used, pictured above, radiates in the following pattern:
Picture from http://rcexplorer.se/
Picture from RC Groups Forum – http://www.rcgroups.com/forums/showthread.php?t=833260&page=6
To resolve this I had to align the antennas so that each rubber duck antenna was in the radiated area of the previous antenna (Signal coverage). I’ve had some problems with some of my antennas I suspect but I’m currently hoping to figure out what was happening exactly, I’ve been consulting some of the people at the Arduino forum regarding it.
Here is a little demo on how the system works at the moment:
I know that this was a super long post but I hope that you enjoyed reading it and seeing my progress. Wishing you all the best for this New Year.
Paladin Enabling Technologies 
Leave a Reply