Smart TCP Watch, prototype.

TCP, no BlueTooth (and as a result, no Smart Phone) is required. The "watch" can connect directly to the network.
See a first prototype here.
And a short video here.

Smart watch..., who's smart, who's watching?

I got a Pebble watch a while back, for $100 it did everything I was expecting from it. I came with a cloud/web-based IDE, a really fine piece of work, it was possible to develop and debug applications running on the watch in JavaScript, that was really well done, smart and neat.
Then a while back, Pebble got acquired by Fitbit. And now, the Cloud IDE of Pebble is not available anymore. Than means I cannot develop new apps for my Pebble, even if it is still working just fine.
Why would I buy a new watch (twice as expensive), and re-write all my apps? This is quite frustrating...
In fact, there was something wrong from the beginning.
All those so-called smart watches need a Bluetooth cell-phone to connect to, and from there it will reach other data. Why not a TCP-based protocol from the watch, to bypass the phone? Power consumption? I doubt it.
This is not about accessibility or configuration either, I do it all the time for Raspberry Pis and similar boards, ssh and similar protocols have been here for this kind of remote access, for ages, and for good reasons.
Smart glasses, head-up displays (HUD), smart watches, all those devices are just displays, all they need is to connect to a data bus and display what they mean to (just like an NMEA bus).
I suspect some marketing bullshit behind the scene..., again.

If this kind of TCP watch does not show up soon, I'll build one. Bam!

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!

NMEA Rebroadcasting

This post is more like a question...
This is always the same problem, most of the NMEA devices use a Serial Port, which is always accessed exclusively (i.e. by no more than one program at a given time).
The way around this exclusive access is to have the exclusive reader to rebroadcast the NMEA data using another channel, accessible from several other programs. This other channel can be HTTP, TCP, UDP... Those channels are machine, system and language agnostic. From Java to Java, RMI is also an interesting alternative.
SailMail reads the NMEA Stream to get the position of the boat, and thus is able to find the best SailMail station, provides the possibilty to rebroadcast the data it reads. Available channels are TCP, UDP, and even COM (rebroadcast on another serial port). It rebroadcasts the NMEA Sentence as it has been read, assuming - appropriately in my humble opinion - that if it is NMEA you are interested in, you know how to parse it.
There is also something else, which OpenCPN is aware of, this is GPSd.
It runs as a daemon - on the systems where daemons exist - and is only good for GPSs, not all the NMEA messages, because it's rebroadcasting the data after reworking them in another format, some proprietary classes over json (JavaScript Object Notation).
The GPSd protocol is not exactly documented, and the project leader does not return my emails...
In the NMEA Console, you can read any of those channels (Serial, TCP, UDP, RMI) and rebroadcast on HTTP, UDP, TCP and RMI (simultaneously if needed). I'm also working on a GPSd rebroadcast, running anywhere Java runs (no need for a daemon).
Anyway, both approaches have pros and cons (even if I'd rather rebroadcast the data as they come).
If anyone has any comment or idea, please speak up!
Thanks in advance.