Collision Avoidance, Cones of Uncertainty, and Appropriate CPA

[nigel1]

Just a quick word on AIS if being used for collision avoidance.
On some occasions, the AIS target can be completely misleading. On numerous occasions we have noted that AIS targets overlayed on the radar can be a few cables displaced from the actual radar target, and on one occasion we had an AIS target in the Aberdeen Harbour turning basin, and the actual ship was a mile away at the anchorage.

I have no idea what causes these discrepancies, but as with using any electronic method to ascertain if risk of collision exists, it should always be crossed checked by other means.

[Dockhead]

Originally Posted by nigel1

Just a quick word on AIS if being used for collision avoidance.
On some occasions, the AIS target can be completely misleading. On numerous occasions we have noted that AIS targets overlayed on the radar can be a few cables displaced from the actual radar target, and on one occasion we had an AIS target in the Aberdeen Harbour turning basin, and the actual ship was a mile away at the anchorage.

I have no idea what causes these discrepancies, but as with using any electronic method to ascertain if risk of collision exists, it should always be crossed checked by other means.

Indeed, and radar is a great cross check even if your ARPA/ MARPA doesn't work well as on my set. The blotch coinciding with the AIS carat means you're good.

There is a limit to accuracy of calculated data from radar, but what's really great about it is that you can directly see the target return on the screen. Take the bearing with a grain of salt on our toy radar sets, but range is very accurate and it is very unlikely that any glitch will be misstating the range to the target.

[DotDun]

Originally Posted by nigel1

Just a quick word on AIS if being used for collision avoidance.
On some occasions, the AIS target can be completely misleading. On numerous occasions we have noted that AIS targets overlayed on the radar can be a few cables displaced from the actual radar target, and on one occasion we had an AIS target in the Aberdeen Harbour turning basin, and the actual ship was a mile away at the anchorage.

I have no idea what causes these discrepancies, but as with using any electronic method to ascertain if risk of collision exists, it should always be crossed checked by other means.

One must remember that AIS data is where the vessel WAS when the last broadcast was received. Hence, one must pay attention to how long ago the broadcast was received. A good display will allow you to specific the timeout period whereby the target disappears from the screen, i.e, do you care where the vessel was 3 minutes ago?

ARPA data can age also, i.e., lose the target depending on distance and sea state. ARPA data gets more reliable and accurate the closer the target, which is when it is most important.

[transmitterdan]

Some AIS displays make a dead reckoning plot of each vessel on the screen. And all of them make a CPA calculation based on last known course and speed to project into the future where each vessel will be assuming they stay on course and hold speed.

I think it would be wrong to have the AIS display set to delete targets where the data is only 3 minutes old. Three minutes old is better information than pretending it never existed at all. Most displays can set a timeout to delete vessels that have gone out of range. Some change the color or size based on the time since last update. Typically I think the delete timeout should be set to 30 minutes or thereabouts.

[DotDun]

Originally Posted by transmitterdan

Some AIS displays make a dead reckoning plot of each vessel on the screen. And all of them make a CPA calculation based on last known course and speed to project into the future where each vessel will be assuming they stay on course and hold speed.

I think it would be wrong to have the AIS display set to delete targets where the data is only 3 minutes old. Three minutes old is better information than pretending it never existed at all. Most displays can set a timeout to delete vessels that have gone out of range. Some change the color or size based on the time since last update. Typically I think the delete timeout should be set to 30 minutes or thereabouts.

My comment was in response to Nigel stating his AIS display was showing a vessel a mile from where it actually was. That’s not helpful for navigation.

[nigel1]

In the cases I mentioned, the one in Aberdeen harbour was showing as stationary, with the actual vessel a mile away at anchor. On the ones where the AIS target was offset from the radar target, the AIS was showing to one side of the radar target, not astern of it which could then be attributed to a time lag, but for most Class A installations on a ship underway, the update rate is 10 seconds which would at worst put the AIS target very close to the radar target, not cables away.

As I said, I have no idea what the cause of this is, but it is a bit worrisome.

[Kelkara]

Is there a risk of datum errors using AIS, for example if the GPS feeding the AIS transmitter was using WGS84, but the chartplotter attached to the AIS receiver was set to NAD27 ... is the AIS system robust enough to correct for this? or will the target appear offset by the datum error?

