Posts | Comments

Planet Arduino

Archive for the ‘Calunium’ Category

« Previous Entries
May
17

Calunium v2.1a

Calunium Comments Off on Calunium v2.1a 

I've made a few minor improvements to the Calunium design, partly to satisfy compatibility between Calunium and Arduino shields and partly to fix a few minor hardware errors.

Disconnect VCC from the ISP header

The ISP header is a 6 pin male header which can be used to program the microcontroller, such as to upload the bootloader. On Calunium the VCC pin of this header is wired to the same supply voltage used by the microcontroller, ie +3.3V or +5V depending upon the operating volatge selected. This makes sense, especially when used when programmers such as Atmel's AVR Dragon which use the pin to set the HIGH voltage level on the SCK and MOSI control lines. Unfortunately it seems that on Arduino devices (such as the Ethernet shield) this pin is always wired to +5V. This is true even for the latest hardware versions which should be aware of the operating voltage via the IOREF pin. To avoid the possibility of connecting the +3.3V and +5V supplies I added a jumper. For normal operation the shunt can be omitted. When using an ISP header programmer that needs to know the operating voltage a shunt can be added.

Pull-down resistor on D13 FET

Calunium uses a field-effect transistor (FET) to switch on the D13 LED. This is to avoid load on the D13 SCK line when it is used for SPI communications. I learnt this trick from Freetronics who do something similar with their range of clones. In normal use, when D13 is an output, everything works fine. However, when it is an input, such as during RESET state or bootloader programming, the FET gate can float to potential such that the LED is switched on. A 1 megaohm pull down resistor connected to D13 is sufficient to prevent this happening without loading the SCK line. It also helps prevent damage by electrostatic discharge. The latest Calunium design now has room to add this 1 megaohm resistor. On older boards an 0805 surface mount resistor can be fitted between the gate and source of the 2N7000 FET, or alternatively between the D13 and adjacent ground pin.

Auto-reset behaviour corrected for MCP2200 USB interface

I recently added the option of fitting the MCP2200 USB-serial interface. Despite suggestions to the contrary this useful USB  device can automatically reset the Arduino when the device is opened. This auto-reset behaviour as it is known is used to activate the bootloader when uploading sketches. The intention was that auto-reset could be disabled by removing a shunt from the AUTO RESET jumper. Unfortunately an error in the schematic meant that auto-reset could only be disabled when using the FTDI interface, not the MCP2200 option. The latest version corrects this error.

Silkscreen label corrected

On Calunium v2.1 a jumper was added to select FTDI or USB power. Due to a rotation of the component the correct position for the shunt is opposite to that indicated by the silkscreen label. The latest version corrects the text.

Open source

The Eagle PCB design files for Calunium are available on Github and are licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. Files to allow Calunium to be used with the Arduino 1.0 IDE are available on  Github and are licensed under the Gnu General Public License v2.

May
17

Calunium v2.1a

Calunium No comments 

I've made a few minor improvements to the Calunium design, partly to satisfy compatibility between Calunium and Arduino shields and partly to fix a few minor hardware errors.

Disconnect VCC from the ISP header

The ISP header is a 6 pin male header which can be used to program the microcontroller, such as to upload the bootloader. On Calunium the VCC pin of this header is wired to the same supply voltage used by the microcontroller, ie +3.3V or +5V depending upon the operating volatge selected. This makes sense, especially when used when programmers such as Atmel's AVR Dragon which use the pin to set the HIGH voltage level on the SCK and MOSI control lines. Unfortunately it seems that on Arduino devices (such as the Ethernet shield) this pin is always wired to +5V. This is true even for the latest hardware versions which should be aware of the operating voltage via the IOREF pin. To avoid the possibility of connecting the +3.3V and +5V supplies I added a jumper. For normal operation the shunt can be omitted. When using an ISP header programmer that needs to know the operating voltage a shunt can be added.

Pull-down resistor on D13 FET

