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.
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.
