Simrad NSO EVO II bugs

I feel badly about dumping on all these products, but I think it's really important to keep pressure on manufacturers to test more thoroughly so that we actually get what we pay for.  With that preamble, let's talk about the bugs in the Simrad NSO EVO II.

The NSO is Simrad's top-end black box chart plotter and multi-function device.  These issues were all encountered in their V2 software.  Here's what I ran into:

Problem 1:

CPA and TCPA is not calculated and often blank for AIS targets.  Sometimes no data shows at all.  But if I go to Coastal Explorer and look at them, all the info there and CPA and TCPA are calculated fine, so the AIS device itself is working fine and putting all the data on the N2K bus.  Simrad told me this is a known problem that is fixed in the next release.  They just released version 3, so perhaps this has been fixed.  The pictures below show the problem.  These happen to be the radar screen, but if you drill down on any of the targets, you get the same results.

In the first picture you can see that the first target, "Destiny", shows SOG and COG which is info included in the ship's position report coming from the AIS receiver.  But CPA, TCPA, RNG, and BRG are all missing.  These values are calculated (or not in this case) by the NSO.  The second two targets are fine.

Missing critical AIS info

 The next picture shows the problem again, but now there is no data at all other than the ships name, and even that appears to be jibberish.  Note that the first target is a MARPA target, and only the second two are AIS targets.

Missing critical AIS info

Problem 2:

The next problem also relates to AIS processing and display.  The targets are supposed to be sorted by either CPA or range.  So the targets we see listed here should be the most dangerous.  But these appear to be in a completely random order.

Problem 3:

The NSO provides a way to change the instance number on N2K devices.  It's a nice feature, and easy to use.  But depending on how you work through the steps, when you finally give the OK to make the change, the NSO gets stuck forever "Configuring device".  I worked out the exact procedural steps to reproduce this and gave them to Simrad.  Fortunately, if you hit the Cancel button you can recover from this.

Problem 4:

