Using the Raspberry Pi sense hat to show the AuroraWatch UK status

Image © Barry Osborne 2017. Used with permission.

This post uses the Raspberry Pi sense hat to display the AuroraWatch UK alert status. It assumes you already have Raspbian installed on a Raspberry Pi, networking configured and enabled, and the sense hat fitted to the Pi.

The current status level is easily obtained from the AuroraWatch UK API with a custom python module. First, ensure you have the necessary python modules installed from the Raspbian software archive:

sudo apt-get update
sudo apt-get install python-lxml python-requests python-six

Then install two custom python modules. We will install them into the user profile, so run these commands as the user pi:

pip install --user --no-deps atomiccreate
pip install --user --no-deps aurorawatchuk

Finally, download the python script which fetches the status and displays it on the sense hat (I used bit.ly to shorten the original GitHub URL):

wget https://bit.ly/awuk-status-on-sense-hat -O awuk_sense_hat.py

The AuroraWatch UK status can then be displayed on the sense hat with this simple command:

python awuk_sense_hat.py

The program will monitor the current status and set the LED colours to show the status level (green, yellow, amber or red). For more information about the AuroraWatch UK status level meaning and interpretation see http://aurorawatch.lancs.ac.uk/alerts/. If you don't have a sense hat (I don't) it is even possible to try this with the sense hat emulator.

Credits

The geomagnetic activity status is courtesy of AuroraWatch UK and uses data from the SAMNET and AuroraWatchNet magnetometers.See also the AuroraWatch UK conditions of use for the API.

Thanks to Barry Osborne for testing the software with a real Raspberry Pi sense hat, and for providing the photograph.

AuroraWatch UK camera update #1

ZWO ASI 174MC colour USB 3.0 camera. Image from ZWO website.

Recently AuroraWatch UK purchased a ZWO ASI174MC colour USB 3.0 camera to (hopefully) record images of the aurora. The aim is to build an all-sky imager. To minimise the cost the camera will be connected to a Raspberry Pi single-board computer and be located outside in a waterproof enclosure. This particular camera was chosen for several reasons:

• No mechanical shutter to wear out. 
• The large pixel size (5.86um) should give good sensitivity. 
• The sensor has an IR cut-off filter fitted (filters cannot be used with the fish-eye lens). 
• The manufacturer provides support to access the camera from Linux. 

At present the Linux support from ZWO is limited to a software development kit (SDK) which provides a C language library and header file. This is sufficient for a Raspberry Pi to be able to interface with the camera. However my preferred approach is to write the image capture and control software in Python since that will simplify development and access to the AuroraWatch UK API. I therefore decided to write a Python wrapper for the C library. This is not something I have done before and after a little experimentation with ctypes, Cython and CFFI and I settled on using ctypes. You can find the source code for my Python wrapper on Github. It's also available on pypi so you can install it simply by running "pip install zwoasi".

I've written a short demo program to illustrate how to access the camera from Python. The camera can operate in two modes. The first, snapshot mode, takes a single exposure. The second, video mode,  continually takes exposures which can be downloaded from the camera as and when required. At first glance either mode would appear suitable for the purpose of taking a single exposure once a minute. My main concern is how to set the exposure correctly for an automated system which will run in a variety of different lighting levels (twilight, nighttime, and possibly even daytime). Fortunately this particularly camera provides an auto-exposure mode which can adjust the exposure time and gain settings according to the ambient light levels. It does this by analysing the image histogram after each exposure. The documentation doesn't explain the auto-exposure mode but I suspected that the camera would have to be operated in video mode for this to work. A quick test proved this to be correct. How well the auto-exposure algorithm works at night has yet to be discovered; since it is an astronomy camera I'm optimistic that it will be suitable and save me from having to implement an exposure control algorithm.

Sample image from ASI174MC and Fukinon FE185C057HA-1 2/3" fisheye lens.

The complete control system is intended to timestamp and watermark images, change the recording cadence according to AuroraWatch UK status and solar elevation, record temperature and humidity, and control heating and fans.

FTDI all-in-one serial converter, programmer, switch

FTDI all-in-one PCB layout.

There are a multitude of FTDI converters and breakout boards available but none of them exactly fitted my needs so this is my version tuned to suit my requirements. I'm publishing the design files in the hope they are useful for others. Like the Sparkfun FTDI Basic Breakout and the Adafruit FTDI Friend it uses the FTDI FT232R but there are a number of differences, for instance it has a USB type A connector to plug directly into a USB host port.

Serial converter

