NMEA over 802 format

[laika]

I see there are a number of ipad applications which use "wireless" nmea data. The fact that there are a number of nmea to wifi bridge products on the market which aren't aimed exclusively at one software application suggests that there must be some kind of standard encapsulation involved. Unfortunately googling hasn't turned up any detailed info. I don't have the software or hardware to just set it up and packet sniff. Tried mailing navionics to ask what data format their software expects as I was considering buying it, but as usual mail to them is an unanswered black hole.

So...
* Is "nmea over wifi" actually done over IP or encapsulated in raw 802.11 frames? In either case, what is the data format?
* Is it nmea 0183 or is it nmea 2000 (can bus over IP?)

Detailed pointers gratefully accepted as on this occasion my google-fu has let me down

 

[aluijten]

I don't have all the ins and outs available, but basically there are a few ways to send NMEA data over a network.
- UDP as a sort of broadcast system (compare webradio)
- TCP/IP as a handshaked protocol with retry functionality

Both systems work with the principle of a datagram that carries the actual NMEA data.
The first one simply sends out datagrams at anyone who wants to have it and does not check if the receiver received it clear and in full.
There is a small variant where messages are directed at a specifc client
The second sends out the datagram but also responds to messages of the receiver if something went wrong and resends the packages in error. This is more reliable. It also limits to 1-to-1 communication.
The first variant can't be used over the Internet (as opposed to a local network) as the Internet routers will ignore this traffic.

From message point of view NMEA is just a bunch of characters forming a string, this message is stored in the datagram. The datagram is encapsulated by a lot of information about the source, destination, etc. etc. this is then put into the raw network frames.

So basically the transport uses "normal" web-technology

The only difference is that the sender of the NEMEA data uses a specific port-number (normally 10110) as opposed to webservers that normally use 80.

I don't think that nmea2000 uses another messageformat. It's just the protocol that is different. So the actual string that contains the data is the same.

Hope this helps,

Arno

 

[laika]

Thanks Arno but I should have phrased that better. Standard Internet Protocols I'm all good with, it's the details on the bridging from RS422 I after.

I take from what you're saying that essentially a raw nmea sentence is simply stuffed into a UDP packet and broadcast. In which case...
- you say the source port is set to 10110 (which now I look I see is registered with IANA for nmea-0183)..is destination port the same?
- Anyone aware if there's any buffering and stuffing multiple sentences into one udp packet or is it simply one datagram per sentence?

The basic broadcast udp case I see, but not so sure I see how tcp would be used for simple bridging. co-operating IP-aware plotters on the other hand yes....

Taking my cue from looking up 10110, I notice that 10111 is reserved for nmea onenet. Not directly relevant to this thread but might be of interest to those who, like me, were not previously aware of it.

 

[nigelmercier]

I've been considering this for a future project, but my first thought was to serve up a web page.

 

[prv]

- you say the source port is set to 10110 (which now I look I see is registered with IANA for nmea-0183)..is destination port the same?

