I have a problem with my OpenCPN
coms and I'm looking for some help in understanding it.
I run OpenCPN
V5 on a Windows 10 NUC.
The PC receives NMEA
data via a virtual coms port from a multiplexer of my own design. The mutiplexer converts SeaTalk1 data to NMEA
equivalents, combines it with GPS
sentences and sends them all to the VCP.
(The micro-controller in my multiplexer is an Atmel AVR and uses the signed VCP driver available from Microsoft Update. OpenCPN is set to use the VCP at 57600 baud.)
The PC's BIOS is set to start as soon as power is applied and OpenCPN starts as soon as Windows has loaded (there's a short-cut in the start-up folder). IE it's a "turn-key" system.
On power-up and programme start, about 1 time in 4, the coms doesn't initialise.
OpenCPN doesn't receive any NMEA data and the NMEA debug window is blank.
Closing OpenCPN and restarting it never fixes the problem.
Restarting the PC will fix the problem with about the same 1 in 4 chance.
Closing OpenCPN, opening the VCP with a terminal emulator shows that the NMEA data is present as expected. Closing the terminal emulator and restarting OpenCPN always fixes the problem.
Opening the terminal emulator without closing OpenCPN results in a coms port in use error. This suggests OpenCPN has the VCP opened but isn't receiving, reading or displaying the data.
The problem my be entirely with my own multiplexer but it seems more likely to be an odd interaction between the VCP and OpenCPN (because OpenCPN has opened the VCP). I will try adding a 60s delay to OpenCPN start-up in case the VCP isn't fully initialised when OpenCPN opens it.
I have attached two OpenCPN log extracts showing two start-ups a few minutes apart, one good and one bad. I'd be grateful if someone with the knowledge to interpret the logs
could give me some insight.