The FTDI AIO provides a serial adaptor with the standard 6 pin FTDI pinout (TX, RX, CTS, DTR, VCC, and GND). A jumper block enables the VCC pin to be switched between +3.3V and +5V. A separate jumper enables the logic levels of the TX, RX, DTR and CTS signals to be set for +3.3V or +5V operation. The Sparkfun FTDI Basic Breakout can also be switched between +3.3V and +5V operation but does not allow for independent selection of VCC and the logic levels. This means when the Sparkfun FTDI Basic is set for +3.3V operation it's not compatible with the standard FTDI cables, which always supply +5V to the VCC pin. Whether that's a good thing or a bad thing depends on your needs; the FTDI AIO gives you both options.

AVR ISP programmer

Programming AVR microcontrollers, even with just a small bootloader, can be painfully slow and normally I'd use the AVR Dragon. There are situations however where it would be useful to have a low-cost USB programmer. A bit-banging AVR programmer is easily made and Adafruit has an excellent tutorial which explains how to do this.The FTDI all-in-one makes this convenient by providing the standard AVR ISP header. The defacto AVR standard is that the VCC pin is set to the same voltage as the logic-level signals. Unfortunately this practice isn't followed by +3.3V Arduino boards which always set VCC to +5V. For the widest compatibility the AVR ISP VCC pin can be set to either +3.3V or +5V with the logic levels of the !RESET, MISO, MOSI and SCK signals independently configured to either  +3.3V or +5V.

On-board +3.3V voltage regulator

One of the features of the FT232R is that it has a built-in +3.3V regulator. This was used by older Arduinos to provide a +3.3V supply. However the current capability is limited to just 50mA which in many cases is not sufficient to power a microcontroller and all of its peripherals. The FTDI all-in-one can include an on-board voltage regulator with 250mA current output which should be sufficient to power an Arduino and several shields.

Auxiliary switch and LED

One of the key features I wanted was the ability to add an auxiliary switch and LED to the Raspberry Pi. Although the Pi has GPIO the AuroraWatchNet magnetometers normally have a radio fitted to this connector, which prevents it being easily used for other purposes. I worked around this by wiring a switch and LED to a Sparkfun FTDI Basic Breakout but I wanted a single PCB which plugged directly into one of the Pi's USB sockets.

Why would you want a switch? There are probably many uses. Mine is that I run one of the AuroraWatchNet magnetometers and I wanted a way to conveniently signal when I am going to cut the grass, or make some other magnetic disturbance in the garden.The data logging software, which runs on a Raspberry Pi, checks for the existence of a file which signals data quality might be bad. When the file is present data is logged to a separate set of files which aren't used by the AuroraWatch UK alerts system. While it's no bother for me to create the file by logging into the Pi I needed something simpler for other members of the family, so I wanted to wire up a switch. A separate daemon monitors the serial port to detect if the switch is pressed, if so the LED is turned on and the semaphore file created. If the switch is pressed again the file is removed and the LED turned off. The LED actually tracks the state of the file being present so it is possible to override the monitor process by creating or removing the semaphore file by other means.

Breakout board

All of the GPIO pins from the FTDI FT232R are conveniently broken out to pads spaced at 0.1" pitch. Also included are pads for the filtered +5V supply obtained from USB and +3.3V from the on-board regulator (if fitted, otherwise from the FT232R's built-in regulator).

Why use the FT232R?

Given the recent controversy regarding FTDI and Windows drivers you might wonder why I am using the FT232R instead of some other device. I'd probably prefer to use the Microchip MCP2200 USB UART converter for this application as it works well with my Calunium Arduino clone and it is available in a SOIC package which is easier to work with at home. Unfortunately its not possible to read the CTS line with the USB CDC driver which rules it out.

Open-source hardware

The Eagle PCB design files are available on Github and are licensed under the Creative Commons Attribution-ShareAlike 3.0 (CC BY-SA 3.0) license.

The PCB layout is not yet tested, although I did breadboard and test all of the functionality. I'll be sending the design off for manufacture in the next few days, it's likely I'll have a few boards spare.

Update: the first boards have been assembled and tested; all features work as planned. The bit-banging AVR ISP programmer is even slower than I feared, taking about 10 minutes to read the 4Kb EEPROM on the Atmel ATmega1284P on one of my Calunium boards.

Cloud detector: a review of progress so far

The hardware

