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