Tag Archives: hard drive

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

Posted on by under anchoring, living aboard, Systems, Weather

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: over reaching and hitting the wall

Posted on by under anchoring, living aboard, misc, Systems, Weather

For background, see the previous post here. At this point, the Raspberry Pi (RPI) has proven itself aboard Schooner Mahdee by reliably logging data from our Airmar weather station plus other boat data and displaying that data on an HDMI monitor, as well as monitoring that data and sounding alarms as required. We built in the capability for more than one computer to read the Airmar weather/boat data from the RPI network port at the same time. To realize that potential, we needed a Wifi access point. A USB Wifi dongle, supporting the access point protocol, with the right software (in our case HostAPD) turned the RPI into an access point for all Mahdee users. A good access point provides some basic network services that were set up on the RPI–such as IP address assignment DHCP server–and is a domain name server (we used Bind9 server) for all the Wifi-connected computers aboard the boat.

Raspberry Pi and Cat

Further adding to the roles for the RPI, I wanted to be able to read email without turning on any other computer, so we needed to set up internet access on the RPI. We set up the RPI to use either a Sprint phone with a data tethering plan using PPP or our Verizon Wifi hotspot using a second USB Wifi dongle. Since Brenda’s Windows 8 machine can’t tether directly to the Sprint phone, we decided to make the RPI Mahdee’s internet gateway that can be switched between either Sprint or Verizon. That also meant a better firewall setup for the RPI.

The RPI doesn’t have a hardware clock (by design it would rely on an internet connection to set the time on boot), so when we rebooted the RPI, sans-internet, in the middle of nowhere in Alaska, the data logger had the wrong time stamps. To fix that, we setup a USB puck GPS as a time source for the RPI. This meant also running a GPS position server on the RPI which is then available on a network port of the RPI for other computers aboard Mahdee. The fast high resolution GPS data was also setup to be used by a Python anchor watch and position alarm which I’d previously written for the Nokia N810. The sound system on the RPI is not very good nor very loud even with our USB powered amplified speakers.  For the alarms we setup a piezo-electric buzzer which is energized by a RPI GPIO port so that we can hear alarms anywhere aboard the boat. The RPI also uses GPS time stamps to provide a network time basis for other computers aboard.

With the 2TB Passport hard drive attached to the RPI, it only made sense to put a copy of our public file archive on it and thereby make it available to us 24-7. The public file archive includes repair manuals in PDF form for most boat systems (nice to have in an emergency), all of our photos as well as digital books and magazines (nice for passage entertainment). This nicety meant putting PDF and e-book readers on the RPI. Then, to enable access to those files from Windows computers, we setup a Samba server which also requires a network time server. Fortunately we already had the GPS-based network time server on the RPI.

To enable us to read our email when there is no internet connection available, we setup the RPI with OfflineIMAP to sync mail from our main email server (an off-boat/shore-based virtual private server) whenever we have internet access. I read email using Mutt which can run in a terminal on the RPI. Brenda likes to access email using SquirrelMail webmail via her computer’s web browser, so we added an Apache2 web server to the RPI along with Squirrel Mail and an IMAP server.

In among the public archive data is our music collection, so we setup RPI as a network music player. On those long passages, we thought it would be nice to listen to music, but this is where things start to break down. The poor, now very overloaded, RPI just couldn’t make the music sound even decent. I also setup my Bluetooth stereo headset on RPI, but that was even worse than listening to broken up music through the speakers.

Many boaters want their RPI to run a navigation program like OpenCPN. I had managed to compile a version of OpenCPN on our first RPI, but running OpenCPN required all the resources of the RPI and I was not willing to forego all the other important roles our RPI was needed for–simply to use OpenCPN as a backup chart plotter.  Our real chart plotter is used to display radar and chart data including charts for other countries without free official charts (like Canada). Not needing to run OpenCPN helped a little with our overloaded RPI situation.

From the RPI GUI interface, I found web browsing to be very slow and unproductive. I could get email and read it using Mutt just fine, but there was other trouble lurking. Brenda informed me that basic web access from her computer through the RPI Wifi access point was way too slow. I tried it using my main computer and had trouble too. I had had hopes–fantasies perhaps–that RPI would also run a contact and calendar web service. Most people would just use Google for this, but we are often not near internet access and besides, who really wants to trust the big guys with all of your sensitive contacts and scheduling. But, it was not to be–at least not yet.  Stay tuned for the next installment in this series of posts about the RPI and how we turned the corner towards success.

The Power of Raspberry Pi: the blissful beginning

Posted on by under anchoring, living aboard, misc, Systems, Weather

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