|Arashi - Open Weather Station||| Print ||
|Written by Akiba|
|Thursday, 07 June 2012|
This is the project page for Arashi. This is mainly a public development log and I'm hoping to show the steps I go through and the reasons for the decisions I make through this journal.
Arashi means "storm" in Japanese and I thought it was appropriate for this project. I was contacted by Marco from WSN Blog and ICTP in early 2012 about an interesting project to collaborate on a remote weather monitoring station for a UNESCO project. I've never done a professional weather monitoring project but the chance to work with the ICTP climate scientists and also put together a sophisticated communications platform sounded too good to pass up. The goal of Arashi is to provide a remote weather monitoring station for developing countries, mostly in Africa. The communications will be via cellular modem (either 3G data or SMS) or satellite modem. I'm especially interested in the power management aspect of this project since a very special power supply will be needed to power these things over long periods of time. Best of all, there was no problem with my requirement that this design be completely open source, both hardware and software. I'm excited by the potential applications of an open source professional grade remote weather monitoring station, especially since it will be designed in collaboration with climate scientists, meteorologists, and little ol' me :)
Studying the rain gauge today. We can't use a standard rain gauge like a tipping bucket since the hard requirement is no moving parts. Because of that, we're using an optical rain gauge from rainsensors.com . It doesn't look like it's built for low power since it uses as 12V input and seems to drive a relay output. There seems to be a 5V input on the test connector so I'm going to see if it can function using that input. Otherwise, it's going to be a pain in the ass to add a boost for a 12V rail on the board. A 5V rail is about as high as I want to go. Here are some pics from the teardown:
In any case, I should be able to make it work for the first version. Now I need to plan out the power management strategy. This is going to be interesting since this device needs to be very low power. I'm planning to run the AVR and whatever components I can at 1.8V. There will also be other enhancements to the power management like tiered power reservoirs where I'll be using a supercapacitor and a battery. The supercap will be used to reduce the duty cycling of the battery so that the battery will last longer. This will be important since the solar cell will charge and discharge the reservoir multiple times a day.
I've been working on the project all last week and also a bit today. There were a lot of nasty gotchas that had to be thought out, mostly with the power supply. I've been thinking a lot about remote weather monitoring recently and have come to the conclusion that there are two main parts to it: the base station and the sensors. The base station is the part that handles the power management, communications, and processing. The sensors are obviously the sensors. This was actually a major breakthrough for me because all of the weather expertise mainly goes to the sensors, ie: positioning, housing, calibrating, etc. However the base station requires a lot of electronics design expertise such as low power design, power distribution, communications/RF, and of course software architecture and design.
This means that if I partition the design this way, I can do the base station architecture on my own and then try and gather help from the climate scientists and weather experts on dealing with the sensors portion. I have a couple of ideas on that too. One of the ideas I'm toying with on the sensors is to make them all share a similar interface, most likely I2C. I2C is "not as" proprietary as 1-wire and many popular MCUs support it with dedicated hardware. Forcing all the sensors to share a similar digital interface will make it easier to have modular sensors. From a software point of view, it would make the weather station more "plug and play" with sensors. I'll probably need to describe this in more detail later on.
On the base station, I'm currently using a fairly sophisticated power management methodology. I have a solar cell input feeding both a lithium-ion-polymer (LiPo) charger IC w/battery and also a 5V supercapacitor set. The primary power source is from the supercapacitors and the LiPo is for backup if the supercaps get depleted. The main reason to use this setup is because supercaps can be duty cycled quite a bit without losing any charge capacity whereas LiPo's will lose capacity over time. Because of this, the supercaps act as an energy buffer to reduce the cycling of the LiPos. The switching mechanism is complex though and it has to be automatic and failproof. Once power is lost to the system, the system is dead which is a catastrophic failure in the field.
The communications will be via a 3G modem on the first version and will support either a digital satellite modem or 3G modem on the final design. The satellite modem will be challenging because it uses a 5W radio which means that I'm probably going to need to make major modifications to the power supply to handle that type of output, even if it's just for a short time.
For this first prototype, there will be three major goals to achieve. The first is obviously power. The sizing of the solar cell and characterizing/optimizing the circuit to reduce power consumption will be important. The second is to verify the communication will work. That means writing some basic software to get the 3G modem to connect to a server or send an SMS/email. The final goal is to write and verify software that will allow remote field upgrades. This is crucial and I don't want to release a remote weather station unless it can be remotely upgraded and there's no chance of bricking. I learned quite a bit when I did the Safecast deployment and it taught me that it's painful to upgrade software on deployed devices. If those three things can be verified, then I'd consider the first prototype a success.
Here are a couple of pictures of the modems I'm playing with. The first one is my 3G modem test setup. The second one are some more of the 3G modems. The third one is my digital satellite modem evaluation system.
I was playing around with the Hydreon Optical rain gauge today because I needed to know how it would work before I designed the interface to the system. The rain gauge has two outputs. The first output is a 12V relay output that can drive things like motors. This is definitely undesirable for me because 12V is nasty to implement in a low power system and I definitely don't need a relay since there won't be any high current loads driven by the rain gauge. The second way to interface to the system is via a serial port interface. The manual says that it supported an RS-232 interface but actually, it was just a 5V serial interface and only the transmit side (output) was supported.
The serial port was a bit finicky. The first strange thing I noticed was that it was an open drain output but on the low side. That means you needed to tie a pulldown resistor to it to get it to work. Once I figured this out, then I still had trouble getting my FTDI USB/Serial converter to understand the data. It turned out that the serial data didn't have good timing accuracy or stability at 1200 bps. Most likely, it was being bit-banged by the microcontroller rather than using a true hardware UART. I was able to get around this by using my PC serial port (yes, it still has a serial port) which is very tolerant. Once I could see that I was getting data as expected, then I wrote a short program in Processing to parse the data. Here's a circuit diagram of how I hooked things up:
Also, here's an example of the raw output from the device as well as the parsed output:
PeakRS = 00
In case you're interested, here's the Processing script that I used to parse the output data from the serial port. You'll need to modify the COM port selection to match your PC though.
Anyways, now that I know how it works, I can proceed to design in the interface to the sensor. This is what my test setup looks like.
written by Chris Crowe, June 23, 2012
written by Gary Stofer, October 25, 2012
written by Gary Stofer, October 26, 2012