Garmin (N2K) via QK A034 to OPN CPN

[cas206]

Originally Posted by Corsair63

why not using the QK 0183 inputs for GNSS and AIS?

If/When you get the N2K data going to the Laptop, and then get the GPS USB / AIS USB back online to the Laptop, I would second Caorsair63's comment. If you plan to keep this configuration (3 USB inputs at Laptop) for only a short while before going full N2K, then it will probably be fine to skip moving the GPS/AIS to the QK.



For long term use, I would be more worried about corrosion of the USB connectors than a potential throughput bottleneck. The manual for the QK states that it has built in Galvanic Isolation for the 3 NMEA 0183 inputs which helps to keep this from happening. I would assume your GPS (puck?) and AIS device doesn't have that built in.


-cas

[s/v Jedi]

Originally Posted by Grippy

For us mere mortals not blessed with the "Nanites" of the FORCE in our blood, or the fiscal foundation, to lather ourselves, and our vessel with the comforts and luxuries of all that the "Imperial Overlords" enjoy. We must work within our resources to overcome.

Confused you are, my padewan. The Borg it is, who are blessed by their nanites, while the Jedi are born with the genetics of The Force

It may be good to know that the funds for the Ethernet switch I recommend are very tolerable, under $60 here: https://www.amazon.com/gp/product/B08MBFLMDC

Especially when your multiplexer can do Ethernet, buying the switch now is a no-brainer because you don’t need the $249 Ethernet gateway I linked.

I say this because the problems are always caused by the serial connections. Windows especially does not play nice with those. As soon as you put that data on Ethernet, everything will work.

[cas206]

Originally Posted by Grippy

Okay...
we have cycled through each different baud rate, one at a time, restarting the QK, laptop, and OCPN after each new setting...

No changes.

But what about trying the different baud rates in the OpenCPN connection window? No need to restart QK, etc.

[Grippy]

Yes,
I checked each baud rate in both the QK and Ocpn...
no changes at all.

[s/v Jedi]

Originally Posted by Grippy

Yes,
I checked each baud rate in both the QK and Ocpn...
no changes at all.

I don’t think USB drivers use baudrates. Whatever rate you set in the OS, they all work the same.

[cas206]

You are also closing the configuration program, or any other programs, that might be trying to use that COM port?



Last thing I would try, before calling for tech support, is to download and install Putty. This program lets you see what's coming across a COM port. However, it's not "blessed" by Microsoft. So if you run it, Windows will pop up an alert, in which you need to give permission to allow it to run.


If you decide to give it a shot, here are instructions:
Download and install: putty-64bit-0.79-installer.msi from this link.

https://www.chiark.greenend.org.uk/~...ty/latest.html


If a windows comes up, when you install it that says not to trust this program, click advanced and install anyway.



Run "PuTTY" after it is installed.


Change "Connection Type:" button, from "SSH" to "Serial".



In the box above that, "Serial Line", type "COM8".



In the box for "Speed", try some of these, one at a time, "4800", or "9600", or "38400", or "115200".


For my GPS puck, on USB, I see garbage scrolling across the window when the speed is not correct. Only when I find the right speed, do I get readable text.

[cas206]

Originally Posted by s/v Jedi

I don’t think USB drivers use baudrates. Whatever rate you set in the OS, they all work the same.

I thought that too and it's mostly correct (apparently). Windows driver apparently doesn't care, but the program itself does.


I just experimented with my USB GPS puck on Windows. Going to the Device Manager/Ports/COM Settings and changing the baud rate doesn't change the behavior of seeing data.


However, getting the baud rate correct in PuTTY or OpenCPN does matter.

[Grippy]

Okay Warren.
I will give this a try.

[Corsair63]

I guess since the beginning we're loosing the plot of situation.

Grippy please just clarify the devices that you have and how you have then connected to computer either QK.

from deducted of your messages you have at least GPS and AIS connected to computer via USB.

using windows, I guess,
right click on start menu and click on device manager.
go to COM and LPT port and deploy it.
now take one USB connection device e.g. GPS and unplug it, look which COM port is gone after some seconds plug it again and check which port is coming, note the com port number and source name.
do the same with all you navigation devices connected to your computer and write down the numbers and device name.
now start the QK configuration software and set outputs to USB with speed of 115K, apply and exit from configuration software.
now start OCPN and review connections
at least you'll have to have one for each USB connection and for better recognizing give then a proper name.

check if you have one for the GPS it has to be set as 4800 bps, and name it "USB GPS", in the COM port that you have identified as GPS.
you should have to have one for the AIS, set it to 38400 bps and name it "USB AIS", in the COM port that you have identified as AIS.
same for independent input devices not connected to QK but connected to computer if they are not HS the speed must be 4800 bps.
now the connection for the QK, set the speed to 115K, in the COM port that you have identified as QK, and until you have all clear don't set it as "output", you'll do later when everything would be working, and you'll filter the output sentences e.g. to autopilot. (Also name connection something like QK multiplexer or whatever you want for being clearly recognized)

doing it step by step you should not have to have any problem.

if AIS and GPS have only USB connection it would be difficult to send the information to N2K network via QK, but if the connections are done via USB adaptor, maybe you can connect it directly to QK but always having clear the baud speed in QK configuration software.

but first of all try to connect the devices as you have now and having the data in OCPN.
in the connection part of OCPN on set-up every connection, click on apply and keep the NMEA debug window opened to see the data flow.
if you see that is coming data on every connection done, you can unable it on the thick box and apply and check one by one and not messing with data.
when you have checked that all data are received you can enable all and click apply.

[Grippy]

Okay
As of now, all usb are disabled and unplugged,
except the QK...
I will now go back and reintroduce each, varify input to cpn, then disable.

[Grippy]

QK is showing 38400 as max... 115K not even input through manual.

[Corsair63]

if in the caption attached you cannot deploy and set to higher speed than 38400, then keep it at 38400.
but when setting the communication for the QK USB in OCPN set as the same speed than in QK setup.

[Grippy]

Check!
so, all done, no real change...
GPS puck is no longer gergistering in the com ports. But the internal GPS seems to be taking up the slack.
A com 17 seems to be multiplying itself, up to 5 COM17 and know idea what it is responsible for. Or what is making the new ones.
Com 5 is the AIS puck, and that seems to be working well.
But COM8, ID as the QK A340 , all set at 38400 on both OCPN and QK, but no feed to OCPN even though there is constant feed showing on the Config tool...

[Corsair63]

bear in mind that you cannot have open at the same time the configuration tool and OCPN, will work only one, so keep all programs accessing to COM port closed and only work at this time with OCPN.
How many COM ports have you and what are the assignment to it??
also, are you doing the connections via USB switch??
because in previous windows version they were a pain in the a... because every time you unplug and plug the same device, they used to exchange the port.
why you say that you cannot find the COM port for GPS?

[Grippy]

Last question first....
When I plugged back in, the AIS, And the the GPS pucks...
the AIS puck, came up as its old com5 and produced data to the Bug display,
the GPS puck did not. GPS data coming through, but must be from the internal GPS, as I double checked and unplugged the puck...