3.2.0 incompatible with XPort Virtual Serial Port

[RhythmDoctor]

I have used OpenCPN with XPort virtual serial port for 2 years using Windows XP. My GPS feed goes to COM41 at 4800 bps, and then XPort redirects it to COM12 and COM13 at 4800 bps. I then run two instances of OpenCPN in side-by-side windows. The one on the left is zoomed in to see detail, and the one on the right is zoomed out to see a wide view which includes AIS targets (which come in COM40 at 38400 bps). Running this way, I can just sail and not have to be zooming in and out all the time. I can also turn on the autopilot output on COM12, and XPort sends it out COM41 to my autopilot.

This configuration worked fine with versions 2.5 and 3.0 of O, but it fails with 3.2.0. It works OK as long as I don't turn on the COM12 output, but once I turn it on the GPS input halts after a few seconds. I can tell this is happening because the red "ownship" icon turns grey after about 5 seconds. I also confirmed this on the NMEA debug window - the sentences come in for about 5 seconds, but then stop. Sometimes if I wait, the NMEA sentences will resume, but only for a few seconds and then they stop again.

I have tried filtering the output to allow only a couple sentences (RMB, RMC), but the same problem still happens. I am aware that I have to filter out the AIS, because that data would overflow the COM12 port at 4800 bps.

I also tried uninstalling XPort and having both instances of OpenCPN look directly at COM41, but that fails even with output turned off.

Can you suggest what else I might try to make this work?

[nohal]

RhythmDoctor...
The first thing that comes to mind is using OpenCPN's internal MUX instead of XPort to deliver the sentence to the other instance, preferably over a network socket, not a virtual serial port which is an unneeded complication. Setup the "master instance" as a TCP or UDP server and the "slave" one as a client.
Anyway this looks like a problem we should look at...

Pavel

[bdbcat]

RhythmDoctor....

I acknowledge the bug.
IMHO, XPort is internally broken. OCPN Version 3.2.0 works around the XPort flaw if the port is used only for input. However, as in your case, using the port for output triggers the XPort flaw again, in a slightly unanticipated way..

This will be corrected in the upcoming Service Release for OpenCPN, to be called 3.2.2, and due in a week or so.

Meanwhile, I recommend nohal's suggestion. Us one instance as a master, and send NMEA data via UDP to the other.

Or, wait patiently for 3.2.2

Thanks
Dave

[RhythmDoctor]

Thanks for your advice. I'm working on configuring the UDP server as suggested, and once I get that working I'll abandon XPort altogether. I made some progress on it today, but could not get the second instance set up because I ran out of time on the boat.

I'll keep my eye out for 3.2.2, but I'm heading out on a cruise this Friday so need something working before then.

[RhythmDoctor]

Please pardon my naive question, but in setting up a UDP port, is it acceptible to have the hostname of "localhost" or do you need a xxx.xxx.xxx.xxx IP address? It's not entirely clear because your examples only show "localhost" for GPSD.

FYI, I have finished configuring my netbook for 2 instances of OpenCPN (using localhost on UDP, assuming this is acceptable) but I have not tested it yet because I need to take the computer to my boat in order to have the GPS and AIS NMEA streams available (via Bluetooth COM port emulation). So by tomorrow evening I should have confirmation that it did work, or more questions on how to get it to work.

Thank you so much for this incredible program! OpenCPN is, by far and away, the best open source program that I have ever used. You guys are fantastic!

[RhythmDoctor]

I've gotten rid of XPort and have my dual instances of OpenCPN almost running. There is a little bit of reliability problem with the sharing via UDP (sometimes I have to quit and restart one of the instances to get it to communicate). But there's a more consistent problem that I would like to fix first. I would appreciate any help you can to fix the settings.

My first instance of OpenCPN takes input from COM41 (GPS) and COM40 (AIS), and shares everything but the AIS sentences on the UDP channel:



The second instance takes the data exclusively from the UDP channel:



The first instance which shows AIS targets is zoomed out to give a good view of traffic coming from a few miles away. The second instance is zoomed in and shows local details of the chart. I like to activate my route on the second instance, because I prefer to have the highway showing on that window instead of hiding potential AIS targets. However, when I do this, the XTE, DTW, and other autopilot data do not make it over to the first instance via UTP.

You can see from the NMEA debug window that the second instance is dutifully receiving the data on the UDP channel once a second, and is sending out the RMB, RMC, and APB sentences onto the buss:



But unfortunately, the first instance does not receive any data from the UDP buss. The only data listed in black is from COM 41 and COM40, nothing in black from UDP:



Do you have any suggestions about what is wrong? Should I be filtering more data? Is it possible that the second instance is trying to echo the same data that it receives from the first instance, and that's causing the first instance to shut down all inputs from the UDP channel?

I hope I've provided enough info for you guys to help me. Let me know if you have more questions.

[cagney]

Localhost is only your local computer equal to 127.0.0.xxx.
So you are outputting to all programs on your local computer that are able to receive.

When you have several computers on board it seems natural to me to create a local network in the 192.168.xxx.xxx range. This will simplify many things, for example getting wifi Internet to all computers.

I just did a test with two computer
"one" 192.168.0.9
"two" 192.168.0.3
"one" has an UDP connection 192.168.0.3 with output.
"two" has an UDP connection 192.168.0.9 with output.
Both have a connection to the "other" computer.
This setup would work with TCP as well, but using UDP keeps the network traffic down and the speed up.

I connected AIS to "one" and the received targets were instantly visible in "two".
Then I stopped the AIS in "one" and created a route in "two" that I activated.
The created autopilot data was instantly visible in "one", but the active route is not mirrored on the chart in "one", as that kind of data is not transmitted.

This limited test shows that the communication works both ways.

Thomas

[RhythmDoctor]

Thanks for the suggestion. Unfortunately I do not have room for two computers, so I need to have two instances of O running side-by-side on one computer. Also, since my GPS and AIS are coming in through COM ports, and autopilot needs to go back out to the GPS COM port, I need those communications too.

Would you be willing to try doing two instances of O on one computer, and see if the communications run successfully between the two? That might be the key difference that causes mine to break.

Also note that I want the XTE data, etc. to go from the second instance back to the first instance, from which it gets transmitted out to COM41.

Sorry to be so picky, but I'm trying to get this to work with the legacy nav equipment that I already have, and it all runs NMEA0183 via serial communications.

Here are a couple of old pics from a couple years ago:

[RhythmDoctor]

Last night I modified the connections settings. Instead of just disabling COM40 and COM41 on the second instance, I deleted them out completely. I also tweaked the filters a bit, but not in a significant way.

Now the configuration works a little better, but has intermittent problems. The first instance of OpenCPN seems to work reliably as shown in my previous posts. But when I launch the second instance, it often fails to receive transmission from the first instance, and it can be quite difficult to get it to "wake up" the UDP port. Sometimes I have to quit and restart the second instance. Sometimes that does not work and I need to go through a complicated sequence of disabling the UDP port, turning off the output, and changing the priority of the UDP port on the second instance (odd, since I've deleted out the COM ports so there really should not be any priorities to resolve). It's complicated enough that I have not been able to come up with a specific procedure that works every time. I just need to fiddle with it.

If any of you can help I would appreciate it. Just run a second instance of O on the same computer and set up a UDP to funnel data between the two.

If I don't hear anything back in soon I will start a new thread, since this one has drifted away from the original topic of XPort incompatibility.