Debugging OCPN Connections

[nohal]

olmen...
Get WinDump - Home
Record a few seconds of the traffic on the network interface connecting your machie to the LAN to .CAP file
Post it here

Pavel

[nohal]

olmen...
Looking at Panbo: The Marine Electronics Weblog: Furuno FA-50 Class B AIS, first impressions it will probably be a loss of time - FA-50 does not emit NMEA over the network interface but just the proprietary NavNet stuff

Pavel

[olmen]

Originally Posted by nohal

olmen... Get WinDump - Home Record a few seconds of the traffic on the network interface connecting your machie to the LAN to .CAP file Post it here Pavel

Thanks pavel. I tried the windump program but it did not seem to work. I am trying another sniffer program. Give me some time.

[olmen]

Originally Posted by nohal

olmen... Looking at Panbo: The Marine Electronics Weblog: Furuno FA-50 Class B AIS, first impressions it will probably be a loss of time - FA-50 does not emit NMEA over the network interface but just the proprietary NavNet stuff Pavel

Thanks pavel again. I will check with furuno. A bit of a surprise to me. The documentation suggests they are using standard nmea.

[muttnik]

The panbo article nohal quotes says:

And, yes, that is a first-ever-for-transponders Ethernet LAN connection, but there’s a “gotcha” to its use. While you can access the FA-50’s extensive set-up and diagnostic menus with any browser on any computer, you can not get GPS and AIS target info to anything but Furuno NavNet hardware or MaxSea software via Ethernet

The FA-50 manual makes no mention of anything other than navnet on the ethernet port. The mention of IEC 61162 output is in the section on COM port configuration (which you can presumably use to connect to OCPN over a serial link)

[KenNorris49]

Originally Posted by bdbcat

RobbieW...

In OpenCPN, a single TCP connection can be either a server(i.e. output enabled) or a client (i.e. input enabled), but not both at the same time.

Not sure who one would want to connect to in such a full duplex manner, so to speak. I suppose we could arrange to so connect to another instance of OpenCPN, but that seems of limited usefulness.

Does kplex want to handle both client and server connections on one address?

Dave

Full 'duplexing' would be handy in my case.

Installing a VesperMarine XB8000 AIS transceiver on WiFi enables full multiplexing of NMEA 0183 data wirelessly into Opencpn but the one-way nature of the TCP connection prevents the output of navigation data (at least) on WiFi back through the network to the Autopilot. There is no UDP support on the XB8000.

Is there a workaround in this instance?

[muttnik]

Originally Posted by KenNorris49

Is there a workaround in this instance?

Not in OpenCPN alone as it stands at the moment. The Vesper, if I read the documentation correctly (and I baulked at watching the video) can only be configured as a server to accept incoming connections. This means that OpenCPN won't be able to send data to it.

You could get round that using multiplexer software to sit between OpenCPN and the Vesper: creating a bi-directional tcp connection then presenting OpenCPN with a virtual COM port, but that's extra hassle you probably don't want. Which OS are you running OpenCPN on?

I was actually looking at this very bit of code only yesterday but my inability to even spell "Stroustrup" makes me reluctant to commit to anything in the short term. Anyone know if anyone else is looking at this stuff at the moment?

[KenNorris49]

Much obliged for the reply.
I know nothing of the detail of networking but was assured that the XB8000 is capable of receiving 0183 inputs on WiFi and multiplexing out. It certainly seems to do that for hard-wired inputs, both 0183 and 2000.

I'm running OpenCPN Version 3.2.2 Build 2013-05-08 on Ubuntu 12.04 32-bit.

"Stroustrup"?? I daren't ask.

[muttnik]

Originally Posted by KenNorris49

I know nothing of the detail of networking but was assured that the XB8000 is capable of receiving 0183 inputs on WiFi and multiplexing out.
[...]
I'm running OpenCPN Version 3.2.2 Build 2013-05-08 on Ubuntu 12.04 32-bit.