This issue will appear twice, once here under the NSO, and again under the Auto Pilot bug list since both products are party to the problem.   The issue is that depending on the sequence in which you power up the NSO and the autopilot components, the AC12 auto pilot computer becomes forever un-discoverable.   More particularly, if you start up the NSO first (turn on breaker and push the pwr button so it boots up) before you power up the AC12 (turn on it's breaker), the NSO will not discover teh AC12 and will alarm saying there is no auto pilot computer.  Furthermore, if you power up the AP controllers by pressing their PWR button (they get power from the N2K bus, so there is no dedicated breaker) after they boot up they alarm as well saying there is no AP computer.  At this point, you can power down again adn back up in any order and neither the NSO or the AP controllers will be able to find the AC12.  It's like it's been disconnected.  HOWEVER.... if you cycle power on the N2K bus, then turn on the breaker to the AC12 before turning on the NSO, it recovers.  And as long as you power on the AC12 before the NSO, it will continue to work fine.  But is at any point you forget and power on the NSO first, it again locks up.

OK, there you have it for the NSO EVO II.

New Electronics layout

I made pin-ups of all the new electronics devices so I could experiment with different locations for everything.  Getting all the pin-ups to the correct size took a little effort, but was well worth while.

Below is the new layout.  From left to right we have:

1. FAR2117 radar control panel.  This is the larger panel with all the dedicated controls for easier operation.
2. Dual autopilot controls.  They come in a large and small form factor, and by using the smaller ones I'm able to fit both.
3. The FCV627 fish finder fits nicely in the remaining space
4. Up next to the monitor is the control panel for the windlass.  It needs to be relocated from where the AP and fish finder controls will go.  I'd much rather have the AP, fish finder, and radar in easy reach from the helm chair, so the windlass control moves further away.

New equipment layout

Now all I need is room for the second radar, and that brings us to the overhead.  In the next picture you can see the existing setup with the two large control panels for the wing and main engines.  Each has start/stop controls, a dimmer, PowerView multi function display, alarm, tach and a handful of dedicated gauges for various functions.  My primary display for all this data is my Maretron monitoring screen, so these panels are just for backup.  And anything displayed on the dedicated gauges can also be displayed on the PowerView device.

Large dedicated engine control panels

So, to recapture a big chunk of space and create a perfect spot for the 1835 radar, I decided to combine both engines into a single, simplified panel.  Below is one of the original panels, followed by a Photoshop mockup of the new combined panel.  For each engine there are start/stop controls, a dimmer, a PowerView display, and an alarm sounder.   The power view can show 4 gauge values at once, so I can still see 4 out of the 5 pieces of data from the original main engine panel, and all of the data from the wing engine panel.  So very little is given up in exchange for all the recovered space.

Original, full-function engine control panel

New, simplified control panel for both wing and main engines

With all this new-found space, I have a perfect location for the 1835 Radar.

Furuno 1835 radar and combined engine control panel

Installation work resumes in about a week and we will see how all this pans out in reality.

Upgrading to AIS Class A

I have always argued that Class B AIS is more than sufficient for recreational boats of all kinds.  Well, it's time to eat my words, or at least some of them...

Here are some of the key arguments, including what's changed.

1. Transmit power:  Class A transmits at a higher power than class B.  On the surface (pun intended) you might then expect to be detected by ships further away, giving more time to adjust course, etc.   The reality is that your antenna height will limit your transmit range way before transmit power will.  And how far away do you need to see a ship to avoid it anyway?
2. More frequent transmissions:  Both Class A and Class B adjust the frequency of position reports based on your speed.  The faster you are moving, the more frequently your position gets transmitted.  But for any given speed, class A transmits more often so other boats have a more current view of your whereabouts. Unless you are trying to perform ballet with another boat, I don't think this makes any significant difference.  After all, AIS is about keeping clear of other boats, not to aid close-in maneuvering.
3. Access algorithm:  Class A uses a different access algorithm to slot in all the ships that want to transmit their position.  Everyone essentially gets a negotiated time slot when they can talk.  This is the way digital phone systems work.  Class B, on the other hand, uses a collision detection algorithm.  It's like a people talking in a group.  If two start talking at the same time, they stop, pause, then restart.  Eventually one wins out.  Lots of people fear that you can get blocked out in such a system.  But you know the ethernet networks that the entire world has been running on for around 30 years?  Well, up until gigabit networks, all of them operate on this simple yet effective algorithm.  And nobody seems to be getting blocked out.
4. Big ships selectively ignore Class B targets:  This always struck me as ridiculous, but are the words I now get to eat.  What captain in their right mind would elect to ignore certain boats, right?  Are some boats OK to plow down, but not others?  After all, the rules of the road make no distinction between different size boats.  There is no such thing as "the rule of tonnage".  I have challenged people to show me a nav system with an "ignore class B targets" button, and nobody has produced one, so I always took it as a myth.  Not so.

 It turns out that the very navigation software package that I use has just such a check box.  Oops.  Worse yet, I discovered that Puget Sound and Seattle vessel traffic services do not receive Class B.  So the guys who are guiding the ships around and tell them when it's clear to cross the shipping lanes and when it's not, can't see you if you have Class B.  Now in my book that is down-right negligent, but it is what it is.

So with all the other Simrad gear getting removed from my boat, I decided to include the Class B AIS and replace it with a Class A device.  Then the question was, which one?

Furuno's FA150 is a very popular device and seems to carry an excellent reputation.  The problem for me was that it's gigantic.  The control panel isn't too bad - about the same size as a typical VHF - but the main box is the size of a brief case.  I'm getting tight on space already, and one of the new radars is gigantic too.  So I kept looking.

In general, there are LOTs of class B devices available from different manufacturers, but Class A devices are much fewer and further between.  In fact, I only found a few, several of which are actually identical products with different names on them.  I found:

• Comar CSA 300
• Digital Yacht CLA 1000
• ComNav Voyager X3
• Raymarine AIS950
• AMEC Camino 701

The first four are all identical, and are made by SRT in the UK.  It actually looks like SRT makes most of the AISs out there in both class A and B.

The AMEC device is made by AllTech in Taiwan.  The device looks nice, but after all the hassles I've had with equipment not performing to expectations, I didn't want to experiment anymore.  The various SRT clones all seem to get good owner feedback, so I decided to get one of them.  The rest turned into a buying exercise, and I found a ComNav unit for just under $2000 which was pretty darn good.

Oh, and I forgot to mention that all the other devices listed above have a much smaller footprint than the Furuno.  The control head is the same size as the furuno, but there is no brief case size control box, but rather a small junction box for wiring everything up, making for a much easier installation.

The next step was deciding where to put everything.  The picture below shows one of the few spaces where we still have room for a control panel, but it's kind of hard to reach.  I made a variety of these little full size pin-ups to figure out where to put all the new electronics parts.

Pin-up of ComNav AIS control head

In the end I moved the AIS over to the left as far as possible so my wife can more easily reach it.  It's a stretch either way, but fortunately it doesn't need to be fussed with much.

Final location, moved a bit to the left

 And a little while later, presto, we have an AIS control head.

Control head in place

A little more work to install and wire up the junction box, and we are in business.

Control head in action

But there's more too it.  As IMO certified devices, Class A AIS is NMEA 0183 only.  N2K is not approved for IMO use.  So this has required some creative converter use, and a few discoveries along the way.

The AIS has six 0183 ports.  Three are input-only and are intended for various sensor inputs like heading, position, speed, etc.  Even thought the AIS has it's own built-in GPS, it is meant as a backup only.  You have to provide external GPS info and External heading info.  And the heading has to be a True heading in the form of the HDT sentence.  Plus, all the AIS info needs to get out on the N2K bus so it can be displayed on Coastal Explorer, etc.  The challenge is figuring out how to do all this with something less than three different converters.

According to their manuals, only the Furuno converter will product HDT, but it won't handle AIS info at the same time.  Also, according to the AIS manual, you can use any port for any data.  Luck was with me when I discovered that a new converter I decided to try actually can do AIS, GPS, and HDT info all at the same time.  This adapter is the NK-80 made by AMEC - remember the guys above who make the other Class A AIS device - well I decided to give it a try.  So far, I'm really pleased with it.  Because the AIS can accept any data on any port, and because the converter can convert everything, it looked like I could use a single converter.  Not so fast, I'm afraid.

It turns out the AIS doesn't work exactly as the manual says.  You need to give it the heading and GPS data on one of the input-only ports.  It won't accept it on the input-output ports.  But, there is a simple cheat.  I just wired the converter's output to both ports on the AIS.  It's getting more data than it needs on each port, but that is typically the case and doesn't really matter as long is it's not overflowing the device.  So far so good.  Since making that last change it's been working non-stop and can be tracked on MarineTraffic.com or your favorite site.

NMEA 2000 Standard Committee

I think a group picture of the NMEA 2000 Standards Committee deserves a place on the Wall of Shame.  NMEA 2000, aka N2K, has so much potential, and has helped the marine industry in many ways.  But it's implementation falls well short of it's real potential.  It's great for wiring up a 25' center console boat with one of this and one of that.  But try building up a bigger system with lots of devices, many of which are redundant, and it very quickly comes unglued.  It's no wonder that N2K is not part of any IMO approved device.

One of the biggest problems is that N2K is a secret.  To get a copy of the spec costs $5000 or more, so nobody other than a manufacturer will ever see it.  And even if you cough up to $5000 to buy the spec, it comes with a stipulation that you keep it secret.  The result is that none of "us" - not boat owners, not repair techs, and not electronics installers - really know how it's all supposed to work.  So when something isn't behaving properly, there is no way for us to know what's right and what's wrong, and hence no way to chase down whoever's product is misbehaving.

Instead, we get the run around.  Has anyone else ever experienced this?  You are having a problem, and might even be using an analyzer like Actisense's NMEA Reader, or Maretron's N2KAnalyze (both great products) and have an idea where the problem might be.  So you call tech support for vendor A, describe the problem and tell them how you think their product might be misbehaving.  Vendor A gives you some mumbo jump about how things are supposed to work and tells you that Vendor B's product isn't doing things correctly.  Not knowing any better, you believe them and now call Vendor B, explaining to them what you were told by Vendor A.  Vendor B now gives you some different mumbo jumbo and explains how Vendor A is doing things wrong and that they are the problem.  Now you are in the dark here, so have no way of calling bull-shit on either of them.  And these two companies won't pick up the phone to the other company to sort out the issue, but instead leave you as monkey in the middle.  Sound familiar to anyone?

If purchasing a spec includes other stipulations, one should be that you are not allowed to tell a customer that another vendor's product is broken, but rather be required to call that vendor and work it out.  If these guys want to sell more product, it has to work.  By way of example, my boat started out 100% N2K.  I have subsequently removed about 30% of the N2K devices, and the replacement communications is via 0183.  I did NOT want to do that, but it has proven to be the only way to make it work in a reliable and predictable way.

The next issue is NMEA 2000 Certification.  I read over and over again about how all troubles will go away if you only use NMEA 2000 Certified devices.  These are devices that have voluntarily subjected their products to a battery of tests that demonstrate proper adherence to the N2K standard.  Well, I can tell you in no uncertain terms that NMEA 2000 Certification does not indicate that a product complies with the standard, and there is one very large and glaring example.  Instancing.

[Editor's note, Dec 12, 2015.  Please note that in this post I am talking about NMEA 2000 Device Instance Numbers, not Data Instance Numbers.  I was not clear and I believe this has led to a lot of confusion.  Here is an article explaining the difference, so please take a look]

[Editor's note, Dec 12 2015.  Please also note that the following discussion of Device Instancing is heavily used by Maretron, and not used at all by many other vendors.  Please read all the way through to understand NMEA 2000 NAMEs and how they provide an alternate, and more commonly used way distinguish and select devices.  But keep in mind that these two different approaches and the conflicting support in device certification is exactly the point of this post.]

Instancing is a way to distinguish between otherwise similar devices.  It's a number that you assign to devices, kind of like taking a ticket at a deli counter.  The picture below shows a real life example of where this comes into play.  The network in the pictures shows a chart plotter, a sat compass, a GPS, and a rate compass.

Example N2K network with redundant sensors

The sat compass and GPS both provide position, speed, and course information, but the sat compass is the superior instrument providing more accurate info than the GPS.  Similarly, the sat compass and the rate compass both provide heading and rate of turn info, and once again the sat compass is the superior instrument yielding more accurate info.

In the absence of instance numbers, the chart plotter would have no way to distinguish between the two duplicate sources of data.  It might pick randomly, or even worse it might use both, mixing data from different sources.

Instancing solves this problem in two steps.  The first step is that every device producing data, typically referred to as a Source (the sat compass, GPS, and rate compass in this example) must have a way to change its instance number.  There is a standard message that can be sent across the N2K bus to change it, and many devices support this, though it's not required.  But if a device doesn't support that method, it must provide some other way.

The second part of the solution is that any device making use of data on the bus, sometimes called a Listener, needs to have a way to pick which device it wants to listen to.  More sophisticated devices can be given a prioritized list of devices, and they will always use the highest priority device that is available.

Bringing this back to N2K Certification, I have encountered numerous devices that are certified and that do not provide programmable instance number.  These are certified as standard compliant devices, yet they blatantly violate the spec.  And if you try to use these devices in anything other than the most simplistic network, or more accurately a network where there is never more than one such device, it doesn't work.  This is a HUGE loop hole in the certification process, and a huge short fall in vendors implementation of N2K devices.

Devices where the Instance number cannot be changed or doesn't work properly:

• ICOM M506 N2K
• ICOM M506 N2K-AIS
• Simrad HS70 sat compass
• Simrad AT10
• Simrad AT10HD
• Simrad NAIS400 AIS transceiver
• Furuno NavPilot 700 computer (FAP7002)

Looking at the other side of the problem, it gets even more complicated.  I actually don't know whether devices are required to be capable of source selection.  If I could read the spec I could tell you, but I can't read the spec, and if I could I wouldn't be allowed to tell you.  What I do know is that there are a variety of ways a device COULD do source selection, they all seem to be valid and compliant, but are often times incompatible.  Here are two examples.

Every N2K device has a "Name", and that name is guaranteed to be unique.  A device's name is composed of a number of different things similar to a first, middle, and last name in our US culture.  An N2K name is a combination of the device type, manufacturer, instance number (there it is again) and a unique number assigned by the manufacturer.  Worth noting is that every device has a unique name even if they all have the same instance number.  So every device on the planet could have instance number zero and you would still be able to differentiate all of them.

When doing source selection, some vendors use the unique name and are not dependent of programmable instance numbers.  But other vendors depend on programmable instance numbers and use it as the primary way to perform source selection.  Both approaches are legitimate, but it results in two very different views on the importance if programmable instance numbers.

One guy at NMEA told me that a network should be completely usable and operable even if all instance numbers or zero.  That says that one cannot depend solely on instance numbers for source selection.  And a number of vendors I have spoken with about their non-programmable instance number point out that it's not needed.  Well, maybe it's not needed by them.

Maretron, a prominent vendor and member of the NMEA 2000 Standards Committee has build a product line that depends 100% on programmable instance numbers to do source selection.  If you can't program a devices instance number, then you can't tell it apart from another device sending similar data.  Maretron defends their position saying that programmable instance numbers are mandatory in the standard and that other vendors needs to implement it.

Both are right, but the result is that building larger, redundant networks is very problematic, and we the customer are caught in the middle.  It also means that we the customer aren't buying as much product as we would if we could reliably build redundant systems using N2K.

All this comes back to the N2K Standards Committee.  If they can enforce secrecy of the specification, then surely they can enforce compliance with the spec.  And at a minimum, certification should actually reflect compliance with the spec.  Then it would be a mark that we could seek out to buy with confidence.  But right now, NMEA 2000 Certified doesn't mean much of anything.

Problems with Simrad/Navico radar

One of the driving reasons for removing all the Simrad gear from my boat was the radar and associated bugs.  Top of the list among the bugs (all of which I will share) is erratic MARPA performance.  MARPA stands for Mini Automated Radar Plotting Aid, and is a poor man's version of ARPA (Automated Radar Plotting Aid).  For the sake of simplicity, I'm just going to refer to it as ARPA.  The difference, as best I can tell, is that ARPA can automatically acquire targets within a specified area, where with MARPA they need to be manually acquired.  But that is jumping ahead.
ARPA let's you "acquire" a target.  It all sounds very military, but it's a really critical feature for navigation and collision avoidance.  When you acquire a target, the radar tracks that blip on the screen, and calculates it's course and speed based on it's observed movement.  It's all basic trigonometry, and a great example of how that stuff is actually useful.  As one of my kid's teachers used to say, "math is everywhere".

So in the middle of the night, or in the depth of fog, you see a blip on the radar.  Rather than watching the blip and trying to assess where that boat is going and what it's doing, you can acquire the target on your radar.  Within a minute or so, the radar will show a vector (see, math is everywhere) indicating the target's direction and speed.  Now, rather than guessing, you can see exactly where that boat is going, and how fast they are moving.  This is hugely valuable, and probably hard to appreciate if you haven't tried to navigate in the fog.   We've made a couple of trips from Gloucester to NYC, a trip of about 300 miles through some of the busiest waterways on the east coast, and never seen land or another boat the whole way.  That wouldn't be possible without ARPA, or at least the stress level would prevent me from doing it.

Problem #1:

The killer problem with Simrad is that their ARPA function is fundamentally broken in the current product line.  We first became aware of this when we nearly got run down by a boat off the Columbia River.  After that, I really started looking at this closely.  The problem is that:

1) The ARPA vector does not accurately represent the boat's movement

2) The vector's direction swings around and is unstable

3) The vector's length (boat speed) is also unstable and varies widely.

