Wednesday, January 2, 2013

Solar powered, Wireless autonomous radiation sensor network



I designed a system a few months ago that had the aim to track the amount of radiation of my backyard over a period of time. I figured that the least cumbersome way to keep track of the count-rate was to make the radiation sensor post the data directly to the internet, via cosm Xively. Cosm Xively is basically an 'internet-of-things' platform where devices can freely post, access and share data points.

This project can be particularly interesting for those who, like me, want to keep track of the relative radiation rates for some reason. (This is not a radiation dosimeter, hence the 'relative count rate')

I found it worthy to share this design because:
  1. It is solar powered, and (energetically) fully self sufficient.
  2. It connects to the internet via Wi-fi, so no messy ethernet cables trailing across the backyard. (Assuming, of course, it is within range of your wifi router.) 
  3. It is fully weather-resistant due to the IP-66 rated casing and connection terminals.
  4. Data-collection is automatic and cosm provides various interesting ways to share the collected data points(twitter, custom API, etc...)
  5. It is a very low cost system for what it does. B.o.M is under $100. 

Hardware overview

Component list:

First some pictures for a general overview of how one node is assembled.

Holes for two watertight cable pass-throughs

Adafruit's solar charger board. A bit overpriced in my opinion, but works very well. 

Roving Networks RN-XV WiFly 'wonder' Module

The RP-SMA connector was sealed with silicone glue after the antenna was  screwed-in

Arduino+WiFly+Solar Power Subsystem minus the Geiger interface

The Geiger Muller Interface + GM Tube attached , as described previously

Cramming everything together produces this. 


Schematics

I won't be describing how to connect up the power subsection as this is pretty obvious, and is also dependent on what exact components you chose to use.

I will only describe how to connect the WiFly module and the GM tube interface, in the way expected by the Arduino code.

Part I - RN-XV to Arduino




The pin numbering scheme of the RN-XV module is shown above. This project uses only 6 pins from the module and they are connected to the Arduino as described by the table below.










The Arduino code puts the module to sleep by pulling pin 7 to LOW. For the module to obey this, it must be configured so that when it gets a 'LOW' signal on pin 4, it goes to sleep. For instructions on how to configure the module, please consult its instruction manual about 'GPIO8'.

If the WiFi module does not enter sleep mode, the LiPo battery will be eventually drained as the solar panel won't be able to keep up with the load. From my experiments, the system will only last 2-3 days if that happens. 

The Arduino code also wakes up the module by pulling pin4 'High' (pin 16 on the RN-XV) after a certain period has elapsed. No configuration is needed for that as the module automatically wakes up from sleep as its pin 16(UART_CTS) is pulled high.

It is highly recommended that you give it's instruction manual and datasheet a good read before wiring the module up. How this module works is far from obvious, but very interesting nevertheless.


Part II - GM-Interface to Arduino




The GM-interface used is exactly the same as described in this post: http://theiopage.blogspot.com/2012/09/simple-gm-tube-interfacing-to-arduino.html

It consumes a few micro-amps when not active and about 10mA when its high-voltage generator(boost converter) is active. By default, it is active for about 30 seconds each 30 minutes so that the overall current draw remains adequate for what a small solar panel can provide.

It has 4 wires to the arduino: Vcc, PWM_IN, Pulse_Out and Ground.


  1. Vcc can be anything less than 6.0V but above 3.0V. (note: The HV is not regulated - just a ballpark value that works.)
  2. The "PWM_IN" of the GM-Interface is connected to Pin 9 of the Arduino Pro Mini. This is for the boost converter section of the interface. The firmware is programmed to send a 1.9KHz PWM signal through Pin 9. 
  3. The "Pulse_Out" of the GM-Interface is connected to Pin 2 of the Arduino Pro Mini. This is for the 'pulse detection' section of the interface. Each time a pulse is detected, it triggers an interrupt on the Arduino for it to register the event as one count. The Arduino accumulates theses counts over a period of time to produce the count per minute value. 


Arduino Sketch

The Arduino sketch can be downloaded here: https://github.com/manis404/RadSenseNode


You have to change a few things before you upload the sketch to the Arduino Pro Mini.

  • You'll need to hardcode your wifi AP settings inside the "Credentials.h" file. 
  • You'll need to have a cosm account and enter your cosm feed details in the "Credentials.h" file
  • You need to have the WiFly library installed for it to compile. I've made a copy of the original Sparkfun WiFly library to maintain compatibility: https://github.com/manis404/WiFly-Shield

After these, your code should compile and work properly.

The documentation is still very minimal, but this will hopefully change progressively.

Random extra text

My current Cosm feed is currently private, but I will make it public and post it here soon after I complete some add-ons.

You can also use a GM-Array instead of a single tube to get a more reliable count rate.







3 comments:

Razr Behary said...

Awesome build manis !

Kemley

Janne M said...

Have you experienced any issues with RN-XV? I tried to use it for my electricity meter (http://antibore.wordpress.com/2012/10/06/updating-electricity-meter-to-communicate-via-wlan/), but no matter what I tried, it lost the connection to AP first time after about 8h of operation and after that it was offline about 40% of time.

"Manis B" said...

My connection to the AP is not continuous as in your case. It's intermittent in the sense that the module disconnects and goes to sleep after posting the data to the internet, and later wakes up to repeat the cycle again.

Sometimes it randomly fails to reconnect to the AP upon waking up from sleep (1 in 12hours typically) so the arduino makes it go to sleep forcefully if that happens. That's the closest I've been to your issue. It's a pretty strange issue, but in my case, all I lost is one datapoint because it always reconnects after failing for the first cycle.