Problems sending autopilot data to PolarCOM

[RhythmDoctor]

Because of problems connecting OpenCPN to Bluetooth virtual COM ports in Windows (described in this thread), I have started testing PolarCOM to make the Bluetooth connection and feed the data over to O. I've managed to take two virtual COM ports (containing GPS data @ 4800 and AIS data @ 38400) into PolarCOM and mux them to a TCP server at 127.0.0.1:11083, from where I can easily access them on OpenCPN.

This whole thing works fine as long as O is only receiving data. But I would like to output autopilot data back out through PolarCOM. As soon as I hit the "output" checkbox, the NMEA Debug Window freezes until I uncheck it. When this happens, PolarCOM's NMEA terminal window continues to show an output stream flowing to OpenCPN, so the problem seems to be at the OpenCPN end of things.

Does anyone know what the problem is and how to resolve?

[bdbcat]

RD...

I'll take a look at the code, but I think this may not work.
1. A single TCP connection can be either input, or output, but not both.
2. If set for output, O will try to act as a TCP server at the specified address/port. Does PolarCom have a TCP client at that port?
3. Autopilot output over a TCP or UDP connection is not tested. You are a leader again

Dave

[RhythmDoctor]

Originally Posted by bdbcat

RD...

I'll take a look at the code, but I think this may not work.
1. A single TCP connection can be either input, or output, but not both.
2. If set for output, O will try to act as a TCP server at the specified address/port. Does PolarCom have a TCP client at that port?
3. Autopilot output over a TCP or UDP connection is not tested. You are a leader again

Dave

Specific responses to your three comments/questions:

1. That surprises me. I thought a TCP connection could be full duplex (just like TCP connections between a computer and a router). I did not know that, in this case, the master doesn't allow the slaves to talk.
2. I had PolarCOM set up as the server, so O with output turned off would be the client, and O with output turned on would cause it to break. I went back and tried PolarCOM as the client and turned on O output, but could not get any bidirectional communcations.
3. After your comment, I went back and tried a UDP connection between PolarCOM and O, and was getting bidirectional communications. But O's autopilot commands were echoing back from PolarCOM and creating some pretty chaotic behavior. I tried filtering out some sentences, but that did not seem to help. And I have no way of knowing whether PolarCOM would forward the AP commands to the correct port, because I'm not at the boat.

But for now, I have a very workable solution. XPort does a great job of opening and maintaining the Bluetooth connection, and I know from 3 years of using it that it also sends O's autopilot commands back out the same COM port. Its only deficiency is that it only works with one COM port. So I'll use it for the GPS data, and to split between two instances of O if I choos to run both. For the AIS feed, I'll use PolarCOM TCP server to send half-duplex feed of the data into O (one or two instances). Using both utilities gives me everything I want for now. I need to confirm all this on the boat, but it seems to work in my house when sending NMEA logs from my old netbook, through a USB-serial connector to my BT transmitter, and ultimately into my tablet.

(By the way, VERY NICE upgrade in O 3.2/3.3, having VTG and RMB/RMC sentences going out even when a route is not activated. That allows my autopilot to display SOG and other data when in standby. Previously on 2.5/3.1 my autopilot would only get that data when a route was activated, which is relatively rarely.)

[RhythmDoctor]

Originally Posted by RhythmDoctor

...XPort does a great job of opening and maintaining the Bluetooth connection...

...I discovered by chance this evening that XPort will only run with UEFC Secure Boot disabled. (Use Google to figure out how to do this.) I had not realized this until I re-enabled Secure Boot (thinking that it had no effect), and XPort stopped working afterwards.

XPort is an unsigned driver, and that's prohibited by Secure Boot.

Even with Secure Boot disabled, you need to Run as Administrator (and click "Yes" on a verify warning) for it to work. Fortunately, you can set a shortcut to run as Administrator automatically.

[RhythmDoctor]

FYI, I headed down to the boat to make sure our 12" of snow did not pile up on the cover (wind blew it all off). While there, I climbed inside the cabin and fired up the radio/AIS and GPS, attached the Bluetooth transmitters, and fired up the new tablet with the PolarCOM/XPort configuration that I mentioned yesterday. It all worked perfectly with current location, AIS targets, and output going to autopilot. I even went out in the cockpit to confirm that the Bluetooth signal was strong enough. As I watched the tugboats on AIS I felt really bad for those guys out there in 10°F (-12°C) temps.