We are the people who work on old things

Yes it’s true, we are now the people who work on our old boat and we used to be the people who worked on our old house.  Plaster, woodworking, repairing marble surrounds, copper flashing and mission tile roofing, replacing galvanized pipes for newly soldered copper ones, refinishing floors, repointing bricks, reglazing windows, and restoring intricate plaster crown moulding.  That was then: the house.  This is now: the boat.   Someone really introduced us to another couple that way “those people who work on their old wood boat.”  At the time it made some sense because when we were in a slip it was because we needed shore power to work on the boat more conveniently and when we were sailing we were “out there” and absent from the view of the particular fellow.   It’s an interesting life–being the people who work on their old wood boat.

But right now all I can think is “Buttercup, oh Buttercup. How many ways can you make my life interesting?”  David and I recently took Buttercup for a “spirited ride,” let’s call it. A Sunday, a glorious day of driving our 1976 Saab 99 on winding roads, dirt and paved, up hills and over mountains, and along the seashore just as Buttercup loves to be driven. The drive was a ‘post tuneup check’ to see how she was doing.  She was to have her state safety inspection the next day and I needed to make sure she was in good form.  With little bits of rust here and there, the old girl is not looking her best and it was all the more important that she pass the inspection with flying colors.

On the drive we found all was good with Buttercup except we noted the rear shocks had seen better times and further since the ball joints I’d ordered from Rock Auto had arrived, it looked like we’d be spending a day working underneath Buttercup sometime very, very soon. We’d just need to find someone to do the alignment.  As an aside — Rock Auto has amazing deals on car parts for, shall we say “elderly” cars.  A further aside, Buttercup did pass her safety inspection just fine — more or less an emissions check, the inspector must still make sure brakes, lights, and all the rest work.  Lucky for Buttercup they are not as picky as we are and they didn’t do the big sideways jiggle/push/pull thing we do on the front wheels or they’d have noted the tiny bit of a giveaway that her right front ball joint wants to be replaced and they didn’t take her on a spirited drive or they’d have known her shocks weren’t up to snuff.  Fine for normal driving but not so great for rutted country roads.  

Gone are the days where one can get a selection of good shocks for any USA-based pre-1978 Saab model 99.  Having owned our 1974 Saab 99 Pepe for his last 34 years and 400K of his half a million miles (1982-2006) and Buttercup since 1998, I know a little thing or two about shocks for the model.  Before we owned Pepe, David’s father owned the car since it was new.  David had cajoled Dad into many things that were lifetime warranted to the purchaser — and since David did all maintenance for Dad on Pepe, that meant David owned the lifetime replacement guarantee on let’s see…a JC Penny (later Firestone) battery, lifetime alignments, and even lifetime warranted Koni shocks.  We used those on Pepe for about a decade during which we re-valved a few times and then gave up. The lifetime warranted Bilstein shocks? I blew through those on our Saab 900 in less than a month. Replaced and ruined again within weeks.  Let’s not talk about the 900 for now.

Back to shocks for the 70’s era 99 models. For our Mexico jaunts in Pepe, we used different springs, lifting kit/spacers and I obtained Bilsteins meant for a particular import truck with the same vertical pin shock mounting system and a little different range of motion. Alas while that was good for our ’74 99 for many back road excursions in the 80’s and 90’s it likely contributed to every shock mount point being ripped apart (on the road) and rebuilt (in a local welding shop nearby) a few times…even those trusty (lifetime warranted) shocks were rebuilt a few times and swapped out with the Konis on Pepe until finally I gave up on them when we said our farewells to Pepe in 2006 (RIP.)  Buttercup, with her original 1976 axle is stuck with those same old-style shock mounts.  When we got the car, we put the Koni shocks on her, or maybe it was the Bilsteins — whichever ones that were not on Pepe.  A few years later we threw some KYB shocks on the car thinking “we’ll find something different, later” and so now is “later” and we see that shocks for this car are available from only a few makers.