My cloud detector has been running outside for over 5 months now. Overall I'm very pleased with how it works. The battery-powered hardware is based on the AuroraWatchNet magnetometer design, which uses my own Calunium microcontroller development board. The remote sensor board and fluxgate sensor are omitted. I've added a Melexis MLX90614 non-contact infra-red thermometer to measure the sky temperature. Clear skies should give low temperatures whilst clouds are expected to have warmer temperatures, although still colder than the ambient temperature. The MLX90614 also outputs the sensor temperature, which should be close to the ambient temperature. I also added a Honeywell HIH-6131-021 humidity sensor which has an I2C interface. Do not confuse with the similar sounding version which has an SPI interface! The HIH-6130 also provides and ambient temperature measurement. To avoid direct contact with water the humidity sensor is placed at the bottom of the enclosure with a hole underneath to expose it to air. This hole also functions as a breather hole and ensures that the internal pressure matches atmospheric pressure. Since this hole was drilled there have not been any more incidents of water ingress.

The Calunium board is running a firmware is a modified version of the magnetometer firmware. It communicates with the Raspberry Pi data logger using an 868MHz radio link, with the same signed communication protocol used by AuroraWatchNet. This means I can use the data recording software from AuroraWatchNet. It also inherits the signed over-the-air firmware update capability. In principle it should be possible to combine both magnetometer and cloud detector functions in one unit.

I started off using the 90°  field-of-view version of the non-contact IR thermometer but later switched to theMLX90614ESF-DCH-000-TU-ND variant which features a 12° field of view. Its greater height meant it was easier to fit into the cable grommet housing. However I think the FOV is too narrow and I plan to switch back to the original sensor when I have time.

Data processing

The data processing and plotting now uses the auroraplot library for Python, which I developed to process the AuroraWatchNet magnetometer data. On the graphs I plot the sky temperature measured by the non-contact IR thermometer and the ambient temperature measured by the humidity sensor. For monitoring purposes I also plot the sensor temperature of the IR thermometer (marked as "detector temperature"); this should be similar to the ambient temperature but its exposed position makes it more likely to undergo solar heating and radiative cooling. For good measure I also plot the system temperature, which is measured by an LM61 temperature sensor connected to the ATmega1284P's analogue to digital converter. This measurement is noisy but useful to check the system doesn't overheat on sunny summer days.

The plan is to estimate the upper and lower bounds that I would expect for the sky temperature, and from that derive an estimate of the cloud cover. I initially expected that with complete cloud cover the sky temperature would match that the lifted condensation level, which I estimate using the ambient temperature and relative humidity. I soon saw temperatures higher than the LCL temperature. Research literature indicates that the clouds can act as a mirror at long IR wavelengths and thus the expected temperature should include an effect of ground temperature too. On the plots this is shown as the effective cloud temperature. The clear sky temperature is derived from results found in research literature but none of the equations tried so far have been a great match. Other researchers have fitted parameters for their specific location (including altitude) by comparison with visual measurements. I have yet to try this but daily measurements are made at the nearby Hazelrigg Weather Station. The graphs are too cluttered for production use but help me to understand what is happening.

Example plots

Below are a selection of plots. You can see the entire archive (from 2013-07-14) at http://aurorawatch.lancs.ac.uk/testing/cloudwatch/test2/.

Cloud detector data for 2013-09-03. The asterisk (*) indicates derived parameters (ie not directly measured).

The figure above include most of the effects that can be identified. After midnight there is thick cloud, which later clears for short periods. At around 0300 UT I think it must have rained, the sky temperature is almost identical to the detector temperature and the variability is much reduced. Whilst the sensor is wet no sensible conclusions about cloud cover can be drawn. At about 0700 UT the sensor clears of water and the sky temperature falls indicating clearer skies. The rest of the day is dry, with heavy cloud cover until 1400 UT. At around 1700 UT the skies are completely clear. The clear sky estimate is too low for this time. At 2000 UT the clouds return, with some clear patches.

Cloud detector data for 2013-09-28 showing the effect of clear skies.

The figure above shows an almost completely cloud-free day. The higher variability in the sky temperature measurements between 1200-1600 UT corresponds to similar effects in the humidity data (shown below); both are direct measurements made by different sensors.

Humidity data for 2013-09-28. Notice how the higher variability occurs at the same times as the sky temperature measurements.

Dew

During summer operation dew has not been a problem but now that the nights are colder I have noticed effects which I believe are due to the formation of dew on the sensor. In the first plot below the sky temperature apparently rises from around 2230 UT. The rise is smooth and during this period the ambient temperature is falling, which overnight is often a sign of clear skies. After midnight (second plot) the sky temperature increases slightly before falling sharply around 0630 UT. Sunrise on this day was 0622 UT.

This pair of plots is believed to show dew formation on the sensor.

Conclusions

I know from the informal comparisons with visual cloud cover that I regularly make the cloud detector does generally work very well. It does not function during wet periods. As anticipated dew is becoming a problem during the colder nights and a dew heater will be required for reliable winter operation. Future development will be to add a heater, which will need a wired connection to the cloud detector. Once a wired connection is made the radio link appears superfluous so I plan to investigate the options for power-over-ethernet. The Arduino ethernet shield is one possibility, although its compatibility with 3.3V operation has not been established.

