Monday, April 28, 2014

The case build (for the weather station), and installed in the field

Around the time I started to plan for the weather station case I came across a post on reddit that peaked my concern about heat management of the Raspberry Pi. Further reading on HackaDay confirmed it was a factor to consider. My RPi weather station is not stressed from a network or CPU perspective, but the summer heat on the sealed case could be show-stopper. From what I've read, 80ÂșC is the critical temp for the RPi. (Link also includes a shutdown script if critical temp is approached, something I may consider implementing.)

What follows is  overview of my case build dealing with both weatherproofing and heat management for the RPi in my remote garden weather station.

For starters, below is a quick review what is in the weather station (case), or external to it. Pictured below are the core components of the station: a remote and base-station. Both include a Raspberry Pi (RPi) with the RPi900 add on board hosting the DNT900 radio and antenna. (The WiFi pictured not used in the final system, only for testing.) The base-station for the system remains in my home, one of the units (the remote end) goes in the case installed at the garden ~2 miles from my home.

Aside from the RPi, the case also needs to house the electronics that interface with the RPi's GPIO. I discussed all the sensors in a prior post and bulk of the board is show below. What is missing from the image below are the sensors attached to the breadboard.

The RPi and breadboard above share a similar footprint, so I ended up picking the Otterbox 3500 for the final case  (better to Google this), it is not produced any longer but deals can be found on Ebay and even Amazon. The Otterbox by design is naturally waterproof. Although I planned to add multiple holes for sensors and power I felt it would be better to start with a waterproof case, then try to make a traditional case water-resistant.

Below is a rather boring picture, but what can be gleamed from it is (and the picture that follows it) is the relative size of the RPi in the case. You can also see standoffs I placed inside the case. The standoffs hold a copper plate slightly elevated from the back of the case to allow for other mounting items, and cables to be run under the plate.

Below is a RPi  in the case, on the copper plate (actually a bad/broken RPI, one I just use for test fittings), as to not rough up my good hardware).

The mount (to attached the case to a wooden pole) being added below. Back of case seen.

The inner attachments of the mount (The nuts do not protrude higher than the copper standoff plat.) Case is actually up-side down in this pick .

So back to the copper plate (mentioned previously.) At fist mention, that may have raised a few eye-brows. The backing copper plate is actually multi-function. One purpose is simple to ease installation mount everything to a plate, then just insert the plate inside the case. The more significant role is actually part of the somewhat elaborate cooling system. Anyone familiar with RPi has likely seen the heat-sinks (of questionable value) that get taped onto the RPi, often made from aluminum.

With my soon to be sealed/waterproof case, I anticipated that simply sticking on heat-sinks wouldn't allow the heat to escape the case , and a cooling fan would be impractical. (Size and power limitations of my solar installation.) My solution was to somehow get the heat-sinks to facilitate heat exiting the case. In comes the idea for a heat pipe solution used to cool laptop computers. My implementation is not a perfect heatpipe setup, but hopefully enough to get the job done.