Though David reminded me that KYB really just means “keep your Bilsteins” I had decided I’d just get some decent KYB shocks for Buttercup and probably just needed to find a local sale.  It’s so hard to justify more than the basics for Buttercup when we drive so few miles and well, we try to keep the maintenance funds together for Mahdee’s much larger appetite.  These old ladies vie for attention, that is for sure.

Yesterday when suddenly Buttercup’s passenger rear side started making a clunk-clunk-clunk over rough road spots, I thought “hum, I’ve heard that noise–the shock bushing just popped off top or bottom of that shock.” David and I both have a lot going on right now and I hate getting dirty anyway so I also thought “I have an excuse to get someone else to replace these shocks! I’ll take the car by the local auto parts place” where I’d recently seen they have a model of decent KYB shocks “and I’ll have them put a set on the rear of Buttercup.”  I texted the same to David.  He came back with “sure, ha!” implying the shop couldn’t do the work.  I won’t say he jinxed it but I will say he was right.

I looked at the estimated cost and almost just bought the shocks and took them to the workshop to install myself.  But I hate getting dirty.  I have mentioned that? It’s always dirty, gunky, yucky work to get the nuts loosened up and off of the top and bottom pins of the shocks.  It’s sometimes really difficult to do, as well.  Wesley is playing “garage king” in the workshop while we wait on an electrical part so the logistics of getting Buttercup into our workshop would involve me PUSHING Wesley out of the way…no, no, not going to happen because then I’d have to push Wesley back inside the workshop, too.  The car is heavy and there’s a lip on the concrete sill that I would find difficult to deal with.  Therefore installing shocks on Buttercup would mean doing the work outside the workshop door rather than inside. Outside on the pebble-strewn, dirty, gritty asphalt.  Nope.  Not going to do it. Nope.  And David was tied up all afternoon with other things–so much the more perfect excuse to just pay someone to do the work.  The only things Buttercup has ever had anyone besides David and I do? a couple wheel alignments when we’ve replaced tie rods or ball joints– and we had a gas tank lining installed once.  Lifetime warranted lining, I might add.  Old habits die hard.

As I was filling out the paperwork for the shop to replace the rear shocks, I wrote details of the noise and then wrote “please report whether the top and bottom bushings were in place on old shock rear passenger side and if both are in place, please do careful inspect the rear suspension, panhard arm bushings, shock mounting points, and related that might produce a clunking noise from that area.”  No work on the front suspension requested.  I  knew they’d be likely to note the right front ball joint and was in enough of a hurry that I didn’t want to deal with a full suspension inspection by them.  Because Buttercup still has her reverse lock intact, I also gave them the standard Saab bit about “key between the seats, car must be in reverse to remove key, reverse lock is annular ring around shifter knob, pull up on ring while clutch is depressed to put shifter into reverse.  Only try to remove key once the car is in reverse. Do not remove key if you cannot get car into reverse.  Just leave key in ignition if you experience any problems.”

I sat in the waiting room an hour, anxious and unexpectedly worried about that reverse lock–playing the game of odds: will they break it or not? Thinking how ridiculous it would be for this car to have survived 41 years of driving without the reverse lock being broken and having it get broken now.  The service manager came out to the waiting lounge, handed me the paperwork and said “we can’t fix your car.”  I said “fix? what fix? do you mean install? Do you not have the shocks? You cannot install the shocks?”  and he said “No, we can’t fix you car.  There’s too much wrong with it.”  I asked “what’s wrong? Is a shock mount to the body ripped out?”  thinking that even though the shock itself seemed fine, my worst fear was true and I’d have to find a local welder for the work.  “No mam, there’s just too much wrong. ”  Now I was perplexed. I asked to speak to the mechanic to find out what “everything” was.  After all, I already knew about the ball joint… maybe he was looking at the front end, not the rear suspension. I actually knew that we should replace the brake pads sometime in the next few months.  We do that as a preventative though.  Brakes are not suspension…he couldn’t be thinking about brakes?  The hard to find MetalMasters are on back order and will be here in a few weeks.  My mind went automatically spinning through the logistics of going ahead and bleeding the brakes at the same time as doing the pads. Solid rotors made for different pads.  I really like the vented ones.  No reason to change them though. But I really like the vented ones.  Finding a place to take the old brake fluid.  Does O’Reilly’s do that? How about the US Coast Guard Auto Hobby Shop? But bringing myself back to reality, today! The brakes would be no reason to say “too much wrong” and not install new rear shocks.