Securing your SSH server against brute force password attacks

If you run an SSH server open to the whole internet you'll soon notice many attempts to break into your system using random username and password combinations. This 'noise' in the log files is annoying and might mean you miss an important message. If you are unlucky or use a common username and password your system might be compromised by one of these brute force attacks.

One method to drastically reduce the number of cracking attempts is to restrict access to the SSH server by IP address. This can done be done either by editing the SSH config file or by using configuring iptables. However this method requires valid users to have static IP addresses, something which most home users don't have. In many cases public key authentication is a better choice.

Use public key authentication

A better method to stop attackers from using random username and passwords is to switch off password authentication entirely and require public key authentication instead. Attackers will not be able to try random username/password combinations and will not create 'noise' in the log files. Valid users will still be able to connect.

To describe how this can be set up assume we wish to protect a computer with a static IP address called server. We wish to access it from another system called laptop, (which may be using a dynamic IP address). The account on server that we will access is dave. We'll assume that the SSH configuration file is /etc/ssh/sshd_config. Adjust these names to suit your setup.

Firstly, on laptop create a public/private key pair.

ssh-keygen -t dsa

A passphrase is not required although it is a good idea. On server make sure a ~/.ssh directory exists with the correct permissions:

mkdir ~dave/.ssh
chmod go= ~dave/.ssh

Using your favourite editor (emacs of course) paste the contents of the public key into the ~dave/.ssh/authorized_keys file on server. Putty users may find the instructions at http://www.howtoforge.com/ssh_key_based_logins_putty helpful. Check that you can log into server without requiring your password. If you are going to configure server remotely ensure you can log in without needing your password, otherwise you will lock yourself out! If you set a passphrase you will need to type that.

Configure the server

The key requirement for the server configuration is that by default password authentication is turned off. Find the line in /etc/ssh/sshd_config which sets password authentication. Make sure it is set to

PasswordAuthentication no

If necessary remove any leading # character. Whilst editting /etc/ssh/sshd_config its a good idea to disable empty passwords and root logins, ensure the following lines are set

PermitEmptyPasswords no
PermitRootLogin no

If you need empty passwords or root logins from specific hosts this can be overridden later.

Enable password authentication for trusted hosts

Once password authentication is disabled users on a multi-user system will have a problems copying their keys to grant them access! Exceptions can be made for trusted static IP addresses so that users can copy their public key. Assume we trust all IP addresses in the subnet 192.168.1.0/24. Passwords can then be enabled by simply adding the following lines to the end of /etc/ssh/sshd_config

Match Address 192.168.1.0/24
PasswordAuthentication yes

Enable root logins

Suppose a root login using password authentication is required for one host only (192.168.1.123). Add the following lines to /etc/ssh/sshd_config

Match Address 192.168.1.123
PasswordAuthentication yes
PermitRootLogin yes

Summary

These simple steps keep your SSH server accessible from everywhere but greatly reduce the likelihood of a successful brute force attack. The Match keyword requires openssh version 4.4 or later.

Cloud detector progress

Microcontroller and radio communications

To minimise the time and effort required to test the cloud detector concept I am following the approach used for the AuroraWatchNet magnetometer system and reusing as much hardware from it as possible. The MLX90614 non-contact infra-red temperature sensor is located outside. To minimise the infrastructure requirements the sensor unit is battery-powered and transmits its data over a bi-directional radio link. The sensor is controlled by one of my Calunium v2 microcontroller development boards. I'm using a pair of RFM12B radio modules operating at 433MHz to emulate a transparent serial connection. One is fitted on  the Calunium board and the other radio module is connected to a Raspberry Pi via my RFM12B shield. The Pi records the data and is responsible for uploading it for general access. I am also reusing most of the AuroraWatchNet firmware, which means I already have signed data communications and the capability to deploy over-the-air firmware updates - quite a good starting position for a new project!

Waterproofing the sensor

The biggest challenge I expect to face with this project is waterproofing the sensor. Although it is hermetically sealed there is no easy way to deploy it outside. As explained in a previous post, only a few materials are transparent to long-wave infra-red emissions and the better ones are toxic, water-soluble or expensive. I am therefore trying to avoid covering the sensor window and instead keep the electrical contacts dry. My first attempt was to drill a hole in the box and attach the sensor with silicone sealant. The mechanical fixing lacked strength and I wasn't convinced I had completely sealed around the sensor. To make matters worse I ended up with sealant on the sensor window which had to be cleaned off before it set. Another approach was required.

