Saturday, August 2, 2014

DNT900 / RPI900 / Remote Weather Station lessons learned

Debated breaking this up into a bunch of little posts, but I tend to slack on this blog, so here 'goes a smattering of lessons learned while working on the Remote Weather Station Project.

The weather station has been in the field for several months, and I've learned a few good lessons to share. I could imagine these issues/concepts could be applicable to any remotely controlled and/or solar projects. Some solutions to remote projects are provided specifically for the rpi900/dnt00/RPi, but these items issues should be considered if you are looking into other communication or power management devices. remains the best source for working with dnt900 in conjunction with the  Raspberry Pi (and perhaps 2nd to the dnt900/dnt2400 manuals themselves).  Also it is very exciting that Matt has made the various rpi900 software components into Arch Linux packages. That said, here are some lessons learned on my specific project:

Link Stability of PPP over DNT900

My remote Raspberry Pi can be SSH'd into, and communicate with Xively and to push its measurements. My RF connection between my dnt900 radio's supporting this (PPP network) is very much on the edge of its capabilities, the RSSI is frequently near -100 dBm. Shortly after getting the weather station in the field I noticed many of my Xively posts were getting dropped (as the dnt900 base/remote PPP network was unstable.) Ping showed extreme delays, and the packet loss was high. Poking around in the journal, I found a way another way to check for radio connection stability.

[jay@basepi ~]# journalctl |grep minute
basepi pppd[332]: Connect time 1.2 minutes.
basepi pppd[332]: Connect time 0.4 minutes.
basepi pppd[332]: Connect time 0.1 minutes.
basepi pppd[332]: Connect time 3.9 minutes.

So now that I was keenly aware of my problem, I was pleased to find out the dnt900 radio's had some handy features to help me solve my problem.

The radio default for each packet is to only try 8 times. Bumped up to max retries (63 I believe). Radio's now remain connected for days/weeks at a time.

echo "0x00" > /sys/class/dnt900/ttyAMA0/0x000506/ARQ_Mode
echo "0x3F" > /sys/class/dnt900/ttyAMA0/0x000506/ARQ_AttemptLimit

On a related subject, I found a ligherweight SSH setting was more tolerant of the poor connection. I eventually didn't feel the need to use, but was impressed that it was helpful when the network was spotty.

ssh -v -C -c blowfish <hostname> 
-v optional

Power Management

When I initially deployed the system, my power usage was very close to my consumption, so my battery was more apt to drain if my use of the radio link was excessive. Given the fact I extended out the Max retries for each packet I also suspected the transmission length of the radio was challenging to characterize and control.  I initially spent a fair amount of time deciding on the intervals of the data posting (trying to find the minimum I could live with.)

At some point I stumbled across a post on power conservation on Raspberry Pi. (I unfortunately cannot find my source at the time.) I learned (albeit late) Model A, vs. B, would have made more sense in my configuration. Some options existed to make the power usage on a B similar to A, but they do have significant implications.

The HDMI output can be disabled on the Raspberry Pi (minimal power savings); I don't use the HDMI on my battery powered Pi,so this was a no-brainer:  Here is the command I use to remotely disable, same command could be run locally on the remote Pi:

ssh jay@remotepi '/opt/vc/bin/tvservice -off'

The other option is to disable the usb/buspower. This would make USB ports and the Ethernet ports unusable. I'm not using USB, so I gave it a try. I was pleasantly surprised to realize I didn't need this powered since I'm using PPP (over serial/ttl/dnt900). Will not be applicable to most applications, but worked in my setup. Again, a command to remotely disable:

ssh jay@remotepi 'echo 0x0 > /sys/devices/platform/bcm2708_usb/buspower'

With bcm2708_usb buspower removed (and perhaps hdmi), my power usage profile changed dramatically. My solar setup creates and stores much more power then I need. I'm feeling confident it may be able to run without (any) sun for more than a week. (My panel is already positioned for winter sun.)

In case you missed it, the RPI900 has an excellent ability to Remotely Monitoring battery levels. Has been critical to my project. Was very pleased that was thought about ahead of time in it's design. I post my battery level to Xively, its awesome to see the history, and use that data to see effectiveness of  adjustments to the system.

Soil Moisture Sensor 

The moisture sensor chosen for this project was regrettable (SHT10/SHT11). Long story short, it is expensive and not really helpful for measuring moisture in a way a gardener might find helpful. ( Details here, perhaps only relevant if your shopping around for Soil Moisture Sensor Solutions.)

Heat Management 

In prior posts I walked through the rather extensive steps take for  heat management  of the remote garden station. That has been working out great. The station (in a small, weather proof case) has been outside with temps above 105 °F (40.5 °C), and Raspberry Pi CPU temps maintained below 45.0 °C. (As a point of comparison, my base station which exists in my attic on similar days gets north of 50.0 °C.... and it actually has a fan blowing directly on it.) I see a fairly wide temperature fluctuations (+/- 25 °C in  day) on the fan-cooled Raspi base station vs. the  heat sink/pipe cooled remote station  (+/- 10 °C in  day).

The heat sink/tube setup was a project unto itself, so a primary drawback of it is that if I wanted to upgrade/replace the station Raspi (to say a B+, or change to a model A) it has large implications.

Misc Items

Noob: If built another station (or perhaps any Raspberry Pi project) I would likely skip the NooB option and directly load the OS of interest.  I started with a 4GB card, and lost a bunch of space by 'trying' other OS. I now have to keep a closer eye on my disk space then would be desirable.

Kernal update: On  a couple occasions I performed a full update on the Raspberry Pi. Each time the dnt900 line discipline required rebuild. The first time I encountered this I lost some time trying to figure out why the radio's stopped working.  Luckily Matt  (behind RPI900) was nice enough to steer me in the right direction.

Testing configurations:  Before I had the units in the field I needed to be able to directly log into each Raspberry Pi (and not over the RF PPP link). Get the sequence of event right to allow this ultimately boiled down to disabling ppp if the dnt900 line discipline was required on the remote.

Updating remote radio configurations: Obvious in retrospect (but I did cause myself some heartache with this a couple times) Long story short, if updating remote radio settings (such as Hop Rate/Data Rate, ect. ect.) be sure to update the remote radio first (expect the link to drop), then update the base station. When radio's reconnect, the values can be made permanently stored values.


The project has been a fun one, but I'm still debating as winter approaches if I'll leave it in the field.  Perhaps taking a 'run-to-death' approach of managing it, just doing triage and preventative maintenance. Or, I may pull it indoors for upgrades. At the moment leaning towards just preventative maintenance, run-to-death, to focus on other projects (to include the garden itself.)

Final thought on this project is that  all the weather/garden data in the world does not make for a more lush and plentiful garden. I spent a fair bit of time early in the season working out the weather station issues, and the actual garden suffered for it. Hmm,  maybe some water automation could help that.... 

No comments:

Post a Comment