The mechanic, a small Hispanic fellow, came out and said “the car, it pulls a little to the left when I push hard on the brakes but other than that I could find nothing.  I don’t work on old cars.  You should take the car to the people who work on old cars.”  I ask him “what about the bushings on the top and bottom of the rear passenger shock?” and he says “the bushing is there.” And I say “did you see any other missing bushings? Panhard arm or nearby anything?”  to which he says “no.”  And I ask why he didn’t go ahead and replace the shocks.  I learn that again “I don’t work on old cars, you should take the car where they work on old cars.”

So an hour wasted and I still don’t know what is causing the clunk, clunk, clunk.  As I got in the car I noted the key was in the ignition, turned to the position to keep the radio on, the car was in 2nd gear.  Guess the guy didn’t read the instructions but thankfully he didn’t break the reverse lock. I look at the time and realize David is likely on his way to the boat very soon, riding right past our workshop, so I text David to meet me at the workshop and I drive the few blocks there.  Took a look under the car.  Missing shock bushing as suspected.  Drove the two blocks to the O’Reilly Autoparts store to purchase something to use for shock bushings thinking “we have these things somewhere… but it would take more time to find them than to buy them.”  A four-pack of generic bushings is $4.49 plus tax.  One bushing needed.  Three spares for the glove compartment.  I wonder if I’ll remember they’re there in a few years when they may be needed? Jackstands and chocks in place, David laid in the gravel and grit on the asphalt and got gunky greasy fingernails while installing the cheap bits of rubber. He has a big loopy grin on his face.  He’s happy–but won’t admit it–that the mechanic didn’t work on Buttercup.  I wonder if he even notices the dirt?

We put David’s bike in Buttercup’s trunk and drove together to Mahdee.  The clunking is completely gone.  I mused on the way home thinking of what the mechanic said “you should take your car to the people who work on old cars.”

We are the people who work on old cars.

The Power of Raspberry Pi–MythTV tweaks and techniques

This post continues my previous ramblings about using the Raspberry Pi aboard the boat.  To start this story at the very beginning, go to this post. To go to the previous post in this series, go here.

Screenshot of MythWeb running on Raspberry Pi 2

Now to discuss some lessons we have learned about using our RPI-2 with MythTV aboard Schooner Mahdee to record over-the-air TV broadcasts for later viewing: Why record when so much is available instantly over the Internet?  Four reasons:

  • we are often anchored where Internet access is unavailable, or the speed is too slow to stream video;
  • we pay for high speed (4G) access per gigabyte;
  • broadcast HDTV provides an effectively free source of additional bandwidth and the HDTV programming is often many times much higher resolution than via Internet streaming;
  • those shows can be saved on a hard drive for later viewing anywhere and anytime.

Stunningly beautiful full 1080 HDTV programming is often broadcast and can be saved for later viewing on a big vibrant HD computer monitor–even in places with no Internet at all.  Those very high resolution shows consume around 5GB per hour.  If using our 4G hotspot, at that rate, our entire monthly Internet bandwidth for work and pleasure is equivalent to a couple of HDTV movies.  By comparison, in some locations, we can record HDTV shows around the clock for free–an incredible deal!  In practice, each 24 hours of saved H-264 encoded HDTV recordings exceeds our total Internet bandwidth usage for the entire month. Our only cost is for the hard drives and each $150 hard drive can save thousands of shows and take up less space on the boat than a small paperback novel.  So, even when we could stream videos over the Internet, we rarely do.

