Autopilot taken over by "Smart Device"?

[ProjectManaia]

Hello everyone,
We have a Simrad Autopilot on board, that worked flawlessly for years.
It is a NAC-3 controller, hydraulic drive, has a Simrad heading sensor as well as a backup heading sensor we added as we realized people with cellphones sitting next to the existing antenna make the autopilot a little crazy. Anyways, that problem was solved. We also have the Bluetooth remote for the Autopilot which never gave us headaches either.
This year all of a sudden from time to time the autopilot simply goes in to NFU (Non Follow up) and goes hard to port. This happens both, with engaged heading hold, but also in the middle of the night on anchor when it is in standby.

My suspicion is that some smart device for some reason taps into the Bluetooth and doe this but I could not confirm anything. We have a crew of 10 on board that switches every two weeks and the problem usually appears for one of those periods and then all is fine for the other crew. So really I was wondering if someone had a similar issue and how you went on with tracking down the source of the problem.

All thoughts and pieces of advice would be wildly appreciated!

[stevead]

My suspicion is that some smart device for some reason taps into the Bluetooth and does this but I could not confirm anything.

I think it is extremely unlikely that a mysterious device will pair to the WR10 Remote Base station and generate random data that magically transforms itself into a set of commands that interact with the autopilot.

Next time it occurs, goto your MFD, goto Settings->Network->Diagnostics->Save CAN data and send the resulting data to Navico or your dealer for analysis.

If you truly think the fault is caused by the Bluetooth remote, either disconnect the WR10 Base Station from the NMEA 2000 network or relocate it somewhere else and see if the problem persists.

Good luck, it sounds like a weird problem.

[ProjectManaia]

Thank you for the advice, I will try the Data saving and send the files (not sure yet how I will get them off the system, but will work it out..)
As I said before, this is really just a suspicion, I just don't know what else it could be? Why would the autopilot just randomly fire up and turn by itself? It should get an impulse from somewhere to start doing things (at least that would be my thinking)... But very open to hear any other thoughts.

[stevead]

I will try the Data saving and send the files (not sure yet how I will get them off the system, but will work it out..)

There is a cheat sheet in this post that describes how to import & export routes, waypoints and tracks from a Zeus/Vulcan chartplotter over the network. If your chartplotter and PC are connected to a WiFi or Ethernet network then you could use that approach to download the data capture files. Otherwise you will have to manually copy the files to either a SD card or USB memory stick depending on your chart plotter.

IIRC correctly they are archive files named using a date, something like 2019-7-14_15-16.canlog.tar. They contain the captured NMEA 2000 traffic. Off the top of my head I can't remember which folder they are contained in.

If you wish, you can send a PM to me with a copy of the data capture file and I will try and analyse as best I can.

The autopilots only do things when they receive specific commands over the NMEA 2000 network. Unless there is some fault, I wouldn't expect the autopilot to perform an uncommanded action.

[ProjectManaia]

Thanks a lot for the detailed response, I will wait for things to happen again and follow the guidelines. As I won't have any idea what I am looking at/for any more skilled pair of eyes would be appreciated so. thank you for that offer! In the meantime I will try look for other reasons for this to happen... there must be SOME issue somewhere...just a matter of tracking it down I suppose...

[donradcliffe]

I would look at every cable connection for corrosion. However, your heading sensor should never be in an area that is well marked for "No Metal".

[deblen]

Your first post says it will go hard over,both in standby mode and in pilot mode-
plus it displays NO(n) follow-up(rudder angle sender).
I suspect the fault may be limited to intermittent loss of "rudder sensor/angle sender" info.
Suggest disconnecting RFU at processor & checking RFU with an analog ohmmeter to see if there are any bad spots in it's pot.Also check RFU 3 wire cable at RFU,along it's length & at processor.
I can't see it being a compass problem because compass is effectively disconn. when in STBY.
In STBY,the only things that can command a rudder turn is the "power steer" function,which skips most of the "computer" stuff & acts directly on the P & S ram output. This rudder turn command can come from the control head keys or remote buttons,or possibly,a NMEA signal from another "course change" driver such as plotter XTE,etc.
Are any P or S buttons getting "touchy" from age/heat/etc?


Just some thots.
Cheers/Len

[ProjectManaia]

Thank you for the response!All the buttons ar in good shape, protected from sun a nd heat... I will check the rudder sensor for sure, but when I checked the connections all was good.
RFU means the rudder angle device? I will certainly have a look at that, not easy to get to (as for most I suppose) but will get it done
Thanks again for the responses!

[donradcliffe]

You should be able to check the rudder sensor by looking at the display while you turn the rudder. Turn slowly and look for smooth response on the display before you start tearing anything out.

[ProjectManaia]

Originally Posted by donradcliffe

You should be able to check the rudder sensor by looking at the display while you turn the rudder. Turn slowly and look for smooth response on the display before you start tearing anything out.