The new approach is to fit the sensor inside a cable gland. Before doing so I had to attach wires to the sensor connectors and insulate with heat-shrink sleeving. The result is shown below.

The next step is to fit the sensor in the cable gland before fitting the cable gland to the box.

The other end of the wires can then be soldered. For the prototype the wires are soldered to a small piece of stripboard. The stripboard has two pull-up resistors for the I2C bus and a decoupling capacitor. There is also an IDC connector to link the board to the unused JTAG interface. This was the easiest way to connect to a stock Calunium v2 board. For the lowest power operation the sensor is powered from logic-level output and I am using software I2C so all connections can be grounded when the sensor is not in use. The real-time clock on Calunium is connected the the hardware I2C interface on the microntroller and can be operated independently of the sensor.

The box and cable gland are rated IP65. Hopefully the result will be waterproof  

Results

The sensor is now deployed outside and reporting back to the Raspberry Pi base station. The transmitted packets are logged by the Raspberry Pi but as yet I don't have a convenient way to extract the ambient and object temperatures for analysis. That is the next task.

How to use the GPIO version of avrdude on the Raspberry Pi

Introduction

I previously showed an implementation of a AVR ISP programmer using the Raspberry Pi GPIO port which can be used to program Atmel's AVR range of microcontrollers with avrdude. An ISP programmer based on this design was incorporated into a shield to interface to the RFM12B radio module. This post explains how to use avrdude to actually program devices.

Software installation

Download the patched version of avrdude from http://project-downloads.drogon.net/files/. I also keep a copy in the RPi_RFM12B_ISP respository, https://github.com/stevemarple/RPi_RFM12B_ISP/tree/master/software/avrdude. You will probably want the armhf (hardware floating-point) version. Download the documentation package for avrdude too. Install the packages using "dpkg -i". For example

sudo dpkg -i avrdude_5.10-4_armhf.deb
sudo dpkg -i avrdude-doc_5.10-4_all.deb

Using avrdude over the GPIO interface is problematic for users other than root. The easiest solution is to give the avrdude binary setgroup permission:

sudo chmod g+s /usr/bin/avrdude

Usage

Selecting the GPIO programmer is simply a matter of including "-P gpio -c gpio" options; the -P option specifies that the GPIO port is used (as opposed to USB, serial or parallel interfaces) whilst the -c option selects the correct programmer type on that port.

For example, to check the signature on an ATmega328P execute the command

avrdude -P gpio -c gpio -p atmega328p

To read the fuses execute the command

avrdude -P gpio -c gpio -p atmega328 -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h

Customisation

The packages above define a single programmer called gpio which uses the gpio interface on GPIO pins 8 to 11. Since the RFM12B shield for Raspberry Pi implements two independent programmers I prefer to use gpio0 and gpio1. You can add these by creating a .avrduderc file in your home directory. The file should contain:

programmer
  id    = "gpio0";
  desc  = "Use sysfs interface to bitbang GPIO lines";
  type  = gpio;
  reset = 8;
  sck   = 11;
  mosi  = 10;
  miso  = 9;
;

programmer
  id    = "gpio1";
  desc  = "Use sysfs interface to bitbang GPIO lines";
  type  = gpio;
  reset = 7;
  sck   = 11;
  mosi  = 10;
  miso  = 9;
;

RFM12B shield for Raspberry Pi

RFM12B shield for Raspberry Pi, with integrated in-circuit serial programmer.
Click on the image for an annotated version. 

I recently described the preliminary design of a RFM12B shield for the Raspberry Pi, which used an Atmel ATmega328 to interface between the Raspberry Pi's UART and the RFM12B's SPI interface. The design also included a buffered two-channel in-circuit serial programmer (ISP) using the Raspberry Pi's general purpose I/O. The first channel is for programming the on-board ATmega328 whilst the second channel can program external microcontrollers.

The boards have now been manufactured and the first one assembled and tested. The interface to the RFM12B and the built-in AVR ISP programmer both work as designed. I have been using the Arduino environment to compile and upload the firmware to the ATmega328. The microcontroller pin mapping is identical to the Arduino Uno although the activity LED is wired to D9 since D13 is normally in use by the SPI interface. The ATmega328 operates at 3.3V and is clocked by the internal 8MHz RC oscillator. No bootloader is needed. The Github repository contains boards.txt and programmers.txt files for use with the Arduino IDE, the standard Arduino core is used.