[DotDun]

Originally Posted by Kelkara

Is there a risk of datum errors using AIS, for example if the GPS feeding the AIS transmitter was using WGS84, but the chartplotter attached to the AIS receiver was set to NAD27 ... is the AIS system robust enough to correct for this? or will the target appear offset by the datum error?

Hmm...there is no map used in the AIS system, it’s simply transmitting geo-frame coordinates derived from a GNSS system. IIRC, datum only matters when you plot the coordinate on a map.

[transmitterdan]

Datum does matter. The Coordinates transmitted are relative to a datum. AIS uses WGS84.

[TeddyDiver]

But the wrong datum would make all AIS targets misplaced, not just one or two on occasions. Such incident's are scary if they happened wrong time. Thus AIS information should be used only as additional information AFTER other reliable ones as radar and sight..

Teddy

[DotDun]

Originally Posted by TeddyDiver

But the wrong datum would make all AIS targets misplaced, not just one or two on occasions. Such incident's are scary if they happened wrong time. Thus AIS information should be used only as additional information AFTER other reliable ones as radar and sight..

Teddy

The GPS system (not AIS) uses WGS84. If you are using a different datum on your plotter, it will convert the raw GPS data to whatever datum you choose. I see no reason why your plotter would place your position with one datum and the AIS target with a different datum. It makes no sense.

[StuM]

Originally Posted by DotDun

The GPS system (not AIS) uses WGS84. If you are using a different datum on your plotter, it will convert the raw GPS data to whatever datum you choose. I see no reason why your plotter would place your position with one datum and the AIS target with a different datum. It makes no sense.

Assuming that the plotter is accepting NMEA sentences from the AIS, AFAIK, there is
no indication of what datum the position information is based on.

I don't see how the plotter can "convert" the position.

[DotDun]

Originally Posted by StuM

Assuming that the plotter is accepting NMEA sentences from the AIS, AFAIK, there is
no indication of what datum the position information is based on.

I don't see how the plotter can "convert" the position.

NMEA 0183 has a DTM sentence. Garmin, Magellan, Sony, etc. have a proprietary sentences to convey datum, but they caution people to not change the datum if mixing manufacturers. I don’t have any NMEA2K decodes to look right now, hence I don’t know if they replicated DTM in N2k. Also, by default, the GPS uses WGS84 (GPS is a global 3D algorithm, it would be hard to use a NAD). I doubt an AIS unit’s internal GPS is programmable such that you can change the datum output by the GPS to something other than WGS84. Hence, I would like to believe that all AIS data is WGS84.

So my point is that unless declared otherwise by the DTM (or equivalent N2k) sentence, the plotter assumes WGS84. If your charts are based on a different datum, the plotter has no choice but to do the math and convert (or display the wrong position on the map). I see no reason why the plotter would convert your position to another datum and not the AIS target position.

Or, what am I missing?

[Kelkara]

Originally Posted by DotDun

The GPS system (not AIS) uses WGS84. If you are using a different datum on your plotter, it will convert the raw GPS data to whatever datum you choose. I see no reason why your plotter would place your position with one datum and the AIS target with a different datum. It makes no sense.

Although it would appear it has happened in the past:
https://www.nautinst.org/en/forums/a...cfm/probadvice
But it doesn't sound like a common problem.

What I've been able to glean from google: AIS is _supposed_ to broadcast WGS84 coordinates ... so a plotter should know to convert to the local datum. However unlike class B, class A AIS equipment can accept coordinates from an external GPS, and if that GPS is set to a different datum, the AIS will broadcast coordinates with the incorrect datum. It is supposed to trigger an alarm when when the DTM sentence isn't WGS84, so that the crew can correct it or switch to a different GPS source, but apparently some older equipment didn't have this alarm.

So my current understanding of my original question is that (without software bugs) to get a datum error on AIS, it would take the unlikely scenario of a target ship not using WGS84 on their plotter, and having the AIS datum alarm fail.

continuing this train of thought ... will a class B receive-only AIS getting it's own-boat GPS coordinates from an external source trigger an alarm if the DTM is not WGS84, or is the software smart enough to look at the datum and back-convert to WGS84 to perform the CPA calculations?

[transmitterdan]

Class B does not allow external GPS input. It must be integrated with the receiver.