Ethernet AIS and radar into OpenCPN

[nohal]

I'm not aware of NMEA0183 permitting binary, non-ASCII payload, at the beginning of the sentence or anywhere else in it. My source of information is for example NMEA Revealed
As from this and other recent threads you seem to know everything about it, I'm expecting you will correct me by linking a reliable source proving me and my sources wrong.
I sure do agree Furuno is doing their own thing though.

[bcn]

Originally Posted by DotDun

Broken by what standard?

I'm not aware of any standard for NMEA0183 over IP, hence Furuno is doing their own thing.

look here:

IEC61162-450 - Lightweight Ethernet (NMEA0183 over Ethernet)
NMEA0183 = IEC61162-1
The industry response for vessels vs. NMEA2000 for leisure boats

UDP Multicast.....

[DotDun]

Originally Posted by nohal

I'm not aware of NMEA0183 permitting binary, non-ASCII payload, at the beginning of the sentence or anywhere else in it. My source of information is for example NMEA Revealed
As from this and other recent threads you seem to know everything about it, I'm expecting you will correct me by linking a reliable source proving me and my sources wrong.
I sure do agree Furuno is doing their own thing though.

First, the standard you reference is NMEA0183 over RS422, not NMEA0183 over IP.

My point is since there is no standard for NMEA0183 over IP, each manufacturer is free to do whatever they see fit. Just because Furuno's proprietary implementation doesn't fit your idea of what it should look like doesn't make any lesser than any other manufacturer's proprietary implementation of 0183 over IP.

Since Furuno isn't interested enough to publish their implementation, it's hard to guess the motive for their protocol.

That's what standards do, make all implementations look the same. It doesn't appear NMEA is interested in IP as they never worked on 0183 over IP and their announcement for OneNet 5+ years ago has failed to produce anything.

[bcn]

DotDun,

please look here:

https://en.wikipedia.org/wiki/IEC_61162

If you search for IEC61162-450 you will find some more references.

To start:
https://rietman.wordpress.com/2016/0...in-nemastudio/

http://raga3.marintek.sintef.no/MiTS...er-isis-v9.pdf

[nohal]

Originally Posted by DotDun

First, the standard you reference is NMEA0183 over RS422, not NMEA0183 over IP.

My point is since there is no standard for NMEA0183 over IP, each manufacturer is free to do whatever they see fit. Just because Furuno's proprietary implementation doesn't fit your idea of what it should look like doesn't make any lesser than any other manufacturer's proprietary implementation of 0183 over IP.

Since Furuno isn't interested enough to publish their implementation, it's hard to guess the motive for their protocol.

That's what standards do, make all implementations look the same. It doesn't appear NMEA is interested in IP as they never worked on 0183 over IP and their announcement for OneNet 5+ years ago has failed to produce anything.

Well, as you see one post above, there is IEC61162-450 - Lightweight Ethernet (NMEA0183 over Ethernet). Which seems to be broken already by using broadcast, not multicast...

Even if there wasn't, NMEA0183 over IP is implemented industry-wide and as far as I can tell, interoperability is not a problem with anybody but 1 vendor, Furuno, because it is including binary payload we talk about here in the packets. Again, I am highly interested in links to reliable sources of information providing some insight.

[DotDun]

Originally Posted by bcn

DotDun,

please look here:

https://en.wikipedia.org/wiki/IEC_61162

If you search for IEC61162-450 you will find some more references.

To start:
https://rietman.wordpress.com/2016/0...in-nemastudio/

http://raga3.marintek.sintef.no/MiTS...er-isis-v9.pdf

Thanks! I wasn't aware of this. Unfortunately they want $500+ for the standard, but the overview you provided the link to has quite a bit of information.

The Furuno implementation was out several years before the IEC standard, I purchased NavNet3D in 2008, not sure if the previous VX2 supported 0183 over IP. I wonder if Furuno has any IEC61162-450 capabilities, i.e., capable of listening to an IEC talker. I would guess Furuno commercial gear supports the IEC standard.

[DotDun]

Originally Posted by nohal

Well, as you see one post above, there is IEC61162-450 - Lightweight Ethernet (NMEA0183 over Ethernet). Which seems to be broken already by using broadcast, not multicast...

Even if there wasn't, NMEA0183 over IP is implemented industry-wide and as far as I can tell, interoperability is not a problem with anybody but 1 vendor, Furuno, because it is including binary payload we talk about here in the packets. Again, I am highly interested in links to reliable sources of information providing some insight.

