The SMS gateway worked between the sensor RF network and the mobile phone network. However, it lacked sensitivity, occasionally struggling to get a signal 20 yards away.
Ciseco OpenKontrol Gateway on lid of device, with Dallas 1307 RTC implemented
I mounted the OKG board on the lid of the box and the SMS board in the base, unwittingly placing the sensor RF receiver between two ground planes. And a mobile phone signal source in a similar part of the radio spectrum. Which was probably not the best way to get good performance out of the LLAP sensor radio – screen it and then desensitise it with a strong nearby signal. Oops. Continue reading “Improving the coverage of the sensor radio network”
Our smallholding is an island site with no power and no broadband. No power means things like a Raspberry Pi are marginal – we’re looking at a current drain of about 500mA for a Model A. For a 85AH leisure battery of which you only want to use half the capacity for good service life that’s about 80 hours. So it’s time to look at the system architecture of a remote sensing network to try and reduce the power used at the remote site. The aim is to offload the processing for graphing to a site with mains power (home), so the system has sensors, a gateway that collates all the sensor data and sends it via SMS in my case, and a data processor.
Remote sensing network system architecture
At a site with mains power the gateway and data processor can be the same thing. The architecture of such a system is therefore two-level –
many sensors out in the field
a gateway/data processor
At home I have a Raspberry Pi that collects data from my sensors using a RF board, Ciseco’s Slice of Radio. The same Raspberry Pi runs RRDtool to do the graphing and SFTP to put the graphs onto the web.
Sensor network on a mains-powered site – the Raspberry Pi does most of the work
At the farm, however, because of the power constraint I need to use a gateway to transfer the data onto the mobile network using SMS.
That sort of site typically consists of three levels –
many sensors, out in the field doing the data collection,
a gateway, that collects all the sensor data
a data processor – that consolidates the data from the sensors, graphs it and saves it, perhaps uploading to the web
So the next stage down from a Pi is something like an Arduino
The Arduino OKG and Sainsmart SMS to serial device reduce power usage by 80%
The Raspberry Pi can be at home so its power consumption isn’t an issue any more. It takes an SMS message of various sensor readings and munges this via Python and some scripts into a RRD database which then goes with RRDgraph. Which gives the single-sensor plot as shown below. The battery voltage chart shows that something rather nasty is happening to the main battery – it looks like the charge controller is not disconnecting the solar panels from the battery when the battery voltage is high enough – if so this is the second Kemo charge controller I’ve had from Maplin that has failed in service.
Simplified sensor chart
What, no IoT platform?
I’ve gone off third-party IOT services, because the RPi lets me run RRDtool, and shifts the conversion from simple CSV text files to home. I get to control what goes on, I am not subject to the whim of third-party changes, cessations of service, charging for what was free and all the other hurt that goes with relying on people you don’t pay. I found the Xively Arduino stack memory leaky and buggy despite my initial enthusiasm, and now I can run a Raspberry Pi at home I can insource the job, and get the Ethernet stack off the Arduino.
In that way the data gets processed more as it is staged along the signal path as the processing power of my devices and electrical power available to them increases. Electrical power is shortest at the sensor, which draws an average of about 1mA. It gets consolidated at the OKG gateway, which is powered by a 12V leisure battery and draws about 60mA, handling all the sensors. Once it gets to the Raspberry Pi at home that is mains powered I can live with the 500mA-700mA@5V and that does the collating, data transforming into a RRD database, graphing and uploading to the Web.
Sensor design
For my system architecture I have pinched ideas from the design of industrial process control system – historically these used wired sensors, firstly using 4-20mA analogue signalling using current (this independent of wire resistance). With zero response the sensor would draw 4mA and at full scale it would draw 20mA. These fed into a console for display.
However, I don’t want to run wires all over the farm, so I will use Ciseco’s LLAP serial data format over radio. This replaces the naalogue current loops and wiring and lets me reduce cost and power at the sensor, which can sleep for most of the time, only waking every 10 minutes to send a 12-byte packet on the radio network to be received at the gateway. That’s just as well, since losing the wiring means the sensors each have to be autonomously powered.
Ciseco’s thermistor board with XRF
Ciseco already make some sensors using the processor on the XRF radio – you simply upload a different firmware to the XRF – there’s an example in the picture, and this is powered from a CR2032 coin cell on the board just under the XRF.
thermistor board in box
These make a neat small sensor, and great for measuring the temperature in a shed where sunlight doesn’t fall directly on the black box (generating large readings unrepresentative of the air temperature) but they aren’t great for soil temperature measurements.
soil temperature measurements from a buried probe and a LLAP thermistor sensor in black box on the soil surface
The blue line is the LLAP sensor in a box – placed next to the soil sensor – they are physically very close, but the box on the soil experiences a much wider temperature range!
Sensors deployed in a polytunnel
Not only is there the sunlight problem, but being on the soil keeps the radio low which minimises range, hence the choppy blue line. However, it wouldn’t be hard to mod one of these with a jack switched socket to use an internal thermistor unless an external one was plugged in, and they’re quick and easy to deploy, which is great. They can also be run off two NiMH AA cells instead of the Li battery, which opens up the possibility of using solar power for unattended operation (the CR2032 battery is good for 6 months at least at a 10min update rate).
To get more out of the limited data rate on the SMS gateway, I’ve also got a LLAP sensor design with two sensors and a PIC microcontroller than encodes two temperatures onto one LLAP packet. I use two of the the Dallas18B20 digital temperature sensors for that.
PIC microcontroller/XRF dual dallas 18B20 control box. Powered off 4xAA NiMH maintained by a solar cell
The Gateway
Ciseco do a Arduino Uno based gateway PCB that has an UNO and sockets for their XRF modules, called the OpenKontrol Gateway. This also has space for a Real Time clock which is nice. I only needed the Arduino, the RTC and the XRF hence the gobs of unused space on the LHS. I wired this via the serial port to a Sainsmart TC35 used as a SMS gateway, mounted on the bottom of the box. Unfortunately the XRF ends up between two ground planes, which doesn’t do wonders for the RF sensitivity. However, I was ready for that, bringing out the serial connections to a DIN socket, so I can mount the XRF remotely and up high if necessary, taking just power and 9600-baud RS232 back to the box.
Ciseco OpenKontrol Gateway on lid of device, with Dallas 1307 RTC implementedthe finished LLAP to SMS gateway
So far I have learned a lot from this deployment – it’s proved the principle, but I need to improve the RF performance of the OKG/SMS gateway with a remote XRF receiver to be in with a good chance of covering a significant part of the smallholding.
I’m a fan of Ciseco’s OpenKontrol Gateway. It doesn’t get anywhere near enough love on their site compared to the flighty Eve. Where it scores is that it’s a cheap way of making stuff happen and I like that.
It makes a dandy data logger, basically get the RTC kit and the SD card socket, slam one of their XRF radios in the left hand socket plus a LLAP thermistor device within 50 yards and you’re all set 🙂 You can add more thermistor devices while the datalogger is running and they get logged too without bumping it. And all for less than about £80 total system cost, what’s not to like? Okay in an ideal world the power consumption could come down a little bit as the OKG is in receive only mode, but it’s livable with – using 8 NiMH AAs gave me a couple of days runtime.
This saved our tail with finding out what the soil temperature was like in and outside a polytunnel earlier this year
What you can also see in the OKG picture is a Wiznet 5200 Ethernet card. What I didn’t realise is that this damn thing has a microcontroller inside. And it’s reset at the same time as the Arduino, so you get some sort of evil who-dares-wins race to get out of the starting blocks when that reset line goes High. The horse you want to win is the Arduino, so as the Wiznet’s ready to get initialised by the Arduino, but it doesn’t seem to happen that way.
Looks like with some configs the wiznet wins the race, and presumably gets confused when it sees data and stuff. I never got it to work reliably with the SD card datalogging. I the got another OKG, this time without the SD card and RTC option, just for posting LLAP devices from the XRF to Cosm. And this damn thing was about 50% reliable, it gave me a world of hurt until I discovered this natty fix for this sucker over at Open EnergyMonitor. I am so grateful to them. Basically you dis the reset on the Wiznet and ground the sonofabitch once the Arduino powers up, so you know where it starts from rather than whatever it got to see on the data lines as everything Arduino and SD card and XRF and what have you fired up. Sounds good to me, and it works. I had considered chucking a monostable at this to ground the line for a sec so the Arduino can sort itself out, but caught the Wiznet getting its knickers in a twist after a while having started okay. So the option to deck it if it returns more than five -ve values for etherclient post is necessary. I went off pin 3 of the RH socket which is arduino pin 6 ISTR, but I need to see if there is a genuinely spare pin because one day I might want to use the OKG as an RF to RF gateway which would mean getting both slots into service. I’m open to pinching the red status LED if necessary 😉
The Wiznet seems actually reliable now, and if it does get itself stuffed in an IoT application returning a negative value for a post five times in a row I simply reset it and reinit the device. It’s not the end of the world if five temperature readings get lost, as long as recovery is possible 😉
The obvious place to look is this post, OpenKontrol Gateway as Data Logger from openmicros.org, which has some sample code, which didn’t work for me. It created the log file but didn’t write any data to it.
It’s also a bit more tricky to use, compared to a regular data logger. This is because the RF network is unsynchronised – the temperature nodes fire themselves up every 5 minutes, transmit a temperature reading and then go to sleep. This isn’t a polled system, and there may be other transactions on the network. The data logger simply logs all of these transactions, be they temperature readings, status readings or setting up devices – anything starting with an a is logged.
This is why I added the unix timestamp, so that it would be possible to plot these unsynchronised elements onto the same xy plot, with the timestamp along the x axis. Some data might want to be sampled more frequently than every 5 minutes, and some might be reactive, like a PIR sensor.
The receiving application has to pull all this stuff apart, first splitting the streams into the devices, using LEFT(LLAPmessage,3). This will always be aXY with XY being the deviceID
The OpenKontrolGateway a board like an Arduino Uno, but with a SD card interface, three RF board interfaces, an Ethernet board module slot and a DS1307 Real Time Clock with battery backup. It’s a nice collection of all the stuff you need to make a datalogger. If you want to retrofit a DS1307 RTC to an Arduino project Seedstudio’s Grove RTC board features the SMD version of of the chip and saves you the tiresome surface mount wrangling.
Ciseco OKG
The OKG bundle at £25 gives you everything needed to box it up but I added the RTC kit and SRAM which added £12 to the cost, since a data logger without an RTC is always going to be a pain, where you have to connect up a PC to set it. That’s OK at home but no fun at the farm.
The RTC gave me a hard time right off the bat. There are a few gotchas.
You have to set the damn thing,
you need to do that to even see it started, since it can need initialisation from the SPI bus before the oscillator will start
You need a 2032 coin cell present for it to be able to work too, so no testing that without and thinking you’ll fit that later 😉
So if you ‘scope the crystal and think ‘ah, that’s why it isn’t working’ then not so fast, you may need to initialise and set it before you see any action there. I found all of this out the hard way. This is what I used to set it, which I largely pinched from LadyAda’s tutorial. One of the nice things about that is it lets you set the clock to the time the sketch was compiled, which save a whole load of faff. What you must not do then is to press reset, or switch off and on again, else it will do that all over again, setting the RTC back to the time it was compiled. You must comment out the line
   // RTC.adjust(DateTime(__DATE__, __TIME__));
and re-upload it. This listing has that line commented out, so you must uncomment it to set the clock, then recomment it.
