Shallow Thoughts : : Feb

Akkana's Musings on Open Source Computing and Technology, Science, and Nature.

Sat, 23 Feb 2019

Natural Topiary

Tags nature,mysteries

Some months after we moved into our new house, we came home to notice a really ugly job of tree trimming on some junipers in the driveway.

[deer topiary] We hadn't done it, nor had we requested tree trimming service. Yet we'd been in the house for months, and we were both pretty sure that the junipers hadn't looked like that before. They were nearly denuded at the bottom, belling out higher up.

Was there some rogue topiarist wandering the neighborhood, defoliating people's trees without asking them? When I was growing up, occasionally my grandmother would show up and slash branches off trees in our backyard without asking. But it made no sense that anyone in our neighborhood would do that.

We hoped the trees would grow back to their former bushiness, but several years later, they don't look much better. And all that time it has remained a mystery how the trees came to look like that.

Until a party a few months ago, when a visiting friend cast a knowing look at the trees and said, "I see the deer have been visiting you."

[deer topiary] Of course! Somehow that had never occurred to us. We went out to the driveway and checked -- and sure enough, the trimmed parts of the trees go up to roughly the height a deer could easily reach.

So sure enough -- there is a rogue topiarist wandering the neighborhood after all. Lots of them, in fact. Most of the time they eat more tempting fare; but when the weather gets inclement and there isn't much to eat, they'll go after the junipers. And I guess these non-native junipers in the driveway are a little tastier than the native ones that are all around the property.

We don't feel quite so resentful about our unwanted tree trimming now. Sure, we're still not crazy about the look of our oddly shaped junipers, and they've gotten even worse during the current exceptionally snowy winter; but now that we know it's a natural process, not some crazed shear-wielding neighbor, it's hard to be too upset by it.

[ 11:35 Feb 23, 2019    More nature | permalink to this entry | ]

Tue, 12 Feb 2019

Reading the Output of a Weather Station Using Software Defined Radio

[Weather station] A while back, Dave ordered a weather station. His research pointed to the Ambient Weather WS-2000 as the best bang for the buck as far as accuracy (after it's calibrated, which is a time consuming and exacting process where you compare readings to a known-good mercury thermometer, a process that I suspect most weather station owners don't bother with).

It comes with a little 7" display console that sits indoors and reads the radio signal from the outside station as well as a second thermometer inside, then displays all the current weather data. It also uses wi-fi to report the data upstream to Ambient and, optionally, to a weather site such as Wunderground. (Which we did for a while, but now Wunderground is closing off their public API, so why give them data if they're not going to make it easy to share it?)

[Weather station console] Having the console readout and the Ambient "dashboard" is all very nice, but of course, being a data geek, I wanted a way to get the data myself, so I could plot it, save it or otherwise process it. And that's where Ambient falls short. The console, though it's already talking on wi-fi, gives you no way to get the data. They sell a separate unit called an "Observer" that provides a web page you can scrape, and we actually ordered one, but it turned out to be buggy and difficult to use, giving numbers that were substantially different from what the console showed, and randomly failing to answer, and we ended up returning the observer for a refund.

The other way of getting the data is online. Ambient provides an API you can use for that purpose, if you email them for a key. It mostly works, but it sometimes lags considerably behind real time, and it seems crazy to have to beg for a key and then get data from a company website that originated in our own backyard.

What I really wanted to do was read the signal from the weather station directly. I'd planned for ages to look into how to do that, but I'm a complete newbie to software defined radio and wasn't sure where to start. Then one day I noticed an SDR discussion on the #raspberrypi IRC channel on Freenode where I often hang out. I jumped in, asked some questions, and got pointed in the right direction and referred to the friendly and helpful #rtlsdr Freenode channel.

An Inexpensive SDR Dongle

Update: Take everything that follows with a grain of salt. I got it working, everything was great -- then when I tried it the very next day after I wrote the article, none of it worked. At all. The SDR dongle no longer saw anything from the station, even though the station was clearly still sending to the console.

I never did get it working reliably, nor did I ever find out what the problem was, and in the end I gave up. Occasionally the dongle will see the weather station's output, but most of the time it doesn't. It might be a temperature sensitivity issue (though the dongle I bought is supposed to be temperature compensated). Or maybe it's gremlins. Whatever it is, be warned that although the information below might get you started, it probably won't get you a reliably working SDR solution. I wish I knew the answer.

[Raspberry Pi with SDR dongle] On the experts' advice, I ordered a RTL-SDR Blog R820T2 RTL2832U 1PPM TCXO SMA Software Defined Radio with 2x Telescopic Antennas on Amazon. This dongle apparently has better temperature compensation than cheaper alternatives, it came with a couple of different antenna options, and I was told it should work well with Linux using a program called rtl_433.

Indeed it did. The command to monitor the weather station is

rtl_433 -f 915M

rtl_433 already knows the protocol for the WS-2000, so I didn't even need to do any decoding or reverse engineering; it produces a running account of the periodic signals being broadcast from the station. rtl_433 also helpfully offers -F json and -F csv options, along with a few other formats. What a great program!

