Brad McConahay

The latest AES amateur radio catalog recently made its way into the “library” where I spotted the new TH-D72A portable rig with APRS.  I’ve had the aging Kenwood TH-D7AG with APRS for a number of years, but this newer rig also has GPS and *gasp* a USB port. I almost bought it.

The Davis Vantage Vue

I also happened across a compact weather station in the same catalog – the Davis Vantage Vue. I decided to buy it instead of the radio to replace my old Scientific Oregon WMR-968 station which was in a state of total disrepair.

Putting the new station together turned out to be easier than taking the old one apart. Besides being a huge spider convention, the bolts were so badly rusted onto the mast that I finally hammered all the old hardware off into pieces.

Despite the station’s low cost, connecting it to a USB port ends up adding an extra $150. That’s for the hardware adapter and a software package. A standalone Ethernet-connected version is also available for $250.  The WeatherLink software appears to be straight out of the Windows 95/98 era – good enough to confirm that the station’s data transfer is working, but that’s about it.

Weewx

I had used wx200d on Linux with the old WMR-968 station. It provided a reliable daemon along with everything needed to graph data, report to Weather Underground and CWOP, and send packets out over the local APRS network via RF on 144.39 MHz. I had to do some extra perl scripting to glue it all together, but that was part of the fun.

So, what was the new Swiss Army Knife for the Davis Vantage View on Linux to be? wview was the early frontrunner, but while installing it, I could feel the time-vacuum of dependencies and troubleshooting that a lot of Unix based projects turn into. While checking alternatives, I found a modest sounding package called weewx that was almost easy to overlook. It’s a well thought out system written in Python by Tom Keffer. I put it in place, set a few variables, installed the init.d script, and went on my way. It provides a comprehensive page of data that can be used in place or automatically FTP’d to a remote server. It reports to Weather Underground, CWOP (APRS-IS), and PWS Weather. It’s also well templated and object oriented – all very extensible in general.

APRS – Back to Radio

The only thing left to figure out was how to get it onto the local APRS ham radio network. I got my old Kenwood TH-D7AG working again, hooked it up to the server using a serial-to-USB adapter, and put it in standard TNC mode where it’s bypassing the built in APRS and simply receives regular TNC commands.

Since the CWOP routine in weewx already creates the same packet needed for APRS, it seemed a shame to rewrite anything. But having never worked in Python, my first instinct was to use my original perl script written for wx200d, and have it read directly from weewx’s SQLite database. Knowing this wasn’t the best way to do it, and having a recent interest in learning Python, I put a message on the weewx Google Groups forum and immediately received some great direction from Tom on how it might be best integrated into weewx. It only took a few hours after that to get it working. Although it will probably be obsolete by the next version of weewx, I made it available on github in case anybody else needs it.

Skycam

Okay, it’s actually more of a view-of-sky-somewhat-obstructed-by-trees-cam, but I really wanted to do a real time view of the sky this time. It’s the Foscam FI8918W wifi camera in an upstairs window. It has a built in web server that provides live images and video, and the ability to remotely pan and tilt from any Internet connected device. It also makes a nice way to continue watching a storm long after nearby lightning chases everybody inside.

The old weather station lasted three or four years – I hope this one will last as long or longer. It will definitely be easier to replace when the time comes.

- Brad N8QQ

After recently using the Ruby-based s3sync tools to handle backups to Amazon’s S3 service, it seemed a good time to give the Ruby programming language a fair shake and see what all the hubbub was about.  I had a little exposure to Ruby a couple years ago using a book tutorial to create a blog in Ruby on Rails, but didn’t really learn much about the language itself in that process.  And having recently discovered The Dev Show podcast on the 5by5 network, it’s also possible their extreme Ruby bias started rubbing off on me!

Speaking of which, has anyone else noticed that all Ruby podcasters and screencasters sound like they’ve been neutered and reprogrammed by aliens to be void of all but the most mildly pleasant Xanax-laced emotions?  Very even keel and NPR-sounding, as you drift… off… into… Roooooooby…..

It always helps to have a real application when learning something like a new programming language, and having recently completed an upgrade to my Perl Module for the QRZ Callbook API, it seemed that porting it to a Ruby Gem might be the perfect goal.  Armed with “The Ruby Cookbook” and “The Ruby Programming Language” in my Safari Books account, and some free time during the holidays, I began.

