One AIS SART message, many MOB waypoints.

[AedanC]

Hello,

I'm seeing behaviour I didn't expect with OpenCpn 4.8 running on Windows 10.

I receive one AIS SART message, which I have generated myself so it's possibly malformed. The MMSI number is one that's set an an MOB device in Options->Ships->MMSI Properties.

OpenCpn correctly generates a MOB waypoint and alarm, but then proceeds to generate another MOB waypoint at the same location every second until the alarm is acknowledged. It then stops generating waypoints, but starts again when the MOB acknowledgement times out. The only way I have found so far of permanently stopping it is to exit OpenCpn.

I have attached a vdr file (renamed as .doc) that demonstrates the problem. Note that the AIVDM message is near the beginning and there is a lot of other NMEA traffic after it, this is just to give you a chance to stop playback before it auto-repeats.

Is this intended behaviour?

Thanks,

Aedan

[bcn]

Can you please try the actual Beta version and report back?

[AedanC]

Appears to be the same on 4.8.10125.

[bdbcat]

AedanC...

I know we have talked about this at length before, but we can talk again.

This is the designed behavior.

AIS SARTS are rare. And each one is important. So we choose to be ultra-conservative when it comes to showing their status on screen.

We recently added code to allow OCPN to ignore specific MMSI numbers, as a way of silencing a spurious SART from faulty transponders.

Dave

[AedanC]

Hi Dave,

Thanks for your reply. Conservative is very good in this matter all right.

I don't think this is the behaviour that was being talked about before. My recollection of that discussion is that it was to do with silencing particular errant SARTS, what I'm talking about is many (it looked like many hundred the first time I spotted it) MOB waypoints being generated in the same place from just one SART AIVDM sentence that does not repeat. This is not one waypoint per SART message. A new waypoint is being generated every second and I don't seem to be able to stop it happening until I restart OpenCpn.

If this is indeed the designed behaviour then I can live with it, it just seems rather odd to me.

Aedan

[nohal]

Aedan...
Playing your attached sample for the past 30 minutes with VDR at maximum speed and see no problem at all. I have exactly one AIS MOB target and no MOB waypoints. What am I doing wrong?

Pavel

[AedanC]

Hi Pavel,

I thought I had replied to this a few minutes ago but I don’t see it, so here goes again.

You should only have to play it once to see the problem. The reason I left a load of stuff on the end was to give you a chance to stop it before it repeats.

What version of OpenCpn and what OS are you on?

I’ll re-run it again tomorrow morning and remind myself of all the details.

Thanks for looking at it.

Aedan

[rgleason]

Once again Windows breaks the mold.
Win 10 Opencpn v4.8.2
1. If you don't acknowledge you will get a message every second.
2. If you acknowledge, you will silence it for almost exactly one minute.
3. If it comes back up and you acknowledge you will again silence it for about one minute.

Note: I have identified a number of problems with plugins that apppear to be particular to Windows, such as Weather_routing_pi (released, trying to get to an updated release), Nmeaconverter_pi (beta, can't run in MSVC debug, won't compile debug in standalone), Deviation_pi (alpha, similar problems), squiddio (Pavel helped with this and decided it must be deferred). The answer always seems to be "works for me" and it is Linux.

I am losing hope of having a complete set of v4.8.2 plugns that are solid and ready to be "archived", because there are no volunteer windows programmers that I know of, and it seems to fall on Nohal, which is not the most effective use of his available time. (Oh why is Window so picky, picky?)


Please see screenshots attached. Now I have hundreds of them because I didn't hit acknowledge while writing this.

[AedanC]

Thanks for reproducing it. It happened for me on a Pi 3 as well so this is not just windows. After about 30-40 mins Openplotter becomes unusable as it gets very slow. Presumably because it’s busy adding in all the new waypoints.

[nohal]

OK, started a Windows VM, played just the first few messages, did not acknowledge the AIS alarm, can not reproduce. What am I doing wrong?

Pavel

[rgleason]

Oh Pavel, I am sorry. you are incredible. What is the version of windows for the vm?
Maybe that is what is happening. I believe we are both using Win10, otherwise I don' t have a clue!
Win 10 pro version build 1709
PS: I've been noticiing some other weird things with 1709, like read-only issues with Weather-routing_pi Edit Polar -Dim Tab. It won't save and causes an Opencpn crash. Yet the Grid Tab does not. Weird. We had these problems before, but these were not saved into the User files as they are now...

[nohal]

Rick...
Yes, it is Windows 10, up to date today. It is also Linux and it is also macOS. But, please, try to concentrate on what we are talking about here - how should I reproduce the problem discussed in this thread, not your 150 other problems, preferably using the data sample provided in this thread?

Pavel

[rgleason]

Ok,Pavel

I will try to focus on this problem. I have a SART icon somewhere in England, with many many Alerts. How did I get here:
1. I played the VDR
2. I entered the MMSI into the Options > Ship > MMSI as as MOB/Sart

If I did not Acknowledge the SART Alert, I got an alert every second.
If I did Acknowledge the SART Alert, I got an alert evey minute. Then I missed one and got one every second!

Sounds rational, except that is not what is supposed to happen.
What is supposed to happen? Seriously. What happens in LInux? I think that is the intent. I know that we are not supposed to get so many alerts, particularly if acknowledged.


From the manual https://opencpn.org/wiki/dokuwiki/do...ons:ais:sart&s[]=sart

Alert is Acknowledged Once the alert is Acknowledged, the target behaves as any other AIS target. In the picture below the cursor is over the target. The SART target will persist on screen for 18 minutes after the last transmission irrespective of other settings for AIS. SART alerts always have priority over DSC and CPA alerts.

What does the Code tell us?

1. Is there a If Win then ... which is different?
2. If not, is there some byzantine statement that MSV++ chooses to interpret differently to what is supposed to the happen?

I am sorry but this is the best I can do. I can't explain why your's works, except

Is there some OpenCPN setting that I have forgotten that should be set for it to run properly?

[rgleason]

As infuriationg as it may sound, maybe we need additional documentation?
IE:
Windows: This happens.
Linux: This happens.

Seems rather arbitrary, and considering the significant skills and standards of this group of programmers, that would be unsatisfactory, no doubt.


PS:If there is anything else I can help with, within my limited capactity, I am ready to assist!

[rgleason]

PS: to clear up questions, I used the data sample provided.


PSS:I could kill Microsoft for screwing up a perfectly good product, an unforgiveable arrogance!