Raspberry Sailing. How the Raspberry Pi makes sense on board.

A computer can be helpful on board, for several reasons.

• Some useful navigation softwares need one to run (SailMail, for example, that allows you to receive faxes through the SSB, send and receive emails, all kinds of useful things)
• Some chart plotter softwares (like OpenCPN, the best) require a computer to run as well, to plot the current position on an electronic chart.
• The on-board electronics can be read from a computer (through NMEA, or some other proprietary protocols), and the data they emit can be used as parameters for calculations, like performance evaluation, routing, current estimation (tricky, but so useful).

Electricity can be precious on board (specially on a sail boat, where it is in short supply), it is required to run several important devices, like the autopilot, the water maker, and to some extend, the fridge. A laptop can draw a substantial amount of current, specially if its battery is old (2 to 3 amps and more, I have evidences). In those conditions, leaving it on all the time can be questionable. On top of that, turning it down, and turning it back up takes time...

Serial port access

The data we are interested in usually (like in 99% of the cases) come from a Serial port (USB, or 9-pins). A big detail to mention is that a Serial port can only be accessed by one process at a time. That means that when your chart plotter accesses the serial port, no other program can access it, even it is is not the same data the other program is interested in.
The chart plotter will be interested in the GPS data, another soft might be interested in the wind data; but there is no way around, one program, one port.
GPSd does not address this issue (even if it pretends to), and - in my opinion - makes things more complex. It's only interested in GPS data (not in Speed Through Water, not in Wind Data, etc), but it locks the port like everyone else, and just rebroadcasts them in another bloody format! Why isn't it just rebroadcasting the NMEA sentences as they've been read?.., I have no idea.

Introducing the Raspberry PI