The attached video shows this clearly.  We are looking at a tug and barge.  The tug has AIS which is a radio-based report from a boat telling you it's actual speed and course.  There is no ambiguity, and no room for error.  It is telling you exactly what the ship is doing.  The AIS target is represented by a triangle with a line showing the course and speed of the tug.  I have then created a ARPA target of the barge behind the tug, represented by a circle and arrow showing it's course and speed.  The tug and tow are of course moving at the same speed and in the same direction, but the video would suggest differently.  Referencing the points above, we see:

1) The ARPA course and AIS course differ significantly.  They should be the same, or very close.

2) You can see that the ARPA vector swings around rather than maintaining a steady course.

3) You can see that the ARPA vector changes length by quite a bit.  It should be a consistent length. representing a steady speed.

The result is ARPA that is simply not usable.  I've worked through a wide range of tests and experiments with Navico support and engineering, and the installation has been scrutinized every way to Sunday and passed with flying colors.  Engineering finally reproduced what I have been seeing and agreed there was a problem they needed to fix.  This impacts both my radars (4G and 10kw open array), and based on reports from other Simrad owners, appears to be a long standing problem that has gone unnoticed until now. 

As part of testing, one thing Navico asked me to do was to acquire the same target multiple times.  They wanted to see whether there was any difference between the different targets.  The next video shows this.  I acquired the target three times, and you can see that two of the vectors are mostly in lock step with each other, but the other is pointing off in a different direction.  And all three wander around.

