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

An open-access cloud-detection network

Introduction

Living in the North-West of England I find that my attempts to view the aurora or astronomical events such as meteor showers, lunar eclipses and comets are often prevented by cloud. On these occasions I wonder if it is worthwhile driving somewhere to find some clear sky. But where? If only I could look at a map to see where it was clear now. Publicly-available satellite images don't appear to have the resolution needed for this purpose. Maybe I should go to bed instead and wait for an alert when the skies have cleared? Could the question of where and when to find clear skies be answered by an open-access cloud detection network operated by citizen-science volunteers?

Requirements

I've together a draft list of requirements to construct a useful network:

• Open-access. While my primary concern is with viewing the aurora I can see there are many other uses of such a network. Astronomy and obviously meteorology. Open-access enables other observers to make use of the data for their own purposes.
• Near real-time. The weather here can quickly change. Ideally measurements should be taken every few minutes and be made available without unnecessary delay.
• Use open-source hardware (OSHW). More specifically, an OSHW design should exist which allows users to contribute readings with the lowest possible cost.
• Large geographical coverage. 
• Night time operation required, day time beneficial.

The most difficult requirement to satisfy is the coverage. With ground-based sensors the viewing area might be as small as 2km diameter (cloud-base 1000m, optical viewing angle ±45°); at this size complete coverage of Great Britain would require over 57000 installations. A useful network does not require complete coverage, for auroral and astronomical purposes good results could be achieved by positioning sensors in a few viewing locations selected for low light pollution.

Remotely-sensing clouds

Perhaps the simplest method to remotely-sense cloud cover is to measure the 'sky' temperature with a non-contact infra-red (IR) thermometer. In the absence of cloud cover this is very low (say -12 to -20°C for Spring in the UK) but with cloud cover the temperature measured is warmer (0 to 4°C). These temperatures vary over the course of the year but by looking at the difference between the sky and ambient ground-level temperatures an estimate of cloud cover is possible. Some of these themopile sensors have a digital output for interfacing directly with a microcontroller.

A camera and image-recognition software is another approach but it is more complex to develop, install and operate. It is not clear how such a system would perform at night. In order to install the maximum number of sensors I plan to concentrate on cheaper methods.

Design concept

I believe there are two key factors which limit the number of sensors in the network: cost and ease of installation. To minimise the infrastructure I plan to begin with a battery-powered unit which communicates with a Raspberry Pi (or other computer) via a low-cost, licence-free radio module. This is the same concept used by the AuroraWatchNet magnetometer sensors.

Potential problems

Precipitation (rain, snow, hail) and dew on the sensor will prevent accurate sky temperature measurements, most likely indicating cloud when it may in fact be clear. A heater to prevent dew forming is an option but the temperature gradients may cause the thermopile to give incorrect measurements. The power consumption needed is incompatible with battery operation. It may be possible to point the sensor downwards, to avoid precipitation and dew, and use a reflective metal surface to observe the sky. Tests shows the sky temperature readings are partially compromised by this approach.

Sensor

I have found a number of sensors which may be suitable:

• Melexis MLX90614. This sensor contains thermopiles for sensing both the object and ambient temperature. An SMBus interface enables direct connection to a microcontroller. It is packaged in a TO-39 metal can. The standard 3.3V operation, 90° field of view (FOV) variant is readily available in single quantities from UK hobby electronics stores for around £15 each. Other variants exist for 5V operation and with different fields of view (10°, 35°, and a dual 70° FOV). The minimum object temperature is -70°C. The only irritation is that the sleep mode requirements are not compatible with low-power operation on a I2C bus.
• Melexis MLX90615. Similar to the MLX90614 but the sleep mode requirements are compatible with low-power operation on an I2C bus. Cost is similar to MLX90614 but no UK supplier exists. Package is a TO-46 metal can. Limited to 3.3V operation and a single FOV (80° or 100° variants). The minimum object temperature is -40°C.
• Texas Instruments TMP006. Small thermopile with I2C interface for direct connection to a microcontroller. Ball-grid array package. Readily available from UK suppliers. Cost is around £3 each for single quantities.
• Thermometrics ZTP-135SR. Thermopile with analogue output in a TO-46 package, with a thermistor for ambient temperature measurement. Being an analogue output additional processing is required. Around £10 from Farnell.
• Devantech TPA81. Linear array of 8 thermopiles. Cost is around £65.
• Panasonic AMG88 Grid-EYE. An 8×8 imaging sensor in a surface-mount package. The minimum object temperature is -40°C. Available from Digikey for around $40.

For the prototype system I plan to use the Melexis MLX90614 sensor. It should be possible to work around the problems with low-power operation by using software I2C and powering the sensor from a logic output, allowing power to be completely removed when not in use.

I excluded the TMP006 because the BGA package is hard to work with; not only is it difficult to solder it will require some kind of enclosure or window to protect it from moisture. Only a few materials are transparent to long-wave infra-red emissions and the better ones are toxic, water-soluble or expensive. The other sensors may be suitable but are more expensive. The TPA-81 linear array and Grid-EYE imaging sensor could provide spatial discrimination and thus distinguish between a thin layer of complete cloud cover and denser clouds with open areas of sky.

Initial results

