Fatal Flaw in Standard Horizon Matrix AIS.

[fxykty]

My Axiom+ also displays the crossing geometries of AIS targets, with increasingly bold displays of too close crossing tracks. That’s on a waterproof cockpit display which is much more useful in our cockpit than the laptop running OpenCPN at the nav station and not visible from my helm position.

Maybe it’s just me, but I find OpenCPN too prone to freeze or crash (on a Windows computer) and the Raspberry Pi just too finicky (I did IT for my day job - I don’t want to do it for my leisure time also) to consider using OpenCPN as my primary piloting tool. For planning, fill my boots, but not for live events.

MBTILES have been a game changer however and I’m truly grateful to the developer. That’s worth bringing the laptop outside for.

[Dockhead]

Originally Posted by fxykty

My Axiom+ also displays the crossing geometries of AIS targets, with increasingly bold displays of too close crossing tracks. That’s on a waterproof cockpit display which is much more useful in our cockpit than the laptop running OpenCPN at the nav station and not visible from my helm position.

Maybe it’s just me, but I find OpenCPN too prone to freeze or crash (on a Windows computer) and the Raspberry Pi just too finicky (I did IT for my day job - I don’t want to do it for my leisure time also) to consider using OpenCPN as my primary piloting tool. For planning, fill my boots, but not for live events.

MBTILES have been a game changer however and I’m truly grateful to the developer. That’s worth bringing the laptop outside for.

That's great to hear that some of the MFD makers are catching up with OpenCPN.


OpenCPN doesn't run all that well on a Raspberry Pi in my experience. It needs a fair amount of power and a fair amount of memory.


I'm getting really good results now with a Win 11 minicomputer based on one of the new 10nm Jasper Lake chipsets and sold as "Pentium Silver". I have 6BG of RAM, and an SSD drive, and OpenCPN runs very well on this. This is one of the ultra low voltage Atom family processors so uses extremely little power (like 6W) and doesn't need a fan.


I'm sure it would run even much better on Linux.


I still wouldn't use it for primary navigation, however. It's still consumer electronics. I use standard MFDs (B&G Zeus) with up to date charts for that.

[donradcliffe]

The SH matrix has a built in GPS. It sometimes takes a minute or two to find position when it is turned on/ The COG and SOG jump around too much (pet peeve), but I have never seen them wildly off (unlike Navionics on my Android phone, which has shown me going backwards out the Golden Gate at 8 knots).

I am not sure where OpenCPN gets its GPS data, but I presume it is coming from the AIS transponder. I'll have to ask the owner.

I will contact SH when I get the details on model and serial#, purchase date, etc.

I disagree with Dockhead on waiting until you are an hour out to deal with collision situations. I usually make my course changes early, when I can see the ship's Class A signal and they don't see my Class B signal. When they do pick me up, I am either going behind them with a CPA of 2 miles or ahead of them with a CPA of over 3 miles, and they can happily stand on. In one of the incidents we were crossing a shipping route and there were 5 targets besides us. I have to monitor the plot to make sure that they are not changing course to avoid each other and hitting us.

To its credit, the SH matrix did eventually alarm on both incidents (I set CPA of less than 2 miles and TCPA less than 40 miutes). Its a nice loud alarm, but I can't just push one ACK button to shut it up. My main complaint is the WTF moments I have to resolve when it gives me wrong CPAs.

Having used Open CPN as my primary chartplotter for over half of a circumnavigation, I am far more comfortable with it than say a Raymarine MFD. I really like its ability to easily select and compare multiple charts, and its superior AIS, and its ability to select averaging times on COG and SOG. On this delivery it ran for 18 straight days on a Windows computer without ever locking up.

[goboatingnow]

Originally Posted by donradcliffe

The SH matrix has a built in GPS. It sometimes takes a minute or two to find position when it is turned on/ The COG and SOG jump around too much (pet peeve), but I have never seen them wildly off (unlike Navionics on my Android phone, which has shown me going backwards out the Golden Gate at 8 knots).

I am not sure where OpenCPN gets its GPS data, but I presume it is coming from the AIS transponder. I'll have to ask the owner.

I will contact SH when I get the details on model and serial#, purchase date, etc.