Maybe Furuno doesn't want to play with everyone else? Has Furuno committed to supporting 3rd parties over IP?

[nohal]

Originally Posted by DotDun

Maybe Furuno doesn't want to play with everyone else? Has Furuno committed to supporting 3rd parties over IP?

I do not know and I do not care. But if it is the case, the guy designing the anecdotal “protection” should probably be fired...

[DotDun]

Originally Posted by nohal

I do not know and I do not care. But if it is the case, the guy designing the anecdotal “protection” should probably be fired...

Furuno designs a proprietary system for use between their products only, they never commit to 3rd party support, you reverse engineer it and decide you don't like it, so someone at Furuno should get fired?

Maybe you should pass your desire along to Furuno, I'm sure you would get a reaction!

[nohal]

Originally Posted by DotDun

Furuno designs a proprietary system for use between their products only, they never commit to 3rd party support, you reverse engineer it and decide you don't like it, so someone at Furuno should get fired?



Maybe you should pass your desire along to Furuno, I'm sure you would get a reaction!

Why should we talk to Furuno exactly? It is a matter of a two line patch to our code to deal with this issue. Whether it is some sort of intention from them or pure engineering idiocy is unimportant, at least for me.

[nohal]

Dirk...
To get back from the blah-blah-land where we spent some not very productive time lately. The fix for the Furuno equipment sending data over UDP just got commited for the upcoming OpenCPN 4.8.2 release.
You will have to edit your configuration file and add a line EnableUDPNullHeader=1 in the [Settings] section.
May become default at some later moment when we make sure enough it does not break something else.
I have made a build for Windows (you are using Windows, right? I forgot to ask...) you can get from https://spideroak.com/storage/NZXWQY...ff6b05e166231d
Let me know if it still does not work (It does here replaying your capture). Or even if it does...

Pavel

[Daurin]

And there you have it! Yes, I have a Win7pro 64bit box. The patch worked perfectly. Thank you all so much for teasing this out, and especially to Nohal for implementing the patch.

This is a breakthrough on a problem I have been messing about with off and on for years, and the fix is exciting. For one thing, this means that I now have FULL AIS and navigation display redundancy, so I can use OpenCPN even if the chartplotter is off by just using the AIS stream from the ethernet. (Until now, my workaround for redundancy was to plug in a handheld Garmin 76 into OpenCPN via serial, but of course, no AIS functionality there.)

[Daurin]

Originally Posted by nohal

Dirk...
3) There is nothing that looks like some data from a broadband radar, only NMEA0183 on the two above ports. You can stop using the radar plugin as there is no chance it will do something in your current configuration.

It's possible the radar is not outputting from the 1720/1724C NT to the network. The manual does not seem to cover radar output to the network (see photo). What should the broadband radar sentence look like?

[Hakan]

Pavel.
Win10/XP
Just for info I've tried using EnableUDPNullHeader=1 and what I can stress it's not disturbing any "normal" NMEA traffic by Wifi/Net (or serial).
I'll also try the FA50 capture in Win to see if I get the same result as Daurin.

This is good! The Furuno idea to "lock" there gadgets to work only within there's own net is partly broken with this?? (For example they have some GPS that won't work on Raymarine's plotter, or vice versa. Now OCPN is again the best solution!)

Håkan

[muttnik]

Originally Posted by muttnik

I *think* you can ignore stuff you might find about furuno data being dropped because of the headers which precede the data: I think it was Nohal whose rework of the nmea parsing should have sorted that out.

Originally Posted by nohal

May become default at some later moment when we make sure enough it does not break something else.

My bad for suggesting that this was already fixed: What *was* fixed some years ago was the problem where sentences would be dropped if they were preceded by v4 TAGs but revisiting the code I see that maneuvering to the beginning of a sentence is done using string operations which don't work if there's a null before the $ or !.

When people were complaining about TAGs breaking their parsing I recall seeing a statement in a presentation I found online somewhere (USCG?) that folks parsing sentences correctly wouldn't have a problem where "correctly" was simply to discard everything before $ or ! and start from there.

My github-** has not been strong enough (or more likely the morning coffee wasn't) to find your what you've done to fix this but assuming it's just that (forget substrs and find_last_ofs and just move to the first $ or !) I'd say you can have a fair degree of confidence that this is the right thing to do. It's what kplex has done for the past 5-ish years and no-one has complained about it yet.