Calunium uses a field-effect transistor (FET) to switch on the D13 LED. This is to avoid load on the D13 SCK line when it is used for SPI communications. I learnt this trick from Freetronics who do something similar with their range of clones. In normal use, when D13 is an output, everything works fine. However, when it is an input, such as during RESET state or bootloader programming, the FET gate can float to potential such that the LED is switched on. A 1 megaohm pull down resistor connected to D13 is sufficient to prevent this happening without loading the SCK line. It also helps prevent damage by electrostatic discharge. The latest Calunium design now has room to add this 1 megaohm resistor. On older boards an 0805 surface mount resistor can be fitted between the gate and source of the 2N7000 FET, or alternatively between the D13 and adjacent ground pin.

Auto-reset behaviour corrected for MCP2200 USB interface

I recently added the option of fitting the MCP2200 USB-serial interface. Despite suggestions to the contrary this useful USB  device can automatically reset the Arduino when the device is opened. This auto-reset behaviour as it is known is used to activate the bootloader when uploading sketches. The intention was that auto-reset could be disabled by removing a shunt from the AUTO RESET jumper. Unfortunately an error in the schematic meant that auto-reset could only be disabled when using the FTDI interface, not the MCP2200 option. The latest version corrects this error.

Silkscreen label corrected

On Calunium v2.1 a jumper was added to select FTDI or USB power. Due to a rotation of the component the correct position for the shunt is opposite to that indicated by the silkscreen label. The latest version corrects the text.

Open source

The Eagle PCB design files for Calunium are available on Github and are licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. Files to allow Calunium to be used with the Arduino 1.0 IDE are available on  Github and are licensed under the Gnu General Public License v2.

Mar
25

Power over ethernet (PoE) magnetometer and cloud detector

arduino, AuroraWatch UK, AuroraWatchNet, Calunium, cloud detector, Magnetometer Comments Off on Power over ethernet (PoE) magnetometer and cloud detector 

Combined magnetometer and cloud detector
Combined magnetometer and cloud detector.


To improve the performance and stability of the AuroraWatchNet magnetometers I recently began experimenting with a power over ethernet (PoE) version. With restrictions on power consumption lifted considerable performance improvements are possible. As a result I have developed the magnetometer hardware specifically to support a power over ethernet version. Another instrument I've been developing is a cloud detector. This too should benefit from a power over ethernet version. One problem I encountered was with dew settling on the sensor but fitting a heater is incompatible with battery-powered operation. Since both the magnetometer and cloud detector use almost the same hardware I decided to design an Arduino-compatible 'shield' that could be used to support both systems.

Combined magnetometer and cloud detector hardware

Combined magnetometer and cloud detector PCBs
Printed circuit boards for the sensor shield (left), the IR or humidity sensor (top right)
and fluxgate magnetometer (bottom right). Click for annotated version.
The complete system requires six circuit boards (five for the wireless version). The first is the microcontroller board, I use my Calunium Arduino clone. I hope that in future it will be possible to use an off-the-shelf Arduino Mega2560 instead but the current firmware relies on Calunium's real-time clock to generate the hardware interrupts which control the sampling interval. There is also a sensor shield, the Arduino Ethernet shield (omitted on the battery-powered wireless version), and one board for each of the sensors (fluxgate magnetometer, IR temperature and humidity).

The sensor shield is based on the existing design and retains the option of battery-powered operation with radio communication. The magnetometer sensor and analogue-to-digital converter must be powered at 5V, which requires a level-shifting circuit when the microcontroller is powered from 3.3V, which is the case when operating from batteries. For power over ethernet use the microcontroller must also operate at 5V for compatibility with the Arduino Ethernet shield so the level shifting is not required. It is kept however as it provides buffering between the two circuit boards; 1.5m is a considerable distance for an I2C bus. The cloud detector uses a non-contact infra-red temperature sensor operating at 3.3V so a level-shifting circuit is required for PoE operation where the microcontroller is connected to 5V. (I've ignored the fact that a 5V version of the sensor exists since it isn't readily available in the UK). The sensor shield allows a humidity sensor to be connected so that estimates of the clear sky and cloudy sky temperatures can be made. As before, an on-board LM61 temperature sensor monitors the system temperature. The new sensor shield also adds a header to fit an Embedded Adventures lightning sensor module. I don't have one of these at the moment so I can't be certain it will work and there is no software support for it in the existing firmware. Fitting it at the same time as the cloud detector sensors will require long break-away headers to be soldered to the bottom of the lightning sensor module.