You can use kplex as the intermediary (obvious disclaimer, but I hopefully get excused as it's free in all senses). Download the 1.1 beta. Configuration file something like this:
[tcp]
address=192.168.15.1
port=39150
persist=yes
[pty]
filename=/var/tmp/nmea0183
baud=38400
mode=master

(The "persist=yes" bit means it'll reconnect of the network goes down which wasn't implemented in 1.0)

You can then use /var/tmp/nmea0183 (that's arbitrary: set filename as you like) as a bi-directional serial port connection in opencpn with baud rate 38400 (actually 57600 might make more sense but change that in the kplex config too).

There's not a kplex deb for 32 bit ubuntu 12.04 (there is for 64 bit) but pm me if you don't want to compile from source and I can sort you out.

Bit of a faff but it should work if you start up kplex before opencpn.

Originally Posted by KenNorris49

"Stroustrup"?? I daren't ask.

Think of the Object Oriented paradigm as Joy Division and the procedural as Hawkwind.....

[KenNorris49]

Marvellous effort thank you.

At first blush, kplex seems to provide the duplex WiFi comms with the XB8000 that OpenCPN couldn't. At least, the Simrad AP24 monitor now recognises the input of 0183 data converted to 2000 via the AT45 device as the 'Navigation' input and I presume that is coming from OpenCPN via kplex. I now need to see if it makes any sense as a functioning Autopilot input. I still get the ominous 'No Navigation Data Available', or something similar.

OpenCPN is now a little unstable (very to begin with) but I'm not sure to what that is due.

Ken

[Neptune's Gear]

Good to see you are making some progress Ken!

I, for one, think Kplex is an unnecessary complication, and it would be good to see OpenCPN add this functionality as a standard feature.

Wifi connections are becoming more and more common aboard, and "most" network systems use TCP, not UDP. IMO, OCPN should try to make things as easy as possible for the novice. Even if, to begin with, it's just duplex UDP...

Also IMO, many people, like Ken, will want to control an AP via Wifi, once they have the hardware available. It makes sense, if you get all your boats data to the PC via Wifi, to be able to send what you need to back to the AP over the same route. Or to upload data to the GPS, or whatever...

I actually thought you could do this already, until Ken hit this issue. It had not occurred to me that the WIFI connection could be one direction only, and I did not find it in the manuals or threads...

[jeffrobbins]

Originally Posted by muttnik

The Vesper, if I read the documentation correctly (and I baulked at watching the video) can only be configured as a server to accept incoming connections. This means that OpenCPN won't be able to send data to it.

That's not correct. The XB-8000 and WatchMate Vision accept data sent to it over the WiFi and will route that data to the other output ports (0183 and USB right now).

You could make a 2nd TCP connection to the XB or Vision and use that just for output, but I don't think that's the best solution.

[muttnik]

Originally Posted by Neptune's Gear

I, for one, think Kplex is an unnecessary complication, and it would be good to see OpenCPN add this functionality as a standard feature.

"undesirable" for sure and "unnecessary" in this particular application in that there are other ways to do it (e.g. with socat and probably marinux's muplex). But unless I'm mistaken I do think you need an intermediary to facilitate what is required. Totally agree it's not ideal.

Originally Posted by Neptune's Gear

I actually thought you could do this already, until Ken hit this issue. It had not occurred to me that the WIFI connection could be one direction only, and I did not find it in the manuals or threads...

After the original part of this thread last year the wiki/beta manual was updated:
Data Connections | Official OpenCPN Homepage
I notice that as you say it's not clear in the "stable" manual: I'll see if I can find out how to resolve that.

Originally Posted by jeffrobbins

That's not correct.
[...]
You could make a 2nd TCP connection to the XB or Vision and use that just for output, but I don't think that's the best solution.

If you've demonstrated that working then I've read the code wrong. If you can configure your product to make an outbound connection (i.e. act as a tcp client as well as just a server) then I've missed that in your documentation: if that's the case then apologies and please say because two connections between OpenCPN and the Vesper is indeed a much better solution. Bottom line (in my reading of the code) is not simply that OpenCPN doesn't do bi-directional tcp but that it won't provide output to a remote server: Only to clients which connect to *it*. This isn't a criticism of the vesper: credit to you for doing bi-directional which seems obvious most similar products don't seem to do.

[KenNorris49]

Tried various configurations of kplex to provide a WiFi interface between OCPN and the VesperMarine XB8000 AIS device: some worked partly i.e. inputs but no out, some not at all, some cause almost immediate crashes in OCPN, but I think the configuration below has communications going both ways.
I can see (some) data at the AP24 autopilot display. Am yet to test it at sea.

The XB8000 NMEA 0183 input and output (accessed via the vmAIS program) is set to 4800 baud; choosing 38400 prevents the GPS speed reading to the 0183 display.

The kplex config file is as muttnik advised but with changing baud on OCPN and the kplex config file to 57600. I also have allocated a local network address of 192.168.1.2 to the XB8000

[tcp]
address=192.168.1.2
port=39150
persist=yes
[pty]
filename=/var/tmp/nmea0183
baud=57600
mode=master

I set the output sentences in OCPN to only RMB,GLL,VTG,APB as suggested by Matt Paulin. No input sentences filtered.

[RhythmDoctor]

Sorry to join late, but I just found this thread. FWIW, I encountered the same half duplex limitation with TCP, for a similar reason. I want to bring in raw GPS data and send out OpenCPN's autopilot control data on the same port. I've mentioned this on other posts over the last few months.

For the time being, I'm using Bluetooth through an emulated COM port, which gives me the full duplex capability. However, OpenCPN has difficulty establishing a connection on the emulated COM port, so I need to use trusty old XPort to establish the connection. This works OK on Windows 8 32 bit version, but I expect it won't work if I ever upgrade to 64 bit. One other catch is I need to disable the secure boot feature in the UEFI BIOS. I also need to run XPort as Administrator. So it is a real kludge that I'd love to get rid of.