I have been using the first board to replace a Ciseco URF radio module. The firmware for the ATmega328 incorporates my transparent serial emulation layer. This provides a Stream object to which data can be read, and written (or printed), in just the same way as HardwareSerial and SoftwareSerial objects. The same emulation layer can then be used on remote Calunium, Arduino or JeeNode boards to provide a bi-directional data stream, allowing the user to interface to the RFM12B as easily as an XRF or XBee radio module. The emulation layer transparently uses acknowledgements and retries to provide a robust channel, which is an improvement over the Ciseco XRF and URF radio modules. Alternative firmware for the RFM12B shield is easily uploaded to provide different functionality.

ISP programmer

The avrdude configuration file contains details for two GPIO programmers; gpio0 is connected to the on-board ATmega328 and gpio1 is for programming external microcontrollers. By fitting a jumper to the JP1 header the external microcontroller can be powered from the Raspberry Pi's 3.3V supply. Be sure to observe the maximum current rating for the 3.3V supply and never fit the jumper if the remote microcontroller is self-powered. The 74LVC244 buffer ensures that MCUs operating at 5V can be safely connected. Typically the high output level from the 74LVC244 buffer will be recognised as a high but it doesn't meet the worst-case specifications when the external MCU is powered from 5V.

Open source

The Eagle PCB design files for the RFM12B/ISP shield for Raspberry Pi are available on Github and are licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. The RF12 transparent serial emulation layer is also available on Github and is released under the MIT license.

Errata

There is a connection missing on the schematic from the drain of FET Q2 to pin 5 (/RESET) on the external ISP header (X3). This connection is also missing from the PCB but can be easily fixed with a direct wire connection on the underside of the board.

Update

I've added a description of how to install and use the patched version of avrdude, http://blog.stevemarple.co.uk/2013/03/how-to-use-gpio-version-of-avrdude-on.html.

Magnetometer progress report

About AuroraWatchNet

I am developing a simple, low-cost, battery-powered magnetometer for auroral alerts and citizen science. It is intended to be wireless to allow easy installation, a unique feature as far as I am aware. The magnetometer uses my own Calunium micro-controller board, which is an Arduino clone based on the ATmega1284P micrcontroller. Data is sent via a radio link to a Raspberry Pi base station which will then forward the data to AuroraWatch UK. I am hoping to deploy a network of such magnetometers in 2013 to enable AuroraWatch UK users to contribute data to improve the service. If you want to track the development then follow @aurorawatchnet on Twitter. 

The first AuroraWatchNet magnetometer is currently running in my garden. The environment is not ideal as I can see disturbances from cars and even the garage door being opened but it is convenient for testing and representative of what to expect from user-contributed data. I have been comparing the results from our SAMNET magnetometers with the AuroraWatchNet prototypes and generally the results are very encouraging given the difference in cost between the two systems. Now I can plot the AuroraWatchNet magnetometer data in the standard AuroraWatch UK style, using the same Octave code. Below is a comparison of today's plots. 

AuroraWatch UK

The data is taken from SAMNET's Lancaster magnetometer. The X axis is time and the Y axis shows the magnetic field strength in the direction of magnetic North (H component) in nanotesla (nT) relative to an unrecorded baseline. This exact plot appeared on AuroraWatch UK. We would normally expect cleaner data but our Lancaster site has recently been experiencing some interference.

SAMNET data from Lancaster, as used by AuroraWatch UK

AuroraWatchNet test magnetometers

The plots below correspond to the same time interval as the plot above. The first plot is from my garden magnetometer.

AuroraWatchNet data from near Lancaster.

The Y axis again records magnetic field strength but this time it is the absolute field. This magnetometer is operating in power-saving mode, turning off the sensor when not needed. This slightly increases the noise level but I hope will give one year of operation from two D cells.

Another AuroraWatchNet magnetometer has been deployed almost adjacent to the SAMNET magnetometer we already use for AuroraWatch. In this system the magnetometer sensor is continually powered, resulting in reduced noise levels. The alignment with magnetic North is only approximate. 

AuroraWatchNet data from the Lancaster University field station.

Conclusion

The AuroraWatchNet magnetometers are sufficiently sensitive and stable to make useful contributions for auroral detection and citizen science. My experience with the garden magnetometer suggests that in many cases performance will be limited by the noise at the site, rather than the magnetometer.

RFM12B shield for Raspberry Pi: Preliminary design

Raspberry Pi interface to the RFM12B radio module, with integrated ISP programmer. The cut-out is to enable the PCB to fit inside the Multicomp Raspberry Pi case.

Current status