Problem #2:

Over on the right side of the screen you see a bunch of data boxes, include 3-4 larger ones showing various AIS targets.  My understanding is that these are supposed to be the closest target.  But you can see that there is no data in the data boxes.  You see a ships name in one case, and just the MMSI (ship's number) in the others, but there is no course or speed info, and no computed CPA (closest point of approach), or TCPA (time to closest point of approach).  If I look up these ships on Coastal Explorer (it also receives and displays the AIS data), all the info is there just as it should be.  So the receiver is working and the data is available, but the radar is not displaying it properly.  The targets plot correctly on the screen, but the data boxes are not filled in, and the CPA and TCPA is only occasionally calculated.

Missing AIS info

Problem #3:

The radar incorrectly reports the operational hours on the Magnetron.  A Magnetron is the part of the radar that generates the ping used to find targets.  It's the Flux-Capacitor for a radar, and it has a limited life span.  They are good for a few thousand hours, but when their time comes they need to be replaced.  So all radars have a built-in hour meter to keep track of this.

The Simrad 10kw radar reports a seemingly random number of operational hours.  The first time I looked, it reported 26,000 hours and I thought I had been sold a used radar.  But the next time it reported a very small number.  Simrad confirmed it's reporting garbage info.  I don't know how to maintain a radar under such circumstances.   I guess I need to buy an egg timer.

Problem #4:

Simrad advertises a feature whereby you can tell the open array what angle you want it to park at.  Most radars just stop where they stop, and this little feature was really interesting to me since it allows the radar to be parked where it doesn't shade my solar panels.  But despite numerous attempts to park the array in a predictable manner, I called Simrad tech support.  They told me that the feature didn't work.  Worse yet, they know it's not possible for it to ever work.  The radar has no brake, so they have no way to control where it stops.  WTF?  Talk about false advertizing.  Wow.

Problem #5:

This one is related to the park angle that doesn't work and can never work, so it's kinda moot, but it's reflective of the overall disregard for product testing before releasing it for sale.  You can go into the radar menus on the NSO and program in the angle where you want to array to park.  But when you turn the radar off, it forgets the angle that you programmed in.  So you need to reprogram it very time you shut down the radar.

Problem # 6:

This is another ARPA problem.  If you lock onto a target, then shut off the autopilot, the ARPA vector swerves off about 90 deg from the actual course of the target.  These two systems should have nothing to do with each other.  Why turning off the AP impacts ARPA is beyond me, but it does.  A friend tried the same experiment on his Simrad equipped boat and got the same results.

Radar comparison

I was asked for more detail on which radar I plan to use in Electronics 2.0, and about the differences between some of the radar models available.  This chart shows a feature comparison between radars focused on the key navigation features.  Note that all radars that I've ever encountered have Electronic Bearing Lines (ELB), and Variable Range Markers (VRM), so I haven't included them in the chart.

The issue with Simrad, by the way, is that the ARPA/MARPA heading vector is erratic.  Sometimes it's stable, but other times the heading swings all over the place (+/- 30 deg), and the speed (vector length) varies widely (+/- 50% or more).  It makes it pretty much unusable for figuring out where a boat is going and how fast it's traveling.  Navico says they are committed to fixing the problem, and I'm sure they will since it's such a glaring bug.  But it's been in the systems for a long time.  I know at least two people with Simrad radars that are 2+ years old the exhibit the same behavior.

You will see that the chart below covers Simrad and Furuno.  Notably missing are Garmin and Raymarine.  Why?  Well, because.  Just because a long time back I rejected them for various reasons - reasons that may no longer be valid - and have just never looked back at them.  If anyone wants to contribute the chart entries for those products, please feel free to send me the data and I'll add them in.

Feature	Simrad TX10s, and 4G	Furuno FAR2xx7	Furuno TZTouch	Furuno NN3D	Furuno 1835
ARPA/MARPA	MARPA	ARPA	ARPA	ARPA	ARPA
ARPA targets	10	100	30	30	10
ARPA Vectors	R, T (1)(2)	R, T (1)(2)	T	T	R, T
ARPA Track History	T	T	none	T	T
Echo trails	R	R, T	R, T	R, T	R, T
AIS Vectors	R, T (1)(2)	R, T (1)(2)	T	T	R, T
AIS Track History	none	T	none	T	T
Notes
1	AIS and ARPA vector settings are linked.  Changing one changes the other too.
2	Data box changes to report rCrs, rSpd, etc
	R=Relative
	T = True

What you can see from the chart above is that only Simrad and the Furuno stand-alone radars have support for relative motion vectors.  The more consumer oriented radars from Furuno don't have this important navigation feature, and they even dropped Track History in moving from NN3D to the TZTouch series - clearly a step backwards, in my opinion.  But when asked about it, Furuno said I was the first person to ask about it since the TZ was released.

I think what a lot of this says is that the vast majority of recreational boaters don't know how to really use a radar for navigation and collision avoidance, and until the last 6 months, I'd count myself among them.

I did a little poll on TrawlerForum to see how people use ARPA.  I would consider the audience to be among the more knowledgable in the overall population of radar owners.  32% didn't know what ARPA was or never use it.  And only 24% use it regularly.  The rest use it occasionally.  And even if you are among the minority who use ARPA on a regular basis, if all you have ever experienced is your Simrad ARPA, you would naturally assume that's just how it works.  That was certainly the case among my friends who have Simrad radars.  I only knew something was broken by comparison to my Furuno NN3D on my Grand Banks.  That's what got me digging into this.  But at that point I knew nothing about relative motion vectors, and when/why you would use them.

So I started reading books and trying to figure out whether the radar was messed up, or if I just didn't know what I was doing.  It turns out both were true.  Perhaps ignorance is bliss.  Between reading books, and taking a radar certification course, I now know a whole lot more than I did before.  I'm allegedly now qualified to operate the radar on any ship, of any size, anywhere in the world.  I'm not quite sure I believe that, but it's my story and I'm sticking with it.

Ironically, the Simrad radar is the most feature-complete of the consumer-oriented radars, having the key features that Furuno's NN3D and TZTouch do not have.  Hint, hint, Furuno.  Except for Simrad's extremely broken ARPA, I would likely be happily using my old system today.

I was asked which of the Furuno FAR2xx7 models I plan to use, and whether I'll use it with one of my existing monitors.  I'm planning on either the 2117 which is a 12kw open array, or the 2127 which is a 25kw open array.  In both cases, I'll be using the Black Box version which just means I'll be using my own monitor.  The video output from the radar is 1280x1024, or 1600x1200.  I know 1280x1024 works well on my monitors, though it leaves black bands in the unused space given their 1920x1080 native resolution.  I'll also try running at 1600x1200, but expect the scaling will degrade the image enough to make running at 1280x1024 preferable.  After all, I'd only be losing 27 lines top and bottom by not utilizing the full 1080 height of my screen.  But experimentation will ultimately decide.

Electronics 2.0

I've been through countless variations of many different plans for my electronics version 2.0 to replace the Simrad suite that is riddled with bugs.

I considered adding a high-end radar as the primary, and keeping the rest of the Simrad gear.  But there are just too many other issues, and no sign that Simrad will get them fixed in any reasonable time frame.  We are heading to Alaska in the spring, and I want to have a solidly working system by them.  Besides, if I kept one of the Simrad radars, it would have to be the 4G.  I don't have room for two open arrays without major reconfiguration of my stack.  And I have been woefully unimpressed with the 4G radar.  I'd say the Emperor has no Clothes.

It's a bit of an apples to oranges comparison, but I haven't found any situation of any kind where the 10KW open array didn't outperform the 4G.  And that includes close in situations where the 4G is supposed to be all super duper.  And although I've never run them side by side, I think my Furuno 4kw dome outperformed the 4G as well.  And there are a number of situations where the 4G simply did not pick up targets at all, and we are not talking about sticks floating in the water.  We are talking about boats that I can see with my naked eye.  If I can see better than the radar, something's wrong.  The other issue with the 4G is interference from other radars.  When you are in close with another boat that has a beefy radar, you get all sorts of interference on the 4G.  The streaks in the picture below show a a very moderate example, and it tends to happen when you are in close with other boats.  I've had other situations where it pretty much obscures the whole screen.  So you go blind just when you need radar the most.  Now that's helpful, isn't it?

Interference on 4G radar from another boat

So the problem became what to do about a secondary radar.  I'm not willing to go venturing far and wide without a backup radar.  It's one of the most important navigation tools on a boat, and a backup is mandatory for any long distance or remote cruising.  I considered the Furuno TZ black box which could control a second radar, and can also control a fish finder thereby restoring that functionality too.  Then someone pointed out that I could run two radars off the TZ and not have to buy the giant and expensive commercial radar.  I'm not a fan of the Furuno NavNet3D or the TZ, but I figured that I could suck it up if all I was using it for was radar control.  So for a few days I was pretty excited about this approach.  With the TZ as a single point of failure I would have to carry a spare, but I was planning to carry a spare NSO as well for the same reason.  Then the excitement came to a screeching halt.

I discovered that the TZ is missing two key radar features - features I consider to be mandatory - and features that even Simrad has.  They are 1) Relative motion vectors for AIS and ARPA targets, and 2) target history tracks.