I disagree with Dockhead on waiting until you are an hour out to deal with collision situations. I usually make my course changes early, when I can see the ship's Class A signal and they don't see my Class B signal. When they do pick me up, I am either going behind them with a CPA of 2 miles or ahead of them with a CPA of over 3 miles, and they can happily stand on. In one of the incidents we were crossing a shipping route and there were 5 targets besides us. I have to monitor the plot to make sure that they are not changing course to avoid each other and hitting us.

To its credit, the SH matrix did eventually alarm on both incidents (I set CPA of less than 2 miles and TCPA less than 40 miutes). Its a nice loud alarm, but I can't just push one ACK button to shut it up. My main complaint is the WTF moments I have to resolve when it gives me wrong CPAs.

Having used Open CPN as my primary chartplotter for over half of a circumnavigation, I am far more comfortable with it than say a Raymarine MFD. I really like its ability to easily select and compare multiple charts, and its superior AIS, and its ability to select averaging times on COG and SOG. On this delivery it ran for 18 straight days on a Windows computer without ever locking up.

In general under the latest specs AIS can’t export GPS positions to other equipment.

I use SH radio equipment exclusively , I’d believe it before anything else personally

[goboatingnow]

Originally Posted by donradcliffe

Compare the two attached pictures, one from the Standard Horizon Matrix VHF and one from OpenCpn. Note that the VHF display shows a healthy CPA equal to the range of the other vessel. Note that the OpenCPN display shows a very unhealthy CPA of 0.12 miles from a vessel whose length is about 0.12 miles.

If you depended on the Standard Horizon, you could be dead.

I do have similar pictures for another vessel.

You really can’t compare these as you need ships heading comparison to ensure both receivers are dealing with the same info.

[goboatingnow]

Originally Posted by donradcliffe

The SH matrix has a built in GPS. It sometimes takes a minute or two to find position when it is turned on/ The COG and SOG jump around too much (pet peeve), but I have never seen them wildly off (unlike Navionics on my Android phone, which has shown me going backwards out the Golden Gate at 8 knots).

I am not sure where OpenCPN gets its GPS data, but I presume it is coming from the AIS transponder. I'll have to ask the owner.

I will contact SH when I get the details on model and serial#, purchase date, etc.

I disagree with Dockhead on waiting until you are an hour out to deal with collision situations. I usually make my course changes early, when I can see the ship's Class A signal and they don't see my Class B signal. When they do pick me up, I am either going behind them with a CPA of 2 miles or ahead of them with a CPA of over 3 miles, and they can happily stand on. In one of the incidents we were crossing a shipping route and there were 5 targets besides us. I have to monitor the plot to make sure that they are not changing course to avoid each other and hitting us.

To its credit, the SH matrix did eventually alarm on both incidents (I set CPA of less than 2 miles and TCPA less than 40 miutes). Its a nice loud alarm, but I can't just push one ACK button to shut it up. My main complaint is the WTF moments I have to resolve when it gives me wrong CPAs.

Having used Open CPN as my primary chartplotter for over half of a circumnavigation, I am far more comfortable with it than say a Raymarine MFD. I really like its ability to easily select and compare multiple charts, and its superior AIS, and its ability to select averaging times on COG and SOG. On this delivery it ran for 18 straight days on a Windows computer without ever locking up.

My raymarine with its AIS 700 SOTDMA system is excellent and interfaces really easily over nmea2000 with my axiom mfd. excellent pictorial area of concern calculations CPA etc are presented. Well better then opencpn in my view.

I can then hit the target and trigger a DSC vhf call from the mfd

[requiem]

Originally Posted by donradcliffe

I disagree with Dockhead on waiting until you are an hour out to deal with collision situations. I usually make my course changes early, when I can see the ship's Class A signal and they don't see my Class B signal. When they do pick me up, I am either going behind them with a CPA of 2 miles or ahead of them with a CPA of over 3 miles, and they can happily stand on. In one of the incidents we were crossing a shipping route and there were 5 targets besides us. I have to monitor the plot to make sure that they are not changing course to avoid each other and hitting us.