Usually (ie, in every example I'm aware of) the IANA-registered port is the destination, with the source being an ephemeral port picked at runtime. That is, I think 10110 would be the NMEA listener (destination) port, not the source.

Note that IANA generally assigns you both a UDP and a TCP port when you register, regardless of whether you intend to use both, so the fact that NMEA has both assigned does not necessarily mean both are used in practice.

Pete

 

[laika]

Usually (ie, in every example I'm aware of) the IANA-registered port is the destination, with the source being an ephemeral port picked at runtime. That is, I think 10110 would be the NMEA listener (destination) port, not the source.

Unusual to set the source port for a client as you say, but easily done with bind() and sometimes done for example for security purposes: e.g. to assign a well-known privileged port, and can also make your firewall rules tighter. As you say, possibly surprising in this application but not necessarily a reason to doubt aluijten's info.

I'll have to see if I can find someone running such a network and do a little packet sniffing

 

[prv]

not necessarily a reason to doubt aluijten's info.

Perhaps not, but asserting that Web servers use port 80 as a source, and that Internet routers don't pass UDP (so no DNS then?) certainly set my antennae going.

(Still a useful post as a whole; I hadn't even considered how NMEA over 802.11 was done before.)

Pete

 

[laika]

Perhaps not, but asserting that Web servers use port 80 as a source, and that Internet routers don't pass UDP (so no DNS then?) certainly set my antennae going.

I see what you're saying but traffic *from* a web server running on 80 *will* probably have 80 as the source port (client's ephemeral port as the destination). I believe aluijten point about Internet transmission was distinguishing between tcp and udp *broadcast* (rather than unicast). Whilst of course directed broadcasts are possible, it's common to disable transmission of directed broadcasts on routers as a security measure. The point he's (correctly) making is that udp broadcast is more used for distributing data on a LAN as opposed to a point to point connection across networks.

Given the informed nature of aluijten's posts, if this is an accidental source/destination transposition (which I agree is entirely likely) it's the same as the ones which frequently cause me to tell crew "Did I say 'port'? I meant starboard..." etc.

multicast would be too much to expect given that boat networking is largely partying like it's 1989...

 

[aluijten]

Jus some additions from personal experience. I have a NMEA multiplexer that has also a Ethernet port added to the party. If I want to connect my client software (for example iNavX on the iPad) to the NMEA datastream I need to configure three main parameters
- Protocol: UDP or TCP/IP
- IP Address of NMEA multiplexer
- Port number

So I'd say the port number is on the sender side, where I need to point the clients request to.

As far as I know datagrams have a more or less fixed length but you can only use a part of it if the amount of data is less then a datagrams lenght. So given this I would say the NMEA sentences are not combined into a single datagram, but as has been said I would need a network sniffer/logger to see.

Here is a link to the user manual for the multiplexer:

http://www.shipmodul.com/downloads/manuals/MiniPlex-2E_3.13.pdf

It may help you a bit more

 

[yachtorion]

Given the max usable size of an ipv4 UDP packet is nearly 64k it would be tremendously wasteful to restrict to one NMEA sentence per packet and very inefficient in network terms.

Even if you wanted to keep the datagram within one ethernet frame to avoid fragmentation for some reason, nearly 1500 bytes (or actually more on 802.11) would buy you a lot of NMEA sentences.

It would also be unnecessary in protocol terms to restrict to one sentence per datagram - NMEA is designed to work over a serial connection which doesn't have datagrams and packets so you don't need a way to differentiate between sentences transmitted together - it's built in.

That said I haven't got a device generating NMEA over IP that I can sniff, so I can't tell you for certain. But if one of you folks has got the kit and knows about UDP/TCP - do you have a linux box and a copy of tcpdump?

tcpdump -i wlan0 -s0 -X udp and port 10110

Or if you are on Windows just install Wireshark, it's free...

In terms of destination/source ports, the manual kindly linked above shows three modes.

In either of the UDP modes - in this case the client shouldn't need to be given something to connect to, just know that it needs to listen for broadcast or unicast datagrams. The destination port in the datagram would need to be the known port, which based on the above would seem to be 10110.

In the case of the TCP mode - it seems a client needs to connect to the data source, again the destination port in the initial SYN packet would be the well known port, but this would be a port on the sender in this case.

I've also found it interesting to think about this for the first time!

In fact now I'm dreaming about what could be achieved with an Android tablet mounted next to the chart table....

 

[laika]

To follow up on this...

Sentences are just pumped out over a tcp stream or stuffed into a udp datagram unchanged, complete with terminating <CR><LF>, simple as that. The developer of iNavX says his app can handle one or multiple sentences per udp datagram.

With that info I knocked together a software multiplexer for linux. There doesn't seem to be much around app-wise to display nmea data on android, but it seems to work and bridged between the serial output of my ais and digital yacht's free iais app running on an ipod (over both tcp/IPv4 and udp/IPv4).

I'd like to test this with multiple inputs and iNavX as a display. If there's anyone in Gosport (and preferably Royal Clarence cos it's too cold to go far..) with iNavX on an i-thing and their boat's nmea data available over a serial port, please PM me. Shouldn't take long. And I'll bring beer.

 

[Keith-i]

Have a look at today's entry on panbo.com. It covers some matters of nmea over wifi. Quite a complex subject by all accounts.

 

[laika]

One more thing on this...

If anyone wants to try out an nmea-0183 software multiplexer for Linux, OS X or FreeBSD it's here:
http://www.stripydog.com/kplex
(GPLv3)

Does sentence filtering, prioritisation/failover etc, multiplexing between multiple serial lines, tcp over IPv4/IPv6, udp broadcast and pseudo terminals. It's bi-directional (if you want, but unidirectional if you don't) and you'll run out of space in your boat for serial lines before you hit the limit on connections. The pty support means it can "own" your serial ports, present the data up to your chartplotter or other programs via ptys (or "virtual com ports" to the recent converts form Windows) and still pump data out to the network and elsewhere.

Currently a source distribution until I get enough feedback to know if anyone actually wants to use it and how. Only requires gcc and gnu make to build.

No GUI yet: I've never been the GUI type but I concede it's time for me to learn.

Whilst it runs on Mac, the preceding statements may understandably put the average Mac user off.

This is the software I was using on the raspberry pi in these posts.

Feedback appreciated.

This is what happens when you start saying "I wonder how they do that?" and the weather's too rubbish to entice your friends out saliing...

 

[laika]

Sorry to revive an old thread but somehow seems more economical than starting a new one as this is just partly answering the initial question.

There is a published standard for nmea-0183 over "ethernet": (which actually translates to "over IP over 802.something"): IEC 61162-4., latest version seems to be 61162-450 ed1.0.

Unfortunately it costs CHF280, but the index page suggests that the transport layer is multicast UDP. That makes lots of sense, but isn't something that any manufacturer that I know of is implementing it: everyone is going with tcp and/or UDP broadcast.

If anyone knows a way I can learn more about the contents of IEC 61162-450 without shelling out CHF280 (my little project is free so no budget), please PM me.