Tracking relative motion is the foundation for collision avoidance.  One of the first things you learn in any boating safety class is how to tell if you are on a collision course with another boat.  You sight the bearing to the other boat, and monitor it over time.  If the bearing remains the same and the boat keeps getting closer,  you are going to crash.  Said another way, that boat's relative motion is directly towards you.  If the boat's bearing moves towards your bow, the other boat will pass ahead of you.  If it's moving towards your stern, it will pass behind you.

Radar can be used to figure out the same thing, either manually by marking positions with a grease pencil, or using more modern tools like ARPA (Automated Radar Plotting Aid).  ARPA tracks the targets position and calculates both it's true course and speed, and it's relative course and speed.  From these it can also calculate the closest point of approach (CPA) which is how close you will come to one another, and the time to closest point of approach (TCPA) which is when that closest encounter will occur.  All this can also be done manually, but it's way easier to let a computer do it.

The relative motion vectors that I was talking about earlier are just arrows emanating from the target showing its direction and speed.   On any commercial radar you can select whether you want those vectors to show true motion or relative motion.  True motion is much more intuitive to look at, but it leaves you guessing about collision risk, doesn't tell you whether you will pass ahead of or behind the other vessel, and doesn't let you see how you should alter course to achieve a safe passing distance.  Let's say, for example, that your radar is reporting a CPA of 1/4 mile, and you want 1/2 mile.  Which way do you turn to increase the passing distance?  If you turn the correct way, your CPA will increase, but if you turn the wrong way, it will decrease even more.  You need to know whether the boat is going to pass in front of or behind you to know which direction to turn to increase your distance.