Since we obviously travel a lot, our settings for MythTV are not set and forget–in contrast to more stationary users.  We use Antenna Web in each new location to determine where HDTV transmitters are relative to us and how well we can expect to receive different stations.  We have both an omni-directional and a directional gain antenna to choose from.  Spinning around on a single anchor makes the directional antenna unusable, but if the boat is fixed in orientation with multiple anchors or shore-tie, we can use it to increase reception of more distant HDTV stations.  Sometimes we can get great reception with the antenna below decks in a stealth mode.  For more challenging stations, reception may require an antenna be raised on a flag halyard–not so stealthy.

We have an inexpensive account at Schedules Direct which interfaces very well with MythTV.  With an Internet connection, we generally upload new schedule data every day or two.  There is limited (just the next 12 hours) program schedule data provided for free by the stations themselves on the transmitter frequency using EIT, but scheduling works best with longer range data and Schedules Direct provides about two weeks of scheduling. That data also includes lists of actors and other credits as well as descriptive information which we retain with our recordings and in a separate custom Ruby-on-Rails (RoR) web interface and database.

Schedules Direct also allows us to have four different locations in our profile.  Thus, we have one for each major city area we typically visit.  In those profiles, we can remove stations we do not want–such as those without English language audio–and our custom settings will persist until our next visit to that area.  I am constantly amazed at the number of over-the-air broadcast stations we can receive even when we are far from a metropolitan area.

With our large MythTV database of over 10,000 previously recorded shows, nearly 100 channels of available broadcast programs in many locations, and large number of rules and priorities about what we want to record, it can take several minutes after starting the MythTV back-end for it to figure out what to record. During that time, the MythTV front-end and MythWeb browser interface running on the RPI-2 will will show no scheduled recordings. Whenever possible, I use the command-line mythtv-status to see what is in the recording queue rather than running the more resource-intensive front-end. Even mythtv-status can take several minutes to complete and will show that nothing will be recorded until all of the data has been parsed and prioritized by the MythTV back-end.  Loading new schedule data from Schedules Direct can take nearly 20 minutes to process on our–admittedly overloaded–RPI-2. Sort of like sailing tack to tack to get to one’s ultimate destination, patience is required and one can not expect a newly added show to be put into the recording queue right away. I plan for the RPI-2 to take up to five minutes before a new recording is reflected in the queue.

With an Internet connection, MythTV gets program meta data for each recording so that we have images of cover art–which makes the front-end display nicer.  MythTV can also flag commercials so that they can be easily skipped during replay or even removed from the file entirely.  Commercial detection is very resource intensive, so we set MythTV on the RPI-2 to not do any commercial detection on the recordings. With this setup, the RPI-2 is also very useful as a desktop computer for me to browse the Internet using Firefox/Iceweasel, read and write email and other miscellaneous things all while displaying current weather data and monitoring anchor holding.

One glitch that I have encountered is that the MythTV startup script does not always work in Debian Jessie due to incompatibility with SystemD. The symptom is that the startup script completes with no errors, but the back-end is not running–starting and restarting MythTV using has no effect. The problem seems to be related to the init-functions command. Adding the following just before that call in /etc/init.d/mythtv-backend as follows helped:

_SYSTEMCTL_SKIP_REDIRECT=true
. /lib/lsb/init-functions

Then that fix failed so I am now manually starting MythTV using the old InitV command:

/etc/init.d/mythtv-backend start

It is also good to ensure that MythTV is not running before starting it and to make sure there is no file named /var/run/mythtv/mythbackend.pid. First kill hung processes and then check for the pid file and delete it if necessary before staring MythTV using the above command. Since I rarely reboot the RPI-2, manually starting MythTV works fine and the InitV command is trouble free.

Another glitch is that the HD HomeRun recordings sometimes fail leaving MythTV thinking the recording is still happening. After upgrading the HomeRun to the latest firmware, this situation happens less often. Still, every few days I need to stop MythTV and wait for all the threads to be killed and then restart MythTV.

