Problem with OPENCPN Serial Connection

[scud]

I am experiencing some glitches while using serial connections with OpenCPN5.0 in WIN10.

COM10 connected to AIS 38400 baud works smooth and fine

COM3 connected to an old GPS antenna (pharos) via USB/COM at 4800b works smooth and fine

COM1 -> here is the glitches!!! conneced via serial port 4800 baud to ACTISENSE NDC-4 multiplexer (IN-0/OUT-0)
problems are the following ones
1- randomly when I start OPENCPN apparently there is no communication on COM1. Playing with the connection (changing the serial port and then going back to COM1 ) apparently seems to solve the issue. §Note: if I temporarily set it to COM11 and then revert back to COM1 then in the NMEA Debug Window I keep seeing messages transiting on COM 11 as well as COM1 till I create a new connection with COM11 and then I delete it.

2- I try to output on COM1 some NMEA sentences relevant to the GPS (RMC or RMB or GLL and similar). From the debug window I can see the blue messages going out to the ACTISENSE input port (the inclusion list of hte ACTISENSE is perfectly matching the sentences that are suposed to come from COM-1). But when I check the output of the multiplexer I can see no evidence of RMC or RMB or GLL such as they have never been received by the ACTISENSE or else they have been filtered out or deleted because of some checksum or mismatch.

3- I try to set the sender ID of OPENCPN to a 2 letter code but it seems not to affect at all the OPENCPN and hte mesages going out. I can see a lot of $GPGLL or $GPRMC being GP the id code of the Pharos GPS antenna but whatever 2-letter-code I write in the input box of he connection gets simply ignored by the program.

Have I misunderstood the settings and the system? I'd appreciate any hint or suggestion coming from the forum.

[Hakan]

scud..
Connection via a serial port, e.g. COM1, use to work fine as long you've made correct wiring on the DB9 connector and the baud rate on your Actisense is really set to, in your case, 4800. (Use your "NDC control centre" program)

The Actisense NDC-4 can be tricky sometimes. If you for example have the USB connected then the RS232 ports are not fully functional. You've to power it by the on board power connectors.

[scud]

Originally Posted by Hakan

scud..
Connection via a serial port, e.g. COM1, use to work fine as long you've made correct wiring on the DB9 connector and the baud rate on your Actisense is really set to, in your case, 4800. (Use your "NDC control centre" program)

The Actisense NDC-4 can be tricky sometimes. If you for example have the USB connected then the RS232 ports are not fully functional. You've to power it by the on board power connectors.

When it works the connection on COM1 is perfectly fine. The problem is that quite often when I start OPENCPN the COM-1 is silent and still (but correctly recognized by OPENCPN apparently )and then I try my tricks in order to resurrect it (swap the COM number to COM11, go back to COM-1; sometimes it is sufficiento to enable/disable the connection and it is back to work.)

Regarding the ACTISENSE the COM1 is correctly wired to IN-0 and OUT-0 since when I use NDC Control Center on COM-1 it works flawlessly. I don't use the USB for the ACTISENSE sinceI have an unsolved problem withthe associated WIN10 driver.

I wonder if I may wire an additional serial port to COM1 TX/GROUND wires, I mean
COM1 TX (pin 3) -> to COM 5 RX (pin 2)
COM1 GROUND (pin5) to COM5 GROUND (pin5)

and then actually veify what comes out of COM1 using a sniffer on COM5

[scud]

Maybe I've understood the issue with point #2, i.e., NMEA sentences OUT from OPENCPN that don't actually show up in the ACTISENSE output.

By looking at the diagram block of the ACTISENSE it seems that whereas
IN 1 to 4
and also IN-0
(for a total 5 talkers) gets all clubbed together and all combined in OUT-1

instead on OUT-0 only IN 1 to 4 are clubbed together. By looking at the OUT-0 (what I have been doing so far) I cannot see the sentences channeled on IN-0.

Eventually that explains also point #3, i.e., complete insensibility to the instructed talker identifier code in OpenCPN. I wanna D-check this one too since in the NMEA debug window the talker id seemed unaffected no matter what and that has nothing to do with the actisense.



Still I have no clue @ why COM1 often shows up as still when launching OpenCPN.

[scud]

I am glad to report that by moving all the "listeners" on OUT-1 and leaving just the SERIAL RS-232 connection on IN-0/OUT-0 magically all the glitches have vanished.
OPENCPN seems to broadcast the GPS signal correctly.

Just a question still lingers in the back of my mind. When the "NMEA output" checkbox is activated for a connection in OPENCPN then OPENCPN simply relays a sentence as received from the GPS antenna or can generate NMEA sentences on its own?

[Hakan]

Originally Posted by scud

I am glad to report that by moving all the "listeners" on OUT-1 and leaving just the SERIAL RS-232 connection on IN-0/OUT-0 magically all the glitches have vanished.
OPENCPN seems to broadcast the GPS signal correctly.

Very good. Well done!

Just a question still lingers in the back of my mind. When the "NMEA output" checkbox is activated for a connection in OPENCPN then OPENCPN simply relays a sentence as received from the GPS antenna or can generate NMEA sentences on its own?

If you select output on a connection all incoming NMEA from any connection are multiplexed/combined and sent out on that port. If you don't want everything to be sent out you have to use the "Output filtering". Either select what to transmit or what to filter out (drop).
The only situation when OCPN is creating its own NMEA message is when you activate a route to follow. Then NMEA messages relevant for a autopilot are created. And transmitted to a "Output" port. In that case you may want to make a transmit filter to send only messages having the "Talker" "EC", e.g. ECRMB.