Initial tests with the Melexis MLX90614 sensor confirm the concept is viable. I have not noticed any ill-effects from the sun within the field of view, suggesting that daytime operation is possible. Further work is required to package the system into a usable prototype which can be deployed outside permanently. Full-time operation will indicate the frequency of measurement errors from dew and precipitation.

Other work

It would be wrong to suggest I am the first to make measurements of cloud cover in this way, useful links are listed below. I am not aware of any existing cloud detection networks.

http://bildr.org/2011/02/mlx90614-arduino/

Useful code for interfacing the MLX90614 IR thermometer with an Arduino. This code works with my Calunium Arduino clone.

http://www.kwos.org/clouds_detector.htm

Good background information.

http://kcotar.org/arduino-weather-station-1/
A weather station which uses the Melexis MLX90614 sensor for cloud detection.

http://www.noao.edu/staff/gillespie/projects/cloud-detector.html
Similar in concept but using a Peltier device (in reverse) to measure the difference between ambient ground temperature and sky temperature.

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

Three-axis sensor unit for AuroraWatchNet

Three-axis sensor unit. The RJ-45 connector is for power and I2C data signals, not Ethernet.

AuroraWatchNet is a network of magnetometers for auroral alerts and citizen science. Whilst the  magnetometer is intended to function with one single-axis FLC100 sensor from Stefan-Mayer Instruments I have designed the system to support 3-axis operation by mounting 3 sensor boards at 90° to each other using just standard right-angle PCB connectors. This approach avoids the requirement for external mounting hardware which would be expensive to manufacture.

The power supply (a charge-pump DC-DC converter), temperature sensor and RJ-45 connector are fitted to just one circuit board. It is possible to use only one analogue-to-digital converter (ADC) but given their low cost it was presumed they would be fitted to all boards to enable simultaneous sampling of all 3 axes. The MCP3424 converter was chosen because eight options are available for the I2C address, thus jumpers can be fitted to select a unique address for every ADC on the I2C bus. This converter also features 4 input channels. All magnetometer outputs and the temperature sensor are connected to each ADC so that the spare channels can provide some redundancy in case of an ADC failure. The SYNC connectors of all sensors are linked to synchronise their excitation frequencies.

Several single-axis units have been built and one is in active use by AuroraWatch UK. The photograph above shows the first three-axis unit to be built. Initial testing indicates it functions as intended but the performance of 3 simultaneously-powered sensors in close proximity is yet to be established.

The importance of brown-out detection

The batteries expired in one of the AuroraWatchNet test magnetometers this week. I was expecting that to happen since the magnetometer wasn't operating in its low-power mode and the battery voltage from the two 1.5V alkaline cells had been hovering around 2V for some time. The Atmel ATmega1284P microcontroller is actually powered at 3.3V using a boost power supply. What I didn't expect was for the system to not start after replacing the battery. I could tell xboot was working since the LED flashed 3 times as usual after the reset button was pressed. After that the LED stayed on but nothing else happened, not even the start-up debug messages from the serial port. I guessed the flash program memory had somehow got corrupted.

I used the AVR Dragon to extract the contents of the flash memory (avrdude -P usb -c dragon_jtag -p atmega1284p -U flash:r:flash.img:r) and compared it against the saved raw image file using the linux split and cmp commands. Sure enough, three pages of flash memory were set to 0xFF, probably from some erroneous page clear operation. Brown-out detection was disabled by the fuse settings to save power. Big mistake! What I think happened was as the voltage dipped below its valid range the microcontroller started executing random commands, including 3 SPM page clears, one of which was the first page of flash which holds the interrupt vector table. Valid execution was doomed.

What I should have done was to enable brown-out detection in the fuses, 2.7V seems the most appropriate setting for an 8MHz clock and 3.3V operation. To save power during sleeping the brown-out detection can be disabled with a call to sleep_bod_disable(). Lesson learned!

Calunium: version 2.1

Calunium v2.1.
Click on the image for an annotated version.

This upgrade to Calunium v2 provides several minor improvements. There is the option to fit a Microchip MCP220 UART-USB converter instead of the FTDI connector. For development purposes the MCP2200 is much more convenient than an external FTDI cable or adaptor; operation at both 3.3V and 5V is supported. For low-power battery operation the MCP2200 uses too much power so the FTDI connector option has been retained.

I find I operate Calunium almost exclusively at 3.3V. I've not been able to find any real-time clocks in a dual-in-line package that operate at 3.3V and feature battery-backup. Suitable clocks are supplied in a SOIC or smaller package. I have therefore removed the DIP footprint option for the real-time clock. The space saved has allowed me to add optional load capacitors for the crystal so that a MicroChip MCP7941x real-time clock can be used. This clock has several benefits over the popular DS1307 (or its 3.3V equivalent, the DS1338). It is cheaper, it can compensate for crystal frequency errors, it has EEPROM storage, two alarms and it also has a unique identifier. This change goes against one of the original aims of Calunium, to use through-hole components to keep it accessible to the widest possible audience. However, considering the other interesting on-board peripherals (micro-SD socket, RFM12B and MCP2200) require surface-mount soldering skills I thought this a reasonable compromise to make. The original through-hole only designs are still available for those who really do not want to use any surface-mount components.

The final improvement is that the SPI clock signal is now routed with a ground plane between it and the real-time clock crystal.

For the full list of features please see the original Calunium v2 blog post.

Calunium v2 (top) and v2.1 (bottom) PCBs.
Click on the image for an annotated version.

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.