OpenCPN 5 can not connect to USBserial device (virtual COM port) in Windows 10

[ManekiNeko]

Dear OpenCPN developers!

I am Yacht Devices tech support engineer.
Recently we have received several issue reports for our YDNU-02 USB gateway.

It seems openCPN 5 can not open virtual COM port of our USB device on Windows 10.

I suppose it is a possible duplicate of the issues reported at "flyspray" (FS#2595 and FS#2642) for other USBserial devices.

The bug can be reproduced only on Windows 10, Windows 7 works fine.


Here is my test setup:

Windows 10 Pro x64
OpenCPN version is 5.0.0+9065270
YDNU-02 is visible in "Device Manager" as "STMicroelectronics Virtual COM Port" COM3.

To reproduce an issue:

- connect YDNU-02 to NMEA 2000 network and PC USB port
- reboot the PC
- start OpenCPN
- connect OpenCPN to the YDNU-02 virtual COM port
- no data received by OpenCPN (NMEA Debug Window empty and YDNU-02 LED indication shows the port is not open from a PC)


In opencpn.log I can see

4:33:48 AM: Opening NMEA Datastream Serial:COM3

but no further messages for COM3 port present.

It is possible to use a workaround mentioned in FS#2595:

- disable COM port connection in OpenCPN or close OpenCPN
- start PUTTY and connect to YDNU-02 virtual COM port
- observe valid NMEA 0183 data stream in PUTTY terminal window, also YDNU-02 LED indication shows that the port was open from a PC
- close PUTTY
- start OpenCPN
- connect OpenCPN to the YDNU-02 virtual COM port
- valid data received by OpenCPN, (NMEA Debug Window shows valid sentences and YDNU-02 LED indication shows the port was opened from a PC).

I can see the FS#2595 was in "assigned" state for rater long time, but no progress was made on the issue so far.

Please, tell me if you plan to investigate an issue further and if I can help you to debug the issue.
Maybe there is a possibility to record an extended openCPN log?

Thank you.

[CarCode]

ManekiNeko


Years ago I have been in the device production myself and I guess the poor quality of STMicroelectronics chips has not changed til then. Try to use the FTDI chips for your devices. They are far better and their drivers always works well.

[transmitterdan]

Originally Posted by ManekiNeko

Dear OpenCPN developers!



I am Yacht Devices tech support engineer.

Recently we have received several issue reports for our YDNU-02 USB gateway.



It seems openCPN 5 can not open virtual COM port of our USB device on Windows 10.



I suppose it is a possible duplicate of the issues reported at "flyspray" (FS#2595 and FS#2642) for other USBserial devices.



The bug can be reproduced only on Windows 10, Windows 7 works fine.





Here is my test setup:



Windows 10 Pro x64

OpenCPN version is 5.0.0+9065270

YDNU-02 is visible in "Device Manager" as "STMicroelectronics Virtual COM Port" COM3.



To reproduce an issue:



- connect YDNU-02 to NMEA 2000 network and PC USB port

- reboot the PC

- start OpenCPN

- connect OpenCPN to the YDNU-02 virtual COM port

- no data received by OpenCPN (NMEA Debug Window empty and YDNU-02 LED indication shows the port is not open from a PC)





In opencpn.log I can see



4:33:48 AM: Opening NMEA Datastream Serial:COM3



but no further messages for COM3 port present.



It is possible to use a workaround mentioned in FS#2595:



- disable COM port connection in OpenCPN or close OpenCPN

- start PUTTY and connect to YDNU-02 virtual COM port

- observe valid NMEA 0183 data stream in PUTTY terminal window, also YDNU-02 LED indication shows that the port was open from a PC

- close PUTTY

- start OpenCPN

- connect OpenCPN to the YDNU-02 virtual COM port

- valid data received by OpenCPN, (NMEA Debug Window shows valid sentences and YDNU-02 LED indication shows the port was opened from a PC).



I can see the FS#2595 was in "assigned" state for rater long time, but no progress was made on the issue so far.



Please, tell me if you plan to investigate an issue further and if I can help you to debug the issue.

Maybe there is a possibility to record an extended openCPN log?



Thank you.

@ManekiNeko

I am willing to help debug but i don’t have a Yacht device to test. Here are a few questions:

When Putty connects does it automatically send some character to the USB port? OpenCPN expects the serial device to just send text as soon as the port is opened. There is no timeout if no data is received. Is it possible that the device needs to receive a character before it starts sending data on the transmit channel? Perhaps Putty sends a carriage return or some other character when it opens the port and the device sees that as an indication to start streaming.

OpenCPN assumes a USB device is the same as a plain RS-232 port at the application layer. Some USB navigation devices need to receive a character or special string to trigger the start of data streaming.

[Dsanduril]

This issue has been reported with a number of USB devices (but I don't know about chipsets) with OpenCPN 5. In all cases that I know about the devices used to work in 4.8.x, so some change in the way 5 deals with com ports (at least virtual ones).

In some testing using various terminal software it appeared that the com ports in question required some combination of DTR/CTS/RTS to be set before they would start data flow, and it also appeared that OpenCPN doesn't do that when opening the com port. I did find a method (not reliable) with O of setting the "Output on this port" and "Garmin" flags that got O to raise the pins on the com ports and got data flowing. Sometimes it seemed to work and sometimes it didn't. That was as far as I got since I wasn't working in code itself and didn't have access to multiple devices for testing.

Just throwing it out there in case it saves some time.

[CarCode]

Originally Posted by Dsanduril

This issue has been reported with a number of USB devices (but I don't know about chipsets) with OpenCPN 5. In all cases that I know about the devices used to work in 4.8.x, so some change in the way 5 deals with com ports (at least virtual ones).

Correct, the developers have changed the serial com port software part in version 5.0 to an opensoftware library they have found in the internet. Before version 5.0 these functions have been more related to the operating system. The change have been done without need and was obviously not tested enough. Anyone interested can check Serial by wjwwood

[bdbcat]

Dsanduril...
re:
"This issue has been reported with a number of USB devices (but I don't know about chipsets) with OpenCPN 5."


From your previous investigation, do you recall exactly which devices had trouble on O5?


Dave

[Dsanduril]

Originally Posted by bdbcat

Dsanduril...
re:
"This issue has been reported with a number of USB devices (but I don't know about chipsets) with OpenCPN 5."


From your previous investigation, do you recall exactly which devices had trouble on O5?


Dave

Sorry, that information's on the boat, I currently am not, and my memory is quite fallible. None of them were my devices, was helping other folks. Do remember well that using RealTerm I could control the state of the handshaking bits and that I could get the same thing to happen - connect to port but get no data - by opening the port with all of the handshaking off. And could then trigger data by setting the handshaking bits high.

Also ran O 5 into a virtual com port that was connected to RealTerm and watched what O did to to the handshaking bits - nothing - when opening the port. I could play back recorded NMEA over that port and O was quite happy.

In the end, IIRC, the fix was to use GPSGate Splitter (or one of several other com port sharing tools). That seemed to open the ports OK and then O dealt with new virtual ports just fine.

Bottom line, it seemed that some of the virtual ports out there wanted handshaking and it wasn't present.

I do have to caution that while I play with serial comms nearly every day I could be completely off base and this could be a red herring - I was only looking in from the outside and trying to figure out a problem.

[bdbcat]

Dsanduril...
OK, thanks for the info.
As usual, if we could lay hands on an offending device, the OCPN core source solution would come in due course. But, as is the nature of these things, all my devices work fine...
Dave

[ManekiNeko]

Dear forum members!

First of all, thank you for your fast replies.

@CarCode

Years ago I have been in the device production myself and I guess the poor quality of STMicroelectronics chips has not changed til then. Try to use the FTDI chips for your devices. They are far better and their drivers always works well.

Sorry, but we can not fix the problem this way.

@transmitterdan

When Putty connects does it automatically send some character to the USB port?

I do not think so.

Is it possible that the device needs to receive a character before it starts sending data on the transmit channel?

No, our device does not expect any COM-port input to start the data transmission.


@Dsanduril

In some testing using various terminal software it appeared that the com ports in question required some combination of DTR/CTS/RTS to be set before they would start data flow, and it also appeared that OpenCPN doesn't do that when opening the com port.

I suppose you are close to the truth.

I did find a method (not reliable) with O of setting the "Output on this port" and "Garmin" flags that got O to raise the pins on the com ports and got data flowing.

With those setting the situation gets worse: OpenCPN debug window shows that it outputs data to the port, but it shows no received data, device LED indication shows there is no COM port connection.

In the end, IIRC, the fix was to use GPSGate Splitter (or one of several other com port sharing tools). That seemed to open the ports OK and then O dealt with new virtual ports just fine.

I confirm that this solution works, tested it with VSPE (virtual serial port emulator).
However, I find it more elegant to just write a .bat file which opens the port with PuTTy, closes it and then starts OpenCPN.

@bdbcat

I have received your PM, and will contact you via an email.



Thank you!

[Ben S]

I have YDNU-02 om my boat
I output AIS to the port
Input is GNSS and compass data from a Raymarine AR200, Honda engine etc...

It works, but i have a very old W10 version 1607 on the boat.
Never did update because change of breaking oeSENC charts.
Its never online, so no problem.....

I will test if this stops working when disabling the output on the port

[TheOffice]

I'm not a tech guy, but I do have a YD working with my OpenCPN in windows 10.
Sorry if these seem too basic.

Do you see the data in the browser?
Did you go to settings/plugin and enable the Dashboard and set the preferences?

[bcn]

Originally Posted by Ben S

It works, but i have a very old W10 version 1607 on the boat.
Never did update because change of breaking oeSENC charts.
Its never online, so no problem.....

If a W10 update invalidates the oeSENC license and we see this from the system identifier files we will repair the license.
No reason not to update - there might other reasons not to update W10, I admit...

[Ben S]

I can confirm the YDNU-02 port is not opened by openCPN
I disabled output to the port, and there is no input.
Enable output, and the input is working again.

[Ben S]

Is there a fix already fot this?

[AboardAdventurer]

I discovered the issue with OC 5 and USB Serial comms last fall when trying to integrate a Maretron USB100 gateway. Same issue where it wouldn't open a USB serial port. I eventually abandoned that style of connection, instead creating a virtual tcp connection with the USB input via gpsgate. Had I been smarter, I would have avoided Maretron entirely, favoring the Yacht Devices hardware which now represents a majority of my NMEA2k network. You guys have great hardware and even better customer support. I think using USB serial is temporarily not an option with OC, but frankly it works better over multiple devices to just use the YDWG-02 wifi gateway so that any device on the network can share the data.

AA