If it's an hour or more out, I would consider everyone free to maneuver as they will. If part of that is to head off stickier situations in the future, more power to you!

Running a few example plots, with a two hour TCPA and a crossing situation I can see how small variations in course and speed affect CPA. Variations of 1-2° can easily change CPA by 1-2 miles. By changing own-ship speed from 6 to 6.5 knots I can add about 1 mile to the CPA.

With the other thread about changing navigational habits in mind, here is a good example where taking potential error into account is beneficial. There's little benefit to trying to finesse a 2 mile CPA so far out that instrument error could negate it. Swing it open to 10 miles, on the other hand....

[Dockhead]

Originally Posted by donradcliffe

. .. I disagree with Dockhead on waiting until you are an hour out to deal with collision situations. I usually make my course changes early, when I can see the ship's Class A signal and they don't see my Class B signal. When they do pick me up, I am either going behind them with a CPA of 2 miles or ahead of them with a CPA of over 3 miles, and they can happily stand on. In one of the incidents we were crossing a shipping route and there were 5 targets besides us. I have to monitor the plot to make sure that they are not changing course to avoid each other and hitting us.. . ..

I have nothing against that approach.

Just that when you are fully 2 hours apart from each other, it is very hard to know what the CPA will be when you get closer. A lot can happen in two hours (including a complete change of course or speed by the ship), and in any case, your instruments can't predict the inevitable small changes of speed and course which will happen over that period.

But if you see something like a 0 CPA which is consistent for some time, and you have room, why not? It's undeniably good practice to prevent a risk of collision from every arising, if you can do so. If you get it wrong, you still have plenty of time to correct.


And this of course:

Originally Posted by requiem

. . . With the other thread about changing navigational habits in mind, here is a good example where taking potential error into account is beneficial. There's little benefit to trying to finesse a 2 mile CPA so far out that instrument error could negate it. Swing it open to 10 miles, on the other hand....

[s/v Jedi]

These kind of readings always point to a problem with a heading or GPS sensor. When those are proven to be good (log their 10Hz data stream and check variation from the averages) then something must be wrong with smoothing, averaging routines in software, but I really expect all of that to be worked out by now… but maybe the equipment has old software installed?

About which AIS data to use: professional use it is different per shipping or cruise line but all of them only act on data that meets two criteria: distance and time to point of closest approach. For time most use 30 minutes and for distance 1nm while I observed cruise ships keeping 1.7nm and freighters keeping 0.5nm.

So yes, the further away they are, the less precise data is, but by far the biggest factor is the quality of your own sensors.

All AIS transponders that I have had my hands on export their GPS data over NMEA.

[Dockhead]

Originally Posted by s/v Jedi

These kind of readings always point to a problem with a heading or GPS sensor. When those are proven to be good (log their 10Hz data stream and check variation from the averages) then something must be wrong with smoothing, averaging routines in software, but I really expect all of that to be worked out by now… but maybe the equipment has old software installed?

About which AIS data to use: professional use it is different per shipping or cruise line but all of them only act on data that meets two criteria: distance and time to point of closest approach. For time most use 30 minutes and for distance 1nm while I observed cruise ships keeping 1.7nm and freighters keeping 0.5nm.

So yes, the further away they are, the less precise data is, but by far the biggest factor is the quality of your own sensors.

All AIS transponders that I have had my hands on export their GPS data over NMEA.

Heading is not used in CPA/TCPA calculations and is not used for anything in a Class B AIS set.

But yes -- if the OP is seeing consistent differences between his two units, it could be a problem like what you describe.

Remember also that proper AIS sets are required by the standards to use their own GNSS data, not from the network. So another possible explanation for any deviation, and more likely explanation, is that the SH unit is using its own GNSS data and OpenCPN is using the network data, and the OP has an old GPS with low update rate and/or large position error. That could give significant differences in CPA/TCPA calculations, especially so far out where very small differences have large effects. This would be a good reason for the OP to update the network GPS to a good modern GNSS one; they are not expensive.


Apropos of nothing: The latest edition of the AIS standards prohibits AIS sets from exporting their GNSS data over the network. I have no idea why.

[goboatingnow]

Originally Posted by s/v Jedi