Fluxgate magnetometer sensor PCB
Fluxgate magnetometer sensor mounted on its sensor PCB.
Click for annotated version.

The fluxgate sensor is fitted on its own PCB which contains the analogue to digital converter. For PoE operation a linear voltage regulator is used to convert from 9V to the 5V supply it requires. For battery operation a MAX619 DC-DC charge pump boosts the battery voltage to 5V. Almost all of the temperature variation can be removed by placing the PCB at the bottom of a 1m length of soil pipe. The pipe is buried to a depth of 0.85m with its axis vertical. In the magnetometer-only system the microcontroller, sensor shield and ethernet shield (or batteries for the wireless version) are fitted onto a wooden frame to hold them into the top part of the tube. Positioning the rest of the system away from the fluxgate sensor helps to avoid unwanted effects from any ferro-magnetic components (such as the batteries), it also aids access and enables wireless data transmission.

Humidity sensor PCB
Honeywell HIH6131 humidity sensor mounte on its sensor PCB.
The same PCB design is also used for the MLX90614 IR temperature sensor.
Click for annotated version.

The enclosure design used for the magnetometer isn't suitable for the cloud detector so the prototype cloud detector used a standard IP65 rated box, with the IR temperature sensor pointing upwards to view the sky. The humidity sensor was fitted above a breather hole in the bottom of the box. This concept will continue to be used for the cloud detector; the IR temperature sensor and humidity sensor are fitted to separate PCBs in the top and bottom of the box. To minimise costs the IR temperature and humidity sensors use the same PCB design. The mechanical design of the cloud detector part is something I'd like to improve upon, particularly to reduce the number of PCBs used. However the differing sensor requirements may prevent this.

For a combined system I plan to use the soil pipe to house the fluxgate sensor but locate the rest of the electronics in a separate box following the design of the prototype cloud detector.

Does it work?

I've not yet deployed a system outside but testing indicates the new printed circuit boards work as intended when used in power over ethernet mode. Battery-powered operation on this new version has not yet been tested.

Design files

The design files (hardware, firmware and software) are open source and can all be downloaded from the Github repository. A PDF version of the user manual describing how to construct and operate the magnetometer can be downloaded from http://aurorawatch.lancs.ac.uk/manual.pdf. At the time of writing only instructions to build the original FLC100 shield are included. Instructions to build the combined sensor shield described above will be added in due course.


Mar
25

Power over ethernet (PoE) magnetometer and cloud detector

arduino, AuroraWatch UK, AuroraWatchNet, Calunium, cloud detector, Magnetometer No comments 

Combined magnetometer and cloud detector
Combined magnetometer and cloud detector.


To improve the performance and stability of the AuroraWatchNet magnetometers I recently began experimenting with a power over ethernet (PoE) version. With restrictions on power consumption lifted considerable performance improvements are possible. As a result I have developed the magnetometer hardware specifically to support a power over ethernet version. Another instrument I've been developing is a cloud detector. This too should benefit from a power over ethernet version. One problem I encountered was with dew settling on the sensor but fitting a heater is incompatible with battery-powered operation. Since both the magnetometer and cloud detector use almost the same hardware I decided to design an Arduino-compatible 'shield' that could be used to support both systems.

Combined magnetometer and cloud detector hardware

Combined magnetometer and cloud detector PCBs
Printed circuit boards for the sensor shield (left), the IR or humidity sensor (top right)
and fluxgate magnetometer (bottom right). Click for annotated version.
The complete system requires six circuit boards (five for the wireless version). The first is the microcontroller board, I use my Calunium Arduino clone. I hope that in future it will be possible to use an off-the-shelf Arduino Mega2560 instead but the current firmware relies on Calunium's real-time clock to generate the hardware interrupts which control the sampling interval. There is also a sensor shield, the Arduino Ethernet shield (omitted on the battery-powered wireless version), and one board for each of the sensors (fluxgate magnetometer, IR temperature and humidity).

