Garmin 800 AIS crashing OpenCPN

[Karanga]

I have previously operated a Digital Yacht AIS via USB-serial converter into a Windows 10 laptop, which has worked very well for 3 years.
I recently got a new boat, with Garmin systems already. I added a 800 AIS (shoulda chosen Digital Yacht again!). Input is again via USB-serial converter and nmea 0183. Port is set on 38400 baud.

I simultaneously upgraded to OpenCPN v5.6.0

Now I get frequent crashing of OpenCPN.

Also, I can see many AIS targets on the Garmin plotter screen (nmea 2000 network) , but much fewer on the OpenCPN screen.

I have tried to analyse the data coming through in the nmea debug window. Lots of red sentences. I have set the serial port to ignore any AIVDO sentences so it doesn't conflict with position data of USB GPS puck.

I have enabled as few plugin as possible, and updated any I could find.

I have submitted error reports, but I wonder if anyone else has struck this issue and if they resolved it.

Thank you for any responses

[LennartG]

Karanga,
disabling AIVDO messages does not remove an eventual conflict with the USB GPS puck. You need to also remove the RMC, GGA, GSA and GSV messages from the AIS unit. There is more infoirmation here: https://opencpn-manuals.github.io/ma..._gpsgnss_units.
/LennartG

[Karanga]

Thank you for your response.
You are right - other sentences also contain GPS information.
Except that I cannot see any of them come through that port in the nmea debug window.
In fact, I can't see much in the way of useful data through that port. The GPS Puck has very clear sentences, with lots of GPS data.
It is almost as if the baud rate is not quite correct... Except I have set the port and the serial connection to 38400, as stated in the Garmin manual.
I am currently in a port with many ships. The plotter is displaying something like 100 targets, but OpenCPN is displaying about 7. So it is getting *some* data...

[LennartG]

Karanga,
it is practically impossible to give a constructive answer from the information supplied, The best bet is if you can record a VDR file and attach it to a message. Ad a '.pdf' extension to allow it to be attached.
First clue is that iif you get some messages thru, chance is then that the baudrate is correct. Also look in the debug window for clues, it may be that you have incomplete sentences, a data overflow, wrong checksum or something like that.
Second: Which is your platform? Could it be that the CPU/memory load is reaching a limit? Use the 'top' command if Linux/RPi and strile '1' to see cpu load per cpu.
/LennartG

[LennartG]

Karanga,
should have read your initial post a bit better, now I have.
My best guess is that the number of received AIS messages is simply to many for the 38400 baudrate, the NMEA 0183 interface is 'choking' on the amount of information
If I see right the AIS800 also has a NMEA 2000 interface ( using 250k baudrate), is that an option for you? Problem then is that you may not be able to disable the GPS infiormation and will get double GPS receivers.
/LennartG

[Karanga]

Very interesting thoughts...
Too much info and choking? That seems amazing, although I suppose possible. I do notice that the Rx led on the Garmin is almost continuously flashing, which would indicate very busy receptions. But I'm sure that many other ports around the world would be 10 times busier. And a baud of 38400 is pretty quick (compared to the old 4800 baud RS232 data streams that I cut my teeth on!).
But still, it may explain why the data displayed is so limited and full of errors.

Nmea 2000? I thought OpenCPN was only able to work with nmea 183? What sort of connection is required for that?
Plus the Garmin 800 is already connected to the nmea 2000 backbone...

[LennartG]

Karanga,
let's do some rough math, partly out of my league: According to https://en.wikipedia.org/wiki/NMEA_0183 the maximum length of a NMEA 0183 message is 82 characters (worst case), 8 bits and one stop bit. That makes (including one bit in between messages) 10 bits per byte times 82 characters a total of 820 bits per message.
The use of 38400 bits/s would then allow, worst case, 46 messages per second. As most messages are shorter than 82 characters the number of messages is larger but still not unlimited and 200 AIS (plus GPS etc.) could well hit the roof.

Regarding NMEA 2000 OpenCPN has two options: Signal K and TwoCan both frequently discussed in other threads and both well documented in the OpenCPN documentation.
Signal K interfaces directly into OpenCPN while TwoCan converts into NMEA 0183 that is then read by OpenCPN. If using NMEA 2000, be aware of the 'multiple GPS effect' though.

/LennartG

[Hakan]

Lennart..
Just a real example for comparison:
A AIS station here around, Gunnar, is receiving about 350 AIS targets. The first part of that chain is a 38400 serial connection to a TCP server. I can measure the throughput on my SignalK server and see the amount of target on a OCPN connected to SK.
SK throughput from the AIS receiver is about 17 deltas/second and thus resulting in 350 targets in my AIS list. All of them are of course not transmitting every second.

I've no doubts about your theoretical math but it may be conservative and the real example would be more forgiving. Most big ships around would see the same amount of targets using baud rate 38440 without trouble?

[bcn]

Another reflection: Garmin says the port is 38400 (output), how can the unit then push out more than that bandwidth?

Is the cabling really sound? The output of the NMEA debug window would be helpful - can be a screen shot.


OpenCPN and AIS targets: we have access to the AIShub output and had some 12.000 different targets on the screen. No issue. This is UDP of course..

[Hakan]

I think Hubert nailed the bandwidth logic. As simple as that! (But as a professor may have said: "Why make things simple when we complicate it all in such a beautiful way?")

[LennartG]

Håkan,
I was hoping for you to step in with some 'real life numbers', my calculations is indeed a bit conservativ or worst case. It was more as a reflection on the 38400 capabilities. Have no information on the message length for AIS messages.

bcn,
good question, is it the Garmin unit that is the limit as it also outputs e.g. GPS data (1 Hz/10 Hz?).
This is surely not an OpenCPN problem but likely communication of some kind. Is a good RS422 converter used or is an of-balance RS232 method used? The data from the NMEA debug window could give a clue.

/LennartG