NMEA with Raspberry PI: All Good!

The last step - after this one - was not as straight forward. But finally, everything works fine.
The idea was to use PI4J to read the serial port (/dev/ttyAMA0). All the tests I made with PI4J were all very positive, but apparently, there is a bug when the baud rate is 4800. And unfortunately, this is the one we need.
But as reading a USB port (/dev/ttyUSB0) was not a problem, a simple adapter (serial 9 pin to USB) fixed everything. And on Linux (Raspberry PI runs Linux, a tweaked version of Debian), no driver or any such thing is required. Plug it in, and boom! It works.

The Raspberry PI reads the serial port with the headless console, and rebroadcasts everything appropriately.
The NMEA Console and OpenCPN can use TCP to get the data, The html5 Console uses HTML..., everything goes seamlessly. For less than 700mA. And around $50.
We will detail later all the steps to go through to get this done anywhere. This is just an easy check list.
And we'll built a nice box to host all this. The Raspberry, an optional small screen, and possibly a small keyboard.
More soon.

And just to give you a taste of what will come next,node.js works like a charm on the Raspberry PI, and the WebSocket protocol works as if it had been designed for this platform... That is going to seriously rock.

To summarize

This project goes along with the NMEA console, found here.

The main points this project addresses:

• Serial ports (most of the data we're interested in come through a serial port) are accessed exclusively. Only one program at a time can access the data. I had the problem on the ketch, when the cartography soft was accessing the data port (to plot the boat on the chart), the console (the one evaluating current and performances) had to wait.
• The laptop you can use to read the data draws a substantial amount of electricity (around 10W is not unusual).
• Several devices on the boat (tactician, driver, navigator, trimmers) might need to have simultaneous access to the data, and they might need to be already processed and smoothed (damped)

The various devices needing access to the data might not run the same Operating System (MacOS, iOS, Android, Windows, Linux...). We assumed here that they have a network access, and a browser supporting HTML5 (the tests I made for this particular point are positive).
So, here is the story:

1. The Raspberry PI creates its own ad-hoc network when it boots, and you start on it a utility that reads the data from the serial (or whatever) port connected to the NMEA station
2. The data are read, and stored on the raspberry in some cache (a hashmap).
3. The data are logged (optional), and processed (true wind is calculated, current is evaluated, VMG - on the wind or on the mark, performance, are evaluated). Those data are cached as well. Those calculations require some parameters to be set (max leeway, deviation curves, polars of the boat, some coefficients for the instruments, etc), they are available on the Raspberry PI.
4. The data rebroadcasted on TCP, UDP, and HTML (also possibly RMI; I dropped GPSd). You can select one or more of those channels for rebroadcasting.

Basically, this is all the RaspPi is doing.

The SD card containing the OS of the PI needs to be 4Gb big, minimal recommended. Mine is 8, and it can go beyond 32. This allows DAYS of logging.

Now, when a device from the boat wants to see what's going on (i.e. visualize the data), it connects to the boat's ad-hoc network. Then, depending on its possibilities and needs, it can use the NMEA Console (that one can read any channel for its data input), or the HTML5 Console (at the bottom of this page).

The chart plotting program (like OpenCPN) can use the exact same data stream.
And when you're done watching your device, you can turn it off, hibernate it, what not, the RaspPi keeps reading and broadcasting.

The RaspPi does not take more than 700mA.
And it costs less than $50.
The RaspPi does not need any keyboard or screen. (I use SSH from a laptop to start the reading program on it).
The main points are:

• Low consumption (and low price, if it makes any sense in this context)
• Data rebroadcasting
• Logging (ages of logging).
  I log VWR, RMC, MWV, RMB, VHW, VLW, HDG, MTW and GLL. It's about 1 Mb per hour.
  One day would be 24 Mb. One week around 168 Mb. Peanuts.

I have a lot of data, some logged during our Polynesian trip, I can replay them. This story seems to work.

I was very interested during the recent America's Cup, to see all the crews watching several kind of devices..., many had those displays on their fore-arms, tacticians had some iPad-like devices, fasten on their bellies with some shock-cords and velcro..., it kind of rang a bell! Those boats had for sure way more sensors that just an NMEA station (up to 3000 sensors for Oracle, I heard), but I believe that there is already a LOT to do with the data you can get from a regular NMEA station.

Once the ad-hoc network is setup, the crew members can even use their smart phone to access it, and visualize the HTML5 Console. That actually enhances one point: All the technology is here - nothing has been built or invented specially for this project. It's all about getting access to it with existing devices and techniques. Everyone (including me!) now has a smartphone, Linux has been around for ages, NMEA is one of the (if not THE) oldest standards in IT... And again, a small device you can get for less that $50 makes it all possible!
I like that.