The sensor shield is based on the existing design and retains the option of battery-powered operation with radio communication. The magnetometer sensor and analogue-to-digital converter must be powered at 5V, which requires a level-shifting circuit when the microcontroller is powered from 3.3V, which is the case when operating from batteries. For power over ethernet use the microcontroller must also operate at 5V for compatibility with the Arduino Ethernet shield so the level shifting is not required. It is kept however as it provides buffering between the two circuit boards; 1.5m is a considerable distance for an I2C bus. The cloud detector uses a non-contact infra-red temperature sensor operating at 3.3V so a level-shifting circuit is required for PoE operation where the microcontroller is connected to 5V. (I've ignored the fact that a 5V version of the sensor exists since it isn't readily available in the UK). The sensor shield allows a humidity sensor to be connected so that estimates of the clear sky and cloudy sky temperatures can be made. As before, an on-board LM61 temperature sensor monitors the system temperature. The new sensor shield also adds a header to fit an Embedded Adventures lightning sensor module. I don't have one of these at the moment so I can't be certain it will work and there is no software support for it in the existing firmware. Fitting it at the same time as the cloud detector sensors will require long break-away headers to be soldered to the bottom of the lightning sensor module.

Fluxgate magnetometer sensor PCB
Fluxgate magnetometer sensor mounted on its sensor PCB.
Click for annotated version.

The fluxgate sensor is fitted on its own PCB which contains the analogue to digital converter. For PoE operation a linear voltage regulator is used to convert from 9V to the 5V supply it requires. For battery operation a MAX619 DC-DC charge pump boosts the battery voltage to 5V. Almost all of the temperature variation can be removed by placing the PCB at the bottom of a 1m length of soil pipe. The pipe is buried to a depth of 0.85m with its axis vertical. In the magnetometer-only system the microcontroller, sensor shield and ethernet shield (or batteries for the wireless version) are fitted onto a wooden frame to hold them into the top part of the tube. Positioning the rest of the system away from the fluxgate sensor helps to avoid unwanted effects from any ferro-magnetic components (such as the batteries), it also aids access and enables wireless data transmission.

Humidity sensor PCB
Honeywell HIH6131 humidity sensor mounte on its sensor PCB.
The same PCB design is also used for the MLX90614 IR temperature sensor.
Click for annotated version.

The enclosure design used for the magnetometer isn't suitable for the cloud detector so the prototype cloud detector used a standard IP65 rated box, with the IR temperature sensor pointing upwards to view the sky. The humidity sensor was fitted above a breather hole in the bottom of the box. This concept will continue to be used for the cloud detector; the IR temperature sensor and humidity sensor are fitted to separate PCBs in the top and bottom of the box. To minimise costs the IR temperature and humidity sensors use the same PCB design. The mechanical design of the cloud detector part is something I'd like to improve upon, particularly to reduce the number of PCBs used. However the differing sensor requirements may prevent this.

For a combined system I plan to use the soil pipe to house the fluxgate sensor but locate the rest of the electronics in a separate box following the design of the prototype cloud detector.

Does it work?

I've not yet deployed a system outside but testing indicates the new printed circuit boards work as intended when used in power over ethernet mode. Battery-powered operation on this new version has not yet been tested.

Design files

The design files (hardware, firmware and software) are open source and can all be downloaded from the Github repository. A PDF version of the user manual describing how to construct and operate the magnetometer can be downloaded from http://aurorawatch.lancs.ac.uk/manual.pdf. At the time of writing only instructions to build the original FLC100 shield are included. Instructions to build the combined sensor shield described above will be added in due course.


Feb
13

Performance comparison of power over ethernet (PoE) and battery magnetometers

arduino, AuroraWatch UK, AuroraWatchNet, Calunium, Magnetometer Comments Off on Performance comparison of power over ethernet (PoE) and battery magnetometers 

Introduction