Oh, that I already did, works flawlessly. So there is no issue on that end. at all... I will however keep investigating and post here should I find the source of the problem!
Thanks again for all the feedback!

[stevead]

Suggest disconnecting RFU at processor & checking RFU with an analog ohmmeter to see if there are any bad spots in it's pot.Also check RFU 3 wire cable at RFU,along it's length & at processor.

This suggestion can be ignored. For NAC-3 autopilots, the RFU is either a RF25 which is connected to the NMEA 2000 network and transmits PGN 127245 messages or a RF300 which connects directly to the NAC-3 and outputs an analog signal with a variable frequency. Neither of these can be diagnosed/measured with an ohmeter.

I can't see it being a compass problem because compass is effectively disconn. when in STBY.

The Precision 9 compass is connected directly to the NMEA 2000 network and is always on when the NMEA 2000 network is powered up. There is no notion of the "compass being disconnected" when the autopilot is put into standby.

I suspect the fault may be limited to intermittent loss of "rudder sensor/angle sender" info

That would not explain why the autopilot moves the rudder when the autopilot is in standby. Also the NAC-3 incorporates "Virtual Rudder Feeback" so it can actually operate without a dedicated RFU.

I think it is extremely unlikely that a device on the network is erroneously transmitting autopilot commands.

Quick question, do you have a Follow Up control installed on the boat? If so, then is it possible that someone is bumping it, or could there be a fault with it or in its cabling connection to the NAC-3? Other than a fault within the NAC-3, or a short between the mains supply and the connection to the drive unit, that is one thing that could cause an unexpected movement of the rudder and cause the display to indicate that the autopilot is in NFU mode. It is also possible to change the autopilot mode from Standby to NFU mode by pressing either the port or starboard buttons on the MFD or remote.

(BTW, this feature is perhaps under appreciated by many sailors, that they can invoke NFU mode on their autopilot and use it as an emergency rudder control in the case of a steering cable break. This assumes the autopilot drive has an independent link to the rudder.)

[s/v Jedi]

This behavior indicates something pushes “a left arrow” button. When you do this in standby mode, it will engage NFU mode.

I would disconnect one device that can do this at a time and see if it has effect. Example: disconnect one Triton AP controller. Or the wireless remote. Or shutdown the plotter. Thus should isolate the offending device.

[TeddyDiver]

I recall a couple of similar incidents some years back, other one caused a collision. Don't remember any details thou.

[ProjectManaia]

Thanks for all the feedback,
So looking at the answers the common point seems to be a "stuck button" or button someone bumps.
Trouble is the only thing with buttons is the remote (as in left and right buttons) and upon pushing those nothing happens with the Autopilot in standby (*just tested now).
The control unit is a multifunction display, so again there is a button to choose "Auto", "Standby",m "Menu" or "Mode"
Neither of those is easily accessible though (certainly not by accident).
Which leaves the chartplotter that can control the AUtopilot and that as well is off when on anchor with AP off... so that sort of knocks out the button option.

I did check the cable connections on everything by now, and traced the cables, could not see any (obvious) kinks, bad connectors or alike, so I remain puzzled and on a search... Will keep investigating and updating here ones I find out anything!

[deblen]

Originally Posted by stevead

This suggestion can be ignored. For NAC-3 autopilots, the RFU is either a RF25 which is connected to the NMEA 2000 network and transmits PGN 127245 messages or a RF300 which connects directly to the NAC-3 and outputs an analog signal with a variable frequency. Neither of these can be diagnosed/measured with an ohmeter.
The Precision 9 compass is connected directly to the NMEA 2000 network and is always on when the NMEA 2000 network is powered up. There is no notion of the "compass being disconnected" when the autopilot is put into standby.
That would not explain why the autopilot moves the rudder when the autopilot is in standby. Also the NAC-3 incorporates "Virtual Rudder Feeback" so it can actually operate without a dedicated RFU.

I think it is extremely unlikely that a device on the network is erroneously transmitting autopilot commands.

Quick question, do you have a Follow Up control installed on the boat? If so, then is it possible that someone is bumping it, or could there be a fault with it or in its cabling connection to the NAC-3? Other than a fault within the NAC-3, or a short between the mains supply and the connection to the drive unit, that is one thing that could cause an unexpected movement of the rudder and cause the display to indicate that the autopilot is in NFU mode. It is also possible to change the autopilot mode from Standby to NFU mode by pressing either the port or starboard buttons on the MFD or remote.

(BTW, this feature is perhaps under appreciated by many sailors, that they can invoke NFU mode on their autopilot and use it as an emergency rudder control in the case of a steering cable break. This assumes the autopilot drive has an independent link to the rudder.)

Thanks for education on NAC-3. I am old school & have never worked with NAC-3. Cheers/Len