Next, I will cover some system-wide optimizations that we have made that make MythTV more reliable given the highly loaded RPI2 we run it on.

The Power of Raspberry Pi–rethinking and restructuring to do even more with less

To start this story at the very beginning, go to this post. To go to the previous post in this series, go here. As it may be clear from the discussion so far, I have a tendency to increasingly add more requirements and functionality to my Raspberry Pi (and/or the newer version 2 RPI-2) computer until it cries “uncle”–or more often than not, just quietly dies under the extreme load. This post is about adding more functionality, but by being smarter, avoiding the dying part–at least for now.

myth tv running on raspberry pi
Every traditional boatwright needs to watch the Woodwright’s Shop for inspiration.

One of our luxurious activities when paying to be at a marina with shore power is to run my Shuttle small-form-factor (SFF) computer with its Intel i7 CPU and lots of RAM and lots of storage space. When it is running, it records over-the-air–using an antenna–HDTV movies and shows according to various rules we have programmed. Those shows are re-encoded by the Shuttle computer in a very efficient format to make the files smaller–1/3 to 1/5 original size–and then saved to a hard drive for later viewing–like when storm-bound in a remote bay somewhere in Alaska.

Our time in marinas is limited and the Shuttle requires too much power to run just for recording shows (producing non-shore power electricity is very expensive) and the movie recording program is way too demanding for a regular RPI. But now I thought maybe, just maybe, the new RPI-2 could record TV programs–of course I really mean do that in addition to all the other stuff the RPI-2 already does.

The program we use to record over-the-air shows is called MythTV. I have a love-hate relationship with MythTV, but we have been using it for about 10 years and it keeps track of every show ever recorded by us so that it doesn’t re-record something we already have on a hard disk or DVD or CD-ROM somewhere on Mahdee or in storage. The challenge for us is that the database for MythTV has a huge number of recordings (way over 10 thousand) to keep track of and the scheduler needs to sort through all of our rules (which are numerous and have evolved from our refinements over those same 10 years) and compare rule-matching scheduled showings to already recorded shows and determine which shows to actually record when so as to optimize the recordings. I had my doubts that even the RPI-2 would be capable–let alone doing that task while also doing the really important stuff like keeping track of the weather and how well the anchor is holding–after all, we do have to keep our priorities straight.

To make the RPI-2 able to record TV movies we had to make some changes.

1. We bought a network HDTV tuner (HD HomeRun Extend HDTC-2US) that has a built-in transcoder that re-encodes the movies in a more space-efficient format (H-264) on-the-fly. This removes the requirement for the RPI-2 to re-encode the recordings–which it couldn’t do anyway–and keeps the file sizes reasonable. In addition, H-264 is an open standard whereas the original inefficient proprietary format used in over-the-air transmissions requires one to buy a MPEG license before the RPI-2 can perform hardware decoding for viewing. So not only is the output of the HD HomeRun more space efficient, it also uses an open standard that doesn’t require the purchase of a license. The HD HomeRun even runs on 12V DC which is nice. So we installed a 60W regulated 12V DC power supply on Mahdee to use the HD HomeRun off a 12V DC battery.

2. The other change was to continually power up the Linksys Wifi router. The Linksys is also powered by 12V DC–so it can use the same newly installed regulated power supply as the HD HomeRun. Earlier, we tried to make the RPI be Mahdee’s Wifi access point in order to save the power required to run the Linksys. Running the Linksys offloads the Wifi access point functions but more importantly, also provides a needed Ethernet hub. The hub makes is possible for the HD HomeRun tuner to be available to the RPI-2, as well as to my Shuttle computer, all over fast Ethernet rather than Wifi. Further, we decided that we could also keep running the old RPI and use it via Ethernet to offload some functions from the new RPI-2–such as internet gateway, firewall, GPS server, network time server using GPS, secondary/backup anchor position alarm, Scrabble game server (oh–didn’t I mention that requirement), as well as that coveted contact and calendar schedule web server.

