During the refit of our boat, one of our many requirements was to have a source of weather data on-board–especially for sailing in remote places. For an old classic schooner, we couldn’t use just any weather device and not adversely impact the aesthetic. We decided to install one of the mast top Airmar weather stations that use ultra-sound to measure wind speed and direction–thus there is no spinner and vane. A PB100 was purchased before the boat was even relaunched. This enabled us to modify the top of the main mast (the spot with winds least affected by sail configuration) to accommodate the PB100 as well as a new OGM LED tricolor and to route the required cables through the mast before it was stepped.
After the boat’s relaunch there were many high priority tasks. None of these included hooking up and testing the PB100. When we did get around to it, we found the device inoperative and out of warrantee. The PB100 location is well above all the sail blocks and hard to reach when climbing the mast. Eventually, I retrieved the device and we paid a reasonably fee to have Airmar troubleshoot and repair it. The device was remounted atop the mast after a few months delay as we waited for better outdoor climbing weather. As it so happened, at that point we were without a notebook with Windows 7 installed. The new notebook ran Windows 8 and the Airmar software was not compatible with it. Months went by and eventually we got Windows 8 drivers from a second source and managed to get the Airmar software to run, but only about half of the instrument were working. At this point, there were a lot of potential sources of the problem: new USB isolators, Windows 8, the second source hardware drivers, the Airmar program, or any combination of those due to incompatibilities. Since the device had been reworked and tested at the Airmar factory, we figured that couldn’t be the problem.
Eventually, good support from Airmar helped us to determine that the device needed to go back to the factory. So, it was time to climb up the mast again. This time Airmar fixed it gratis, but not without saying that the device appeared to have been over-torqued during install at the mast-top. Given the required physical contortions I had to go through during the install, I have to admit that was a possibility. This time, once installed, Brenda tested the device while I was still trapped in my climbing gear atop the mast, thus ensuring that it–finally–worked as advertised. Yahoo!
My original goal for the Airmar PB100 was to continuously stream the data to storage for later analysis. Brenda’s Windows notebook was not the right device since she routinely has it with her and it is not always hooked in to the boats NMEA/USB wire. Further, her notebook is usually hibernated when not in active use to save energy. The perfect device is my Raspberry Pi–it uses very little energy and is on all the time anyway. The only problem is the complete lack of software for the Airmar to run on the Pi, but I thought “I can fix that!”
Actually, timing is everything. The PB100 serial to USB hardware was not compatible with the Raspberry Pi FTDI driver until a development update in January 2013. So, even though we only had partial functionality of the device at that time, we were able to work on the first task required–streaming data to storage. That was implemented using a udev rule to recognize when the PB100 is plugged in and to load the ftdi-sio driver, create a symlink to the device, set the baud rate, and then start a script to stream the data to storage.
The last step proved a little more complicated. We wanted the weather data to be available, real time, to multiple applications in addition to being stored in a file. We tried several ways to accommodate multiple readers of this data, most of which divided the data such that each reader received only a part of the data rather than all of it. Eventually, we settled on using the free version of Remserial. Remserial takes the NMEA data, ensures that it is in proper format for serial data and makes it available on a port of my choosing on the Raspberry Pi–23000 in my case.
Next we start a Shell script to stream data to a file. On the Pi, the shell script had problems detaching from the udev script and running as a non-root user even using nohup. In the end we used the ancient “at” to start the acquisition script as a non-privileged user. The acquisition script initially had some logic to parse the data. Specifically, the PB100 runs through a NMEA combiner which adds NMEA sentences that add no value and only take up disk space. We wanted to skip storing those sentences, as well as sentences that were clearly truncated and incomplete. A problem is that any filtering of the NMEA stream imposes a CPU burden and the Raspberry Pi on our boat is already very highly loaded with other tasks. Thus, we changed the script to basically dump everything–with the philosophy that when we retrieve the data for analysis, we will filter and check for data integrity then.
Each time the data streaming script is started, it ensures the last run is stopped by killing that PID, moves the last data file to a subdirectory for archiving, records its PID in the run directory, increases its process priority to nice=-15, establishes a new data file name based upon the current date and time and streams the NMEA data to that file. To aid in later analysis of the stored data, the Shell script prepends each NMEA sentence with a high-resolution time stamp. We use the “ts” command in Moreutils. The core line of code is based upon Netcat (nc) as follows:
nc -d localhost 23000 | ts “%Y-%m-%d, %H:%M%:.S,” > ” $RAWLOGFILE”
The Raspberry Pi is pretty reliable, but it has limited memory and that appears to be a source of reliability problems. Occasionally, we found that data-logging had stopped. The most common symptom would be that Remserial fails. This usually would happen when Brenda’s Windows 8 notebook accesses the GPS data from the PB100 to use real time to plot our course in chart software like OpenCPN. To mitigate with, I wrote a Cron script that runs under root every 5 minutes to check for updates to the data logging file. If no update has happened in the last two minutes, an attempt to restart Remserial and the data logger is initiated along with an audible system beep to alert us to the problem. This Cron script works very well on my AMD64 computer, but for some reason, the ARMHF Raspbian OS handles Sudo commands differently and often fails.
With the above data-logging, the core functionality required is in place. But to actually use the data requires a bit more work. For historical trends, I wrote a script based upon Gnuplot to display multiple types of data in plots that can span various time-frames. Those plots are nice, but the real pressing need was for real-time display of data in a useful format for use when sailing. Stay tuned for how we addressed that need.