New Respect for Navico 4G Radar

[tanglewood]

Arpa very much depends on an accurate heading input. Otherwise you can’t distinguish between a change in your heading as you slosh around in the sea, and a relative bearing change to the target. The fact that nobody’s arpa will work without a compass is confirmation of this.

True vs magnetic heading doesn’t matter.

The fundamentals of arpa is always relative bearing to target. Remember the first rule you learned about collision avoidance? Constant bearing, closing distance? That’s all that arpa is doing.

[Pelagic]

My understanding is that the Radar's processor is still doing the computation for MARPA and OpenCPN is simply displaying that Data as they do information from other instruments.

I think ground stabilizing own vessel with GPS to get precise movement over ground which also averages out the bearing variation, is more helpful to MARPA than compass input.

[Paul L]

Originally Posted by Dockhead

OK, so you mean it's used to stabilize the relative bearing? How? I would be interested to know the exact algorithm involved -- it's interesting.


Edit: Sorry, brain fart. Of course we reduce relative bearings to true in a classic radar plot. That way minor changes of our course don't create the appearance of a changing bearing when it's still a collision course.


But I don't see any reason why ARPA needs to work that way. It can instantaneously calculate a more accurate plot using relative, not true bearings, and our instantaneous COG and SOG. This takes the compass out of the equation and should be much more accurate on a small vessel lacking a $50,000 gyrocompass.



Interesting question -- how does ARPA do it? True bearings, or relative?


If true, then maybe a small boat MARPA could be developed doing it the other way, and maybe it would work much better.


I note that Furuno ARPA for some reason works 100x better than anyone else's MARPA, and not just the ARPA features. Maybe they have a different computational approach?


How is it done in OpenCPN?

You can't use the COG SOG to remove the radars heading change vs the relative bearing changes to the target. You have to differentiate the targets change from the radars change, to end up with what the target is actually doing. A small yaw of the radar will cause a huge change in relative bearing on a target a mile away. COG is not quick enough and it does not indicate the radars twist.

Yes, the Fruno ARPA works well. Its not going to be as good and stable as a 1,000 foot freighter, but it is pretty darn useful. Mind uses a flux gate compass,
PG700 https://www.furuno.com/en/products/compass/PG-700. I'm sure it would work even better with a sattelite compass, at some significant added cost.
We just did a two night crossing with hundreds of fishing boats densely packed together. We used the Radars ARPA dozens of time per watch to sort our way through.

[a64pilot]

I don’t know how, but my old Garmin GMR 18 Radar with my 740s Plotter did it and Radar overlay without a heading source, which my B&G requires.
There were only two components in that system and in that it blew my B&G out of the water as it has to have several.
Maybe the Garmin Radar has a heading source internal? Which would make the most sense as there couldn’t be an installation or calibration error if it’s built into the Radar.

[Dockhead]

Originally Posted by Paul L

You can't use the COG SOG to remove the radars heading change vs the relative bearing changes to the target. You have to differentiate the targets change from the radars change, to end up with what the target is actually doing. A small yaw of the radar will cause a huge change in relative bearing on a target a mile away. COG is not quick enough and it does not indicate the radars twist.

OK, I guess I get this now.


I was thinking about how the EBL works, but now I realize that the EBL works only if we are on a constant heading (with the radar in unstabilized mode).



Maybe that's why the pros tend to use the radar in North-up, stabilized mode, rather than head-up the way most of us use it. If you have a good heading source then the EBL (and parallel indexing) will work no matter what kind of heading variations you have.


Another reason to replace my failing H2183 with a satellite compass I guess.

[Pelagic]

Originally Posted by Dockhead

Maybe that's why the pros tend to use the radar in North-up, stabilized mode, rather than head-up the way most of us use it. If you have a good heading source then the EBL (and parallel indexing) will work no matter what kind of heading variations you have.
.

Exactly!,
1 This way you avoid presentation discrepancies between the watches and watckeepers.
2 Situational awareness is maintained with the chart and weather reports
3 North up.provides built in topographical transit points to check your heading sensors underway.

So much so is this the professional standard that many companies have standing order that deck officers must use this presentation.

The exception being to switch to True Motion when transiting within a constrained channel with current or with multilateral consideration where you need to focus on frequent/anticipated course changes by the other targets

[kokajambo]

Originally Posted by NahanniV

...
The most accurate way to get correct bearings is to supply the 4G directly with heading data, depends what interface box you have. When the 4G dome has heading data it attaches it to each spoke as it is received.

Could you please share a bit more context on this one? Specifically, what do you mean by "attaches to each spoke"? Does 4G compensate the bearing value for the heading angles, or somehow adds it as metadata for opencpn/plotter to do the correction?

If it's the first option, I'm wondering if it may lead to overcorrection if both radar and plotter receive the same heading data and do same corrections.

If it's the second option, I'm not sure what is the benefit of the plotter getting heading data via the radar vs directly from the network/heading sensor.

[NahanniV]

Originally Posted by kokajambo

Could you please share a bit more context on this one? Specifically, what do you mean by "attaches to each spoke"? Does 4G compensate the bearing value for the heading angles, or somehow adds it as metadata for opencpn/plotter to do the correction?

If it's the first option, I'm wondering if it may lead to overcorrection if both radar and plotter receive the same heading data and do same corrections.

If it's the second option, I'm not sure what is the benefit of the plotter getting heading data via the radar vs directly from the network/heading sensor.

I don’t know the details you are looking for.

But my understanding is that when the 4G RADAR dome is supplied with heading data it adds it to the data for each RADAR spoke at the instant it is received before sending it out on Ethernet.

If you are able, you could examine the code for the plugin to see exactly what is being done.

Or, maybe one of the developers might explain it.