Enter relative motion vectors.  Switch modes, and now you just look to see where the target's relative motion vector is pointing compared to your position.  If it's pointing at you then you are on a collision course.  If it points ahead of you then the target will pass ahead of you, and if it points behind you he will pass behind you.  It's a very important tool, and I have to say I'm really surprised that it is missing in the TZ.  To me, that makes the TZ radar unsuitable as a primary radar, and a compromised as a secondary radar.

The second missing features is target history track.  This are nothing more than a dot dot dot trail showing where the target has been.  Target trails are not to be confused with echo trails.  Echo trails are a modern synthesized version of the long afterglow on old radar CRT screens.  They are like comet trails behind anything that's moving.  They show the same thing as a target history track, but history tracks only apply to AIS and ARPA targets where echo trails apply to everything that moves.  So land, for example, all has a big comet trail behind it as you move past.  This quickly becomes distracting and you need to clear the trails and let them reform.  History tracks only apply to the things you care about and don't otherwise clutter up the screen.
 
So all this brought me back to the Furuno commercial radar as the only option for a primary radar.  This radar, by the way, finds itself in some pretty impressive places.  This is the Nimitz-class aircraft carrier Carl Vinson

Furuno FAR radar on USS Carl Vinson

Back at the drawing board, I started looking at low-end stand-alone radars, and guess what I found?  All the Furuno stand-alone radars have all these features.  Even the $3500 complete system with 4KW dome.  Now that's very interesting for a secondary radar, but where the heck do I put that screen?  I'm really jammed for panel real estate.

And what about the fish finder?  With no TZ, how do I display that?  I'm not a big fisherman, but I still find it very helpful to get a good view of the bottom and don't want to give it up.

Next stop was the Seattle Boat Show, and there I found answers.  First, I saw the smallest dedicated radar, the 1835, and it's a really cute little thing about 12" square with nice dedicated knobs and dials for quick radar control.  No hunting around in menus.  I figured worst case I could keep it in a drawer and break it out and plug it in when needed.

Next was the small dedicated fish finders.  Again, the smallest one is only about 7" square and again has knobs and dials dedicated to it's function.  And that little screen is plenty for what I need.  And cost is no more than the fish finder box that I would have needed with the TZ.

So that's the plan.

- Two dedicated furuno radars, one little and one big.

- A dedicated fish finder.

- Dual Furuno NavPilot 700 auto pilots.  Unlike the Simrad pilot, you can actually build up two independent pilots using the Furuno gear so you really have a hot standby.  When I was first evaluating the Simrad gear, I sketched out a dual pilot system and Simrad told be in no uncertain terms, confirmed in writing, that it would work as I expected.  Well, after hours and hours and lots of swapped out equipment, I can tell you with certainty that it DOES NOT work.  Simrad now confirms that it doesn't work, and has never been designed or tested with dual pilots in mind.  Anyway, the Furuno pilots let me finally build the dual system that I wanted from the start.

