MARPA on small radars, is Navico 4G especially bad?
Does Navico 4G radar (branded as Simrad, Lowrance, or B&G) have a “ridiculously broken MARPA” function? I’ve heard similar words from three different 4G owners in the last few weeks, and that’s enough to interrupt the boat show and summer testing entries I’m way behind on. I don’t have a definitive answer, however, plus I’m skeptical that Navico’s MARPA is especially bad because in my experience all small radar Mini Automatic Radar Plotting Aids are somewhat flaky for what seem like fairly obvious reasons…
Let’s start with an example I screen captured on Chesapeake Bay last May. The AIS and MARPA targets seen overlaid on the left side mark the same boat blowing by Gizmo in broad daylight. The reason the AIS target is lagging behind the radar target is a known issue with Class B transponders; they only transmit dynamic data every 30 seconds at best, while the radar blip is refreshing every 2.5 to 1.2 seconds (depending on the array’s possible 24 to 48 revolutions per minute). Very soon after this shot, the AIS target jumped to where the radar blip was as the boat steadily planed up the bay. However, the AIS reporting of 256° heading and 18.9kn speed are quite accurate, as they’re coming directly from a GPS on the target boat. Meanwhile, the 12° degree and 7.4 knot errors in the MARPA calculation are actually pretty darn good in my experience.
READERS BEWARE (added 12/6/15): It would be hard to untangle the text below, but it is to some extent based on a significantly wrong assumption. Radar bearing accuracy is independent of horizontal resolution, and isn’t particularly related to beam width. So the phenomenon of seeing two targets as one is true, but it does not have a direct effect on MARPA calculations. I learned this in the Panbo comments below, slowly and largely thanks to Peter Hayden’s tenacity. However, you’ll also see that I’m not the only one who’s often seen uncertain MARPA calculations from small radars. Why that is — and how much it varies from brand to brand (or in some cases, boat to boat) — is still in discussion. Mea culpa, Ben
MARPA calculations are really hard! The MFD involved has to compare the range and bearing of successive target returns to calculate its relative speed and heading, and then subtract out your own boat’s motion. But radars, especially small ones, are quite imprecise at range and bearing. That’s why pulse power and horizontal beam width are primary specifications always listed for radar units and always discussed in radar courses. The 5 degree beam width, typical of 18-20 inch radomes like the Simrad 4G and the Raymarine RD418HD behind the MARPA example screens above, means that the raw microwave pulses cannot discriminate detail within a 5° swath, and that swath really is a half mile wide at a 6 mile range. In other words, the individual target bearings used in MARPA calculations are quite crude.
Fifteen years ago I used the Ocean Navigator School of Seamanship illustration above to teach how large radar beam widths can even make two targets look like one, and I probably first came across the concept in Chapman’s or something similar in the early 70’s. The uncertainty of radar vision is in my boating bones, and hence I’ve never been surprised to see MARPA true heading and speed calculations jump all over the place, at least until the MFD has had a good long time to compare successive bearing and range guesstimates. By the way, the 5° beam width applied to the Raymarine 3/4 mile MARPA target above — online calculator here — indicates that the radar was trying get precise bearings on the fast 40-foot boat with a beam 400 feet wide. No wonder it got the speed so wrong, and no wonder that I’ve rarely seen small radar MARPA calculate the speed of a fixed navigation aid at 0 knots (though I’ve tried that trick with many radomes).
Radar range resolution is also an issue. While the old illustration above shows how a relatively short pulse can discriminate between two targets with a similar bearing, you can imagine how the companion diagram has a long pulse returning the targets as one solid blip. But small radars with relatively low 2-4 kW power need to use long pulses to put enough energy on target to get any return at all. The resulting range uncertainty is much harder to quantify than beam width because different radars use different pulse lengths at different ranges, but, sorry, range is not truly precise even if MARPA data windows make it seem so.
All this is why I wonder about the recent email that says in part, “I’ve searched your site for any reference to Simrad’s MARPA problem but haven’t found anything…The problem is MARPA is unstable, it often fails to display any data, or the data it does display is erroneous and doesn’t match AIS data. This isn’t a new problem, I’ve logged a call with their tech support but no fix has been made to my knowledge…Apparently Navico is too big to care.” Could it be that this 4G owner has unrealistic expectations of what small radar MARPA can do? Or maybe “the Simrad MARPA problem” really is a particular thing? Hopefully this entry will draw comments from all sorts of MARPA users, especially ones with 4G experience, and maybe from Simrad itself. (Afterall, compared to Garmin, Furuno and Raymarine/Flir, Navico is actually the smallest of the major electronics companies, I think, and surely the one with the most eggs in recreational marine.)
But how many boaters actually use the MARPA they may have? I’m obviously not a big fan myself, and when I searched Panbo for past references it turned out that I used the only MARPA titled entry mostly to discuss attractive alternatives like the True Echo Trail feature seen above emanating from a Furuno DRS2D radome. That little radar can even do full-on ARPA, the automatic radar tracking that’s usually only available on ships, but note that Furuno has removed many such advanced features from the similar DRS4W WiFi radome and even the new no-separate-power-supply DRS4DL. While the prices for these radars is much lower and the user interface much simpler, a Furuno rep at FLIBS also told me that not many recreational boaters use MARPA, ARPA, True Trails, True Motion, high RPM, and similar features, anyway. You could say they’re lazy, but I think that most modern radomes offer a lot of useful information without the extra features, especially combined with AIS and chart overlay. When a yachtsman says that MARPA is critical to safe navigation, I tend to wonder if they’ve been overly influenced by the commercial world where radar beam widths are much narrower and pulses much shorter.
In light of this 4G controversy, I do wish I’d tested MARPA more, but I did find some examples when I flipped through the hundreds of screen shots I’ve collected in recent years. Above, for instance, is Garmin MARPA working with a GMR 24 xHD radome that I’d just installed in Baltimore last fall. It’s the best performing Garmin radome I’ve tried so far, though often not quite up to what I see on the smaller but similarly priced radomes currently on Gizmo. The Marpa calculations were fairly close to what the targets were actually doing — the 24 does have a 3.7° beam width — but I took the shot to remind myself that Garmin also has a lost MARPA target alarm you can’t turn off even though almost all such targets go off screen eventually. Raymarine has already heard it directly about their annoying audible alarm, but please, manufacturers, let us users have some say in this. I’d like to reduce MARPA alarms to a simple blinking icon like lost AIS targets, and I think I’d be just as safe.
I took this shot to show that Garmin does make it fairly easy to cancel all MARPA targets at once and avoid the alarms, but also to remember that target doing 47 knots while only 800 feet away. If it were close to true I probably wouldn’t have been messing with screen captures. Again, I don’t recall ever seeing small radar MARPA calculations that didn’t get screwy at least occasionally. And the developers can’t just smooth out the results so they look more stable than the underlying range/bearing data. A real change in target heading and/or speed is what you’re hoping MARPA can tell you quickly. Besides, erratic MARPA are meaningful; the MFD is saying something like “I’m trying to figure this out, boss, but it’s hard!”
Finally, there’s another aspect of the 4G MARPA problem that I feel obliged to bring up. All three 4G owners who complained about it — one is on the Forum — referenced the Adventures of Tanglewood blog where Nordhavn owner Peter Hayden has put a lot of time and energy into documenting his bad experience with Simrad gear, MARPA in particular. He eventually tore it all off! I think that Peter may have gotten a little carried away. “The very unhappy customer” is a phenomonon fairly common in marine electronics — perhaps the dark side of how much fun it is for certain smart, accomplished men to dive deep into their boat gear — and I’ve been there myself. It’s really hard sometimes to see the forest for that one FUBAR tree.
At any rate, I think I’ve read most of Peter’s Wall of Shame and while our overall (Simrad) systems were quite different — they all are — he had specific issues that don’t jibe at all with my specific experience. I also tried to straighten out some misinformation in his NMEA rant and you can see for yourself in the comments that it was hard going, with no correction to the entry made. Which is not to say that there isn’t a lot of valuable experience laid out on the Tanglewood blog — agreed, for instance, that N2K certification is NOT a compatibility guarantee. But I need more evidence before thinking of Navico 4G MARPA as “ridiculously broken” and I’m hoping readers will weigh in.
I’ll also get another chance to check out 4G and Halo MARPA when Navico again hosts demos in the Florida Keys. Halo MARPA was first shown during the Baltimore NMEA demos, though only briefly. Looking at my photo below, I like the bread crumb trail, which should be solid information about the target’s past course and pace, and I don’t miss the target vector (an option?). Let’s talk about MARPA and other ways you use radar to avoid surprises.
I’m the ranting madman from Adventures of Tanglewood.
Just so I’m not totally dismissed, I’ll offer up that I’m certified for radar operation/watch on any commercial ship, of any size, anywhere in the world. I also have multiple engineering degrees, hold about 20 patents, and finished college math and physics before graduating high school. So I know a little bit about this stuff, even if I’m mad and lost in the forest ☺.
At the end of the day, the proof is in the pudding, and your call for user testing is well placed. You mention that you haven’t used ARPA much, so I would suggest trying out any of the Furuno 4kw dome radars for a comparison. I pick them because they are not high end commercial devices, and compete directly with the Simrad/Navico devices. I have personal experience with the NavNet3D, TZTouch, and stand-alone 1835 radars’ ARPA, and performance is night and day compared to Simrad/Navico’s 4G and 10kw open array, both of which I have owned and operated as well. All these radars are geared towards varying levels of recreational boating and compete head to head. I can’t speak to Raymarine or Garmin since I haven’t used either of their radars with ARPA.
The beam width and pulse length arguments are red herrings. If they were real issues, then Furuno’s 4kw dome radars’ ARPA (4 deg beam) would perform about the same as the 4G (5 deg beam), and would perform worse than the Simrad 10kw open array (1.2 deg beam). But they don’t. And if a narrow beam and lots of power is the key to good ARPA calculations, then the Simrad 10kw, 6’ open array should perform much better with ARPA than the Simrad 4G. But it doesn’t. ARPA performs the same on both. For those brave among us, later on I’ll explain more about why they don’t matter.
As a little aside, I’ll just say ARPA to simplify things. The only difference between ARPA and MARPA is whether the radar can acquire targets automatically as opposed to you clicking on the target to acquire. Once acquired, there is no difference.
There are two simple tests to see how well your radar’s ARPA works.
1) Identify a target with AIS so it’s already displaying a course/speed vector. Now acquire it with ARPA. Once the target is fully acquired (takes a couple of minutes), compare the AIS and ARPA vectors. They should be very close and should track each other closely. Yes, if you are tracking a class B AIS target there will be some lag, but it’s clearly visible as the AIS target lags behind, then jumps to catch up. So just pick a Class A target for your experiments.
2) Pick a non-AIS target and acquire it with ARPA 2, 3 or 4 times (multiple locks on the same target at the same time). Compare the vectors. They should be very close to each other. Ironically, it was Navico’s radar engineering team that suggested this test to me, and it is what eventually led to them agreeing that there was a problem and to the return and refund of my equipment purchase.
I certainly agree that many boaters don’t care about ARPA, and even fewer have any real experience with it. As a result most people don’t know what to expect, so accept whatever they get. But after you have used ARPA that works well (meets or comes close to the IMO performance standards), you will know what to expect.
A few other things are worth noting about pulse length and beam width as they relate to ARPA performance. There are key misunderstandings in both your arguments.
– The pulse length determines range resolution, not accuracy. Range accuracy is what matters for ARPA, and is determined by how accurately the radar can time from the start of the pulse to the first echo return. That first echo return is the leading edge of the target and is extremely accurate. Looking at the Furuno NN3D/TZ 4kw dome radar and the 1835 dome radar, the range accuracy is 20m-25m, and is independent of pulse length. Range resolution or discrimination is the ability of the radar to tell whether there is a single target vs two targets closely spaced one behind the other on the same bearing. There has to be a gap between when the pulse passes over one target and before it passes over the next to tell that there are two targets. Otherwise they look like a single target. Regardless, the range is always to the leading edge of whatever is out there, and it is extremely accurate. That’s what matters for ARPA.
– Beam width determines bearing resolution, not bearing accuracy. Bearing accuracy is what matters for ARPA. This is very similar to pulse length, except it’s the side-to side resolution of targets rather than the distance resolution. The wider the beam, the less you can distinguish two targets that are at the same range, yet next to each other. With too wide a beam, it will still be sweeping across one target when it starts to sweep across the adjacent target, making it impossible to tell the difference between the two. The beam needs to be narrow enough to sweep completely past one target before encountering the next target to tell them apart. But what matters for ARPA is heading accuracy, not resolution. It doesn’t matter whether the radar detects one big target or two small ones that look like one big target. What matters is how accurately it can locate the echo blob regardless of its shape and size. Heck, when you plot targets manually (the same way that ARPA plots them), you mark the locations with a grease pencil and the results are still really accurate. Now, going back to the specs on the two previously mentioned Furuno radars, the heading accuracy is 1 deg, and it is independent of whether it’s a 4kw dome with a 4 deg beam width, or a 25kw open array with a 1.4 deg width.
The bottom line is that pulse length and beam width have very little effect on ARPA, and this bears out in actual product use. In practice see very little ARPA performance difference between a $2000 recreational NavNet 4kw dome, a $5000 workboat 1835 4kw dome, and a $25,000 commercial IMO FAR2xx7 12kw open array.
We already talked about AIS time lag for Class B targets. That’s to be expected and is easily anticipated. The other consideration brought up in the article is the time to acquire an accurate target. All the ARPA implementations I’ve used more or less follow the IMO guidelines that use one icon (typically a partial box) while the target is being acquired, then a different icon (typically a circle) once the target has been acquired. As mentioned in the article, the radar needs to plot a succession of echo marks to do the ARPA calculations, but it’s very clear when it’s “thinking” and when it’s acquired the target.
Oh, and ARPA calculations actually aren’t that hard. It’s basic vector math, exactly like applying set and drift to your heading and speed to figure out your COG/SOG.
I can’t speak to the general population of recreational boaters, but we use and have used MARPA extensively over the last 15 years. The really scary boats/ships/objects out there are precisely the ones that aren’t required to have or show AIS. Small fishing vessels, other recreational craft, squalls, all fit into this category. They’re more likely to behave in ways we can’t predict, and MARPA is all we’ve got.
In general, we have found that MARPA is “good enough” for collision avoidance despite its imperfections.
As a footnote, and US regs to the contrary notwithstanding, the AIS data on ship name, type, dimensions, and destination, everything not generated by GPS, are laughably unreliable, good for a chuckle on almost every watch. People buy an AIS from someone else and just plug it in on their own boat, and the Class-A guys “set it and forget it.”
Peter’s comment makes a lot of sense to me and his experience clearly shows that the problem is not tied to the 4G or Broadband radar but to “Navico” or, at least, NSS and NSO and their supported radars.
Before we all get into an endless technical discussion, dear Navico radar owners and prospective buyers, please just have a look at this set of screenshots, taken near the Danish islands of Mon and Sjaelland on this summer’s cruise:
https://panbo.com/images15/hennings-4G-marpa-screens.html
{Editor, I put all of Henning’s screen shots, captions and comments on a special page so you can them in context. It’s worth a look.}
……
My own conclusion: this MARPA function is useless and I will continue to call it ridiculously broken.
My learning from Peter’s well documented experience: this problem also shows with NSO and with a Simrad 10kw open array.
My learning from our 6000nm sabbatical cruise: of the three uses of radar, inshore navigation and approach, passing situations and weather, passing situations is the most critical for me. I did not have this view before the trip but changed my mind during one hair-raising experience where a cruise ship was bearing down on us at 15 knots (CPA 0.3nm), we were the stand on-vessel and I was absolutely unable to tell if they would pass ahead or astern. I didn’t know which way to turn for a last-minute manoeuver or whether to speed up or slow down. I called them and they agreed to change course but then they didn’t for 20 minutes.
So I am now a yachtsman saying MARPA (in fact: ARPA)is critical to safe navigation (with the possible addition “in open waters”) and no argument will make me change my mind on this.
With passing situations, it is all about motion vectors, ideally relative motion vectors (not true) because only these clearly show if a ship will be passing ahead or astern.
Interestingly Navico does offer relative motion vectors but, as can be seen from the screenshots, I don’t think I would be able to tell the difference.
On the positive side, look at this screenshot:
https://td2ec2in4mv1euwest.teamdrive.net/primespace/public/67443/4QKAA5800P91U0054Z76R92CN3JSJAHM/shot%20005.png
You can practically use the radar to find a vacant slip. A while back I heard a Furuno dealer cynically naming 4G a “parking aid”.
You don’t need radar at all to tell whether a vessel passes ahead or behind, assuming you have good AIS data. Our MFD’s don’t display the crossing geometry, but OpenCPN does.
And you don’t need ARPA/MARPA to see passing geometry on radar; in fact I think it’s dangerously overcomplicating it to do it this way. With the radar set to relative motion display, just set the EBL on the target and see which way the target is walking, and you will see instantly. Or turn on target trails, and put a straight edge on the trail. Like that, you can even see CPA.
I installed the B and G 4G radar on my Sabre 38 last year and used it extensively for several months between Rhode Island and Maine. I found that marpa worked just fine for collision avoidance in some very thick fog and generally nasty weather. Like Ben I did find at times that speed did not match AIS but did track vessels accurately enough to avoid any problems. I was able to pick up the many lobster boats down east that do not carry ais, and sometimes no reflectors plus some are still wood and can be hard to pick up especially on older units. So my experience seems to very different from the above. My whole system worked great from Chart plotter to new auto pilot. I received my first masters license from the coast guard in 1978 to give an idea of my experience and have been working as a delivery skipper for several years where I get the chance to use many different brands.
“Oh, and ARPA calculations actually aren’t that hard. It’s basic vector math, exactly like applying set and drift to your heading and speed to figure out your COG/SOG.”
Exactly, Peter (twistedtree). So if your electronics have COG/SOG, STW, and Heading, it should be easy to figure out Set and Drift, right? But I rarely see a Set and Drift calculation that corresponds closely to what I can see flowing by nearby pot buoys. I think the problem is that a small sensor error — usually in the speedo and/or compass — can result in a large Set and Drift error.
As for radar bearing accuracy, I believe that I’m talking about the raw data — 1 pass, one return — while you’re talking about what a radar can do with multiple passes and a whole lot of signal processing. It’s remarkable how good small radars have gotten at improving crude data, and Furuno is the widely acknowledged leader. You can’t just dismiss fundamental radar imprecision because your big Simrad performed MARPA worse than a small Furuno.
I do think that you have a good point about the difference between pulse resolution and the timing of a pulse return, but the vector math needs super precise range and bearing to see accurate changes from pass to pass. I don’t think I’m the only one who often sees jumpy MARPA heading and speed calcs after a target is acquired. (Is that what you mean by “imperfections”, Larry?)
Plus I believe there’s much more to MARPA calcs than simply the vector math. Check this book around page 199 for discussion of Rate Aiding and Target SWOP:
https://books.google.com/books?id=_sj8BAAAQBAJ&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false
On a somewhat lighter note, here’s “Why MARPA sucks” at SA:
http://forums.sailinganarchy.com/index.php?showtopic=60797
My experience with a Simrad 6kW four foot open array with NSE displays is similar to what Peter (twistedtree) and Hennig reported. The MARPA function was simply not reliable. Targets that I had acquired would become inactive or show incorrect vectors with sufficient regularity that I just stopped bothering with it. That left me with echo trails as the only way to assess the movements of non-AIS equipped boats.
Having come from a Furuno NavNet system that also had a 6kW four foot open array, the difference was very apparent. The Furuno ARPA worked well to acquire targets and maintained a lock on them. The vectors were good and corresponded to the AIS data and trails.
I gave up on the Simrad system too and replaced it with Furuno hardware. This was one of the factors along with the inadequate performance of the BSM-2 sonar.
Navico/Simrad should do what it takes to make a workable ARPA function for their radars.
Simple math and precision of measurements are two very different things. I agree that imprecise measurements (radar heading accuracy and compass accuracy in particular) will beget imprecise ARPA results.
To get a sense of what sort of ARPA performance is reasonable to expect, take a look at this IMO resolution from 1997 https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwi_uv3OvcLJAhWDGx4KHS5eCKQQFggdMAA&url=http%3A%2F%2Fwww.imo.org%2Fblast%2FblastData.asp%3Fdoc_id%3D9876%26filename%3DA%2520823.pdf&usg=AFQjCNEfTThbwzAhiPzQ5SQWYLqnWk91BQ&sig2=YMgF4YB7Ej-hcZA9LKN2eQ
Page 7 shows the expected accuracy of ARPA once a target is locked on. With one exception, the true course is within about 3 degrees of actual, and the speed within 1 to 1.5 kts. And this is based on 1997 technology – nearly 20 years old. I’m not saying all radars will or need to meet theses specs, but they give you an idea of what was considered reasonable and achievable back in 1997.
You are posing a bunch of theories about imprecision in measurements and how they explain what we see with Simrad/Navico radars. Let’s leave the theory aside and look at empirical results. After all, I think that’s what you are calling for.
Have you tested and compared ARPA with wide beam and narrow beam scanners to see the difference? I have (4G vs TX10s on an NSO EVO2), and there is none.
Have you tested and compared ARPA with a good precision rate compass vs a very high precision satellite compass? I have (RC42 vs HS70), and there is none.
Have you tested and compared ARPA with a good precision GPS vs a very high precision satellite compass GPS? I have (GS15 vs HS70), and there is none.
Have you compared ARPA performance between a best case (using your criteria of beam width and instrument precision) Simrad/Navico radar setup (Tx10 6′ open array with HS70 sat compass) vs a worst-case Furuno radar setup (DRS4D scanner, Airmar GPS, and RC42 rate compass)? I have, and the Furuno ARPA works like a charm where the Simrad/Navico does not.
But let’s get back to the basic question. When someone says that “MARPA is broken in product X”, you have to ask, “compared to what?” Had I not come from a Furuno radar, I too probably would have thought the Simrad/Navico radar was as good as could be expected. And I’d probably be making the same excuses around measurement precision. But in comparison it stands out as quite poor. Just for kicks, I asked my radar instructor to look at a video of the Simrad ARPA in action. His reaction? “Wow, that’s messed up”.
One thing I don’t know is whether Furuno stands out as superior to all the other recreational offerings (Garmin, Simrad/Navico, Raymarine), or if Simrad/Navico stands out as poor compared to all the other brands. This is because I have no data or experience on Ray or Garmin. Perhaps this exercise will flush that out.
Oh, and Rate Aiding has nothing to do with ARPA calculation precision. It has to do with picking out the target blip on the radar image. As the paper says, it aids with three things:
1) Reduced likelyhood of target swap (lock moving from the boat to a buoy as the boat passes by, or the target jumping from one boat to another as they pass close to each other.
2) Improved ability to track target through rain and sea clutter.
3) An ability to continue tracking when a target is intermittent.
How do ARPA calculations remain precise if those last three issues are not properly dealt with by the various sensors and algorithms involved in ARPA? And how is beam width a theory when you can see its results on most any radar screen?
It would be really interesting to know how many radars with arrays under 20 inches could pass the nearly 20 year old IMO spec for ARPA accuracy. My guess is close to none.
I find some of the tone of this thread a little distasteful.
Having read each of the referenced blogs I find MV Tanglewood in particular to be thorough, carefully written, and devoid of rant and the rather unflattering personal caricature of the ‘very unhappy customer’ that you have painted Ben.
I note Panbo has not yet had an opportunity to investigate the matter nor found a ‘definitive answer’ to the questions raised. So why disparage an expert consumer that calmly, clearly and comprehensively details his experience without fear or favor?
I would have thought that at the least Panbo should investigate why it is Simrad agreed to receive the entirety of this extensive system back for a full refund.
Is this full refund available to all very unhappy customers or was it a return/refund issued in recognition of the system not being fit for purpose?
A further question arises for me. Is Panbo the forum where consumers can raise these questions and expect assistance or at least reasonable engagement?
Is it a forum for the Marine Electronics consumer or the Marine Electronics producer?
Geez, Mike, I think this is reasonable engagement.
And I have reached out to Simrad for comment, though not until this morning after I’d posted the entry.
A full refund is not an admission of guilt. Sometimes the manufacturer would like to get clean out of a relationship as much as the customer does, and I believe I’ve heard of such cases involving every major marine electronics brand.
Please note that I admitted to having been a “very unhappy customer” myself, and I have, more than once. I might very well have been right about this or that, but in retrospect I got a bit carried away with proving my points and maybe extending negative judgements past where they deserved to go. And I think I’ve seen that sort of behavior lots of times in marine electronics, involving every brand.
At any rate, I represent who I am, a livelong boat nut with an outsized enthusiasm for electronics. But I’ve also worked in the overall marine industry for over 40 years and I have huge empathy for boat yard managers, electronics installers, manufacturers etc. Pleasing all of us customers is very hard (like MARPA 😉
Ben wrote:
“How do ARPA calculations remain precise if those last three issues are not properly dealt with by the various sensors and algorithms involved in ARPA?”
They are accounted for, but the situations covered by Rate Aiding concern complete loss of a target under a variety of adverse conditions, and such a loss would of course impact ARPA. But the ARPA issues I’m talking about are in clear calm conditions with no interfering targets, and boats on steady courses. In short, ideal conditions.
Ben also wrote:
“And how is beam width a theory when you can see its results on most any radar screen?”
You are taking my comment out of context. Of course beam width has an effect on many aspects of radar operation, just not a significant impact on ARPA – at least not to the extend observed on Simrad/Navico radars. Go back to the A/B comparison of a wide beam 4G vs a narrow beam open array, and the nill observed impact on ARPA performance on those radars. How can you blame those results on beam width?
The more you argue these hollow points when all the actual test data says the opposite, the more I agree with Mike that this feels like an attempt to discredit what I’ve written, and make excuses for Simrad/Navico.
I have a 39′ sailboat and we do a lot of running all night (to and from Bahamas and elsewhere) with lots of ship traffic and often very lumpy conditions. The Marpa on our 2007 vinage Raymarine in these conditions is all but useless. It has “stabilized” heading input from a 2012 vintage ray AP course computer with gyro.
To me, in our typical conditions, the problem is simply our boat is veering around madly, so its all but impossible to accurately measure angle.
We find commercial fishing vessles to be very well lit at night and so far have not had any issues (that we know about). Large ships offshore also are manageable as their range lights are a great way to determine if the angle between our vessels is changing. The main problem we find is with cruise ships – they are massively lit up to the point where I can seldom make out the range lights… so judging if the angle is changing is all but impossible. We don’t have AIS but are considering getting it just for this very reason.
Thanks for your response Ben.
It is your blog and you get to decide exactly what is reasonable engagement. I respect that.
I observe that in this not-investigated instance you have reached out to the Big Guy, disparaged the Small Guy, and immediately offered a defense proposition for the former.
You have openly declared your huge empathy for manufacturers so I guess that is a fair declaration of where Panbo stands.
Peter, your A/B beam width comparison may just mean that your wide beam radar is very good a MARPA processing. I can not see how beam width could not have an effect on target bearing. If a wide beam can see two boats as one, how can it get a precise bearing on just one in that same arc?
Signal processing of course is the magic — and why older radomes usually didn’t even attempt MARPA — but it’s got to be easier when you start with the more accurate bearing inherent in a narrower pulse beam.
My “hollow point” is that I have seen sometimes flaky MARPA calculations based on all four major brand 18-inch +/- radomes that I’ve tested, which suggests a common problem. The testing has been pretty casual and 4G the least for no particular reason.
But I have no idea if Simrad MARPA is significantly worse than the rest, even just at the radome level. That’s the goal, seeing the forest for the trees. I hope to collect experienced observations like Will Roger’s above, as well as yours and Henning’s.
If nothing else, your opinions on the matter and your Tanglewood blog will get probably get a much wider audience as a result of this entry, and I’m fine with that.
Robert, what you describe is typical when you have a slow heading source. For any semblance of good ARPA performance you need a 10hz so-called fast heading source. Really high end stuff uses 20hz, but I’ve gotten excellent results with 10, and thats what all the manufacturers call for.
You have described exactly what happens if you don’t have a fast heading source. Your boats heading will be sloshing around, causing variation in the target’s heading as measured by the radar. The result will be apparent movement of the target that isnt real.
Regarding beam width, what you lose is the ability to accurately measure how wide a target is. You don’t lose accuracy measuring where the target is, just it’s width. For this reason, a radar observer is instructed to use the center of the swept target. ARPA does the same thing. A wide beam radar and a narrow beam radar will both locate the target’s center at the same bearing, give or take the bearing accuracy which appears to be 1 degree in all the specs that I have checked. What might be different is the indicated width of the target given the beam width, target actual size, and distance.
Here’s another way to look at it. A small target will return a small blip, and a tanker will return a large blip. In this situation you again have a small blip and a large blip. Would you expect ARPA to work better on the small target because of the smaller size of the blip?
I am a big fan of Ben and appreciate all of the information and experiences that he makes available through the site.
Not having the technical background to enter into the debate, I do think it illustrates a phenomenon that I have observed on a variety of websites when marine electronics get discussed. There are typically a large number of variables that go into the perceptions of users about hardware. The two biggest are the installation and the level of experience and sophistication of the user.
In the case of the Simrad MARPA, there are very few possible variables because the user has no ability to change how it performs other than to select targets for tracking. So I hope that we can arrive an objective conclusion. My own experience as noted above is that it works very poorly, just as Hennig and Paul saw on their boats. By contrast, Larry seems to have found it to work well.
Peter, we may be getting into dead horse territory but please riddle me this: If your wide beam radar is seeing two targets as one big return, as you acknowledge possible, which real target do you get the accurate bearing to? Again, isn’t it likely that the 1° bearing spec is after processing numerous radar passes? And if you don’t know where the actual target is in a large blip, wouldn’t the best guess be right at the center?
Thanks, Quitsa. I agree that we live in all sorts of silos, some not obvious, but that it should be possible to determine if Simrad MARPA is significantly more screwy than others. And right now the evidence on this thread indicates it is, your testimony not least. (Readers: you can learn more about Quitsa’s electronics experience from his Furuno TZTouch 2 review: http://goo.gl/k2vEbU )
It seems like you guys are discussing two different concepts: the radar itself and MARPA target tracking and the display of that data. To dismiss the Navico radars (and by association everything they make) as “Junk” appears to be throwing the baby out with the bathwater. I have had excellent experiences with the Navico radars, both 3G and 4G, as Radar systems. But SHOWING the target on the display and TRACKING the target are two different conversations/concepts. The MARPA concern seems more likely an issue of the algorithms being performed in the MFD, not the radar, per se.
As a delivery captain, I take every opportunity I can to play with different systems from different manufacturers and varying vintages. I don’t use MARPA extensively, but over the years have learned to take most of the data with a grain of salt, regardless of manufacturer. I have seen some manufacturer’s radars show targets moving at 10 knots when the radar was in Relative motion (guess what? I was the one moving 10 knots, not the bouy!). Change it to True motion and the target data changes.
I absolutely agree that the data input to the system is vital. For years most manufacturer let you “cheat” by using COG/SOG for things like MARPA and radar overlay. Then they clamped down and said you had to have a heading sensor. Now, many seem to have slipped back to the cheater mode under the guise of the 10hz GPS. I had that discussion with Garmin engineer. I reminded him that no matter how fast it is updating, it is still COG, NOT heading! and the slower you go, the less stable COG becomes.
Similarly, a Speedo that is not calibrated or perfectly straight in the housing will tweak your numbers for anything From MARPA data to current to true wind speed.
Finally, as a CG approved instructor who teaches boaters of all levels, I can tell you that a high percentage of recreational radar users have very little idea of what they are looking at on a radar screen. And if it takes more than 2 key taps, they are not likely to find that function on their display or attempt to use it.
Which brings me back around to the “bathwater” point. I have seen the Navico systems work superbly for lots of customers/boaters and I would not dismiss the entire product line because of a single feature. Did TwistedTree throw out his entire Simrad system just because of MARPA? Admittedly, I haven’t read his blogs…
There used to be a nice little website called theradarreflectorsite.org that had terrific info about the realities of radar use based on the Radar Cross Section (RCS) of targets. Remember, often it can be the characteristics of the target and not necessarily your equipment that dictates how well a return shows, regardless of your beamwidth, etc. I tried to find the site recently but, unfortunately, it looks like it is no longer active. Too bad…
Ben wrote:
“Peter, we may be getting into dead horse territory but please riddle me this: If your wide beam radar is seeing two targets as one big return, as you acknowledge possible, which real target do you get the accurate bearing to? Again, isn’t it likely that the 1° bearing spec is after processing numerous radar passes? And if you don’t know where the actual target is in a large blip, wouldn’t the best guess be right at the center?”
We’d have to ask Furuno about any caveats on their 1 deg spec.
What I do know is that the radar training material says that bearing accuracy is determined by the rotational encoder on the scanner, i.e. the device that determines it’s rotational position. These are commonly used in machines that require accurate rotational control. Based on this, I would say that the 1 deg bearing accuracy does NOT require multiple passes, but rather is achieved with every scan.
Similarly, the radar training material says to take the center of a return when determining bearing to the target. If that target happens to be two boats that are closely spaced and hence indistinguishable, then you (ARPA or a person doing it manually) can only treat it as a single target because that’s all you see. Different movements of the two boats will throw ARPA a curve ball or two, and should the two targets separate enough to be distinguishable, then the ARPA lock will have to follow one or the other and you have one of those split conditions that we were talking about earlier. But yes, I agree you should measure bearing to the center of the echo.
But I agree we are getting off into the weeds and talking about various pathological cases that will certainly cause ARPA a burp, and that it will have to recover from.
I think it’s much easier and more illustrative to look at a few examples under ideal conditions i.e. flat water, clear view, no obstructions, and boats on steady courses. When I compare Simrad/Navico radars to various model Furuno radars, that’s what I’ve been reporting. Then you don’t have to worry about boat headings getting thrashed about, missed echo returns because of sea state, pitch and roll of your vessel, etc.
Bill, you are absolutely right that ARPA is about tracking targets, not about showing them. But of course to track them they need be visible… Ben and I definitely got off in the weeds about how accurately you can see (actually locate) a target, and it’s effect on how accurately you can track it.
As for throwing out the baby with the bath water, I have always said that I really like the architecture and design of the overall Simrad/Navico system. That’s why I bought it in the first place. The problem I had was with the number of bugs and how they impacted the use of my boat. Not everyone will encounter the same issues, nor be impacted by them in the same way, and those people can enjoy their Simrad systems as it was intended to be.
This is not the place to regurgitate the issues I encountered, so please read the blog if you want to know more. What I can say is that now, one year later, none of the most critical problem that I encountered have been fixed, and I remain extremely happy with the revised electronics setup now in my boat. And I say that despite a variety of ongoing issues and work arounds, so none of it is perfect. So no, I don’t think my actions were rash, and no, I don’t have any regrets making the changes that I did.
It seems like you’re having trouble with the riddle, Peter. And it’s not in the weeds. Your subject is MARPA comparison (which is very valid), but my main thesis up there is that all small radar MARPA calculations are very hard, mainly because of beam width bearing imprecision.
When two targets show up as one blip in a 5° wide beam, their bearings can be at least a couple of degrees different. The old diagram above illustrating that is Radar 101. It just like sonar. When you see a fish or a ledge that looks like it’s right under the boat, it may actually left or right of the boat. The sonar shows every ping that’s returned from its beam width (and the closest continuous ones will be interpreted as bottom).
Sorry, but I believe that rotational encoders, fast heading sensors, etc. only come into play as a radar improves its understanding of targets with successive passes. And a small radar not only starts with significantly less precise bearing data, but also collects less precise data on every pass.
If Furuno MARPA can reliably overcome the beam width issue, that’s great. If Navico is way behind the others, that’s news. But those are my questions, not the experience I wrote about above.
I previously had Raymarine E80 with RD418HD radar, I now have NSS12 Evo2 with 4G radar. Until installing HS60 a few weeks ago I used a Maretron SSC200 heading sensor. I have not noticed any difference in accuracy between Raymarine and Navico MARPA, the only difference in performance I’ve noticed is that Raymarine was a bit more robust when it comes to not loosing the targets, but no big difference.
A couple of corrections to what have been written earlier.
The Simrad MARPA processing is done in the radar and not the MFD. This is the reason why the radar interface needs the heading input.
Robert described his experience with Raymarine MARPA using a Raymarine 2012 autopilot with rate gyro for heading. Then twistedtree comments that this is what’s happening when not having a fast heading. A 2012 SPX autopilot is outputting 10 Hz heading.
Twistedtree and I have had our discussions at THT regarding Simrad equipment so I’m not going to get engaged in such discussions at another arena.
We are once again going in circles, so I’m just going to accept that we disagree on the importance of beam width when it comes to ARPA.
What would be productive would be to see an A/B comparison between ARPA on a wide beam and narrow beam radar from the same manufacturer that demonstrates the difference. I have reported exactly this comparison between two Simrad radars, and again between two Furuno radars. Neither demonstrates a detectable difference in ARPA performance between the different beam width scanners.
Perhaps someone can produce a counter example?
abbor, your data is very helpful. Your experience along with Robert’s says that Raymarine and Simrad ARPA performance is comparable. So it’s starting to look like Furuno is the outlier here with ARPA that works much better than everyone else. But we still need to understand where Garmin fits in.
The learned master and commander of Twistedtree may, as he wrote have, “…have multiple engineering degrees, hold about 20 patents, and finished college math and physics before graduating high school. So I know a little bit about this stuff, even if I’m mad and lost in the forest ☺.”
But he is lacking in his understanding of a common saying. He wrote:
“At the end of the day, the proof is in the pudding”. That is not correct. The saying is, “The proof of the pudding is in the eating.” Which clearly makes sense whereas the misquote doesn’t, unless he is talking about the alcohol content of a pudding!
Now, back to the heady stuff of which I am a neophyte! 🙂
Ben – first I want to thank you for the post and TwistedTree for your reply and blog. I have learned a lot from both of you.
I have a full Simrad electronic package with NSO evo2 plotter and 4G radar. In the last year, we have cruised a bit over 6,000 miles. I am not very experienced with using radar. We have gotten caught in fog several days where I had to use the radar, which has taught me to use it on clear days to figure out how to adjust it. Sometimes I use it as an overlay but most of the time I display the radar on it’s own screen.
When I tried to use MARPA, I could not make it match which I was viewing with my 20/30 eyeballs, and have stopped trying to use it. I contacted an installer to ask if a satellite GPS would improve the accuracy and was told absolutely. From what I read above, apparently I have more research to do. AIS is used at all times, but radar is often not up on one of the screens.
I’m not a very avid user of MARPA on my Lowrance 4G but I must say that the few times that I have used it it seemed to be reasonably behaved, and I certainly haven’t seen the “obviously wrong” vectors that Henning has reported. If pressed I’d say it is on about the same level as the experience that I had with my Nobeltec + 4 KW Koden radar before.
Kind of weird that some people see such obvious strange behavior (twistedtree, Henning) and others don’t see this at all.
Also I am not so sure with what Abbor claims which is that the MARPA is calculated in the radome. IMO the reason that the radar needs a heading input before the MFD is willing to do MARPA is that the radar adds the current heading to each radar spoke when it transmits it to the radar. That way any transmission delay and/or processing delay is not important as the radar spoke echo has a bearing intimately tied to it. I will check if I can find any proof of MARPA data on the Ethernet network this weekend.
Third point, twistedtree writes
> Looking at the Furuno NN3D/TZ 4kw dome radar and the 1835 dome radar, the range accuracy is 20m-25m …
With a digital radar the spokes are transferred as an array of radar return strengths at increasing distance from the boat. In the Navico case this array is 512 bytes with 8 bits per return. So its (theoreticla) range discrimination is 1/512th of the maximum range, and is not a constant. It varies from 0.1 m at 50m range to 125 m at 64 km range.
This Panbo entry has been incredibly helpful to me personally because I’m in the process of making a buying decision on radar/chartplotter for a 40’ sailboat. In addition, it confirms some serious issues I have dealing with Simrad on a new AP-28 autopilot. Since this is a discussion about radar I’ll just say that from my experience Simrad has been unresponsive to my report of a dangerous software alarm issue.
I really appreciate Ben asking Simrad for comment on the MARPA issue but I fear he also will be faced with a wall of silence. Is Simrad too big to communicate? It would be nice if they showed up here.
Thanks, Kees (and Richard). Readers may want to know that Kees has cruised from Holland to Stockholm, and out to the Azores over the last couple of seasons, which must have involved lots of traffic situations.
Readers, please also note that last night I put all of Henning’s screenshots and captions on their own page so that its much easier to understand how very bad his 4G MARPA was, at least in that particular situation. When I talk about all the flaky MARPA I’ve seen, it’s not nearly on this level:
https://panbo.com/images15/hennings-4G-marpa-screens.html
Now, Kees (or anyone), can you please explain to me how it’s possible for a radar with a 5° beam width to determine a target’s bearing with 1° accuracy on one pass?
That’s what Peter is insisting on (though he can’t seem to explain how), and if he’s right I need to adjust my understanding of fundamental pulse radar vision and make some significant corrections in the entry above.
I know the MARPA processing is done in the radar, or the radar processor for a HD, see page 17 in the Broadband 3G/4G Radar Installation Manual:
You can use a Heading Sensor with an NMEA 0183 or NMEA2000 output source You must use a Radar Interface box to connect the heading data to the radar system – this is because MARPA calculations are done by the radar.
http://www.simrad-yachting.com/Root/Installation%20Guides/SimradYachting/English/RADAR_3G_4G_IG_988-10113-003_EN_P.pdf
And due to this it doesn’t make sense to talk about Navico MARPA functionality in general, there are different implementations for each radar platform.
I know Navico is working with making MARPA for the HD radars more stable. In some cases for some installations, typically with more than one heading and/or position source, problems have been observed. So Navico is focusing much more on fixing problems reported by customers than some people think. The focus for the latest software updates for all Simrad products have been stability and performance improvements, not adding new functionality.
Jim at BOE (Yachtjim at THT) posted information regarding this at THT some time ago.
http://www.thehulltruth.com/marine-electronics-forum/693525-simrad-nss-evo2-software-release.html
I monitored my ethernet network for commands coming out of the radar when I was manipulating the MARPA targets (adding/removing them) but I could not see any such commands.
Given the puny processing power in the radome I also don’t think it makes sense to do it in there.
Does anyone know whether MARPA targets are shared over the network? In other words: if I create one on MFD #1 does it also show up on MFD #2? If the MARPA is done in the radar you’d think this was the case.
Ben wrote:
“That’s what Peter is insisting on (though he can’t seem to explain how)….”
OK, I’ve tried to explain it three times so far in the dialog above, but am clearly not doing it well.
For the sake of the example I’ll assume 4 deg beam width, and a single target that is smaller than the beam width and that provides a solid return. I’ll also assume calm conditions with good visibility and properly installed and operating equipment. Also for simplicity, I’ll assume the target begins to mark when it is exposed to any part of the beam. Is reality, beams do not have sharp edges, but rather declining power out towards the edges. So a target mark grows in strength as the beam progresses over it and becomes stronger, is max around the center of the beam, then again tapers towards the trailing edge of the beam. That’s why targets look a little like squinting eyes.
Here’s a step by step walk through:
– As the leading edge of the beam starts to hit the leading edge of the target, the echo return starts to appear. The location of this edge is known within 1 deg because the scanner knows where it’s pointing the center of the beam, and because you know the beam width. So with our 4 deg beam, the target begins to paint 2 deg (1/2 the beam width) before the beam center hits the target.
– The target continues to paint as the beam sweeps across the target.
– The target stops painting when the trailing edge of the beam passes the trailing edge of the target, and you know that occurs 2 deg after the beam center passes over the end of the target.
– The resulting echo width is the target width plus the beam width.
– Because you know the beam width and the distance to the target, you could actually calculate the width of the target if you wanted to. But I don’t think it’s necessary. Why? Because you know that the center of the target is the center of the echo return. How? Because you know that the first 2 degs was painted before the beam center, and the last 2 deg was painted after the beam center. What’s left is the actual target, in the center of the return, accurate within the positioning accuracy of the scanner.
So the center of the echo return is the center of the target, accurate to 1 deg. And if you track that target center for the sake of ARPA or anything else, it’s positions will be accurate to 1 deg.
If you walk through the above example, you can see why the radar can’t distinguish two adjacent boats from a single larger boat, and hence the primary consequence of beam width. And if you tried to track such a boat pair, either manually or with ARPA, you would be tracking the mid point between the boats, not either one of them individually. The tracking results would be misleading as best until you were able to distinguish them and track them individually.
When looking at Hennings screen shots, this is not about accuracy in the calculations. To get such erratic results some bug is obviously triggered.
Henning, do you have multiple heading and position sources in your network?
Kees: I have just checked: If I acquire a MARPA target on my B&G Zeus Touch 7 in the cockpit, the MARPA target is displayed on the Simrad NSS7 at the nav station even when the radar screen was not up at the NSS at the time the target was acquired. The targets are numbered and the numbers match between the MFDs.
abbor: For heading I only have an Airmar H2183 with which I am very pleased. Autopilot performance is much improved since I have it. I have multiple position sources (probably everyone does) but the NSS used to document my issue is configured to use a Simrad GS15 and not use its internal GPS which gives no or very poor positions as it is mounted below the breaker panel with a hundred live wires.
Please note that the target trails on my screenshots are as straight as can reasonably be expected which, I think, they wouldn’t be if heading were erratic.
I am very pleased with this discussion and how long the thread has become.
I feel with Mike at some points questioning the impartiality of Ben but I also hear Ben asking how impartial I am myself, being an unhappy customer.
I don’t think much more of my money will go in the direction of Simrad but I won’t rule it out and I certainly will not give up my Simrad AC12 autopilot. And it will be a while before I can swing a dual station Furuno 1835, though if it weren’t for the money, I would probably have an order out as I really want working ARPA (not MARPA, especially not if it drops targets faster than I can acquire them) and, at least at this time, would be willing to give up chart overlay for it.
Peter has reported (and filmed) good ARPA performance from his current Furuno system.
Do we have other reports of a really satisfying ARPA experience?
When I find time, I will provide a few more screenshots (from Coastal Explorer) from that experience with the cruise ship to show why it is so important to me.
And Kees, I was going to ask you: how was your experience with the 4G at sea from the Azores to England?
My results with the 4G and TX10s were not as bad as what Henning’s pictures show. I would see heading swinging +/- 10-20 deg off the correct course, and I’d see speed typically vary from about 1/2 to 2x the actual target speed. Sometimes it was much better, and sometimes much worse, but I’d say that was the average.
But Henning’s #3 target is way messed up – much more so than anything I ever saw. The first 4 shots of ARPA target #3 show a vessel moving more or less NW, but as the echo trail develops we see that it’s actually moving in almost the opposite direction.
Ben: A radar with a beamwidth of 5 degrees can determine a target heading to within 1 degree accuracy, by calculating the centroid of the target response. Telescopes used for astrophotography do the same thing on a guide star, allowing sub-pixel guiding accuracy. This should work quite well for a MARPA system, as long as there is only a single target within the radar target blip, as was the case with the examples given previously in which Simrad MARPA was giving poor results. You are correct that if there are two targets very close together, such that the radar cannot clearly distinguish two separate returns, then MARPA will not be able to determine an accurate heading to either target. This is an “edge case” for which I would expect all MARPA systems, regardless of brand, to give poor results. But for the “standard case” of a single target, the target response centroid should give a heading accuracy which is smaller than the radar beamwidth.
In a similar vein, even with a 10 Hz heading sensor, I would expect any brand of MARPA to struggle if the vessel is in rough seas and heading is bouncing all over the place. The latency between the MFD receiving the radar response and the heading sensor response will be high enough that the two may not correspond to the same physical heading, even if the MFD could keep up to the calculation speed. But the examples given previously were in calm conditions, and for well-behaved targets, so these should not be reasons for the observed poor accuracy of the MARPA.
I agree with your assertion that in general, enough factors could contribute to MARPA inaccuracy that a prudent skipper would always treat the results with some skepticism and caution. But the examples given which showed poor MARPA accuracy were for the best case – a few single targets at constant heading and speed, and calm conditions. Simrad MARPA should have been able to handle those examples better.
I find the MARPA function on my Furuno 1835 to be very useful for collision avoidance on targets that do not broadcast AIS. Granted it takers some time to stabilize to give useful information.
There is a history of marine electronics supplying inaccurate information, Loran for example. Loran was not accurate but it was far better than no electronic navigation. Omega was even worse for accuracy.
Sometimes I wish I had a reflection plotting head on my radar. however, the only advantage is there is no stabilization time. it does require accurate and stable heading information which my fluxgate compass does not supply.
I am a fan of MARPA even with it’s known blemishes.
Patrick Harman
In response to Hennig’s question, the ARPA acquisition and tracking on my Furuno TZT 2 displays with a 12kW 4′ open array is quite good. Generally it will only take 30-60 seconds for the vector and speed to stabilize. The Furuno NavNet 3D 6kW radar on my old boat (installed 2008) also worked very well.
The reality is that small boat radar is far from perfect–and although has become affordable, and far better short distance resolution, the MARPA function has never been excellent in small boats. It is the unstable platform of the small boat (magnified by the radar often posted half way up a mast), the wide beam width and lack of consistency of headings. (Factor in multiple axis). We cannot expect it to compare with a 700 foot ship, and a 12 foot scanner, along with the other gear aboard.
Today we are blessed to have AIS–so we should all be using it–and probably all should at least go to a B transponder, along with our radar. It is just one other form of observation, to go along with visual, and your brain!
I have about 250,000 miles under the keel, and have had to take evasive action at least a dozen times–despite visual watch, radar and best guesses–along with non responsive bridges on larger commercial vessels. (Not even to mention the pleasure boats on autopilot with no-one at the helm).
A couple of times when I had the chance, I called either nearby boats, or the Coast Guard (in US Waters), to come looking for me, if I didn’t report in XX minutes–I was that unsure that a large ship would run me down. I assumed that the ship saw my vessel, the radar reflector, and ignored the call on the VHF. I’m still alive! Some misses were by only a few feet way too close!
I consider myself one of the lucky ones, since I have personally know at least 8 people who were lost at sea in small boats–most likely by a larger faster vessel.
There are no “Safe places” at sea!
I’m very happy with Arpa/marpa on Furuno navnet 3D, 4kw radar and sc-30 satelite compass!!
This is the main functionality for a radar, and we use it all the time.
Coming from the question “is Simrad MARPA is significantly more screwy than others?”, Ben asks the valid question “and if so, does it even matter?”. To this, I would add the third question “and if yes, what to do?”
I think the answer to the third question needs a little more precision about the term MARPA and the vectors coming from it. This is laid out very well on Peter’s blog and I’ll summarize:
“ARPA” = automatic radar plotting aid: when activated, the radar will decide which targets are of interest and acquire them and then track them with a vector all by itself without any user action other than activating the ARPA function. There is a computing power limit to the number of targets that can be tracked. The radar will decide on the most interesting targets if it can’t track all interesting ones.
“MARPA” = manual or mini radar plotting aid: the user can place the cursor on a target and request this target to be acquired. The radar will look for a suitable blip in the vicinity of the cursor and, if one is found, acquire and track it. Only the targets pointed to manually by the user are acquired and tracked. If the target disappears momentarily, there is a short span after which it is reported as a lost target and no longer tracked. Since the process is manual, targets are never “reacquired”. With MARPA, it is more important than with ARPA that the radar is powerful enough to maintain a firm lock on a target (I am disappointed with my 4G in this area) and one can spend a good amount of time to try and place the cursor on targets on a moving boat, only to miss them slightly, and then issue the two or more menu commands for “acquire this”. In my case I would say that on average every successful acquire takes at least two attempts. If the radar loses a target that is still interesting and that it therefore shouldn’t have lost, the screen gets littered with lost target symbols that you need to clear. Two menu commands. There is a “clear all targets” menu command right next to the “clear lost targets” command and more than once, on a moving boat, I accidentally cleared all. So I needed to start over with all targets…
It is about here that I would expect the first comment on whether I should maybe better spend my time looking around.
This brings us back to Ben’s question “is it even a useful function and therefore matter if broken?”. I would say: only if it’s either automatic ARPA or the radar is very good at not losing targets. And the user interface also plays a role.
Then we have the question of the vectors (they are the whole and only point of ARPA/MARPA). The vectors can be “true”, meaning they point in the compass direction in which the target is moving. Targets not moving have no vector. My own boat has a vector. This sound quite logical and “right”. Or they can be “relative”. With “relative, any tracked target has a vector, even if stationary and my own boat has none and the vectors point in a different direction. This all sounds wrong at first, so why would you use this setting? I have tried this setting on my NSS but, as explained, the vector directions were just as whacky, so it really made no difference, but my understanding is as follows:
If you are moving towards a buoy and keep going, you will eventually hit it. The radar tells you this by the vector of the buoy pointing at you. This means: you will be good if you just make it so that vectors are not pointing at you. That’s really simple. More so than with true vectors.
Why is it more simple or more valuable than true vectors? I admit that in the past I wouldn’t have bought this myself.
Now I would explain as follows: Motion vectors are important to avoid collisions with big ships, not small sailboats like mine with which I am tacking up a channel. In the past my only experience was that big ships move in marked channels, in one direction or the other but along the channel. If the channel turned, so would the big ships. None of the big ships would ever attempt to give the right of way to me because they would run aground immediately. It was my job to stay clear of them, period.
But in open waters, outside of shipping lanes or traffic separation schemes, even in the middle of the English Channel, I found that ship’s tracks criss-cross surprisingly much. And suddenly, in many cases, I am the stand-on vessel, meaning I don’t just have the right of way but I have the obligation to hold course and await a change of course by the big ship.
The only (useable) vectors I have known so far are from AIS targets, in my case drawn by Costal Explorer, and they are “true”, not “relative”.
And with big ships criss-crossing around me, I quickly became uncomfortable with them and wished for “better” but not knowing what would be better.
I now believe that relative vectors solve this problem elegantly but this is theoretical. Peter’s blog shows this in detail, so please read there. And anyone with experience with relative motion vectors, please tell me about it. It is much appreciated.
Following is a description of my so far most complex passing situation. The question I am asking is: would relative vectors, either from AIS or from ARPA/MARPA have helped me and to which extent?
And don’t anyone joke that I will someday find my end being run down while taking screenshots below…
https://td2ec2in4mv1euwest.teamdrive.net/primespace/public/67443/FA1XF4000P91U0054ZRNPBC2K3JSJAKK/20131128_1.jpg
We were on passage from Portimao, Algarve, Portugal to Rabat, Morocco (Africa). We had gone in a curve to avoid stronger winds and wind seas generated by a nozzle effect of Gibraltar with winds from the east. This was at 1am in the morning with almost no wind and no wind sea, even glassy water, but the everpresent ocean swell slowly lifting us up and down like an elevator about 6 to 9 feet, but not inducing much rolling. The radar was on, but probably set at 6nm range, as it normally is, and hardly showing even the closest targets. I don’t set it higher because really the only targets it will show farther out are volcanic islands and I don’t need to be alerted of their presence.
Notice how everyone is going “their own way”, to the Canaries, around west Africa or even towards South America.
The Coastal Explorer “vessel list” on the right is not (was not) as helpful as it appears on the screenshot as the list is sorted by CPA and it re-sorts like crazy. This is because my Simrad GS15 5Hz GPS appears to not have any stabilization (averaging) and in ocean swell COG and CPA swing around wildly and so does CPA. This is so fast that even reading the CPA value of a specific target is hard and really only possible if you highlight the target of interest. And highlighting it is much like trying to catch a cockroach for those of you that have tried it.
Coastal Explorer has since received a stabilization function for sensor values like COG and SOG and this helps but does not fully solve the problem.
What I realized later is:
1. Focus on Silver Wind and forget about the others
2. Now, with 1 hour to go for Silver Wind, is the time to make changes because I have not yet become the stand-on vessel (I think; please correct me otherwise)
A relative motion vector form a radar being able to see a cruise ship at 13nm would have pointed straight at us, just a hair ahead or astern. Knowing which would have been very helpful.
https://td2ec2in4mv1euwest.teamdrive.net/primespace/public/67443/AAD38A000P91U0054ZRNPBYN73JSJAKR/20131128_2.jpg
I have zoomed in. 20 minutes of watching the screen has brought me to realize:
– Costa Serena, the unnamed triangle, is clearly not dangerous
– Merwedegracht is apparently passing astern with an OK margin (as long as my engine doesn’t suddenly develop a problem)
– but, oh, Silver Wind is the real problem and shouldn’t they change course soon?
– I can’t really make a change myself anymore as I am now the stand-on vessel (or maybe I should become more relaxed about this?)
So I made mistake no. 1 in not focusing on Silver Wind in time.
I call them on VHF 16 and get an instant response. “Silver Wind, I am the yacht on your starboard bow. Do you see me on your AIS and what are your intentions?”. They take a moment, then ask “do you agree that we pass behind your stern?” I agree, thinking “what difference does it make as long as they don’t run me over?”
That was mistake no. 2. See below for why.
https://td2ec2in4mv1euwest.teamdrive.net/primespace/public/67443/6DQM53800P91U0054ZRNPBPGA3JSJAKU/20131128_3.jpg
Silver Wind is now 22 minutes away. I had called them a good 15 minutes earlier and they agreed to change course but CPA has not changed, meaning they haven’t done what they said they would do. While I watch Merwedegracht pass by, I can see Silver Wind looking like Las Vegas on the horizon.
I realize I made a mistake allowing them to pass behind my stern (or “agreeing to” – I guess I don’t have a right to allow or disallow a specific manoeuver as long as they pass me at 0,5nm or more). Why? If they had declared intention to pass before my bow, I could have stopped and waited for them to pass. Or turned around 180 degrees. But the way it is, if I stop or turn around and they do as announced, they will run me over. And if I keep going like I am supposed to and they continue to not change course, they will run me over. And should my engine die, they will also run me over.
Learning: never again agree to pass behind my stern
https://td2ec2in4mv1euwest.teamdrive.net/primespace/public/67443/1EJ3B7800P91U0054ZRNPBT9D3JSJAY1/20131128_4.jpg
I call them again. Again, instant response. “Silver Wind, we are 15 minutes away from a collision. You have not changed course as agreed. What are your intentions?” Maybe my raised voice and mention of the word “collision” helps. He mumbles “I’m altering, I’m altering” and two very long minutes later at 12 minutes to go with sub-100ft CPA, I see CPA climbing until I finally see a comforting half mile. I also see the vector making an angle to the trail (thank you Rose Point for the trails).
https://td2ec2in4mv1euwest.teamdrive.net/primespace/public/67443/F3RHSE800P91U0054ZRNPBHQ73JSJAKZ/20131128_5.jpg
I watch Las Vegas go by fast and with very little bow and stern waves. I have to tilt my head back to see their masts (the range rings are set at 0.5nm and 1nm). They have already returned to their original course. My wife and kid have slept through all this and will only awake at sunrise when I call the guide boat to take us into Rabat where we will hear the Muezzin sing many times a day.
Note that I don’t blame Silver Wind. They did give the right of way to me and they never got closer than 1/2 mile. Even if I would blame them morally, I am pretty sure I couldn’t legally.
I do want to become more experienced and better equipped to be less stressed by this probably pretty normal passing situation.
My learnings from this regarding equipment is:
1. I want ARPA and I want relative motion vectors!
2. I want a radar that shows cruise ships at 12+nm!
I can’t say for sure that I will ever have this, nor that it even exists. But at this point I would say that a Furuno 1835 is a highly ranking contestant. I have read that it can be rigged to output a TTM sentence (“tracked target message”), which I could interface to Coastal Explorer that, from what I read, understands it and displays it with a vector.
I have also proposed on the Costal Explorer forum to sort the list of AIS targets by range and highlight targets with a settable “uncomfortably close” CPA rather than sort it by CPA.
I surrender! Peter/twistedtree’s fourth attempt, and a little more research, finally penetrated my thick noggin. Peter is right; I am wrong. I now see how bearing accuracy is independent of horizontal resolution, and isn’t particularly related to beam width. Sorry for the wasted words (and thank you Doug for unraveling the two target riddle).
I’m still left with all the twitchy MARPA calculations I’ve seen, and I don’t seem to be the only one. Maybe it’s just that small radars tend to be on less stable platforms?
I’m working on a correction to the main entry.
Excellent discussion.
I previously had an open array Raymarine, and now the 4G dome.
I only started using the Marpa function a few months ago, and I do have some concerns others are noting , but no enough experience with it to justify a comment When others who know this subject much better than me are covering it here.
I want to upgrade to Halo for various reasons, but if some of these items are not resolved, I will go with another manufacturer.
One comment I would like to make concerning the authors comments re Halo: I don’t like the breadcrumbs, and would prefer to see a vector. also, the Marpa alarms are a nuisance and need to be improved. It is distracting every time a target is lost, etc.
Again, thank you to all of the radar pros for taking the time to post. I learned a lot.
Henning, I don’t think I questioned whether MARPA “is it even a useful function.” I did wonder “how many boaters actually use the MARPA they may have?” And these comments seem to suggest that many do not. There are alternatives. Heck, I sometimes an EBL and VRM to get that sense of relative motion you desire. Done right, a touchscreen can make them pretty easy to use.
Henning, that’s a great narrative and an excellent example of a real-life situation. Now, imagine another ship on an opposing course to Silver Wind that will pass you at about the same time. Anyone who has encountered ferries making a crossing at the same time in opposite directions, something very common in the Seattle area, will appreciate it even more. Knowing whether each ship will pass ahead of you or behind you is critical to any corrective maneuvers that you or the other ships take. The last thing you want to do is adjust course to give more passing room for one ship, and end up placing yourself in danger with the other ship.
To bring the discussion back to relative motion vectors, that’s how the Silver Wind knew they were going to pass behind you, not ahead of you. At least one of their nav devices supported the feature, most likely their radar. Their relative motion vector would have shown their crossing path running behind you, and with their last course change, that line would have shown a gap of 1/2 nm, i.e. the CPA.
Here’s a screen shot that shows such a situation. At the time of the photo, I was between the two crossing ferries, one passing behind be and one passing ahead. Imagine this scene 15 minutes earlier as the two ferries got underway from each shore going 16-18 kts with all three of us crossing in the next 15 minutes. Switching to relative motion vectors showed that we would all safely pass as in the picture, and VHF contact with both ferries confirmed that we all saw and agreed to the same scenario.
http://1.bp.blogspot.com/-eDsOYv6HhS4/VSxhhpWLvAI/AAAAAAAAB24/DhbmUoyHJsk/s1600/PCH_2015-04-05_14-24_4464.jpg
No question that in-front-of or behind makes all the difference between a tolerable CPA and a sphincter-tightening one. That’s why I liked what The Cap’n was doing a decade ago with AIS (though I never got to try it at sea). It’s hard to make out, but the short dotted line dropped perpendicular from the target vector attempts to show where you both are going to be at CPA:
https://panbo.com/archives/2006/02/capn_voyager_playing_ais_chicken_over_ip.html
Interestingly, I saw a very similar graphic on a Raymarine MARPA or AIS target while fooling around one day last spring, but a few weeks later — arg! — I couldn’t figure how to implement the feature. It turned out that Ray removed it after one firmware cycle because they didn’t think it was reliable enough. They tell me that they’re still working on the concept and they some interesting AIS collision avoidance graphics to LightHouse 15:
http://www.raymarine.com/view/?id=8291
Henning: I have problems understanding what you try to communicate above.
You have the following statement: Motion vectors are important to avoid collisions with big ships, not small sailboats like mine with which I am tacking up a channel.
I then don’t understand why you even need MARPA since all these vessels have AIS. I only use MARPA for tracking small boats close to me without AIS.
The way I’ve configured my system when fishing in an trafficked area is the following. I’m using heading up orientation. I’ve set the course vectors both for my boat and other boats (AIS and MARPA) to 10 minutes, if I see the tip of a course vector close to the tip of my vector I know I have 10 minutes to get out of the way.
BTW, GS15 has 10 Hz update, it’s first generation NSS which has 5 Hz. And GS15 don’t have any averaging since this is done and is adjustable in NSS.
I’m wondering what’s wrong with your 4G installation or settings if you can’t see big ships past 6 nm.
Navico is claiming the 4G should be able to detect a large container ship at 13-17nm+, I think these is very typical for what the 4G is capable of.
In the link to THT below I’ve posted screen shots from the Baltic Sea where I could track a ship out to 36 km (more than 19 nm), when it was lost it was because I was back to harbour and went behind an island.
http://www.thehulltruth.com/8204950-post7.html
For the first screen shots I’m fishing (trolling) so my speed is 3 knots, the I reduced the speed to pick up the fishing gear, for the last screen shot I’m on my way back to harbour and the speed is 18.5 knots. I think the wave height was about 1m.
Sdpaddler, I just checked the manuals and think that NSS/NSO evo2 will always show a MARPA target heading/speed vector if the target is moving. The lack of one in my last image may be just a screen blink or may be because the unreleased Halo MARPA processing still had a bug.
The length of the breadcrumb trail can be user set or turned off. I don’t think of it as either/or with the vector, but it can be more reliable info than a twitchy vector and the track dots indicate speed changes you don’t see in a track line.
This has been one of the most entertaining and educational postings I have read! Thank you all for sharing your insite and experience. I have now started to go back and read all the comments on your past posts Ben….that’s were the actions at!
“I previously had Raymarine E80 with RD418HD radar, I now have NSS12 Evo2 with 4G radar. Until installing HS60 a few weeks ago I used a Maretron SSC200 heading sensor. I have not noticed any difference in accuracy between Raymarine and Navico MARPA, the only difference in performance I’ve noticed is that Raymarine was a bit more robust when it comes to not losing the targets, but no big difference. A couple of corrections to what have been written earlier. The Simrad MARPA processing is done in the radar and not the MFD. This is the reason why the radar interface needs the heading input. Robert described his experience with Raymarine MARPA using a Raymarine 2012 autopilot with rate gyro for heading. Then twistedtree comments that this is what’s happening when not having a fast heading. A 2012 SPX autopilot is outputting 10 Hz heading. Twistedtree and I have had our discussions at THT regarding Simrad equipment so I’m not going to get engaged in such discussions at another arena.” Posted by: abbor
A common mistake when wiring up this system was the installer only connected via Seatalk. To allow the SPX to output 10hz data you actually needed to connect up NMEA 0183 from the SPX to the MFD, otherwise you only have 1hz heading data. An easy way to test is to pull the Seatalk connection at the rear of the MFD and see if you still have heading on a data page.
Today with SeaTalk NG (and NMEA 2000) this is all a thing of the past!
My complaint with Navico MARPA echos Henning’s comments on the frustration of selecting a target (no touch screen) and that targets get “lost” too easily.
Now that you mention it, I probably have seen tracks that were surprising at the time although never so much that I considered there might be a bug. Something to look for next season.
As to whether the vector math calculations are easy or hard, I submit that it depends if you are talking “in principle” or “in practice”. In principle, if you have two exact points (or vectors), positions at two different times, you can subtract them and get a course and speed. In practice, a tiny error in angle from the scanner can be a large distance at the target, but the error from scanner to target will be smaller. Ignore for a second why, other than to say that is the way radar works.
So in practice, if the target boat’s path is approaching your scanner the MARPA calculated speed should be good but the course may be fuzzy. If the target boat’s path is perpendicular to the direction to your scanner, the calculated course should be good, but the speed may be fuzzy. Has anyone noticed if this is a factor?
That’s just with two-point calculations. If multiple scans are used, errors in individual scans can be smoothed out. Perhaps different scanners have different strategies for doing this.
After the debate about beam width, we can agree what should happen. But if some scanners are giving strange results, maybe the cause could be that they are not consistently choosing the center point of the return properly?
Also, the heading sensor is an important part of this system. Not just the update rate, but the precision of the heading. If it returns heading only to the nearest 1 degree, that could make a significant difference to a MARPA calculation.
But yet, if the radar plots the target in the right positions, the MARPA calculations should also be right, up to the amount of fuzziness of the positions.
Therefore, my guess is that (unless there are bugs) any differences in quality of MARPA calculations between radar systems is due to different smoothing/averaging strategies.
Someone with half a dozen radars on their boat should run a test 😉
Ben, if you are successful in getting Navico to respond, in my opinion the examples documented by Henning are very valuable. The good news in those examples is that the bread crumb trails are straight with little scatter, which means everything in the installation was working well and doing its job. As a prospective first-time purchaser of radar who is interested in the real-life performance of low-cost small-boat radar, I find that very reassuring. The bad news is that the MARPA vectors do not seem to reflect what the trails are saying, which suggests that they need more time averaging, or perhaps there is simply a bug in the vector calculation. Given this, if I owned Henning’s system, my tendency would be to turn MARPA off and keep the trails on, as they do a pretty decent job of showing what the target vessels are doing. But surely, given the good data demonstrated in the trails, Simrad could do a better job of calculating the vectors.
One other point which does not seem to have been raised so far, is that when I checked out Furuno recently, they had higher prices and electric current consumption than other vendors such as Navico or Raymarine. Not that there is anything wrong with that – but there are some apples-to-oranges comparisons going on in the postings (i.e. mid-end radar being compared to low-end radar). As least for me, cost and current consumption are important tradeoffs compared to radar performance.
Thank you for setting up this discussion, and for everyone who contributed, because this information is very valuable for a prospective first-time purchaser.
I have found the results given by the MARPA function on Raymarine products unchanged over the years.
It could be better by reporting the results and showing the vectors of targets based on COG/SOG rather than relative to the boat. Although there is a true motion (rather than relative motion) option available, that changes other features of the display that are undesirable.
I’ve never even heard of this feature (like so many of the new features on radars and MFDs these day) so i wouldn’t even notice if it were ‘broken’!
It’s worth noting that True vs Relative DISPLAY MODE is different from True vs Relative Motion VECTORS.
Kevin Monahan has written an excellent book called “The Radar Book”. It covers the difference between display modes and vector modes, along with a ton of other info on how to understand and get the most out of your radar. I highly recommend it. I think radars are one of the least understood, yet most useful devices you can have on a boat.
Andy wrote:
“I’ve never even heard of this feature (like so many of the new features on radars and MFDs these day) so i wouldn’t even notice if it were ‘broken’!”
I think this is the reason why this issue has gone unnoticed for so long. A minority of radar owners know what MARPA is. And a minority of those use MARPA on a regular basis. And a minority of those have used enough different MARPA systems to know what’s normal and what’s not.
To test this theory, I conducted a poll on trawlerforum.com
http://www.trawlerforum.com/forums/s4/poll-use-radar-arpa-marpa-feature-17468.html
Of recreational boaters, I would expect this group to be among to most familiar with radar features etc. But even among that group ARPA was not well known. Only about 25% use ARPA on a regular basis, and 35% never used it or didn’t know what it was.
I’ve helped friends installing SPX pilots, for all the installations we have of course used SeaTalk ng – NMEA 2000 for connecting to MFD.
It is disconcerting to realize how many people on the water don’t know how to use the basic features of radar. To dig in to the details of vectors, arpa, and the other concepts discussed here requires a certain mindset, which most people don’t have in our sound bite, immediate gratification society we live in.
In any event, This thread was great. Some of the concepts flew over my head, so I intend to reread the comments again in the future.
Furuno PG500 heading sensor is supporting 40Hz heading update when connected using AD-10. How is this influencing the MARPA performance?
Furuno 4kw dome with NavNet3D and SC30 compass on N2K backbone works very well with ARPA targets. It is quick to do the math and is a feature that I use every time the boat leaves the harbor. I am confident in the use of the system and its performance.
When the PC is connected to the navigation network, and Nobeltec is running, the targets show up on the computer. It doesn’t matter whether they are aquired using the MFD or the PC software. However, the historical trails of ARPA targets are not shared between the two processors via network protocols. Accurate heading input is mandatory for reliable results.
AIS resolution provides poor input for CPA calculations, unless it’s class A and the vessel is large and holds course. Radar is much more accurate for determining speed and range to a target, unless they are behind a hill or out of sight. Besides, not everything afloat will carry AIS equipment.
I think it’s super impressive what can be done with a small boat radar. Then the use of additional electronics, like a satellite compass instead of a flux gate compass, makes it come together more consistently.
Hopefully more people will use this type of technology if they have radar sets, as it makes them pay attention to the things that are moving around nearby. But, in any case ARPA is important to me in my slow boat…I also have an engineering degree and stayed at a Holiday Inn Express.
I tried to get Marpa running on HASPA HAMBURG with our Lowrance HDS1 MFD and the BR24 Radar – I had the same results as Henning and gave finally up. Our Heading sensor is the €3000 B&G Halcyon Gyro Compass…
@abbor
“So Navico is focusing much more on fixing problems reported by customers than some people think. The focus for the latest software updates for all Simrad products have been stability and performance improvements, not adding new functionality.”
Do tell. My experience has been just the opposite. I’ve got an 18+ month long sporadic exchange w/ Navico re: many issues I’ve reported. Very little result to show for it. Though friendly enough, they don’t supply case tracking numbers, rarely respond pro-actively, and typically answer “the issue is being prioritized by product management”.
Out of frustration I’ve posted my issues to a public tracking site. Maybe that site should evolve as a general Navico issue reporting system open to all?
All my experience has been with 10hz heading, both from a rate compass (RC42 and SSC200), and a Sat compass (HS70). I’ve never tried 20hz, let along 40hz. So I can’t say how much better things perform with those faster heading rates.
According to the documentation RC42 is actually outputting 20Hz heading when selected as heading source in a Simrad system. I’ve never checked, but I will hook up my CAN analyzer when I have time to verify.
If the weather permits I’ll check it also next weekend
Its been a few years and I am looking hard at the B&G 4G, so for what it’s worth:
“Lioness” had a Raytheon 24″ dome on her Mizzen about 20 ft above water. When motoring at night or in fog, with a heading input from the Halcyon fluxgate, over NMEA183 the marpa was able to track vessels at 40 kts in Sydney Harbor NS, not so much. I Figured that I couldn’t have dodged him anyway. We used it crossing Fundy, and navigating Penobscot and it was quite adequate for those purposes. Any small baseline sensor will have resolution errors on angular measurements, toss in some ambiguity on the rotational encoding and a less than wonderful heading signal and you may have a bit of angular jitter as well. I am wondering how well the Hercules H5000 system will do to create a better heading signal, and whether the Radar will be corrected for pitch, roll and yaw when heeled, though I have not tried to use it much when under sail…
“Out of frustration I’ve posted my issues to a public tracking site. Maybe that site should evolve as a general Navico issue reporting system open to all? Posted by: Sparky at December 8, 2015 8:55 AM”
Sparky,
What is the site you posted the issues on? I would like to read the site, to learn if there are other issues that I have not found yet.
Thanks – Henry
I just heard from Navico’s Head of Product Management John Scott, who’s been involved with radar development at the Auckland R&D center for many years. While he’s understandably reluctant to participate in an online debate, these are his comments on this thread:
“MARPA has a lot of components to it as the blog highlights…target acquisition, holding /tracking target, vector data etc. The performance varies greatly based on the installation environment, target geometry, and the radar’s actual physical performance. Quality of Heading data, the usage mode, and the experience of the users also contributes to expectations. This is why even in this blog there are conflicting reports on how well MARPA works.
I think the specific issue that kicked this off was our vector performance in MARPA in Broadband. We acknowledge this issue and are working on this specifically as well as the overall MARPA performance. To this point we intentionally released Halo without MARPA to spend more time on refining the algorithms & increasing performance. We expect to release MARPA on Halo this year, and once completed we will roll it into HD and the Broadband radars so all our customers will get the benefits. As someone stated it’s not a trivial undertaking, so it’s hard to give firm dates but please be assured we are working on it.
PS: I can’t let this go without a small pitch. Lots of factors go into rating a radar but I strongly believe the 4G is the best overall dome in the market today. It’s what I recommend to my family & friends. I strongly encourage people to discuss with their dealer the usage mode before deciding, but the 4G’s overall performance speaks for itself.”
For more on Halo (and John), look toward the end of this entry:
https://panbo.com/archives/2015/10/nmea_conference_2015_back-to-back_good_times_with_the_big_four.html
“understandably reluctant to participate in an online debate”:
I clearly see general reluctancy but have never understood why. I would think that this would be the cheapest and best way to be responsive. The fact that more and more advertisement budget goes to paying people to write favorable blog comments shows this, doesn’t it? On myself, this certainly would work better than a “100% of all collisions occur at 0nm” advertising campaign where I just think “yeah, but when do they get *avoided*?” (13nm in my case described above).
“The performance varies greatly based on…”:
Let’s not forget that Peter’s experience shows a large performance difference between Simrad an Furuno in a comparable to identical environment (same boat, same mounting location, same installer, same cruising area, same level of user education).
I think it would be quite valid if someone pointed out that, in this comparison, the Furuno products (FAR and 1835) are significantly higher priced than the Simrad products (6kw open array and 4G) but then this conflicts with the statement “I strongly believe the 4G is the best overall dome in the market today”.
Also, in the full thread of comments above there are *only* favorable reports from MARPA in Furuno recreational products that are priced comparable to Simrad (and there are two favorable reports from Simrad 4G).
“We acknowledge this issue and are working on this”:
I am pleased to read this. I had expected something along the lines of “not professionally installed”, “mixed brand installation” or even the old “unsupported router” but not so. This is appreciated.
The response from Navico is about as close to openly acknowledging the issues that some of the users noted above. Indeed, probably the most telling line is “we intentionally released Halo without MARPA to spend more time on refining the algorithms & increasing performance.” Navico MARPA is so poor that they did not want to compromise the launch of their new flagship radar units.
I wish they had been as candid when the “cutting edge” BSM-2 CHIRP sounder was introduced. Then I would not have been lured into buying a Simrad system when outfitting my new boat. Of course we don’t see a big disclaimer on the ads for the Halo radars saying “this radar lacks MARPA so please don’t venture anywhere in fog or at night if there might be non-AIS equipped boats operating.”
“The fact that more and more advertisement budget goes to paying people to write favorable blog comments shows this, doesn’t it?”
Henning, what is your basis for that claim?
Ben,
a mother in our daughter’s kindergarden did this for a living and gave us a little insight. I heard rumors and opinions from friends and colleagues. And the Russian government does it big time (thousands of comparatively well paid government employees) as documented by a single whistleblower whose name I forgot.
I’m pretty sure, though don’t have proof, that this is a major topic for Amazon.
But I mentioned it just to indicate that forum content represents value (or else people would not be paid), not that any part of Panbo’s comments are counterfeit.
I think we all learn better and better to rate anything we see and subconsciously dismiss whatever looks to be uninformed or having a hidden agenda. My 7 year old daughter can already detect commercials in a few milliseconds when fast forwarding recorded TV or Youtube. My eyes can blend out advertisements on web pages and I can click away popup advertisements without the product or service advertised even registering in my mind.
At 14, my daughter will be a master of rating content and so will all her friends.
But anyway:
1. I think marine electronics vendors would gain, not lose, if they engaged their customers in some forums (maybe not all). And if some customers get abusive, I would de-rate them, not the vendor.
2. I have not noticed any hint of “paid engagement” on Panbo unless by vendors and dealers where it is highly welcome.
I appreciate simrads candid response.
They have a very good product, but there are some aspects they are working on to improve it. The same can be said for most products we buy, and especially electronic systems.
I may upgrade to Halo next year, but I will keep my eye on this, and other sites for feedback from users on all of the above described topics, including Marpa. . For me, in a coupe style boat, with the radar mounted fairly low, the fact I am not radiating my guests as they make their way to the bow is a good thing. If I was still do the fishing thing, it would be a 6 ft wide scorcher.
Good thread. No insults, wacky statements, and other jibberish you often find on a forum.
@HenryD … here you go.
https://github.com/woobagooba/Navico/issues
This would not be necessary had Navico their own support forum or anything close to reasonable turn on the issues reported.
AFAIK many Zeus, Simrad, Vulcan units share the same code base.
The MARPA function on my Navico 4G system is not totally useless, but pretty close. It works about the same as the MARPA on the ancient steam-powered Raytheon Pathfinder system it replaced.
It sounds plausible to me that it’s a software problem, for two reasons: (a) the radar works fine otherwise (not revolutionary in any way, contrary to some claims, but very good in every way); and (b) there are so many software bugs in every piece of Navico gear I have — it would be plausible that here is another one.
@Dockhead. “The MARPA function on my Navico 4G system is not totally useless, but pretty close.”
I feel the same re: the route management / route navigation functions.
@Everyone … a thought …
The Github link I posted above. This could be used as an unofficial, public Navico issue reporting / tracking system.
Crowd Source New ARPA software:
Sometimes an ordinary sailor gets a radical idea that can spark the imagination of all the smart engineers. With that in mind I was wondering if it’s possible for those on the forum with expertise in software engineering to crowd source new software that can be flashed into a radar with poor ARPA resulting in an improved feature.
When we purchased radar we paid for the hardware, we paid for the license to use the software, we compensated the manufacturer for all their hard work. This does not mean we have to keep the software. With the fee paid, are we not allowed to use our own software with the gear we own? A similar crowd source project has been done with Garmin radar used to overlay a radar image on OpenCPN.
In any case, if this is just not possible I apologize – just an idea I thought to throw out – you never know….
Because we often do long passages, I sometimes get bored at night and once again try engaging Navico B&G MARPA just for kicks.
Typical scenario: calm nights, big honking targets (i.e., tankers) just 2 to 4 miles away, tracking on a AIS on a separate B&G screen, targets are big on radar screen and show up on the radar screen on every single revolution of the radar.
Typical outcome: acquiring… acquiring… acquiring… acquisition failed!
Or….
OK, locked [1]…. and then after a just few minutes and less than a handful of miles away for no apparent reason… MARPA Target Lost!
B&G 4G radar
B&G Zeus 12
B&G Zeus2
Simrad RC42 Rate Compass
B&G ZG100 GPS (10 Hz)
B&G NAIS 400
B&G AC42 pilot
etc.
In our case, the B&G G4 MARPA is clearly just a toy.
It is nothing that could conceivably be relied upon to safely navigate the boat under any circumstances. Not even ideal circumstances! More times than not it fails to acquire and track any type of target for any useful length of time or distance.
Anyone tried the Simrad updates yet to see if there’s an improvement?
http://www.simrad-yachting.com/en-US/Support/Software-Update/
Ah, I do see that SonicHub2 is now out. This is a drop-in replacement of SonicHub which was built by Fusion. Now that Fusion is owned by Garmin it was just a matter of time before Navico stopped funding a competitor…
Anonymous, if this is in regard to faulty MARPA I believe we have determined that MARPA processing occurs in the radar dome not the MFD (as I have found MARPA targets to appear on an MFD that is not the one on which they were acquired and that did not have a radar screen up at the time the targets were acquired).
Consequently it would have to be radar software to be upgraded.
As can be seen here:
http://www.simrad-yachting.com/en-US/Support/Downloads/4G-Radar-Software/
the latest version is 4.1.57, almost exactly 3 years old, and it is what was running on my radar when I took the screenshots last summer.
It seems to me Simrad is not exactly progressive with software updates for radar. Even the autopilot update from last August is only meant to extend the range of serial numbers for production. There are no bug fixes, feature fixes or enhancements. When a company like Garmin issues a software update it’s sometimes like getting a whole new machine for free. When it comes to Simrad radar and autopilots you are stuck with whatever you bought.
Hi Ben,
I’ve had my Simrad 4G radar for just about 4 years now and I love it. I was very much looking forward to the MARPA functionality, but it’s turned out to be pretty useless for me (aside from the neat little dots it leaves while tracking a target… those I use).
As a result of your article, I decided to try a little test today – tracking a rock. It was surprising how mush that rock was moving!
I posted to our blog a GIF of screenshots taken over the course of about a minute, along with a video of the sea state at the time.
Rich, S/Y Legacy, Currently in New Zealand
Oops, forgot the URL for the screenshots:
http://www.twoatsea.com/marpa-bad/
Documenting MARPA performance without telling which heading source is used is close to worthless. MARPA performance is closely linked to the quality and update rate of the heading source.
Has anyone tried MARPA with the latest updates?
The MARPA processing is done in the 4G dome, not in the MFD.
Abbor, Rich’s heading source and rate seems to be fine – otherwise the radar overlay would move back and forth on the chart…
Interesting video! It raises several questions. Correct me if I am wrong. The plotter is in course-up mode. The heading varies up to about 15 degrees to each side. Is the boat heading actually changing that much? Do you know which hardware and software version of the RI-10 radar interface you have? Not that it matters, they probably all have the same bugs. Since the MARPA processing is done in the dome, that raises the question of whether the heading info is getting to the dome. So it might be the RI-10 and not the dome. The radar dome does not need heading info except for MARPA. That is the reason why the radar interface is required, that and selecting which target to acquire. Heading can go to the dome via N2K; how is the selected target communicated?
The MARPA seems to be calculated using only one pair of scans; no wonder it is flaky. The other odd thing is that the radar overlay of the land varies so much. It even seems to lose the target rock in one scan. It loses the other rock which is 1 nm to stb even more often.
What would your MARPA show for a rock if you were doing a steady turn? That test might help decide where the bug is. Maybe the dome needs not only accurate heading, but also rate of turn info.
Do Navico non-broadband radars have this fault?
I’m not sure what heading source Two@Sea is using, but these issues have been clearly demonstrated with both an RC42 as well as with an HS70. A heading source worse than an RC42 (10hz rate compass) will presumably make things even worse.
It takes multiple scans to establish a MARPA target, and then it presumably updates with each scan. Keep in mind that the “video” that Two@Sea put together is not really a video, but rather a sequence of still shots with some interval between each. So you aren’t seeing successive scans. But it gives a good sense of how crazy the MARPA vector can be.
If I recall correctly how the Simrad MFD works, the orientation of your boat’s icon shows heading, and the vector shows COG/SOG. So if you watch closely you will see some heading movement, but more COG/SOG movement. That’s not unusual in and of itself, but I have no way of knowing if what we are seeing is excessive or not.
Maybe I’m asking a obvious question but are you guys sure the MARPA isn’t done by the RI-10 box?
Reason for my question is that I was informed by the dealer that the radar (4G) could be connected to the MFD (NSE) without the RI-10, but MARPA would be missing. This was suggested by the dealer for a cheaper installation. This I got confirmed by Simrad DK, but they also stated that this was not the official way to connect the devices together. As I wanted MARPA enabled it was installed with the RI-10 box – so I have never actually tried connecting the radar and MFD without the RI-10 box.
The radome is connected by Ethernet, but according to this OpenCPN post, the heading signal is not injected into the Ethernet stream. Testing by Douwe Fokkema shows that the heading data is sent to the 4G RADOME in the ethernet cable but on an otherwise unused pair”
http://www.cruisersforum.com/forums/f134/opencpn-simrad-lowrance-radar-overlay-plugin-123167-7.html#post1665656
The RI-10 is supposed to grab the heading from N2K and send it to the dome. If it did not do this right, the MFD could have a plot perfectly corrected for heading, but the MARPA values would be wrong — and it would probably difficult to set new MARPA targets. But it’s just a wild guess.
Regarding Two@Sea’s video, the boat show’s the heading varying a bit, and the course projection varying more. There is also a number in the autopilot line. Would you expect COG to vary this much? Unless that is calculated from a GPS on a rolling boat? SOG also varies quite a bit. If you watch that video carefully, note that the red vector and the black vector usually move together, as if MARPA is being calculated from COG and SOG instead of from heading and radar distance. No, that’s too crazy…
The optimum dampening characteristics for overlay and MARPA are quite different. So even if a compass gives acceptable overlay performance it may not be suited for MARPA at all (GS25 and Point-1 are examples of this). MARPA and autopilot both require similar dampening characteristics, relatively low level of dampening is preferred, overlay works best with much higher dampening. Point-1 AP delivered with the Lowrance autopilot has a completely different dampening characteristics than the standard version. For HS60 and HS70 the dampening characteristics can be changed within the compass to optimize for the application. The VectorPC program available at the Hemisphere pages is used for this. With HS70 interfaced using NMEA 183 it’s possible to have different update rates and dampening characteristics for the two NMEA ports.
So assuming that a high speed rate compass (Maretron SSC300) was available, as well as a slower damped one (kvh Sailcomp 103 with 0183) does one simply feed the fast rate to pilot and radar as well as H5000 Hercules on n2k vs damped via 0183 to MFDs & analogs/steering displays.
Thank you for that! I have asked about the “ideal” damping settings and I always have received a shrug of the shoulders.
I don’t find overlay to be very effective on my small fast boat. MARPA/ARPA it works fine.
Another consideration is that my AIS transmitted heading probably could use damping.
I do have two sources of heading- Airmar GH2183 for the plotter/radar and a PG500 for the AIS.
Maybe I should pick and choose the source/inputs a bit more strategically?
A Halo software upgrade which includes MARPA (dated 14 Dec 2015) was announced a couple weeks ago:
http://www.simrad-yachting.com/en-US/Support/Downloads/Halo-Software-Upgrade/
zeus2, 12″, received an update a few days ago and now the system tells me no MARPA and no AIS collision warning because of no appropriate compass. Hm,I have a N42 from B&G and a PB200 from Airmar, both on NMEA200, tried all versions of plug-in and off, no avail. Anyone else this problem? The Marpa switch (Aquire Target) is here, but greyed out. I am new to B&G (after 20+ years Raymarine), system installed amonth ago, I think MARPA was working until the update, how reliable, I do not know as it was not put on test, this week I had time to sail and no more MARPA. So I use openCPN for checkups and Zeus2 as intelligent autopilot. thanks for any reply, Henry
zeus2, 12″, received an update a few days ago and now the system tells me no MARPA and no AIS collision warning because of no appropriate compass. Hm,I have a N42 from B&G and a PB200 from Airmar, both on NMEA200, tried all versions of plug-in and off, no avail. Anyone else this problem? The Marpa switch (Aquire Target) is here, but greyed out. I am new to B&G (after 20+ years Raymarine), system installed amonth ago, I think MARPA was working until the update, how reliable, I do not know as it was not put on test, this week I had time to sail and no more MARPA. So I use openCPN for checkups and Zeus2 as intelligent autopilot. thanks for any reply, Henry
We got out to do some sea trials yesterday, and there’s a lot of learning. Seastate 0-1, overcast marine layer at 1000ft.
0. The Navico RI-10 sends broadcast packets, and the third party Ethernet Switch was not forwarding them. Direct connection from RI-10 to SONARHUB to Zeus MFD made all work.
1. BG 4G radar could decorate the 25-50′ fiberglass hulls in the marina with pretty good separation (3′ finger piers, so ~6′ between hulls) which was really impressive, we checked scanner bearing alignment with a 12″ diameter Pipe that supported a daymark at ~100 yrds.
2. Going out the Estuary, we found that with a shot of a 1000′ Container ship ~500 ft bows on, it was essentially a stealth vessel, the tugs on either side were clear, the AIS was very clear and we could see a bunch of weird returns from the bow but nothing you would categorize as a ship. Shooting at the side/stern of course gave a massive return.
3. MARPA (menu–> acquire targets) would place a box around vessels, trucks and a few forklifts ashore and other moving targets (I think we had one bird…) Zooming in caused the off screen targets to be dropped.
4. Did not find a listing of MARPA targets to compare to AIS.
It’s summer in the Northern hemisphere, so everyone should try the Twoatsea rock test with their MARPA.
I found it quite entertaining how my old Navico system reported those fixed targets. I haven’t noticed any MARPA fixes for newer Navico systems (except Halo). If there were any, did they work? How do other systems do on this simple test? Back to the question in the title — is Navico MARPA especially bad? Is it a small radar problem or a small boat problem?
Hi,
since june 2017 (maybe some monthes earlier) navico uses the firmware x.3.17 (x is 3 or 4 for 3g and 4g).
On this website: http://www.simrad-yachting.com/de-DE/Unterstutzung/Downloads/3G-Radar-Software_post-Oct-2014-model/
you can read whats changed.
Does anyone tests this new firmware with the navico Radars and the (M)arpa functions?
Regards
Andreas
For the HD digital radar processors, Simrad issued a software revision March 2017. It purports to address a number of MARPA issues. I’ve downloaded it but have not yet had the opportunity to try it out.
On somewhat of a tangent, our five year old (1,000 hour +/-) 6kw stopped auto tuning necessitating a $3,000+ repair. Instead, for $500 less I bought a whole new replacement. (I’d consider other brands but needed a quick and easy replacement.) Our original installer tried to intercede but the best Simrad would do is offer $200 off the price of a $5,000 Halo radar. I was hoping they’d stand behind their products a little better than that.
The 3G and 4G MARPA was updated this summer. When placing several markers on one vessel, the results are now fully consistent for all MAPRA trackings. The system is also much more robust against loosing targets.
In this link I placed 4 trackers on one vessel, both the tracks and the numerical data are now fully consistent.
https://www.thehulltruth.com/attachment.php?attachmentid=849460&stc=1&d=1501115808
Only radars produced October 2014 and later can be updated. I replaced my 4G with a new one this summer to be able to use the improved software.
OpenCPN now has MARPA and ARPA for all versions of Navico
Broadband RADAR (Br24, 3G, 4G).
It is implemented completely in the OpenCPN radar plugin code (not relying on the RADOME for any ARPA calculations).
I have been testing it aboard and it seems to work very well.
I can confirm that the recent software update seems to have fixed the disaster that was Navico’s MARPA. It now is a good and useful tool that give data that is helpful and as far as my testing has shown, can be relied upon.
It’s great to see that this has finally been fixed, and that my “rantings of a madman” are what ultimately drove that to happen. I guess I wasn’t so mad after all. And as for my rash decision to replace all the Simrad equipment with other, these fixes do not apply to either of the radar units that I had, so I would still have the same problem today, 3 years later, with no fix in sight, had I kept the gear.