The net result is that, even though we now have two Raspberry Pi’s running (an RPI and an RPI-2) along with a network TV tuner and a Linksys router (the latter two alone adding 24 amp-hours a day to our afloat battery usage), our electric power usage is less than half of what it was at the dock with the Shuttle computer running. We are now getting recordings and a practical, fun to use computer that is available 24-7 even while at anchor. All that while logging weather and boat data and monitoring that important data with alarms to keep us safe. The RPI-2 has been exceptionally reliable with our previous and current up-time exceeding three weeks since the last intentional reboot.

When passage making, we can turn off the network TV tuner, Linksys router and the RPI to reduce power usage without loosing any important functionality–e.g. don’t really need our contact server in the middle of the ocean. And with no TV tuner, we can turn off MythTV and have plenty of CPU capability on the RPI-2 to run the OpenCPN chart plotter which can use either the weather/boat data pseudo serial port on the RPI-2 for GPS data or the GPS data on the RPI if it hasn’t been secured to save power. With this nice flexible and stable setup, I have to keep telling myself not to add anything new. Unfortunately, I know that it is only a matter of time before I come up with new ideas of things/tasks/programs to add to the RPI-2. With any luck, a new more capable RPI-3 will come out before I completely overload the RPI-2. Right now, however, I am really happy with both my RPI and RPI-2.  Next I will cover some tips for running MythTV on the RPI-2 without impacting all the other stuff the RPI-2 needs to do.

The Power of Raspberry Pi–the new resurrection

beryl and RPI On Lap Monitor
For background and to start this story at the beginning, go to this post. To go to the previous post in this series, go here. The Raspberry Pi (RPI) on Schooner Mahdee has continued to work well in its primary task–weather and boat data logging to hard drive and serving and displaying that data plus tides and currents as well as performing alarms for anchor position and wind speeds.

The RPI was clearly not good at interactive GUI applications except simple email and very basic web surfing. It was also not working satisfactorily as an Internet gateway and a Wifi access point. The harder we pushed the RPI, the more often it crashed and shutdown. Then the RPI-2 was released with 4-CPU cores and 1G RAM–four times the cores and twice the memory of the RPI–and I thought maybe now I can get everything I want.

The new RPI-2 is designed to use a more advanced ARM architecture which meant that a standard Linux distribution could be used rather than the Raspbian distribution required for the RPI. I like Debian, so I installed Jessie on our new RPI-2. The RPI-2 has a different setup of IO-ports so our woody Ti-Bow case was not usable. That gave me an excuse to keep the RPI in its case and temporarily mount the RPI-2 next to it without a case.

During the extended transition of applications and functionality from the RPI to the RPI-2, I connected the two together with a simple Ethernet cable–no hub needed. The 50W regulated 5V DC power supply we have on Mahdee has more than enough capacity to run both Pi’s, the HDMI monitor, Passport hard drive, along with various other USB accessories and device charging requirements. I describe installing Debian Jessie and setting up the RPI-2 to run the chart plotter OpenCPN here. That article also includes a link to download an installable copy of OpenCPN that I created.

Because we are sometimes without any Internet access, I try to anticipate and install applications before they are needed and while we have good Internet access. Whereas the RPI is well equipped with a 16G SD card, the Sandisk Extreme SD card we purchased for the RPI-2 has a capacity of 64G. More than 6000 packages are now installed on the RPI-2 using over 80 percent of those 64G. SD storage is primarily programs and their documentation because most data is saved on the external Passport USB hard drive. So we have lots and lots of programs. More programs than may ever be used.

There is some stuff (actually a lot) on the SD card that really isn’t needed there. Given our experience driving an SD card to its premature death by writing gigs and gigs of weather data to it, we are sensitive to this. Further, an SD Card with more free space will distribute writes so as to extend its life; a nearly full SD Card can not do this and is more likely to fail prematurely. Since the Passport USB hard drive is always connected (using an entry in /etc/fstab), we can move a few things there. My criteria is to only move things that are not needed to boot the RPI-2 and preferably things that have lots of writes; mostly static files that are primarily read can be left on the SD Card.