I chose to go with a full copper system (for heat-transfer properties, and to simplify the soldering/adhesive needed to hold it all together. Below you can see the start of attaching 1 RPi heatsinks (copper) to copper heatpipe, and to the copper backplane. 2 more were done like this and later bent into place.

Next you can see the RPi mounted on the copper backplane (and the 3 heatpipes/heat-sinks not yet attached.)

Now a few pictures outside the case, this time withe heat-sinks in place (not yet attached) and the soon to be external heatpipe/sink that will help transfer heat outside the case.

The heatpipe/sink that will be external to the case is from a Toshiba laptop, used to cool a Tecra M3 (I believe.) Found with some heavy Ebay searching for something just right the right size and shape.

The following few pictures now show how a Dremel was used to create the access points to the case (and external heatsink).  The Dremel was perfect for the job. It spun fast enough to not only cut the case, but also slightly melt the plastic and make smooth access points.

External heat sink

View prior to attaching to backplane

Test fitting of backplane and external heatsink

Near final fitting, RPI in-place with heatsink.  Since soldering the external heatsink was not possible in the case, Thermal Adhesive (available from Amazon) was used. Thermal Adhesive was so convenient if I did it again, I might have chosen to use that to attach the heatsinks to the tubes connected to the backplane.  

Slightly out of order, but hear is a view of all the cut-outs (all part of case that faces bottom) for sensors and antenna feeds existing the case as well power inputs. (Largest hole is power, followed by air sensor, battery and soil sensors, then the smallest for the bulkhead SMA antenna connection. Flat hole is heatsink discussed above)

Ok, now is the unfortunate time in the post (and project) where I got very excited about how things were coming together and spent very little time taking pictures, and more time assembling the case itself. So here is a near final view (in outside on my deck being tested.)

An now with the case opened up. You can clearly see the the backplane and (white) thermal adhesive that attaches the external heatsink. What is not obvious is I added some additional spacers between the RPi and the RPi900 radio to increase the air-space around the RPi. The heattubs also don't block the camera, ethernet port or SD card incase access to those items are ever needed. The RPi900 can remotely control power to the RPi but I chose to also add a switch inline. The GPIO headers extend through the RPi900 and the GPIO extension cable sneaks under the backplane before connecting to the breadboard. 1 air temp sensor remains in the case, 3 extend out. (1 for actual weather monitoring, 1 for battery case temp, and one for soil temp) PG

Here is the whole system in a deck test. (Solar, battery and weather station) Even had some rain and freezing weather to test it out.

Fast forwarding abit, here it is installed at the garden. You can see I have added a camera to the case, painted the case white (to reflect heat), as well as added another standalone heatsink to the DNT900 radio.

A nice clear shot of the bottom of the case

A view from below

Looking right at the case and into the camera that peeks out

Just a nice shot of the solar panel and case

The whole setup in the field.

The project is nearly complete, and sensor data can be seen online at (Unless it happens to be offline for maintenance). A few posts will follow on the subject to include more lessons learned, problems encountered (and worked through), and hopefully a single post summarizing the project.

Tuesday, April 22, 2014

DECT 6.0 collection with HackRF

After seeing an interest in DECT on reddit  thought it would be easy enough to grab a recording of this and share.

I have a vTech DECT 6.0 cordless phone system.  I may ciricle back and update this post with more details on DECT and the phone itself, but for now wanted to quickly share the results

Some initial observations: 
  • Frequency usage isn't as high as I thought it would be (number of frequencies), I searched around abit and it seemed 80% of the traffic (as least was isolated to two frequencies)
  • The density of transmissions seemed highest at initial call setup, and on hang up. (But this may be due to the display on my phone receiving information from the base station.
  • Both the handset and base station are visible in the file.  I believe the stronger signal is the handset.
Below is a 8MHz collection via hackrf_transfer as follows:

hackrf_transfer -a 0 -r -f 1924000000 -s 8000000

Collection was focused around this frequency since this seemed to be where my phone was primarily active. 

And DECT waveform zoomed (in time):

Finally, here is the sample  of the DECT 6.0 from my vTech cordless if you want to take a look yourself:

(To view in Baudline, decompression off, Initial byte 2, sample rate 8000000, channel 2 quadrature, 8 bit linear, unsigned)  NOTE: these collects from older HackRF firmware, latest firmware creates signed 

Saturday, April 19, 2014

Baby Monitor and WiFi HackRF Collection

After breaking out my HackRF to check my DNT900 radio I thought it would be interesting to check out a system I wasn't very familiar with.

I own a couple Motorola Baby Monitors. They advertise as using FHSS, but this time in the 2.4 GHz range (vice my DNT900 that utilize the 900 MHz ISM band.)

Looking around the 2.4 - 2.5 GHz freq range with the HackRF using GQRX I could see there was alot of frequency contention (activity), so isolating the baby camera (& monitor handsets) could be a challenge. In a successful attempt to find some radio silence I powered off my cordless phone, WiFi (IEEE 802.11g) router, put all mobile phones in airplane mode.

Attaching an antenna for the wrong frequency band (co-locating the monitors near the HackRF) further eliminated interference from neighbors 2.4 GHz emissions. 

I also spent some time experimenting with the handset and monitors to see the RF activity in the various audio and video modes. 

Some observations: 
  • Sending audio and video (default) keeps these radios very active.
  • They only send data when the monitor is tuned to them. (I believe) which is interesting, since this may be a way to see if anyone else is snooping on your monitor. If you can set up a passive RF monitor like hack-rf or rtl-sdr.
  • I do not know if they can send to more then one monitor at a time.
  • Cameras and monitors are uniquely paired. (But like anything with security, if someone has access, that is trivial to establish.)
  • The radios use the entire range utilized by WiFi, Bluetooth and countless other commercial products available. (So they are a potential source for degrading WiFi, and from their activity levels I'd be shocked if that is not happening.) 
  • The data bursts are short (< 1-4 ms), and more narrowband than WiFi.

Below is a 20MHz collection via hackrf_transfer as follows:

hackrf_transfer -a 0 -r -f 2417000000 -s 20000000

Since this is only 20MHz of the possible ~60 MHz the radios use not all data from this ~1 sec timeslice is shown.

And Motorola waveform zoomed (in time):

Look close (on the 1st image showing the larger time scale and you may see two, since two baby monitors in use. Thinking the other just announces its presence when not tuned to (for the scan option.)

Since the manual for these devices focuses on what parents need to know, and not those curious about how it works, alittle FCC database research was needed.

Here is the site for that:

The camera and monitor and manual all had FCC Id's listed (as do most legal equipment). For unknown reason, directly plugging that information in did not work.  I ended up just using the Grantee code (first 3 letters), and providing a frequency range.  That narrowed it down to 10 items easily reviewed.  Clicking "Display Grant" gives more summary information to find the device of interest.

Looks like Binatone Electrons actually makes the radio itself (not Motorola), and they are a big supplier to Motorola, as well as a wide range of other products that require some form of radio.

For example, Camera Unit FCC Grant:

It does seem for this equipment the manufacture requested confidentiality, which didn't seem to be honored (best I can tell.) But I'll at least not re-post anything from their reports and let you do your own exploring. Test Report being the most interesting for those wishing to understand the system in more detail.

Or maybe the internal photos to learn about the device without cracking one open

Finally, for comparison purposes. Here is a collection at the same frequency & Bandwidth that just shows alittle bit of WiFi activity, but baby monitor turned off.  (Off-tuned for WiFi, but I think it still is clear they are very different waveforms.)

And WiFi (IEEE 802.11g) waveform zoomed (in time):

Finally, here is the sample  of the Motorola Baby Monitor transmission if you want to take a look yourself:

(To view in Baudline, decompression off, Initial byte 2, sample rate 20000000, channel 2 quadrature, 8 bit linear, unsigned) NOTE: these collects from older HackRF firmware, latest firmware creates signed 

DNT900 Radio Transmission Collection with HackRF

Since I happen to be a lucky owner of a HackRF I thought it would be interesting to collect the transmission from the dnt900 used in my remote weather station project. Here is a 20MHz collect using hackrf_transfer

I believe this recording captures most of transmission (primarily my base station), at 38.4 kb/s data rate.

For those looking for nitty gritty details the FCC Exhibits lists is somewhat interesting, not much more information than found in the devices users manual though:

Here is a link to the recording if you want to check it out:

If your using Baudline to view the HackRF collected files (via hackrf_transfer)  here are the settings:

NOTE: these collects from older HackRF firmware, latest firmware creates signed 

Thursday, April 17, 2014

Weather Station data displayed on public website (Custom Xively-rickshaw/plot.y and Google Gauges displays)

Last post I highlighted getting all my weather sensor data available on Xively for my RPi hosting sensors accessible remotely over an RF link.

While I think Xively is great, it is really not designed to be the final stop for sharing or exchanging data. My weather station data is now consolidated at Displaying the data on my own site allows for more customization, and presentation of the displays, and easier access for my fellow gardeners. The page is broken up into three sections right now, current garden conditions (what most care about), hardware status (how I keep an eye on my equipment running), and historical data.

The skeleton of the site (I'm not a web developer) pardon my naivety, is Twitter Bootstrap.  I'm just a general fan of that toolkit, to include the documentation. Their templates seem fairly easy to grab and modify. Also looks decent on desktops and smartphones.

Current Conditions 

I originally had high hopes of uses a wide range of current  Google Charts but had a tough time figuring out how to use the Xively JSON. Seemed like I might be fording new territory, not entirely a productive activity for someone with limited web experience.

Luckily I came across a great blog that had figured this out for the Google Gauges, so I used this extensively (on both the Current conditions, and Hardware Status.) If you want to check out my derived work, check my github.

The line graph seen below the Gauges is actually a image retrieved from Xively (for simplicity). Discussed in my last post  But also here is the basics of the html again. 

 Graph can be adjusted by following the Xively API.

For the historical data page I wanted something interactive. I came across this post about plotting Xively data with RickShaw. Was exactly what I needed, and well documented at the xively-rickshaw github. I use Xively-Rickshaw for nearly all my historical displays, both line graph and bar charts. Here is what I implemented from extensively referencing (mostly copying) xively-rickshaw example. Although the Xively feed does restrict the number of points that can be pulled, that model fit well into my various historical data view options.

On the RPi side my various scripts to pull the data are started on boot and otherwise controlled via supervisord I found its control and logging, and able to background processes and control sleep withing the scripts, not under the restrictions of cron useful.

Modifying /etc/supervisord.conf Adding something like the following:


Enabling the service (or later restarting/stopping) is as easy as:
systemctl enable supervisor.service | systemctl restart supervisor.service | systemctl stop supervisor.service | systemctl start supervisor.service

I should mention, I am using Arch Linux,  so my supervisor is first called at startup by systemd:
Description=control progs

Aside from xively-rickshaw I did some experimenting with At quick glance, it might look similar, but does offer some interesting features such as zooming  in, or going into to fork (copy and analyse). I haven't explored it much, so I haven't figured out if there is an easy way to display smaller periods of data (like I do with Xively.) I use it to display all CPU data from my base station (from inception.)

For my RPi and page I came across a simple method that worked great. It relies on cron at the moment (on my RPi). There are also some examples of more advanced use of if you care to look more into this method.

My full base station CPU temp feed: 

Well, that covers it. For the all the details of the web page side of things check out

Friday, April 11, 2014

Getting Sensor Data online with Xively

I was able to recently prove the sensors for temp and moisture (using the SHT11 & DS18B20) worked well with my RPi setup. As I mentioned in the original plan, some early research indicated that uploading the recorded data to Xively would prove useful for later public web access, and help me avoid constructing my own database for the data. 

I'd like to make the weather station data publicity available for my fellow gardeners, but do not want any dependency on the sharing of the data on the RPi itself. In my setup using PPP for my remote radio I intend to have the remote put the data to Xively via my base stations physical network connection. So far, in local testing (around the house) it is working well. Below describes how I've got it working. (Referencing the great work of other.)

I'm not going to detail the steps to get an Xively feed setup, and data posted to it. I followed others tutorials online that did a better job than I'd do. The one provided by Xively itself ended up the basis for nearly all my feeds:, and for those looking for the nitty-gritty details, I'll save you tracking down the API:, and the wrapper library itself:   AdaFruit (as always) has a good follow-along tutorial that could also be referenced:

Here are all my scripts for grabbing data, as well as the scripts for posting to Xively: Update your API and channel names accordingly if you borrow.

Pictured below and available here is my Xively Feed:  I find this Xively page helpful for general use, but for a wider audience a more refined site is needed (and in the works.)

Now that I have the data steady flowing to Xively, I'll work next on visualizing the data in a more useful way on my one site. At the moment I'm considering:, as well as this Also for quick view of current values Google Gauges, like from this tutorial:

Until my site is up, here are a few quick pointers for pulling the Xively data. They are not interactive, but do provide an alternative the Xively site proper. I was tipped off on this simple approach from this site which extensively uses this method.

Actual html:

<img src=>

Template html:

<img src=>

Example output:

For more API details (which apply to the image generation) check out: