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