The first problem encountered was trying to use Ruby on Debian, the epitome of stability in my opinion, and my server environment of choice for that very reason.  The Ruby package for Debian had already been installed on the system in order to use s3sync.  But when trying to do something as simple as listing the remote Ruby Gems, it produced a fairly cryptic error.  Researching the error eventually led to this post from one of the Debian package maintainers. The reputation of Ruby’s instability was immediately showing itself.

Compiling Ruby from source seemed the only realistic way to move on.  I installed the latest version, 1.9.2.  It seemed like a good idea at this point to make sure s3sync and s3cmd were still working, only now they were producing fatal errors.  Research confirmed that the s3sync tools simply do not work with Ruby version 1.9.2.  So I installed Ruby version 1.8.7 from source instead, and thought very seriously about abandoning the project.

Eventually I did finish and publish my new Ruby Gem and felt a little less behind the programming curve afterward.  (Read: keeping up with the youngstahs)  I do like the language a lot – it feels like you can accomplish many things in fewer lines than other languages, and that the code is very clean and legible.  And it does seem that there’s something just plain fun about it, similar to the way OS X feels good in a can’t-necessarily-put-your-finger-on-it way.  And RVM (Ruby Version Manager) appears to be a slick (and fun) way to manage an otherwise unstable version environment.

Fluency in both Perl and jQuery seemed helpful since most concepts in Perl translate fairly well to Ruby – such as the array and control structures – and the endlessly chained object oriented methods feel a lot like jQuery.

Time and energy-allowing, I’ll probably take a more serious pass at Rails; I have an application in mind.  I abandoned Rails the first time when it became clear that incorporating it into our Apache-based server environment at work wasn’t realistic.  This time the approach will be with an application that’s more standalone in nature.  And after learning about Passenger, I have at least some confidence that maybe Rails and Apache can co-exist better than used to be the case – and it might not even be slow!  We shall see…

Occasionally I find myself trying to explain why I can’t switch from one technology to another. Invariably, it’s been so long since trying to switch that I can’t remember the reasons why, and I end up unable to explain myself. One of the these technologies is Google Mail. While it’s on my mind, I thought I might document the reasons here before I forget again.

I’ve been using Google Apps for both work and personal Email for several years, and I love it for many reasons. The web-based interface does come in handy from time to time – it’s the only way to search for messages and administer the account – but, there are a few pieces of functionality implemented oddly enough that I can’t use it as my main interface for mail. So I continue to just use it as a back-end via IMAP with a mail client native to whichever operating system I’m using at the time.

Until last year, threaded messages was one of these stoppers. Thankfully, Google finally offered the option to turn that off. Google’s products often remind me of 37 Signals in that they believe they know more about what you need than you do. The result is that they offer limited configuration options; forced message threading was a glaring example of that.

But, that still leaves two annoyances I’m unable to move beyond…

1. The date on the message listing shows only the date, and not the time of day – unless the message was received on the current day. Further, if you want to know the time the message was received, it’s two clicks away. After viewing the message, you must click “show details”, as though the time of day the message was received is of little value. When trying to switch, I was amazed at how often I needed to know that, and how annoying it was when it wasn’t immediately visible in the message list. I would like the option of having something brief like “2011-01-01 2:37p” on each and every listing.

2. When replying or forwarding a message, instead of including the basic header info listed above the quoted original message, it only says, “On Jan 01 2011, Bob Smith wrote:”. The million dollar question this leaves is: who was copied on the original message? Am I really the only person who finds it highly useful to know who was copied on the original message? (Apparently so.) This really makes it feel like a toy rather than an enterprise level interface. And this isn’t just a problem with Google. Most free email clients, like Mozilla Thunderbird and Apple’s Mail client for OS X, have this same problem to one degree or another. Some will use the full header info with forwarded messages, but not replies.

Oddly, Microsoft seems to be the only maker of email clients that understands this. So in the meantime, I continue use Outlook on Windows, and Entourage on OS X. And there’s no decent equivalent for the Linux desktop the last time I checked – same problems.

There’s also the bigger issue of any web-based interface with not being able to just arrow down through each message in the list and see a full preview of the message, but I think I could get past that.