Moving the Raspberry PI away from Swing

Rationale

This starts from a simple observation. A Raspberry PI can run on a boat, and consumes a very small amount of energy. It can do a lot of computations, logging, and multiplexing, among many others. It can run 24x7, without you noticing. It makes no noise, almost no light, and requires ridiculous amount of energy to run. Even a Raspberry PI Zero does this kind of job (for even less power), successfully.
One thing it is not good at is graphical UI. A graphical desktop is often too demanding on a small board like the Raspberry PI Zero. It becomes some times really slow, and cumbersome.
Running on it a program like OpenCPN seems absurd to me. Such a program runs fine on a bigger device, with several gigabytes of RAM available.
But, running a laptop 24x7 would be in many cases too demanding, specially on a sailboat, where everyone hates to run the engine ;)
I observed that at sea, I spend only a couple hours a day in front of the laptop, but it is often running by itself, doing some logging or calculations.
This is where it comes together, you could have a Raspberry PI Zero doing logging, multiplexing and what not, broadcasting require data on its own network (see the NMEA Multiplexer about that), then you would use a laptop whenever necessary, connecting on the Raspberry PI's network to get NMEA Data and more.
In addition, you can also use tablets and smart-phones, those devices know how to connect to a network, and have great rendering capabilities.
A problem is that writing a native application on those devices requires specific knowledge of the operating system, those skills are often redundant. iOS, Android, JavaFx, Swing all have UI rendering capabilities, but they're all totally different, and the learning curve for each of them is not always smooth.
A solution would be to write the UI part of the applications using HTML. Whatever OS runs on your laptop, tablet or smartphone (Windows, MacOS, iOS, Linux, Android, etc), you have a browser available, supporting HTML5 (if it does not, you should really upgrade it).
HTML5 and JavaScript have been gaining a lot of momentum in the recent years, new frameworks like jQuery, ionic, ReactJS, ...) appear every day, and provide really rich and nice UI.
My feeling would be to go down this route whenever possible, that would save a lot of efforts, and provide a pretty cool Graphical User Interface (GUI). I have written a lot of GUI in Swing. It would be now time to upgrade it. Re-writing them using JavaFX does not sound like the right choice. If I have to learn a new language to build a modern GUI, for now I'd rather use JavaScript and HTML5. This way, the same code runs whenever a browser exists... You have REST APIs available on the server (again, a Raspberry PI, even the Zero does the job well), and you use AJAX and Promises to get to them from the Web UI (WebSockets are also a realistic option, tested). The computation required to produce the payload returned by the REST services (often in json format) is easily supported by a Raspberry PI, and the complexity of the UI rendering is 100% taken care of by the browser, running on a more powerful device.

Implementation

To make sure all this is realistic, we have a REST implementation of a Tide Server, available here.
First, we have defined the REST Services, like

 /GET /tide-stations
 /GET /tide-stations/{station}
 /POST /tide-stations/{station}/wh?from=XXX&to=YYY
 /POST /tide-stations/{station}/wh/details?from=XXX&to=YYY

this is the easy part - and then an HTML5/JavaScript User Interface.

Harmonic coefficients are available for display

Period of time goes - in this UI - up to 1 month.

For one month, with harmonic coefficients, the volume of data transferred from the server is about 10Mb, it took about 14 seconds to get them.

In a most common case, it is around 25Kb.

This is running on a Raspberry PI, even a Raspberry PI Zero does the job without complaining.
There are a couple of challenges to address, JavaScript is not very well TimeZone equipped. But there are ways to get it to work.
That seems to be a viable approach.

Interestingly, even if we are trying here to address an energy problem - and not a budget one - a Raspberry PI Zero today cost just $10.

NMEA Multiplexer, OpenCPN, GPSd...

I have been working on an NMEA Multiplexer that can run on small boards, like the Raspberry PI Zero. The code is available on github, see the documentation in the README.md.

It allows to mix all kinds of NMEA Sources into a single (or multiple) stream(s). You can read from Serial Ports, Log file(s), TCP, WebSocket, Sensors (like BME280, HTU21DF, LSM303, etc), merge those data and rebroadcast them on Serial port, TCP, Log file, WebSocket, GPSd, etc. UDP is being worked on.

Data can also be computed and injected in the output stream, like True Wind, Current direction and speed, etc.

As a graphical desktop can be cumbersome on small boards, the Multiplexer comes with a tiny HTTP server that provides a Web UI and REST services to allow remote Admin.

It also comes with several demos and samples

This all works just fine with OpenCPN, SeaWi, that can take TCP streams as NMEA Data Input.
I was also wondering about GPSd. I had some mixed feelings about it. Mostly, I was asking myself "Why should I parse GPSd json objects if I can parse NMEA Sentences?", and could not find any satisfying reason. The topic is mentioned on the GPSd web site's FAQ pages, but nothing clear (to me) came up from that.
Interestingly, OpenCPN can also take GPSd streams as input. But there is a trick.
The first GPSd exchange begins with a ?WATCH request. It is followed by a JSON Object like this:

  ?WATCH={"enable":true,"json":true}

... and here is the trick, OpenCPN sends a

 ?WATCH={"enable":true,"nmea":true}

This nmea option is "poorly" documented, but very useful. Instead of sending JSON objects, GPSd spits out the raw NMEA sentences, as they were read. Then GPSd is just a regular TCP stream, and OpenCPN already knows how to parse the NMEA sentences it delivers. This way, GPSd is not limited to strictly GPS-related sentences. It can convey all NMEA sentences, Boat Speed related, Wind related, etc. This is what the GPSd forwarder that comes with the Multiplexer is doing.

Happy Streaming, happy new year!