Posts | Comments

Planet Arduino

Archive for the ‘RaspberryPi’ Category

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

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 ASI174MC image
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.




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 ASI174MC image
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.



Jul
14

Arduino CNC Shield – 100% GRBL Compatable

arduino, CNC, grbl, RaspberryPi, shield Comments Off on Arduino CNC Shield – 100% GRBL Compatable 

arduino-cnc-shield

by protoneer.co.nz:

We have designed the Arduino CNC Shield to use all the pins that GRBL implemented. We have also added a few extra pins to make things a little easier. GRBL is opensource software that runs on an Arduino Uno that takes G-Code commands via Serial and turns the commands into motor signals. Now compatible with Raspberry PI.

Arduino CNC Shield – 100% GRBL Compatable – [Link]


FTDI all-in-one
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.

Oct
28

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

AuroraWatchNet, RaspberryPi Comments Off on FTDI all-in-one serial converter, programmer, switch 


FTDI all-in-one
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.

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



  • 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