One of the hallmarks of this new approach is that I have no integrated multi-function display (MFD) or black box.  These multi-function systems, though great in concept, seem to be a big source of bugs.  And I'm finding that their functionality also tends to be a compromise.  But really the only thing I lose by getting rid of the galactic integrated black box is radar overlay on a chart.  Oh, well, it's worth it to have a properly functioning and featured radar, and an auto pilot that works predictably.

Simrad Wall of Shame

To kick things off, let's talk about Simrad.  This posting isn't about specific issues - those will follow. 

This is the culmination of a long battle.  I have been finding and reporting problems with my suite of Simrad equipment for about 6 months now.  In that time, out of 25 problems reported and documented, exactly one has been resolved. 

Now I'm sure you are all thinking "this must be an installation problem".  Nope.  The installation has been checked and verified and passed with A+ grades.  All of the problems are confirmed product bugs.

The biggest issue is that the Radar ARPA function that lets you track targets and project where they are going, is seriously broken.  Rather than giving a stable, consistent predictor, it instead wonders all over the place.  As a result, it's not usable, and ARPA is a key element of collision avoidance in poor visibility.  So the radar needs to go.  And the ARPA problem affects both radars, so they are both unusable for navigation.

10KW open array radar removed

4G Radar removed

Next is the auto pilot.  It steers the boat really well - no problem there.  But there seem to be all sorts of interactions with and among the various devices that cause all sorts of other erratic and unpredictable behavior.  The system is powered up and down via a button on the AP control panel.  That button is supposed to power up/down the control panel and the 4 follow-up steering levers that I have.  Sometimes when you power it up, it's not able to discover all the components and generates an alarm.  Sometimes when you power it down, only some of the components turn off, and the others generate alarms.  It also has a feature by which you select which heading sensor to use.  Sometimes the AP remembers the setting across power cycles, and sometimes it doesn't.  So the auto pilot has to go.

Radar controllers removed from overhead

Then there is the ripple effect.  With the radar gone, the multi function black box computer is of little value since it can't display or control any other vendor's radar.  So it goes too, along with its control keypad.  But it's also the only way to operate the black box fish finder, so that has to go too.  The net result is that every piece if Simrad equipment except the Sat Compass (which still has some problems) has been removed from the boat.

Going

Going

Gone

Now everything is in a big box awaiting return to Simrad.  They are doing the right thing by taking the equipment back, but I am still taking a huge bath on the installation and de-installation costs, not to mention the cost of replacing everything with other equipment that hopefully works better.

Simrad Box of Shame

The Wall of Shame

I've decided to start a new category of postings detailing all the things I run into that are broken with marine electronics.  It's really pissing me off, and I think the only way to start getting vendors to put more focus on quality and testing is if we the consumers start pushing back on them.

This stuff is navigation equipment.  We navigate so our boats don't run aground, sink, and kill people.  In other words, this stuff matters, and it needs to work and work reliably.  These are not iPhone apps.  This is not social media.  These are not office applications.  Re-boot and try again is not an acceptable solution to a problem.  This stuff can be life or death.  It's right up there with medical equipment, and needs to be largely bug free.

I'm really dismayed at the seemingly steady flow of problem that I'm encountering with equipment.  The gear doesn't go up in smoke, but rather is riddled with bugs of all sorts.  Some big, some small, but even the small one in large enough quantity add up to equal big problems.  If nothing else, it erodes confidence in the equipment.

This series can be accessed by clicking "Wall of Shame" in the Categories section on the right side of the screen.

Let the Shame begin....