OpenCPN & Furuno NavNet3D

[mdsilvers]

I currently have a Furuno NN3D chart plotter integrated with MaxSea on my laptop over ethernet.

I'm wanting use OpenCPN and use the NMEA from NN3D to feed GPS, etc, etc to the program. I can't seem to find anywhere the IP and Port for the NMEA broadcasts from the Furuno NavNet. MaxSea works great, but it automatically configures the instruments from the data stream...but does not show the IP, Port, etc. I'm assuming this is probably a UDP stream, but not sure, and am getting frustrated.

Anyone have any ideas on how to use OpenCPN with Furnuno NavNet??

Thanks!

[svrevelations]

You will probably not get any help from the Furuno or Maxsea people.
I would also like to know and if you find a way, I hope you will post the details.

[bdbcat]

mdsilvers....

What we need is a capture from WiresharkWireshark · Download to see what is actually present on the network as produced by NN3d. Maybe we can decode this, and figure out the ip/port and datastream contents.

Good Luck
Dave

[sy_gilana]

Try this, I presume youre on windoze.
Get it all up and running as per normal.

click Start, type cmd (enter) and in the black window that appears type "ipconfig /all"

There you should see all the info you need.

OpenCPN ROCKS!

[muttnik]

Originally Posted by mdsilvers

Anyone have any ideas on how to use OpenCPN with Furnuno NavNet??

With the disclaimer that I don't have NavNet to check this, a number of sources, including comments on panbo articles and a note on an entry in opencpn flyspray suggest it's an IPv4 broadcast on udp port 10021, so create a network data connection, set it for UDP, set the address to 0.0.0.0 and port to 10021. Please do report back as to whether this works or not.

[StarryHorizons]

Just curious, why are you looking to make the switch to OpenCPN from MaxSea?

[jpterj]

Originally Posted by bdbcat

mdsilvers....

What we need is a capture from WiresharkWireshark · Download to see what is actually present on the network as produced by NN3d. Maybe we can decode this, and figure out the ip/port and datastream contents.

Good Luck
Dave

The NMEA messages are sent as UDP broadcast to 172.31.255.255.

All messages are sent on port 10021.

In addition messages from fast updating sources like compass and wind are sent on their separate ports.

The contents in the UDP packets seems to be a prefix/extra information followed by the NMEA message in 0183 format.

I have run OpenCPN with NMEA logging activated, and it is receiving the messages, but it looks like it is not able to decode the contents.
The printouts are all like this:

09:14:18 CET: Changing NMEA Datasource for %& to UDP:0.0.0.0:10036 (Priority: 0)
09:14:30 CET: MEH.NMEA Sentence received...$%&'()*+

09:14:30 CET: Changing NMEA Datasource for %& to UDP:0.0.0.0:10034 (Priority: 0)
09:14:39 CET: MEH.NMEA Sentence received...$%&'()*+

09:14:39 CET: Changing NMEA Datasource for %& to UDP:0.0.0.0:10038 (Priority: 0)
09:15:02 CET: MEH.NMEA Sentence received...$%&'()*+

09:15:02 CET: Changing NMEA Datasource for %& to UDP:0.0.0.0:10021 (Priority: 0)
09:15:04 CET: MEH.NMEA Sentence received...$%&'()*+

09:15:04 CET: Changing NMEA Datasource for %& to UDP:0.0.0.0:10038 (Priority: 0)
09:15:09 CET: MEH.NMEA Sentence received...$%&'()*+

09:15:10 CET: Changing NMEA Datasource for %& to UDP:0.0.0.0:10036 (Priority: 0)
09:15:16 CET: MEH.NMEA Sentence received...$%&'()*+

09:15:16 CET: Changing NMEA Datasource for %& to UDP:0.0.0.0:10034 (Priority: 0)
09:15:30 CET: MEH.NMEA Sentence received...$%&'()*+

09:15:30 CET: Changing NMEA Datasource for %& to UDP:0.0.0.0:10038 (Priority: 0)
09:15:56 CET: MEH.NMEA Sentence received...$%&'()*+

09:16:01 CET: MEH.NMEA Sentence received...$%&'()*+

This is with version 3.2.2 on OpenSUSE Linux.
I have a working build environment set up, and have added som debug logging to try to figure out what is going on.

I have tried to attach a Wireshark capture I have done, but it seems this is not a valid file type/extension.

[jpterj]

Looks like it may work now when I have changed the file extension to .doc.

The extension is actually .pcapng.

[muttnik]