I've been working to improve the performance and stability of the AuroraWatchNet magnetometers. It's apparent that both measurement noise and stability are considerably improved when the sensor is powered continually. Unfortunately with the sensor powered continually the batteries last for only a few weeks. I have therefore been testing a power over ethernet (PoE) version of the magnetometer. The hardware is essentially the same but the addition of the Arduino Ethernet shield requires the microcontroller to operate from 5V. Operating voltage is easily changed on my Calunium microcontroller board. With the power restrictions lifted the sampling interval can also be reduced. The test system has been operating reliably for almost two months, sampling every 5 seconds. With some minor configuration changes sampling every second is possible although I am not convinced the trade-off in measurement noise is worthwhile.

Performance comparison

Below is a plot comparing one hour of data from the new power over ethernet system with two of the existing battery-powered wireless models already in operation. The PoE system is on the same site as LAN1 but located nearer parked cars. I chose this period because it was free of man-made disturbances. I adjusted the baselines so that the plots overlap.Only the H component of the magnetic field is shown.

Power over ethernet compared with existing AWN magnetometers
Click for larger version.

The graph shows that the power over ethernet version has much smaller measurement errors; it can probably operate with ~0.1nT accuracy compared to ~10nT for the battery-powered version. It's such an improvement that I found the measurement accuracy was being limited by the available resolution of the analogue-to-digital converter. The battery-powered versions derive the sample value from the median of 15 samples (taken as a burst over 4 seconds) to reduce noise. To improve the resolution for the PoE version it operates by taking the mean of 15 samples. Further improvement to the resolution may be possible by taking advantage of the programmable gain amplifier that is built into the analogue-to-digital converter.

Let's see how it compares against some observatory-grade measurements. The plot below shows the same interval but this time uses data from the British Geological Survey magnetometers at Eskdalemuir and Hartland. I obtained the data from the SAMNET data archive at Lancaster University, where the data has already been converted into HEZ magnetic coordinates. AuroraWatchNet also operates with HEZ magnetic coordinates, although usually the E and Z sensors are not present. As before, the baselines have been adjusted so that the plots overlap.


PoE magnetometer compared with BGS magnetometers
Click for larger version.


The similarity between the different traces is striking. Some differences are to be expected since Eskdalemuir is approximately 140km north of Lancaster and Hartland is 350km SSW of Lancaster. This interval is interesting because it shows Pi2 pulsations, starting at about 01:15 and ending around 01:30. The period of the pulsations are about 90 to 120 seconds.

Conclusions

For a home-built citizen-science magnetometer which probably costs 25 times less than its observatory grade cousin I'm very happy with its performance. The detection of Pi2 pulsations means a low-cost magnetometer can now notify of substorm onset, not just the arrival of geomagnetic storms. A network of such devices has interesting possibilities for the study of magnetic field line resonances.

You might wonder why anyone would want to buy an observatory grade instrument, there are good reasons. At present I am relying on the sensor manufacturer's calibration, whilst an observatory grade instrument would be supplied with an official calibration certificate. The observatory instrument would also have better long-term baseline stability, lower temperature variation and higher cadence. Calibration is an issue I hope to tackle at a later date. For space-weather monitoring only short-term variations are of interest and
the better performance provided by an observatory system may not be needed.

Data credits

The Sub-Auroral Magnetometer Network data (SAMNET) is operated by the Space Plasma Environment and Radio Science (SPEARS) group, Department of Physics, Lancaster University. Hartland and Eskdalemuir data is provided courtesy of the British Geological Survey.



Feb
13

Performance comparison of power over ethernet (PoE) and battery magnetometers

arduino, AuroraWatch UK, AuroraWatchNet, Calunium, Magnetometer No comments 

Introduction

I've been working to improve the performance and stability of the AuroraWatchNet magnetometers. It's apparent that both measurement noise and stability are considerably improved when the sensor is powered continually. Unfortunately with the sensor powered continually the batteries last for only a few weeks. I have therefore been testing a power over ethernet (PoE) version of the magnetometer. The hardware is essentially the same but the addition of the Arduino Ethernet shield requires the microcontroller to operate from 5V. Operating voltage is easily changed on my Calunium microcontroller board. With the power restrictions lifted the sampling interval can also be reduced. The test system has been operating reliably for almost two months, sampling every 5 seconds. With some minor configuration changes sampling every second is possible although I am not convinced the trade-off in measurement noise is worthwhile.