JSON turned out to be the easiest for me to use; initially I thought CSV would be more compact, but rtl_433's CSV format includes fields for every possible quantity a weather station could ever broadcast. When you think about it, that makes sense: once you're outputting CSV you can't add a new field in mid-stream, so you'd better be ready for anything. JSON, on the other hand, lets you report just whatever the weather station reports, and it's easy to parse from nearly any programming language.

Testing the SDR Dongle

Full disclosure: at first, rtl_433 -f 915M wasn't showing me anything and I still don't know why. Maybe I had a loose connection on the antenna, or maybe I got unlucky and the weather station picked the exact wrong time to take a vacation. But while I was testing, I found another program that was very helpful in testing whether my SDR dongle was working: rtl_fm, which plays radio stations. The only trick is finding the right arguments, since the example from the man page just played static. Here's what worked for me:

rtl_fm -f 101.1M -M fm -g 20 -s 200k -A fast -r 32k -l 0 -E deemp | play -r 32k -t raw -e s -b 16 -c 1 -V1 -
That command plays the 101.1 FM radio station. (I had to do a web search to give me some frequencies of local radio stations; it's been a long time since I listened to normal radio.)

Once I knew the dongle was working, I needed to verify what frequency the weather station was using for its broadcasts. What I really wanted was something that would scan frequencies around 915M and tell me what it found. Everyone kept pointing me to a program called Gqrx. But it turns out Gqrx on Linux requires PulseAudio and absolutely refuses to work or install without it, even if you have no interest in playing audio. I didn't want to break my system's sound (I've never managed to get sound working reliably under PulseAudio), and although it's supposedly possible to build Gqrx without Pulse, it's a difficult build: I saw plenty of horror stories, and it requires Boost, always a sign that a build will be problematic. I fiddled with it a little but decided it wasn't a good time investment.

I eventually found a scanner that worked: RTLSDR-Scanner. It let me set limiting frequencies and scan between them, and by setting it to accumulate, I was able to verify that indeed, the weather station (or something else!) was sending a signal on 915 MHz. I guess by then, the original problem had fixed itself, and after that, rtl_433 started showing me signals from the weather station. It's not super polished, but it's the only scanner I've found that works without requiring PulseAudio.

That Puzzling Rainfall Number

One mystery remained to be solved. The JSON I was getting from the weather station looked like this (I've reformatted it for readablility):

{
    "time" : "2019-01-11 11:50:12",
    "model" : "Fine Offset WH65B",
    "id" : 60,
    "temperature_C" : 2.200,
    "humidity" : 94,
    "wind_dir_deg" : 316,
    "wind_speed_ms" : 0.064,
    "gust_speed_ms" : 0.510,
    "rainfall_mm" : 90.678,
    "uv" : 324,
    "uvi" : 0,
    "light_lux" : 19344.000,
     "battery" : "OK",
    "mic" : "CRC"
}

This on a day when it hadn't rained in ages. What was up with that "rainfall_mm" : 90.678 ?

I asked on the rtl_433 list and got a prompt and helpful answer: it's a cumulative number, since some unspecified time in the past (possibly the last time the battery was changed?) So as long as I make a note of the rainfall_mm number, any change in that number means new rainfall.

This being a snowy winter, I haven't been able to test that yet: the WS-2000 doesn't measure snowfall unless some snow happens to melt in the rain cup.

Some of the other numbers, like uv and uvi, are in mysterious unknown units and sometimes give results that make no sense (why doesn't uv go to zero at night? You're telling me that there's that much UV in starlight?), but I already knew that was an issue with the Ambient. It's not rtl_433's fault.

I notice that the numbers are often a bit different from what the Ambient API reports; apparently they do some massaging of the numbers, and the console has its own adjustment factors too. We'll have to do some more calibration with a mercury thermometer to see which set of numbers is right.

Anyway, cool stuff! It took no time at all to write a simple client for my WatchWeather web app that runs rtl_433 and monitors the JSON output. I already had WatchWeather clients collecting reports from Raspberry Pi Zero Ws sitting at various places in the house with temperature/humidity sensors attached; and now my WatchWeather page can include the weather station itself.

Meanwhile, we donated another weather station to the Los Alamos Nature Center, though it doesn't have the SDR dongle, just the normal Ambient console reporting to Wunderground.

Tags: , , ,
[ 13:20 Feb 12, 2019    More tech | permalink to this entry | ]

Sun, 03 Feb 2019

A Spectacular Lenticular

I was hurrying to check in some tweaks to the BillTracker before leaving to join some friends for dinner when I noticed some beautiful clouds over the Sangre de Cristos.

"That's a spectacular lenticular!" I exclaimed, grabbing the camera.

[Spectacular lenticular cloud]

The clouds got even better ten minutes later as the sunset turned the clouds salmon-pink, but alas by then we were pulling up to a friend's driveway and didn't have a clear view, and by the time I did, I'd lost the light.

When I offloaded the photos from the camera's SD card this morning to see how the photos came out, I found some older photos from our snowstorm a few weeks ago. In particular, a photo of that curly dragon-droop glacier above the den deck after it fell. Before and after:

[] []

Tags: , , ,
[ 17:58 Feb 03, 2019    More nature | permalink to this entry | ]