Plenty of interest there. Notably...if data were being parsed how the NMEA claim everyone should have been doing it all along (when TAG blocks broke a lot of people's code with -0183v4) I think you'd be OK. Looks like the port 10021 (everything except $HCHDG $GPMWV and RADAR??) stuff has an 8 byte preamble with what looks like a 2 byte sequence number (?) at the beginning. If you don't assume the sentence starts at the beginning of the packet but take it from the $/! to CR LF it looks like it'd be fine.

If you're using linux you could try running it through the 1.1beta version of kplex before feeding it into opencpn: that implements parsing which should cope with it (as opposed to earlier versions which like of course would drop sentences preceded by TAG blocks or extraneous characters :-). I can expand on that with an appropriate config if anyone's interested in trying it.

Is that a radar at 172.31.254.3?

[jpterj]

Yes the radar is at 172.31.254.3.
When in standby it only uses port 10034.
When active it looks like the radar data is on port 10024.

I have managed to compile and install kplex.
If you post an appropriate config I can probably test this tomorrow.
Some instructions on how to do it would also be good.

[muttnik]

Originally Posted by jpterj

If you post an appropriate config I can probably test this tomorrow.
Some instructions on how to do it would also be good.

You can do it from the command line or via a config file, as a daemon or in the foreground. This would be the command line taking in broadcast on 10021 and re-broadcasting (in a hopefully more sanitised form) on 10110 over device eth0 (modify for different interfaces):
kplex -f- broadcast:direction=in,port=10021 broadcast:direction=out,device=eth0,port=10110

(any line breaks were not intentional there)

If you want to do it via a config file and give the data to opencpn via a 38400 baud pty called /var/tmp/navnet which opencpn can use like a serial interface, set up your config file thus:
[broadcast]
direction=in
port=10021
[pty]
direction=out
baud=38400
filename=/var/tmp/navnet
mode=master

Any stupid errors entirely due to it being half past rioja in this timezone.
Do use the 1.1beta not the 1.0: the latter is stable but the parsing is different (as discussed). Do let me know if it works: it's just a theory :-)

[bdbcat]

muttnik...

Feel free to post a patch correcting the NMEA0183 code to parse starting from the $ delimiter, if you like. Its on my list, but seems to be receding over the horizon....

Thanks
Dave

[jpterj]

Originally Posted by muttnik

You can do it from the command line or via a config file, as a daemon or in the foreground. This would be the command line taking in broadcast on 10021 and re-broadcasting (in a hopefully more sanitised form) on 10110 over device eth0 (modify for different interfaces):
kplex -f- broadcast:direction=in,port=10021 broadcast:direction=out,device=eth0,port=10110

(any line breaks were not intentional there)

If you want to do it via a config file and give the data to opencpn via a 38400 baud pty called /var/tmp/navnet which opencpn can use like a serial interface, set up your config file thus:
[broadcast]
direction=in
port=10021
[pty]
direction=out
baud=38400
filename=/var/tmp/navnet
mode=master

Any stupid errors entirely due to it being half past rioja in this timezone.
Do use the 1.1beta not the 1.0: the latter is stable but the parsing is different (as discussed). Do let me know if it works: it's just a theory :-)

This worked perfectly!

It looks like OpenCPN picks up information from all the devices that are connected to the MFD, including AIS. It even handles AIS-SART correctly, but the MFD does not pick it up at all.

I have an Em-Trak B100 that supplies the MFD via NMEA 0183 and the Raymarine i70 via NMEA 2000.

[muttnik]

Originally Posted by muttnik

if data were being parsed how the NMEA claim everyone should have been doing it all along (when TAG blocks broke a lot of people's code with -0183v4) I think you'd be OK.

Just to be certain as forums/usenet have huge potential for ambiguity especially with an international audience....this was in no way a criticism of opencpn's parsing. It's actually an ironic comment regarding the NMEA's statement that nmea-0183v4 *is* backwards compatible as long as everyone followed the letter of the implementation doc. Which of course open source developers cannot legally reference.

Anyway, glad jpterj has things working. I suppose it would be nice to figure out the navnet protocol. I will take a look at the opencpn parsing when I get a chance but suspect it might be non-trivial: I'm good with the one-liners, less adept with the serious OO-**.

[muttnik]

Originally Posted by bdbcat

Its on my list, but seems to be receding over the horizon....

Are you sure you haven't addressed it already? Looks like I was wrong: Barring no subtle error or simple misunderstanding on my part, in DataStream::OnSocketEvent you look for a "*" then the $ which precedes it. Which should drop what I was supposing was confusing OpenCPN. So I was talking nonsense.