Author Archives: Richard

Remote Farm camera – experimenting with WiFi

Clive from the Raspberry Pi Foundation very kindly let us have a Pi Model A and camera, so it’s time to take this project forward a stage. At the moment the alpha test version is in service keeping an eye on our new piglets. Although the original purpose was to keep an eye on our newly arrived cattle pigs are more enterprising, so it’s good to know where they are

Our camera on the pigs

Our camera on the pigs

Development was stalled however since it’s not easy to work on a piece of kit in service.  Ideally one MiFi box could serve a number of cameras. This would reduce the camera power drain and consolidate.

The trouble is that the site is on the edge of town, a couple of hundred metres from the nearest houses, and I want to use BT Wi-Fi

Yagi wifi antenna

Yagi wifi antenna

I acquired one of these from ebay I didn’t have much hope for the integrity of the device, and to gain height I needed to go 250m further way from any likely source of WiFi. But it worked a treat, as a WISP client, I’m amazed. I was able to see 18 access points, five of which were BT WiFi , 3 of which were 5dB or above. The TP-Link gives a decent link at more than 5 and nothing at 2. I streamed a video to confirm the stability of the link.

TP Link signal strength with yagi

TP Link signal strength with yagi

I use it with a TP-Link TL-WA5110G which has the advantage of having a sma antenna socket and a native power supply of 12V. Although the adaptor is specced at 1A I measured the power drain at about 210 mA (~2.5W @12V). Which isn’t great but not terrible

A WISP client is not a  repeater

The trouble with using the tP link as a WISP client is the signal is presented as Ethernet, and I’d then want to re-radiate the signal on a different Wi-Fi network.  I could set it as a repeater, but then every Raspberry Pi would have the hurt of logging into BT WiFi. Whereas if I use a Raspberry Pi connected via ethernet to the TP-link and a WiPi dongle to connect to the farm I can collect pictures from the cameras on the farm network and perhaps power-manage the TP Link to only update every so often.

So an unexpected win, and I can look at using a Model B as a concentrator

Remote Farm camera using Raspberry Pi – alpha test version

At The Oak Tree we have acquired two bullocks/steers, and it would be good to be able to monitor these guys to check they are okay.



The obvious way is a GSM trail camera, which has got some merit. However, these are typically tripped by movement, and you get a lot of that outside. It might work to use a trail camera with a 15 minute trigger lockout – it’d be tripped all the time but wouldn’t spam you senseless with the 15 min delay. But it’s going to be dear to run as they tend to use MMS – giffgaff charge 16p per MMS for instance, whereas their data rates are 20p per 20Mb . CCTV solutions have the same problem – they are event triggered, whereas we want to be able to see a picture taken sometime in the last 15 minutes. Well, obviously we’d really like realtime streaming video by a pic at most 15 minutes old is a decent second best 🙂

What we ideally want is a camera you can send a message to to take a picture.

I used to have a Youthnet V900 which you could send an SMS to take a picture, but it was the most maddening hunk of junk I have ever purchased. Configuring the settings was done by SMS, and I only ever got it to work with Virgin mobile once. Then Virgin must have changed something and I never got this to work again, either with Virgin or with Giffgaff. In the end I put a hammer through it so it wouldn’t waste any more of my time and money. The satisfaction of doing that was the most value I got out of it.

I took a look at this trail cam and recognised the same commands as the Youthnet . I’m just not going to go there again if it uses the same software. Plus there’s the fact that it doesn’t really suit what I want it to do.

The Pi’s USB subsystem isn’t good enough to run a 3g dongle

So it’s time to break out the Raspberry Pi. Unfortunately the USB subsystem of the Pi means I couldn’t use Gammu directly with a Huawei E156G USB 3G dongle. It would work for a while and then conk out, and only come good again when the Pi was power cycled, not even a restart would fix it. That’s a real shame – this would save me a lot of power drain. Maybe it’s specific to this dongle, but there is always a world of hurt when it comes to the Pi and USB because of the power problem, and a 3G dongle has a high power usage when connected. Even running the E156G off an approved USB separately powered hub and the Pi off an approved PSU didn’t make it any better.

Go MiFi

Obviously if your site has WiFi you don’t need to wrangle with 3G, but there is a lively market in boxes to put a WiFi hotspot using 3G, called MiFi devices. You need to configure these to make use of your 3G dongle (and make sure they are compatible), the type I used is a TP-Link MR-3220


So I used a MICRONEXT  MN-WD552B WiFi dongle in the A’s single USB port, which seems reliable. Of course I now eat the power drain of the Pi, WiFi is never low power and the TP-Link 3020 MiFi device gives me another power hit. But it works, and I needed results fast rather than good, so it’ll do for now.

The Raspberry Pi Camera module is really rather excellent

The camera module that the Pi foundation sell for of the Pi is rather good – the larger version of the pic above is already scaled down by half in the camera to reduce the file size. And I compressed it a fair bit. You can control the camera in Python too, using Picamera. Python seems to be the default language for the RPi.

Although the Raspberry Pi is credit card sized, it’s remarkable how big it gets if you want to do anything with it. I used a box I already had – if I decide this works well enough for a permanent version then I will use a PICE waterproof case, but for the prototype a temporary rig is fine.

the Pi gets big fast when you hang enough onto it to make it useful

the Pi gets big fast when you hang enough onto it to make it useful

At the moment both are powered up all the time, and a cron job takes a picture and SFTPs it up every 15 minutes during the day. The Pi and the TP3020 are powered via one of those dual-output 12V car to USB converters, the power drain at 12V is 250mA which is horrible, meaning using 40Ah of a 80Ah leisure battery will take 40*4=160 hours, nearly a week. Which is nasty, but livable with. There is massive opportunity to cut the power drain by bringing up the TP-Link 30210 and the Pi only once every 15 minutes when it’s light – they can be up and do their stuff in 5 minutes so I’d get a 3x drop in power drain from that, and not running in the night would save me another third.

The installation is bush-league, but this is going to need a bit of optimisation anyway

the camera is at the top left of this IBC

the camera is at the top left of this IBC

and a close-up shows just how bad it is – waterproofing by electrical tape is living on borrowed time. But that’s where those nice people at PICE come in, so there’s no point in putting any real work in that.

best not let the IEE see that else they'll revoke C.Eng for disgraceful and outrageous bodgery of the first order ;)

disgraceful and outrageous bodgery of the first order 😉 The PICE case has solved most of the mechanical challenges kludged together here.

This shows one of the hazards of this location, in that the crows sit on the bar surveying their domain and crap on the IBC. There’s no crap on the bars though, so I might get away with it. Some anti-bird spikes might be in order.

#$Id: 53 2014-06-26 16:30:17Z richard $
import time
import picamera
import paramiko
import os
import socket
import datetime
# import RPi.GPIO as GPIO

# GPIO.setmode(GPIO.BOARD) # USE Pi BOARD pins, not the BCM ver
# GPIO.setup(7, GPIO.IN, pull_up_down=GPIO.PUD_UP) # 7 is next to gnd on pin 9, so set pull up

# defs
remotename='' # assuming this is reachable by ssh and www

try :
    with picamera.PiCamera() as camera:
        #camera.resolution = (2592, 1944)
        # The following is equivalent
        #camera.resolution = camera.MAX_IMAGE_RESOLUTION
        # run half res to test out connectivity etc and save money
        #camera.led = False
        camera.resolution = camera.MAX_IMAGE_RESOLUTION
        #camera.resolution = (1296, 972) # do half real to eliminate Bayer softness and save TX bandwidth
        camera.capture(DIR+imagename, resize=(800,600), format='jpeg', quality=15)
except picamera.PiCameraError,e :
    print e
finally :
time.sleep(10) # hopefully nw is up by now   

if not(camerafail) :


    while (not timedout) and not connected :
        try :
            s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
        except socket.error,e :
            counter += 1
            print counter
        if counter >= 5:
            print 'Failed to connect to ',remotename,' ',"%y/%m/%d %H:%M")
    # Ideally, this gets called by cron once every quarter of an hour. 

    if not timedout: 
        print 'ftp image starting ',"%y/%m/%d %H:%M")
        try :
            ssh = paramiko.SSHClient()
            ssh.connect(remotename, port=2222, username='username', password='password')
            sftp = ssh.open_sftp();
            sftp.put(DIR+imagename, '/my/remote/path/'+imagename)
            print "closed SFTP"
        except paramiko.AuthenticationException,e :
            print e
        except socket.error,e :
            print e

The cron job

This is then called by a cron job on the Raspberry Pi. You must to this with root privileges because you are accessing the hardware, so use

sudo crontab -e

and mine looks like

*/15 4-22 * * * /home/pi/ > /home/pi/log.txt

which means every 15 minutes between 4am and 10pm run and save the error messages etc to log.txt. Before running this as a cron job you want to make sure that if you manually run

sudo /home/pi/

you get a picture uploaded to where you want it 🙂

Goose Incubator Camera

Getting a camera in an incubator has a lot of the aah factor and lets you see what’s going on without opening the incubator up all the time, which is good for the incubator, the eggs and the reliability of hatching.

You have to take into account that the incubator is a fairly harsh environment. There are lots of ways of making an incubator camera in principle, but  the heat and humidity rule out a lot of them, like webcams and trail cams.

Five requirements of a Incubator camera

  • sealed against moisture
  • elevated temperature running
  • physically small
  • capable of shortening the close focus to ~ 5cm
  • externally powered

I used an outdoor bullet camera I got from RF Concepts – it’s an old variant of this one.



It used to be on top of a fence post looking at my bird feeder, and stood the test of time against the rain. I removed the square part on the front and tried replacing the lens with a wide angle lens, which stuck out too much and cracked the glass.Fortunately replacement mineral watch crystals are to be had – a 24.8mm was a suiable replacement. Replacing the original lens and unscrewing a bit to get the short focus closer worked a treat, and the replacement glass and O rings have held so far.

A single channel Vivotek 8100 CCTV webserver turns the analogue CCTV signal into a IP-compatible one and thei nbuilt FTP client uploads a picture every so often to make it publically viewable. The 8100 could also stream video but I don’t have a good enough connection for that.

Goose hatching camera (inactive most of the time!)

Real IP CCTV cameras are still on the expensive side and a little bit too big for this job.

It’s Goose incubation time again

Goose eggs – pure aggression in a small package. Apparently geese spew the eggs out, about 30 per goose per year, then collect them all up and sit on ’em. Last year we incubated some eggs, and because geese are waterfowl, getting the humidity right is key to improving the hit-rate.

look out, here comes trouble

look out, here comes trouble

Last year I used Xively for the display, but the Cosm/Xively TCP stack is ratty. Certainly for an Arduino, which has only just enough horsepower to run a TCP/IP stack, but the Xively linux library wasn’t that reliable on the Raspberry Pi that I now use as a concentrator.

goose eggs

goose eggs

Incubator temperature

I now use RRDtool, which can run on the Raspberry Pi,

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install rrdtool

and there is a Python library that can inject data into the RRD databases called python-rrdtool

I really didn’t get on with python-rrdtool, I invoke RRDtool explicity

getstatusoutput("/usr/bin/rrdtool update "+DIR+"AB N:1234")

where DIR is the full directory path





Improving the coverage of the sensor radio network

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

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

remote sensing LLAP to SMS gateway

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 sirte - the Raspberry Pi does most of the work

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 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

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 [email protected] 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.

thermistor board with XRF

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

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

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

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 miocrocontroller/XRF dual dallas 18B20 control box

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 implemented

Ciseco OpenKontrol Gateway on lid of device, with Dallas 1307 RTC implemented

the finished LLAP to SMS gateway

the 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.

A denser LLAP serial RF data format

Ciseco’s LLAP format is a nice lightweight and PIC microcontroller and Arduino friendly serial protocol. I use their XRF modules for RF communication, these support power-down so they are well-suited to intermittent operation off a battery. Standing current on receive is 23mA so continuous operation is more of a challenge, for instance at the RF to SMS gateway. It has 12 bytes like so:

LLAP Message format

Each message is exactly 12 characters long and in three distinct sections:

  • One start byte
  • Two bytes for the device identifier
  • Nine data bytes, padded by dashes if necessary.

<SB> <ID> <ID> <D> <D> <D> <D> <D> <D> <D> <D> <D>

See Appendix 3 for details of the permissible characters in each field.

Their examples, however, send only one data value per LLAP message, with a descriptive section. Hence


Which is wasteful IMO. A lot of sensors have two data points,for instance temperature difference measurements, or temperature and relative humidity.

Few real world sensors  can justify the precision of using all the digits; I don’t have any with an accuracy of more than three digits. Sensing temperature to an accuracy of 0.1C is unusual – the popular dalas 18B20 is accurate to 0.5C but to do much more implies a piece of laboratory equipment. Useful values of temperature in the UK would be -20 to 120 °C, Relative humidity is 0 to 100 – cheap sensors don’t really justify a .x so allocating four digits covers most bases. Negative values give the ugly -21. as the – takes up a digit but it’s only a machine that sees it. So I can make a double density device as


and keep within the spec. I use **** for failed or missing sensors, and the X is replaced by L,M or H for battery status. M and H are operational, L means may be about to switch off in a few cycles. In sensors that support H then M means would still accept charge, H is enough. However I use a simple comparator at about 4.4 V on a PIC 16F628 so I can only show L and M.

This saves me precious power, and allows me to consolidate two temperature sensors to one radio saving cost of the radio and aggravation of maintaining batteries.


two-sensor PIC and XRF device

two-sensor PIC and XRF device

I couldn’t use JAL for this because I laid out the board to use the 16F628’s internal oscillator that runs at 4MHz and the JAL one-wire lib wants to run at 20MHz. So I had to code it in assembler 🙁 Next time I’ll leave space for a 20MHz resonator on the board that will save me all that grief.

I now get to read two temp sensor and the battery status, all in one LLAP message 🙂