The Raspberry PI does much more than the boards like Arduino, Sparkfun, Beaglebones, and others (those are great, don't get me wrong, I am not spitting in the soup), it is a fully featured Linux (Debian) computer, that can - as such - do all a computer can do, like multi tasking, multi threading, remote access (SSH, VNC), network access (Ethernet and Wireless). It only has 512 Mb of RAM. But that is enough, as we will see. Its hard disk is replaced by an SD card, ranging from 4GB to whatever you want. I use 16Gb cards. And at work, it draws less than 500mA, which is ridiculous. You can plug several kinds of screen on the Raspberry PI, a TV screen using an HDMI port, or a rear camera car monitor (3.5", 4.3", or 7") using an RCA port. Turning those screens off when not needed will also contribute to save some energy.
The Raspberry PI can read the serial port - Ok, exclusively - and re-broadcast the data on whatever channel (TCP, HTTP, UDP, RMI, whatever). This way they can be accessed from this channel, the data remaining the same. As soon as a device is turned on, it can join the ad-hoc network created by the Raspberry PI, and immediately read the data it broadcasts.

A program like OpenCPN is smart enough to support several kinds of channels.
HTTP is also an option to consider, smart phones and tablets are ready for that, without any modifications. HTML5 and CCS3 will do the job. Those devices have browsers that understand those technologies. It is very easy to display the data read by the Raspberry PI on an iPhone.
In addition, the Raspberry PI can log the data read from the NMEA Port, its SD card is big enough to log several days of data. Another feature of the Raspberry PI is its GPIO Header. This is the bridge to the world of sensors. For example, the BMP180 will allow the Raspberry PI to read the air temperature and the atmospheric pressure. Those data can very well be injected in the NMEA stream (they both have an NMEA equivalent). Some navigation station already provide this kind of interfaces, but in case yours does not, you will then get those data for less than $10.
See some implementation details here.

Even further, it is not difficult to come up with a small setting the Raspberry PI can use to monitor the tension of the batteries on the boat. This one does not - as far as I know - have an NMEA equivalent. It can be injected in the NMEA stream though, it will be considered as a custom sentence. And it can be logged too, along with the rest.
If needed, the data can be displayed on the Raspberry PI as they are read. I did some tests with a graphical interface, as well as in character mode, just to keep the energy consumption as low as possible. The screen is turned off when not needed, for the same reason.

Useful links

• OpenCPN
• Raspberry PI
• Adafruit
• NMEA Console, that runs on the Raspberry PI

Basically, you can reproduce the settings used during the last Aremica's Cup, for a tiny fraction of their budget! The Raspberry PI is less than $40.
Compare with this...

If it does not work for you, do let me know, it should. I might be able to help.

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.

OpenCPN 3.1.1328 released

A new beta of OpenCPN has just been released, it supports other channels than Serial for the NMEA data input. TCP, UDP, GPSD... That means that if you read the NMEA port from the Console, you can re-broadcast them on another channel that OpenCPN can listen to; no more Serial port access conflict, the two applications can run simultaneously, that is very cool. That also means that when you replay logged data in the console, you can visualize them in OpenCPN too. Even better!
AIS Data can also be read this way. The San Francisco Bay traffic can be seen by using a TCP connection on 207.7.148.216, port 9009

New logo for the Weather Wizard

We have a new logo for the Weather Wizard, made by Brainnew.
It comes along with a thumbnail in the control pane, that shows the part you're looking at (the viewport) on the full chart.

Also, for those using the AlmanacPublisher (part of the Navigation Desktop), a leap second has been inserted on July 1^st. DeltaT is now 66.7708 s.

NMEA Stream re-broadcast

The NMEA Console (available at http://code.google.com/p/fullnmeaconsole/) is now fully aware of several communication channels, other than Serial port.

The data can be read from a Serial Port, UDP, or RMI. You can also replay NMEA Data, logged previously (the console has logging capabilities).
The data read from one of the channels above can be re-broadcasted on RMI, UDP, and XML over HTTP (there is a default html page displaying the data).
All the data are also cached in some HashMap, which means that any program living in the same JVM (or reaching it through RMI) can access them, without having to re-damp them (the damping factor is set at the "server" level, the one reading the data first). That is the case of all the modules coming with the console (Star Finder, Planetarium, Google Locator, etc).
If you have a wireless network (like Home Network) setup in the boat, then several machines can share the same data...
The next step would be to write a pugin for OpenCPN, so it can also re-broadcast the NMEA data... But that's another story, this is all in C++.
I also want to port the console (and more) on Android, to be able to display it on a table. The Tide application has been tested already, it's working good.
Keep posted, more to come!

User Manual available

There is a User Manual for the Weather Wizard available at lulu.com.

New display option for faxes

There is a new display option for the faxes.
We used to have check boxes on the right side of the chart panel, to hide or show the various data (charts, faxes, GRIB file, etc).
We now have the possibility to have radio buttons (instead of the check boxes) for the faxes. A right click on the check box panel will prompt you for the option.
That allows you to scroll through the faxes one by one. One fax would be displayed at a time. That would be specially useful when a composite is targeted to display faxes of the same zone, for current time, 24h forecast, 48h forecast, 96h forecast, etc.

Typhoon Ma-On

Typhoon Ma-On is in full force on the Mariana Islands, 95 knots of wind, gusting 115..., and still getting strength...

And the TideEngine code is now available on Google Code.

High-Low water Calculation took 118 ms
-- Oyster Point Marina --
LW Wed Jul 13 06:06:00 PDT 2011 : -1.13 feet
HW Wed Jul 13 12:52:00 PDT 2011 : +5.88 feet
LW Wed Jul 13 17:44:00 PDT 2011 : +2.87 feet
HW Wed Jul 13 23:37:00 PDT 2011 : +7.85 feet

Sample GUI implementation:

Mercator Scale

There are two schools - at least - to plot a line of position with enough details.
Mercator templates are one, plotting sheets are another one.
The plotting sheets rely on the Mercator scale, available at the bottom right corner of the document above. It gives graphically the ratio between one degree of latitude and one degree of longitude.
The Mercator projection relies on the concept of "Increasing Latitude", that gives the value of the latitude, in degrees of longitude...
The increasing latitude λ, for a latitude φ is given by the following formula:

λ(φ) = ln(tan(π/4 + φ/2))

The Mercator scale gives the the ratio between one degree of latitude and one degree of increasing latitude at the given latitude. In consequence, its formula is

ratio = (φ - (φ - 1)) / (λ(φ) - λ(φ - 1))

simplified as

ratio = 1 / (λ(φ) - λ(φ - 1))

also written

ratio = (λ(φ) - λ(φ - 1))^-1

That's it!
The main difference I can see between the two methods is that the Mercator templates can be reused, just like a chart, and the plotting sheets are just a draft, to be dropped after used. That's just my opinion. Whoever has a better - or other - one is welcome to speak up.

Routing Slicing

Just like we had a GRIB Slicing feature, you can now visualize the conditions at the routing level.

Drag the mouse on the top pane, and that tells you where you are on the chart, with a big red dot.

Beside that, it was so windy today in Oyster Point that the wind blew my glasses off my nose... I just could see them sinking 30 feet away from the dock. Rats!

Contour detection

I just finished big improvements in the contour detection of the GRIBs. The performances are now correct (a few milliseconds per GRIB layer, for a full Pacific GRIB 2 degrees by 2 degrees).
Now the contour detection can be part of a GRIB Animation.
In addition, there are now new check boxes to show and hide already computed contour lines, just like for the faxes.
The picture shows PRMSL and 500HGT contours detected in a South Pacific GRIB. Notice that there is now an option to show only the detected contours (with no wind or other GRIB data).

Archives 2009 available

From this page, you can now reach several kinds of archives, along with real-time data. We had in the past the composites archives - which can be opened and rendered by the Weather Wizard - we now have images generated after the composites, they can be visualized from your browser.

Check out this link for details.

Color Faxes

We can now integrate color faxes, like this one.
It is a bit special in the sense that

• It's a square projection (Anaximandre)
• It is in several colors.

Anaximandre never was a problem, but the multiple colors is something that was not managed.
We now have the possibility to just make a fax transparent, without changing the black to another color (which is a possibility that still remains).
Having the colored fax transparent allows as usual superimposition with other data, like GRIBs or charts.
We can produce a rendering like this:
Some improvements in the image processing have been done too, regarding the transparency, and the sharp and blur. Looks much nicer. I had the idea of doing it by looking at what OpenCPN was doing for their charts rendering, which is much nicer than Maptech, based on the same data files.

Externalizing the Look and Feel option

The possibility to apply a Swing Look and Feel on the UI has been externalized. You can apply any Look and Feel you want, its name will be mentioned in the command-line, or in the shortcut properties. That brings more flexibility to the user, and cuts the dependencies with the providers.
On the right is an example of what's possible, using the "Napkin" Look and Feel.
The default look and feel is the System one, not the Metal one (Java default).
Those who have already installed the program should re-install it, as some modifications in the launching script were made.

"What if" routing

Mostly dedicated to cruisers - not good for racing - here is a new feature.Think it like "What if I keep sailing at 50 degrees of the true wind, starboard tack, for 3 days?". Or "What if I keep heading 230 true for 5 days?".
This shows you where you would be! There are some limitations of course, like when you keep sailing head to wind, you wacky weirdo.

Introducing GRIB Slicing

We now have the possibility on rendered GRIB file to draw a line. A graph will then show up, representing the values along the line of the different data contained in the GRIB. 

If the mouse is held clicked on the graph, then a red dot is displayed on the map (and on the line of course), showing where the point is geographically. It becomes easy to see where the wind is the strongest, the pressure the highest, the temperature the warmest, the precipitations the heaviest, etc.

This feature is available immediatly.