Earlier in the year I posted a design for a wireless gateway for the Raspberry Pi. It featured interfaces for the Hope RFM12 and XBee (or Ciseco XRF) radio modules. Also included was an in-circuit serial programming (ISP) programming interface for Atmel microcontrollers. I later refined the ISP interface to include some protection for the Raspberry Pi by adding a buffer and FET switch. I have not yet tried accessing the RFM12B directly from the Pi but other people have had problems, mainly it seems because of the time-critical interrupt handling. I'm sure this problem will eventually be solved once the Eve Alpha boards become widely available. Martin Harizanov solved this problem by adding an Atmel ATtiny microcontroller to bridge between the UART interface on the Pi and the SPI interface on the RFM12B. I bought a bare PCB that did this from the Open Energy Monitor shop. I tested the RFM12Pi Raspberry Pi Expansion board communicating with one of my Calunium v2 development boards, everything worked. Martin chose the ATtiny84 microcontroller which has just 512 bytes of RAM. I would like to have a solution which more closely mimics the Ciseco XRF module that I am currently using, which has a 240 byte buffer. One reason for needing a larger buffer is that the radio protocol I am using supports over the air firmware updates, with the new firmware sent in 128 byte blocks. If I am to implement something with 240 byte transmit and receive buffers I will need a microcontroller with more than 512 bytes of RAM.

Preliminary design

Based on my previous work and inspired by Martin Harizanov's implementation I have designed a RFM12B shield for the Raspberry Pi with integrated ISP interface. The microcontroller on this board is the popular ATmega328P, as used in the Arduino. Including the ISP interface has considerably increased the size of the PCB but this is a price I am willing to pay. The board is intended to be used as part of the AuroraWatchNet magnetometer network and the ability to remotely update the firmware will be very useful, especially since I can already perform over-the-air firmware upgrades on the battery-powered Calunium node. Surface-mount passive components could be used to reduce the PCB size but this would be contrary to my goal of making the AuroraWatchNet magnetometers easy to build for novice constructors.

The 74LVC244 buffer has two 4-bit line drivers, allowing two independent ISP interfaces to be included. The first is for the on-board ATmega328P microcontroller, the second is wired to a standard Atmel ISP header to allow an external microcontroller to be programmed. It means that the ATmega1284P used in the remote Calunium of the AuroraWatchNet magnetometers can be programmed initially, or recovered in the case of an over-the-air firmware upgrade mistake.

I hope to have some circuit boards made in January 2013 so if you spot any mistakes please let me know as soon as possible!

Open source

The Eagle PCB design files for the RFM12B/ISP shield for Raspberry Pi are available on Github and are licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License.

AVR/Arduino ISP programmer using the Raspberry Pi GPIOs

ISP programming of Calunium Arduino clone using Raspberry Pi GPIO. Click on the image for an annotated version.

Introduction

As a fully-featured Linux computer there are many external programmers that can be used with your Raspberry Pi to program the Atmel AVR range of microprocessors. It's also possible to use the general purpose input/output lines (GPIOs) found on the Raspberry Pi to implement an ISP programmer with minimal extra hardware. I say "with minimal extra hardware" because although it can be done with no extra hardware I recommend adding a buffer and FET to protect the Raspberry Pi. You might reasonably wonder what is the point if extra hardware should be used since external USB programmers can be bought cheaply from Ebay. However, if you are going to add an extension PCB to your Raspberry Pi anyway, for instance to communicate with a remote Atmel processor, then including an ISP programmer makes sense and adds very little cost.

AVR ISP programming interface

Most of the Atmel AVR range can be programmed using an ISP interface which resembles the SPI bus. For this description I'll assume that the SPI pins are reused for this purpose but you should check the datasheet to make sure this is true for your part. The RESET pin is used as the active-low chip select pin, SCK is the clock signal, MOSI is the input data pin and MISO is the output data pin. If the directions seem odd remember that the microcontroller is acting as a SPI slave in this scenario; with that in mind the names make perfect sense. The ISP programmer then communicates with the microcontroller, sending commands to read or write flash memory, EEPROM, fuses, and/or locks. Avrdude supports many different programmers which can be used for this task.

Raspberry Pi ISP programmer hardware

The simplest interface on the Raspberry Pi is to use four GPIO pins and bit-bang the SPI commands. I don't recommend this however. After programming has finished the SPI interface on the microcontroller could revert to master mode where SCK and MOSI become outputs. Connecting two logic outputs together which could be at opposite logic levels is not wise. For a safer interface I used the circuit below.

Schematic diagram of ISP programmer. Also available as full-size image, Eagle schematic or PDF.

