Adding to the group gestalt on this one . . .
New Chartplotter (existing A/P)
When we acquired our 2003 SM #396, then MOONSHOT, now PERIGEE, in Newport RI, Oct’16, the previous owner had started down the path of moving to NMEA2000. The basis was a new Furuno Chartplotter and DRS4 radar; integrating AIS (Furuno FA-50) via Furuno Ethernet into a Furuno NAVNet TZT14 display, situated at the NAV STN in the ledge where the original radar display was located. There were indications that a sister or compatible Furuno Chartplotter unit had also been installed at the helm, but this had been removed by the time the boat was placed on the market.
In any case, at the time of purchase, in order to facilitate access to the TZT chartplotter data at the helm (e.g. radar/AIS), a bracket for mounting an iPad had been installed above the engine instrument binnacle. This was presumably to take advantage of the built-in WiFi capability of the TZT chartplotter, to pair with an App on an iDevice, which we have done successfully. The iPad can be either “Read Only” (simply mirror the screen of the TZT at the NAV STN), or you can grant access privileges to allow the iPad app to control the TZT chartplotter from the helm (or any other) connected iDevice. Both modalities work, in a fashion – sight delays in screen-build and refresh.
The original 400-series RayMarine autopilot was still in place – linear drive only, no rotary. I had thought to install a rotary drive to supplement the linear drive, but ultimately decided to ‘keep it simple’ from a spares perspective, and hence stayed with all linear-drive only. Perigee came with a new (still-in-the-box) linear drive, so this helped the decision.
Note: at that time, we did not have a back-up rudder position sensor, either installed or in spares. I believe that the RM 400-series A/P absolutely needs a rudder sensor to function; but reading the literature of later generation RM A/Ps (e.g. the ‘Evolution’ system), manually calibrating the “Hard Over Time” might also be possible in lieu.
The original 400-series RayMarine A/P had been upgraded with the addition of the SHS (Smart Heading Sensor which is, basically, a Rate Gyro to supplement the original flux-gate compass), so was about as good as a 400-series unit can get (I think this addition takes the standard -400 to the “G” spec). We were certainly more than happy with the performance and reliability of the system. The control head was (if I recall correctly) a ST-7001+, as commonly installed, and was all that we needed or wanted. BTW, the new EVO-400 A/Ps can interface with the legacy ST-7001 control head, and the -7001 may even be a better solution in some cases; such as, for example, changing display illumination is quicker and easier on the ‘old’ 7001-series control head. The only ‘glitch’ we encountered with the original A/P was when we spent an extended period in a slip with the wheel lashed firmly amidships.
The rudder sensor developed a ‘weird spot’ at the point where the rudder had been lashed. I conclude that this was due either to some minute wear or corrosion of the sensor mechanism at that exact spot. The fault was evident for a week or two after getting underway again, with the A/P indicating “no rudder sensor” whenever the rudder position was at just that spot, at which point the A/P would alarm and drop into standby. This fault eventually went away, but our experience may be instructive regarding lashing the wheel too firmly – some degree of movement may be more desirable than not.
Regarding NMEA interfacing. The RM 400-series A/P uses -183 to communicate with the outside world. To accommodate this, a Furuno NMEA black-box interface was used to create a bidirectional bridge between the -183 A/P and the NMEA-2000 backbone used by the new Furuno TZT Chartplotter (and, from the chartplotter, via the Ethernet network, to/for the Radar). The HEADING information from the A/P was used as the HDG input for the Chartplotter display and Radar Sensor. Active ROUTE info from the chartplotter enabled A/P TRACK functions (great when motoring for extended periods). WIND information from the HYDRA-2000 processor (still with analogue sensors at that time) was made available to the NMEA-2000 network by yet another Furuno NMEA interface box, to provide an input to the chartplotter for True-wind calculations and also, importantly, for provide wind data to the A/P thereby enabling the WIND VANE functions. This set-up exceeded expectations. But I did (eventually) discover these 183>-<2000 interface boxes to be the source of annoying 1Hz electrical interference that affected HF/SSB reception.
When the SONIC SPEED unit failed – whether sensor or processor, as yet unknown – we researched replacements for the Sonic Speed, but could find none (we found out later that a drop-in replacement for the Sonic Speed WAS available, we just couldn’t find it.). Anyway, the failure of the sonic speed precipitated the transition to replace the analogue sensors with digital ones (initially boat speed / STW). We settled on the DST800, using the same through-hull as the analogue depth sounder. Rather than doing digital-analogue inputs to the Hydra, we elected to expand the N2K backbone to the junction area at the base of the main mast, and then make an additional N2K drop near the A/P to feed new digital displays at the helm. We replaced the 5x B&G analogue instruments at the helm with 3x B&G Triton2 MFDs. We have been very happy with this set-up.
We held the analogue wind sensors for the time being, using the pre-existing Hydra-183<->N2K bridge to send data onto the N2K network, from which the new digital displays at the helm received their data. Worked first time, as it should.
All functionality for the RM-400G A/P was preserved: heading OUT to the radar/chartplotter, and RTE and WIND IN for the A/P TRACK and Wind Vane modes respectively.
When we had the masts off for the replacement of the standing rigging, we replaced the analogue wind-sensors on the top of the main mast with a digital MHU (at the same some extending the new N2K backbone to the mast head).
Shortly afterwards, we then changed out the legacy RM-400G A/P, to be replaced by the latest RM EVO-400 system. The 183>-<2000 interface box for the auto-pilot was replaced by an expensive RM cable to bridge the RayMarine proprietary SeaTalkNG network to the N2K network. But other than that, the new A/P install was ‘out of the box’. At the same time, I replaced the old rudder sensor with the new one that came with the EVO-400 but, strictly speaking, this was unnecessary. I also replaced the old linear drive with the one we already had in spares.
I then serviced the old linear drive – replacing the clutch & brushes – before returning the refurbished unit to spares. This was a morning’s work, if you have the parts on-hand, and an uncluttered work-bench ashore, which made it a fearless task. Knowing that the new linear drive was already installed and working also de-stressed the work programme.
To provide redundancy for the A/P brain and other components, we then bought another complete EVO-400 A/P kit (Sail version); it has an earlier version, with a more rounded control head, but otherwise functionally identical. I upgraded the firmware on the back-up EVO-400 CPU (the Starship enterprise thingey) to the latest-but-one version (couldn’t see any positives about the very latest version, and perhaps some potential downsides); the Control Head needed an update to the latest version; and the Grey Box was already up-to-date. So the firmware on all components of the installed and backup-in-a-box systems are the same. I know that having different variants shouldn’t ever be an issue, but I took the trouble to check and do so, “just in case”.
With all-digital sensors, and new helm displays, the Hydra-2000 processor and display at the NAV STN became redundant, and was electrically disconnected. But it remains in place until we decide what to do with the hole.
With the Hydra-2000 decommissioned, we missed having a nice big readout of the wind at the NAV STN. Whilst underway, we do get a readout of NAV parameters – including wind, apparent & true - on the TZT14 chartplotter display, via a configurable pop-out side bar. But at anchor, having the chartplotter on chews more juice (and pumps heat into the cabin), so we installed a B&G Vulcan7, the smallest unit that would provide WiFi connectivity (the Vulcan5 did not, and in any case has now been discontinued). We chose B&G, simply for similarity with the Triton2 displays at the helm. We did consider putting another Triton2 MFD downstairs at the NAV STN, but for a small sum more we get more functionality (including the WiFi, which we don’t use at the moment, but fully expect to in time). And we also like the thought of a backup, albeit smaller, chartplotter at the NAV STN. Even though we have not put on a set of charts, it has a basic basemap, and may be able to provide a limp-home functionality if ever needed. Also, importantly, it has its own built-in GPS (that can be put onto the N2K network, although we have inhibited this for the time being) AND the unit can, if we want, also output route (and wind) information onto the N2K network for the TRACK (and wind-vane) function of the autopilot.
The disappointment of the whole set-up is that we are unable to port RADAR or AIS data off the FURUNO CanBus or Ethernet networks, and onto the N2K backbone. Meaning that we do not have RADAR or AIS at the helm, unless we add a Furuno MFD at the helm, or run the Furuno APP on an iPad. As we already use a completely independent NAV-only solution at the helm for situational awareness (iSailor), we do not often run the Furuno app on the iPad. As a result, electronic conflict resolution, via either RADAR or AIS, is mainly done downstairs at the NAV station. This is a matter of choice, to reinforce that watch-keeping is primarily visual, and the watch-keeper’s job is to keep their head up and eyes out of the cockpit. So keeping the RADAR and AIS away from the helm discourages the person on the HELM from getting distracted by being “head down”. We have found this also encourages and reinforces team-work and communication in tight situations, having 4-eyes instead of 2 working a problem. But in normal solo-watch situations, someone sitting at the helm can easily see the chartplotter at the NAV STN, and any AIS (or radar) target of interest can be readily seen. With the basics established, we have only just started to set the AIS and RADAR proximity alarms.
All that said, having AIS data on the N2K network would be a welcome enhancement, as we could then use one of the Triton2 MFDs to show proximate AIS traffic. To that end, we are looking at supplementing the current Furuno AIS (Ethernet-based FA-50) with another AIS unit. Current thinking is that this might be something like the Vesper Marine WatchMate XB-8000, which has the added benefit of providing a N2K gateway, with WiFi and USB connectivity also built-in (e.g., to feed OpenCPN on a computer and big-screen, as Steve on SV ALOHA does).
The other thing in mind is to re-wire the NAV STN. The reason being that, we now have a host of 24-to-12V DC-DC converters powering the various boxes at the NAV STN (i.e., 2x for the TZT Chartplotter, others for VHF, AIS, Ethernet HUB, Radar PWR supply, and WeatherFax, for example). These converters are supplied from a common rail, which is powered up by the single NAV STN Circuit Breaker in the hanging locker. Meaning that just to get the VHF up and running, for example, we have the whole current draw for all those converters, whether or not any of the downstream equipment is on. We are thinking to insert a separate switch panel to direct power to the individual DC-DC converters, which then power their respective equipment. But that’s a topic for another day.
Minimise risk during transition: we were able to preserve the original functionality along the way, with minimal risk of ending up with black screens because of a single fault. We achieved this by adopting an incremental approach, rather than going ‘big bang’. (Basically, we were doing a “cruising re-fit” and wished not to be tied down if a glitch in supply or installation might mean that we needed to go to sea with limited (or no) navigation, communication or surveillance capability.)
Ooops – a single point-of-failure: Now, the whole N2K network is being fed from a common power supply (the Furuno TZT chartplotter). Recently, we had to have the chartplotter out to be returned to Furuno for repair (another story). Which took down the whole N2K network. (We did have a separate 12V-DC power connector at the ready, just in case, but it was unnecessary.) One thought is to provide power to electrically separate A and B sides of the N2K network (keeping a common data-path), and establish the ability to provide 12V-DC separately to either side, independent of the Furuno chartplotter. Basically, the ‘A’ side, which links sensors to the NAV Station, and ‘B’ side which takes data to/from the NAV STN from/to the helm & A/P controller.
Prior understanding is necessary – one can never do too much homework: In order to keep upgrade costs from making a startling up-tick near the end, a decision regarding the overall orientation of the upgrade path needs to be made at an early stage. A clear picture of the end-state needs to be established. In my case, this was to keep as closely as possible to the ‘as factory fitted’: RayMarine for Autopilot, Furuno for Radar (& Chartplotter), and B&G for Sensors & Instruments. I didn’t have a choice about the Furuno Radar & Chartplotter combo, but are nevertheless happy with the choice made by the previous owner. So this was no biggie. But getting to the A/P, it is less clear. Knowing what I do now, it may have been better to keep the Raymarine Linear Drive and Rudder sensor, and move to a B&G A/P (brain, control head & heading reference unit). This would have gotten away from the Raymarine SeaTalk NG, and placed everything (except AIS & Radar) on the N2K network and allowed all data from the B&G sensor suite to be available on the B&G A/P Control Head which would, as an added benefit, enable to use the B&G Vulcan7 downstairs at the nav station to also be an A/P controller (either as a secondary whilst on-watch below, or backup should the helm controller fail). Or, go all Raymarine, keeping the RM A/P, using RM for the sensor & display package (i.e. the i70s, as per ALOHA), and a smaller auxiliary RM MFD (or just an i70s) below at the NAV Station (to replace the Hydra 2000 display). We are not unhappy with the present status quo, but one always wonders what might have been done better.
If any questions, please do not hesitate to ask. We are relatively stationary for a few weeks, and minimising ‘boat projects’ during this time, so I should be fairly responsive to requests.
SV Perigee, SM#396
Spanish Water, Curaçao