I create a directory on the Passport drive such as rpi2_rootdir and in that directory, I create the subdirectory rpi2_rootdir/var/cache. Then I move /var/cache/apt into that subdirectory and create a link to the new location in its place. The only time I really need the apt cache is when updating and upgrading and that subdirectory ends up with lots of data and writes that I would rather have on the Passport. Another file with lots of activity is /var/swap which is used by the package dphys-swap. That file is a swap file for when memory is scarce and therefore (unfortunately) can be heavily used in my setup. One can also move the /var/log directory to the Passport once everything is stable. Further, I create a subdirectory in my user home directory which links to a directory on the Passport drive and I use that directory (on the Passport) for most of my user data–e.g. my email folder, downloads folder, music folder, application data, etc.. With those changes, my usage of the SD card is now less than 50 percent–including a complete copy of NOAA charts on the SD Card as a backup.

After email (using Mutt) and general writing using VI/VIM, my most used interactive application is a web browser. In the original RPI, I often tried to use Midori, but it’s development fell behind and it failed to render a lot of sites. Net Surf and some other light browsers don’t work well for me. The new official light browser for the Pi is the Epiphany Browser. I have not been impressed by that browser either. Google Chrome is not available from the Debian ARM repository and I have not found an easy way to get it. My favorite browser, therefore, is Iceweasel (the Debian fork of Firefox). I install the Vimperator add-on which makes the browser usable without a mouse–you just need the keyboard–and then my web browser works much like my VI editor which provides a user interface consistency that is very nice. But, Iceweasel/Firefox is a resource hog! Fortunately, there are several configuration changes that can greatly improve the usability of Iceweasel/Firefox on a resource-limited device like the RPI or RPI-2. I use the modifications described here. Also, I add the following line to my .profile:

export set MOZ_DISABLE_IMAGE_OPTIMIZE=1

Before these changes, Iceweasel would slow down the RPI-2 the more it was used until the RPI-2 was virtually unresponsive. With the changes the RPI-2 works great with Iceweasel. I do try to limit the number of open tabs in Iceweasel, but I currently have 25 tabs, along with about a dozen terminal windows, my QT Weather program, XTide and can even use LibreOffice and have the interface feel responsive! All in all, a very nice computer experience.

The Debian Jessie install went great and the only real hitch for me is not limited to the Raspberry Pi. Jessie uses the new SystemD and that breaks a lot of UDev scripts I wrote to automatically start services such as the Weather data logger when the Airmar USB cord is plugged in, and the GPS position and time servers when the USB puck is plugged in, and the Internet gateway when the Palm is tethered. Jessie has packaged some automatic scripts which work with common new devices, but not our GPS, Palm, or Airmar. For the Airmar, it turns out that my automatic testing and recovery scripts will get the data logging started. The problems with my other old devices may not affect those with newer devices, but my solution for them will be covered in the next post along with some new stuff.

The Power of Raspberry Pi: the blissful beginning

When we first heard about the Raspberry Pi (RPI) credit-card sized computer we thought that it might meet the goal of a low energy usage (just over 1 Watt) server on Mahdee that ran 24-7 and performed some essential functions. Those functions included logging, serving and displaying boat and weather data, as well as monitoring that data and sounding alarms when something isn’t right.  Our first RPI took many months to arrive because of demand exceeding supply in 2013 and the RPI coincidentally arrived at the marina office on Pi day (March 14).  It was late afternoon when I excitedly went to the office to take delivery (possibly just before 1600 and presaging a near obsession with this delicious sounding device).

Screencast of weather program on Raspberry Pi