On the target microcontroller the RESET signal is typically connected to a 10 kΩ pull-up resistor, often with a reset switch pulling to ground. The 2N7000 FET provides an open-drain interface which safely connects the Pi to RESET, even if the reset switch is pressed whilst the programmer is connected. Compare this to the case of directly wiring a Raspberry Pi GPIO; pressing the reset switch could short a high-level output directly to ground. Ouch. The 100 kΩ pull-down resistor connected to the gate of the FET ensures it is normally off (and thus RESET is high) when the reset GPIO pin is an input, such as after programming. The 100 kΩ resistor connected to RESET acts as a weak pull-up in case no pull-up resistor is connected to the microcontroller (e.g., for easy programming on a solderless breadboard). In the circuit above a jumper can be fitted to power the target microcontroller from the 3.3 V supply on the Raspberry Pi (care, maximum current 50 mA).

To protect the remaining Raspberry Pi GPIOs I have used a 74LVC244 buffer. The active-low OE (output enable) allows the outputs to be disconnected when the microcontroller is not held in its reset state. I chose this part because it operates at 3.3 V but safely tolerates 5 V on its inputs, and also 5 V applied to the outputs when they are in the high-impedance state.

The open-drain FET inverts the state of its input. In theory it should be possible to configure avrdude to account for this but I could not make it work with the patched GPIO support so I used a spare gate in the 74LVC244 to form a logic inverter. The circuit described above should be safe to use even if the target system operates at 5V (but don't fit the shunt to the jumper). I've not tested it, so make your own judgement! You should also note what whilst it should be safe, it isn't guaranteed to be reliable; typically the high output level from the 74LVC244 buffer will be recognised as a high but it doesn't meet the worst-case specifications.

GPIO pin mapping

Signal	GPIO	P1 header pin number
RESET	8	P1-24
SCK	11	P1-23
MOSI	10	P1-19
MISO	9	P1-21

Although the SPI has been implemented by bit-banging the pins chosen are the SPI pins on the Raspberry Pi P1 header.

Credits

Gordon Henderson for providing the patched avrdude compiled for the Raspberry Pi, see http://project-downloads.drogon.net/files/.

Radoslav Kolev who submitted the patch to add linux GPIO to avrdude.

Update

This design has been incorporated into my RFM12B shield for Raspberry Pi which contains a two-channel AVR ISP programmer. One channel is used to flash both the on-board ATmega328P, the other channel can be used to program external devices.

I've added a description of how to install and use the patched version of avrdude, http://blog.stevemarple.co.uk/2013/03/how-to-use-gpio-version-of-avrdude-on.html.

Wireless Gateway for Raspberry Pi

Wireless gateway for Raspberry Pi. Click on the image for an annotated version.

Introduction

A wireless gateway for the Raspberry Pi is presented. The gateway will connect remote clients to the Raspberry Pi and the internet. I plan to use these to connect a network of magnetometer sensors to improve the reliability and availability of the AuroraWatch UK network. The gateway can also be used to program Atmel AVR microcontrollers, as used in the magnetometer sensors.

Design Goals

• Footprint for XBee, Ciseco XRF, or similar radio module.
• Footprint for Hope RFM12B radio module.
• AVR ISP programming header.
• Maximum board size 50 mm × 50 mm (to use cheapest Iteadstudio PCB fabrication option).
• All unused digital I/O brought out to pads for easier extension, prototyping and hacking.

It is intended that all hardware directly interfacing with the gateway will use 3.3 V signal levels.

Features

The board has footprints for both RFM12B and XBee (or similar, such as the Ciseco XRF) radio modules and since they use different interfaces and GPIOs both can be used simultaneously. There is an FTDI connector to the Raspberry Pi's UART; this is shared with the XBee so both cannot be fitted at the same time. Only the minimum required set of digtal I/Os for each module have been hard wired. The RFM12B /CS input and /IRQ, and XBee /RESET, can be connected via jumpers. The remaining digital I/Os from the RFM12B, XBee and even the FTDI connector can be used by adding link wires to the desired Raspberry Pi's GPIOs on the second header footprint. If not needed then a pin header can be fitted to allow another expansion board to be stacked on top of the wireless gateway. The maximum current draw from the P1 connector's 3V3 pin is 50 mA. To enable higher power radio modules to be used the wireless gateway includes a built-in 3.3 V voltage regulator (250 mA limit)

Connecting to the gateway

To connect to the Raspberry Pi wireless gateway you might also be interested in Calunium, my shield-compatible Arduino clone based on the ATmega1284P. The latest version will include space for an RFM12B radio module.

Build it

At the moment the design is preliminary and untested. Eagle PCB design files are available under the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) licence. The files will be updated as the design progresses.

Warning!

The Wireless Gateway for Raspberry Pi is intended to be used with 3.3 V devices only. Using it with 5 V devices (e.g., Arduino) will very likely damage your Raspberry Pi.