OpenCPN Version 5.7.1 Beta Test #2

[ZagsAtCF]

Raspberry Pi 4, Bullseye 64 latest with Beta test 2. When viewing the AIS Target Query Dialog Box for a boat named "Liberty" as I hover over the boat the Rollover Dialog Box (yellow box) shows the wrong name "Comrade"

[Hakan]

ZagsAtCF..
It's not only the name that differ. It's two different targets. Not the same MMSI or speed, course. Is this anything you can repeat and see again?

[ZagsAtCF]

I am able to replicate this. I setup another Raspberry Pi 4 at my home and using the candump files from that day replayed via canplayer I have another image showing the issue. I also chose another candump file from 8-29-22 and could see the issue here as well. It appears that the Rollover Dialog Box can appear all over the place with no regard to a ships location.

[Hakan]

ZagsAtCF....
I've tested on my Rpi4 armhf BullsEye.
I played (again) a N2k log-dump via Vcan0. That file was created from a live system, can0, I tested some time ago.

Lots of AIS and most other data.
No problem whatsoever with AIS-mouse-roll-over. Always the correct info for each target as for the target query.

So what can be the difference to your system?

[ZagsAtCF]

Curious, I am using the 64-bit OS version on both of my sites. Perhaps we can exchange setup information or log files if you are interested. Or, if you have any other thoughts. I will play around a bit and see if I can alter the behavior.

[ZagsAtCF]

I ran my canlog again yesterday and noticed that when I first began the issue did not occur, but after some AIS boating activity the Rollover issue appeared and kept getting worse with more time and boat traffic. I realized that the AIS data is persistent on the map and you could get a ships past Rollover info along its track history. I then enabled "Show target tracks (min)" and set it to 60 minutes. Here is a series of photos following WSF Kaleetan from Elliot Bay toward Port Orchard.

[Hakan]

ZagsAtCF....
Just so we are testing the same thing:

This is my method:
Disable any OCPN can0 connection.

The following 5 commands will bring up the interface called "vcan0".

    $ modprobe can
    $ modprobe can_raw
    $ modprobe vcan
    $ sudo ip link add dev vcan0 type vcan
    $ sudo ip link set up vcan0

After that enable a OCPN vcan0 connection.


Here's a file I test if you like: candump_test

cat "filename" | canplayer vcan0=can0

[ZagsAtCF]

This is my method:
sudo ip link add dev vcan0 type vcan
sudo ip link set up vcan0
sudo ifconfig vcan0 txqueuelen 1000
Then I use canplayer like you to play out to vcan0 with can0 disabled in OpenCPN.
I will try your file and get back to you.

[Hakan]

What's txqueuelen 1000? Could that make a difference in behavior?

[ZagsAtCF]

I believe it is a buffer for the interface, in this case the vcan0.

[Hakan]

I'd suggest take this out and maybe try the set-up I've learned to use and check if your trouble persists.

[ZagsAtCF]

I'll give your method a try, but in the meantime I ran your log file and it crashed my OpenCPN several times. I did manage to duplicate the issue with your data, again I enabled Ships-AIS Targets-Show target tracks, length (min) to see the path the vessel "Buro" took. I also ran your livetest_on_board.log file through candump2analyzer and analyzer (Canboat) and noticed quite a few errors. I am attaching the photos, the error list, the OpenCPN.log file (after the crash) and a log file from my collection (candump2022-08-28.log). Also, I first witnessed this behavior on my boat, Opus, as it was occurring live, so I don't think this is a can player playback issue.

[Hakan]

OK. Since it's working on my system I can't investigate more. Sorry.
The log file recorded from a live N2k bus worked fine both to canBus can0 on a RPi and via a YDNU-02 via USB to N2k connection Windows.


BTW: And your can0 bitrate is set to 250 000?

[ZagsAtCF]

OK, apparently I cannot attach files other than images, so here are links to the files I mentioned above. I'm new to dropbox so hopefully this works.
https://www.dropbox.com/s/s45rhhmukw...8.log.zip?dl=0
https://www.dropbox.com/s/bzgc0wabh0...r.txt.zip?dl=0
https://www.dropbox.com/s/5txgn2y5q6...encpn.log?dl=0
Thanks for your help.

[bdbcat]

Zag...
I did manage to reproduce the error reported. Occurs only on N2K AIS target position processing. Will not occur on N0183 data streams.


If you are building from source, the fix is now available in github master. Otherwise, will be coming in next Beta.


Aside: This bug could clearly be responsible for OCPN causing memory exhaustion when run for several days with heavy N2K AIS traffic in the mix.


Thanks
Dave