OpenCPN
Teleported positions
Describe the bug I have had an another weird passage where our ship is frequently teleported to some distant place and back. This is always accompanied by an AIS proximity warning. See the yellow track.
To try and get round another problem with loss of position (will report in separate issue) I had increased the Watch Dog timeout to 30 seconds. Examining the notifications, you can see there were 17 position priority shifts to use AIVDO.
The problem is that it was getting the position of some other AIS target - not us. Each of the teleports was to an AIS target.
My priority settings are
I have my MMSI number entered in the settings Own Ship. In the MMSI Properties tab I have my own MMSI set to ‘ignore’
It seems that when OCPN falls back on AIVDO, it is using the position from some random target rather than own ship.
To Reproduce Steps to reproduce the behavior:
- Interrupt the normal receipt of a fix so falls back onto !AIVDO
- Or raise priority of AVDO
Expected behavior It should use own ship's position, not some other ship!
Desktop (please complete the following information if applicable):
- OS: MacOS 15.5
- OCPN v5.12.0
A AIVDO from another ship is some kind of a device error. It should not happen. (I've once seen it from a Norwegian TCP server though) In your case I'd suggest a input filter to not receive AIVDO.
Curious, what brand/model of AIS? Is it connected via NMEA 2000? Can you capture the NMEA2000 log from your Actisense device?
My setup: Garmin AIS600 -> N2K -> Actisense W2K-1 -> NMEA0183 -> OpenCPN
I cannot read the N2K-1 log as I do not have Windows.
I have just decoded a !AIVDO sentence and it is not from my (UK) MMSI but a Netherlands MMSI (I am in the Netherlands).
I suspect the W2K-1 and will raise this with Actisense.
Had a sneaking suspicion.
The "Garmin Anomaly".
Unfortunately the Garmin AIS sets the 4 bits that indicate the type of AIS transmission to all 1's meaning data not available.
The Actisense device similar to how the TwoCan plugin behaved until I issued a fix last year, interprets this as an ownship message and converts to an AIVDO message.
Four potential fixes.
- Garmin issues a firmware update and correctly sets the transmission type value.
- Actisense issues a firmware fix to correctly 'misinterpret' the transmission type.
- OpenCPN issues a fix to decode a AIVDO sentence and if the MMSI doesn't match your own, parse it as a AIVDM sentence.
- As Hakan suggested, set an OpenCPN filter to ignore AIVDO sentences, although that means you lose a backup source for position fixes.
Option 1 would be preferred because your problem is fundamentally caused by a Garmin bug. The AIS 600 does know what type of AIS transmission it received and should set the NMEA 2000 transmission type value correctly.
Very helpful, @TwoCanPlugIn
Re (1), my Garmin AIS600 has not been updated since purchased in 2000. After this season, I intend to update all my Garmin devices. If the updated AIS600 still has this problem, I will raise with Garmin at the Southampton Boat Show.
It would be sensible for OpenCPN to implement (3) anyway, as a fix from Garmin is not guaranteed and will likely take ages if ever.
Meanwhile, I have set to ignore AIVDO (4).
Please leave this issue up. I propose to implement (3), or something like it, for OCPN v5.14.