These kind of readings always point to a problem with a heading or GPS sensor. When those are proven to be good (log their 10Hz data stream and check variation from the averages) then something must be wrong with smoothing, averaging routines in software, but I really expect all of that to be worked out by now… but maybe the equipment has old software installed?



About which AIS data to use: professional use it is different per shipping or cruise line but all of them only act on data that meets two criteria: distance and time to point of closest approach. For time most use 30 minutes and for distance 1nm while I observed cruise ships keeping 1.7nm and freighters keeping 0.5nm.



So yes, the further away they are, the less precise data is, but by far the biggest factor is the quality of your own sensors.



All AIS transponders that I have had my hands on export their GPS data over NMEA.

The latest ITU derived specifications do not allow AIS to export GPS sentences. See for example the note in Raymarines latest AIS650 and AIS 700 manuals. ( or firmware upgrade notes ) this is especially true of the more modern NMEA2000 connected AIS units.

Some older AIS units of course have export options.

[s/v Jedi]

Originally Posted by Dockhead

Heading is not used in CPA/TCPA calculations and is not used for anything in a Class B AIS set.

But yes -- if the OP is seeing consistent differences between his two units, it could be a problem like what you describe.

Remember also that proper AIS sets are required by the standards to use their own GNSS data, not from the network. So another possible explanation for any deviation, and more likely explanation, is that the SH unit is using its own GNSS data and OpenCPN is using the network data, and the OP has an old GPS with low update rate and/or large position error. That could give significant differences in CPA/TCPA calculations, especially so far out where very small differences have large effects. This would be a good reason for the OP to update the network GPS to a good modern GNSS one; they are not expensive.

Apropos of nothing: The latest edition of the AIS standards prohibits AIS sets from exporting their GNSS data over the network. I have no idea why.

Heading and rotation is used by class A transponders. When their heading sensor (which also provides rotation data) is flaky, their AIS transmissions end up all over the place on receivers that try to plot future positions.
I have seen plenty (!!!) cargo ships broadcasting invalid AIS data. Not just old port of call etc. but also heading 0 degrees etc.

It isn’t easy to ignore data about possible future collisions even when it’s an hour into the future with a probability of that calculation being accurate at or near zero… but when you sail areas like the English Channel or Panama Canal (130 targets, 60 showing collision etc.) you get used to it quickly.

[s/v Jedi]

Originally Posted by goboatingnow

The latest ITU derived specifications do not allow AIS to export GPS sentences. See for example the note in Raymarines latest AIS650 and AIS 700 manuals. ( or firmware upgrade notes ) this is especially true of the more modern NMEA2000 connected AIS units.

Some older AIS units of course have export options.

Hmm, thinking of a reason, the only thing I can come up with is that they want to reduce bandwidth utilization on NMEA…

[tanglewood]

Just FYI, class A and B are different in their use of internal vs external GNSS data. Class B is required to use the internal source, however A is required to use the ship’s GNSS data, with internal data strictly as a backup. I don’t think it’s relevant to the issue at hand, but still worth noting.

[Dockhead]

Originally Posted by s/v Jedi

Heading and rotation is used by class A transponders. When their heading sensor (which also provides rotation data) is flaky, their AIS transmissions end up all over the place on receivers that try to plot future positions.
I have seen plenty (!!!) cargo ships broadcasting invalid AIS data. Not just old port of call etc. but also heading 0 degrees etc.

It isn’t easy to ignore data about possible future collisions even when it’s an hour into the future with a probability of that calculation being accurate at or near zero… but when you sail areas like the English Channel or Panama Canal (130 targets, 60 showing collision etc.) you get used to it quickly.

Sorry, you are mistaken here.

Heading is not indeed used in any AIS system to "plot future positions". The algorithm for determining CPA and TCPA uses COG and SOG exclusively as inputs.

HDG is transmitted by Class A sets as a separate data type, like ROT, but neither HDG nor ROT is used in any of the calculations.

Some Chinese guys a few years ago complained that AIS would work better if more data than just COG and SOG were used as inputs for the CPA and TCPA calculations. See here: https://www.researchgate.net/publica...ion_Prediction

Maybe they're right. But their suggestion has not been implemented.