Performance comparison

Below is a plot comparing one hour of data from the new power over ethernet system with two of the existing battery-powered wireless models already in operation. The PoE system is on the same site as LAN1 but located nearer parked cars. I chose this period because it was free of man-made disturbances. I adjusted the baselines so that the plots overlap.Only the H component of the magnetic field is shown.

Power over ethernet compared with existing AWN magnetometers
Click for larger version.

The graph shows that the power over ethernet version has much smaller measurement errors; it can probably operate with ~0.1nT accuracy compared to ~10nT for the battery-powered version. It's such an improvement that I found the measurement accuracy was being limited by the available resolution of the analogue-to-digital converter. The battery-powered versions derive the sample value from the median of 15 samples (taken as a burst over 4 seconds) to reduce noise. To improve the resolution for the PoE version it operates by taking the mean of 15 samples. Further improvement to the resolution may be possible by taking advantage of the programmable gain amplifier that is built into the analogue-to-digital converter.

Let's see how it compares against some observatory-grade measurements. The plot below shows the same interval but this time uses data from the British Geological Survey magnetometers at Eskdalemuir and Hartland. I obtained the data from the SAMNET data archive at Lancaster University, where the data has already been converted into HEZ magnetic coordinates. AuroraWatchNet also operates with HEZ magnetic coordinates, although usually the E and Z sensors are not present. As before, the baselines have been adjusted so that the plots overlap.


PoE magnetometer compared with BGS magnetometers
Click for larger version.


The similarity between the different traces is striking. Some differences are to be expected since Eskdalemuir is approximately 140km north of Lancaster and Hartland is 350km SSW of Lancaster. This interval is interesting because it shows Pi2 pulsations, starting at about 01:15 and ending around 01:30. The period of the pulsations are about 90 to 120 seconds.

Conclusions

For a home-built citizen-science magnetometer which probably costs 25 times less than its observatory grade cousin I'm very happy with its performance. The detection of Pi2 pulsations means a low-cost magnetometer can now notify of substorm onset, not just the arrival of geomagnetic storms. A network of such devices has interesting possibilities for the study of magnetic field line resonances.

You might wonder why anyone would want to buy an observatory grade instrument, there are good reasons. At present I am relying on the sensor manufacturer's calibration, whilst an observatory grade instrument would be supplied with an official calibration certificate. The observatory instrument would also have better long-term baseline stability, lower temperature variation and higher cadence. Calibration is an issue I hope to tackle at a later date. For space-weather monitoring only short-term variations are of interest and
the better performance provided by an observatory system may not be needed.

Data credits

The Sub-Auroral Magnetometer Network data (SAMNET) is operated by the Space Plasma Environment and Radio Science (SPEARS) group, Department of Physics, Lancaster University. Hartland and Eskdalemuir data is provided courtesy of the British Geological Survey.



Oct
19

Cloud detector: a review of progress so far

AuroraWatchNet, Calunium, cloud detector, RaspberryPi Comments Off on 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_20130903
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, 2013-09-28
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.

Relative humidity, 2013-09-28
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.

Cloud detector, 2013-10-05Cloud detector, 2013-10-06
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.
Oct
19

Cloud detector: a review of progress so far

AuroraWatchNet, Calunium, cloud detector, RaspberryPi No comments 

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_20130903
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, 2013-09-28
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.

Relative humidity, 2013-09-28
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.

Cloud detector, 2013-10-05Cloud detector, 2013-10-06
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.
May
20

Cloud detector progress

AuroraWatchNet, Calunium, cloud detector, RaspberryPi, RFM12B Comments Off on 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.


May
20

Cloud detector progress

AuroraWatchNet, Calunium, cloud detector, RaspberryPi, RFM12B No comments 

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.


« Previous Entries


  • Newsletter

    Sign up for the PlanetArduino Newsletter, which delivers the most popular articles via e-mail to your inbox every week. Just fill in the information below and submit.

  • Like Us on Facebook

    • PlanetArduino is powered by WordPress. Design by Jasone.it. Valid XHTML   •   Valid CSS
    35 queries. 1.871 seconds.