The first RPI had only 256MB of memory and saw little use before we broke the SD socket. So it was replaced by the upgraded RPI with 512MB memory. With twice the memory of the original RPI and an over-clock ability, I was full of anticipation about what this improved, yet still power sipping lilliputian computer was capable of.  In hind sight, there was much to learn about the RPI.  This is the first in a series of blog posts describing how Raspberry Pi’s are used, and how their use has evolved aboard Schooner Mahdee. For the impatient and those who prefer doing rather than reading, the latest version 2 of the Raspberry Pi (RPI-2) can be purchased here and by following that link, you get a great price and can help to support the Raspberry Pi Foundation mission as well as this site.

Weather data on Mahdee is provided by our mast-top Airmar PB-100 weather station. The Airmar PB-100 provides relative and absolute wind direction and speed, barometric pressure, temperature, humidity and dew point, as well as boat magnetic heading, pitch angle and roll angle, GPS position, GPS course and GPS speed. The Airmar data is multiplexed with some boat data such as depth-sounder, water temperature and boat speed through the water before being sent via USB to the RPI. In order for the RPI to decode the Airmar data, the ftdi_sio kernel module must be loaded. And the crucial trick after loading that module, is to execute this special command:

echo 0403 d9a8 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

Without that change the data is not a readable serial port stream. With that change, the Airmar data is readable. We wrote a script to capture the USB serial data, time stamp each line with computer time and save it to a file. Initially, that data was saved on the RPI SD card which the RPI uses like a hard disk and also has the operating system and programs on it. SD cards have a fixed number of writes in their life, and after about a year, the limit was achieved and the SD card failed. So, we got a new SD card for the operating system and programs and a Passport USB-2 hard drive to hold data and thus preserve the life of the SD card.

When the weather and boat data are being saved, the data are forked and also sent to a serial-to-network converter that provides a pseudo serial port that is available on a network port of the RPI. We then wrote a QT-based program to connect to that port, read the data and display it on the RPI’s HDMI monitor. The QT program requires a GUI on the RPI and has many alarms including a position/anchor alarm, as well as a wind speed alarm. We cross-compiled the QT program to make different executables that run on the various computer architectures we have on Mahdee. An early version of that program was published on my GIT account, but if anyone wants a copy, please let me know so that I can update the version on my GIT account.

In the first versions of the QT program, we discovered that the displayed data was lagging further and further behind because the QT program could not always keep up with the Airmar data feed. This defect became painfully obvious during three sequential southerly gales while sailing north in March off the Oregon coast on our way to Alaska and striving to not unintentionally gibe–the displayed wind gust directions were just not matching the observed effects. It was pitch dark and freezing cold out in the cockpit with boarding seas and driving rain and we really, really wanted to steer from inside Mahdee’s warm, sheltered chart house and that required a good weather display with real-time information. We fixed that problem (later while recovering in a marina in Alaska) by allowing data to be dropped in the QT program so that the displayed data is the most recent data. If we want to analyze all data, we can then retroactively parse the saved file.

Sometimes the data capture would fail which would freeze the data displayed by the QT program. This required us to first notice the data freeze and then find the source of the problem.  We immediately noticed a data freeze when we were hit by a williwaw in a fjord in BC Canada and the displayed wind speed froze at only 56 knots even though conditions and our control of Mahdee were rapidly deteriorating. At the white-out stage, we knew something was wrong with the display.  The fix was usually to manually restart the data capture program, but there were often long gaps with no saved data because we didn’t notice the failure right away (or alternatively we were too busy fighting to control Mahdee in a williwaw). This was a big problem if we were counting on the RPI to sound an alarm–e.g. if the anchor came unset while we were asleep. So we wrote a Cron script to periodically check for file updates and if too much time passes without an update, a script automatically runs to restart the data stream. Alternatively if the external Passport USB drive becomes unavailable, the logger will automatically switch over and use the SD card for data storage. The automatic scripts greatly improved the reliability of our weather and boat data and improved confidence that the alarms will sound when they should. At this point, the RPI became a key piece of safety equipment aboard Mahdee.

Of course, we want the RPI to do more and in the next post we will discuss our experiences loading up (overloading?) the RPI.

Google Analytics Alternative