Raymarine experts? ACU400 comm problem.

[LeoKa]

I have a few years old 12V Raymarine autopilot system. Everything was doing well since installation, but recently the ACU400 is having communication problems.
Soon after I turned on the autopilot yesterday, within a minute, I received a ' No pilot ' error. Luckily the trip was just about an hour, so I was able to hand steer back home.
My system is all hydraulic, so the pump connected to the ACU400 was not absolutely necessary. I could steer the independent hydraulic steering.
Before I left the marina, I have updated all the devices to the latest software. See photos. I don't think this issue is related to the software updates. I had similar situation twice last Fall during a two days river cruise, but it recovered all the time.

The whole system is SeaTalkNG wired. There are two blocks involved to connect all the devices and I tested each device by disconnecting each cable. They all seem to work. I did the same with the breakers and fuses. All good.
The ACU400 is providing power to the SeaTalkNG network 12V, so there is no other power source involved, except for the Axiom MFD, which requires its own 12V. The transducer for depth and speed is connected to the ACU400 and that works, because it shows the depth on the displays. So, the data goes through the wires just fine.
On the photos you can see the tested data sources displayed by Axiom7 and the Heading source is missing, cannot be detected.
I tried the Raymarine Forums, but I could only find old entries and no solutions. In the past, the recommendation was to send the unit in for testing/repair, if it was possible. If not, they will still charge you and/or offer you refurbished/new units to purchase. That is the last resort, as these units are around $2K new.
Any advice for further troubleshooting is appreciated.

 

[LeoKa]

I found this on Raymarine Support:

Question
How can a Seatalk NG cable, cables, cabling be fixed and / or tested?
Answer
Troubleshooting a SeaTalkng communications failure

Conflicts between data sources may present symptoms of a SeaTalkng communications failure. When the system features more than one source for any type of data, it is necessary to ensure that the Data Sources feature has been utilized to specify which resources will be used by the system for each type of data (GPS, Wind, Depth, etc.) for which two or more sources are present within the system. As such, prior to proceeding with troubleshooting apparent SeaTalkng communications failure (NO AIS, NO FIX, etc.), it is recommended that one first verify that the Data Sources feature has been properly used. Additionally, should the system feature an AIS350, AIS650, or AIS500, it is recommended that one verify that the AIS350, AIS650, or AIS500 has been interfaced by one communications protocol only (i.e. either SeaTalkng (preferred) or NMEA 0183, but not both).

Should the the Data Sources and AIS receiver/transceiver points raised above have been satisfied, and a SeaTalkng communications failure persist, then it is recommended that the vessel's batteries be fully charged, and that after charging and while connected to shore power that the problem be duplicated. Should the problem not be able to be duplicated under these conditions, then the problem may have resulted from insufficient power, and it would correspondingly be recommended that the power issue be addressed by one or more of the following:
- the vessel's batteries be load tested and replaced depending upon the results of the load tests,
- additional house battery storage be added to the vessel,
- the vessel's charging system be operated more frequently,
- the vessel's charging system capacity be increased.

Should one be able to duplicate the problem while connected to shore power, then it is recommended that the following be verified:
- the backbone be inspected for
----- proper termination,
----- the SeaTalkng backbone's power insertion spur has been located at the approximate midpoint of the SeaTalkng backbone's LEN load
----- if a SeaTalkng backbone power insertion spur has been installed and a Raymarine Evolution ACU200/400 or SPX10/30 autopilot course computer has been installed, that the ACU or course computer's SeaTalkng POWER switch has been configured to the OFF position. Note: it is considered a best practice that the SeaTalkng backbone be powered via a power insertion spur (ex. T-Piece, 5-Way Connector spur socket).
----- maximum total spur length (6m) not exceeded,
----- no more than 3 devices daisy chained within a spur,
----- proper splices,
----- signs of cable damage (cuts, kinks, crush, etc).
- check the resistance of the backbone's two termination plugs ... the measured resistance across its CAN_H and CAN_L pins should be 120 ohms.
- with the backbone powered OFF and one of its two termination plugs removed, check the resistance of the backbone across the CAN_H and CAN_L pins of the backbone socket which had its termination plug removed to verify that it is 120 ohms ... if not, then devices should be removed one by one until it is determined which device is causing the resistance to not be as expected ... should any such device be identified, then it should be sent to Raymarine’s Product Repair Center to be bench checked / serviced.
- with the backbone powered OFF, the aforementioned termination plug should be reinserted into its backbone socket and then the other termination plug should be removed. The resistance of the backbone across the CAN_H and CAN_L pins of the backbone socket which had its termination plug removed should then be checked to verify that it is 120 ohms ... if not, then devices should be removed one by one until it is determined which device is causing the resistance to not be as expected ... should any such device be identified, then it should be sent to Raymarine’s Product Repair Center to be bench checked / serviced.

 

[LeoKa]

And this:

Raymarine FAQs

teledyneflir.my.site.com

 

[boomerang]

Way too much reading for me to do after cocktail hour but from your picture, on the control head, I can't tell if you've lost your rudder position also, which would mean the computer corepack is at fault. If you have rudder but no heading, it is possibly the EV-1 heading sensor. One of the drawbacks of Raymarines old seatalk 1 system was if any of the equipment in the seatalk line failed, it would cause the whole system to fault. In other words, if the gps antenna crapped out, the pilot would go into the "no pilot" mode because it saw a fault on the line.
I would isolate everything except the basic pilot and it's essentials and see if it still fails. I know on the seatalk 1 systems, if the compass portion of the corepack failed, which was a common occurrence with those models, you could add a nmea 0183 compass to the nmea "in" port on the corepack and the system would go on working fine. I did that many times on a seatalk 1 pilot but not sure if it would work on a seatalk-ng system like yours.
You'll have to excuse my rambling answer and it might not be pertinent to your problem but hey, at least it's a reply! Remember, I did say it was post cocktail hour.

 

[LeoKa]

Yes, I don't have SeaTalk1, only NG. I did connect my old Garmin MDF using NMEA0183 adapter, but I did not gain much from it, so I disconnected.
I tried to connect only the control unit and the ACU400 directly, but it did not do anything.
At this point the rudder reference data does not show. It is connected directly to ACU400, so that could be the reason. I ordered at ITC-5 analog-digital converter to test the rudder data connection. If that has positive data connection, it has to be the computer itself. I just do not know how to test the computer (ACU400) for issues? Everything looks normal on it. Unless the problem is with its brain.

 

[Frosty]

I have this vague feeling that I've read it's "safer" to power the Seatalk ng network from it's own power drop vs. via the ACU. I wonder if that could have a bearing on your problem?

Reason I'm hedging is I have the ACU150 and it's not even capable of powering the Seatalk ng network, so I have to (and do) have a separate power drop to power the network. Thus this would have been something I read and didn't pay a huge amount of attention to. It's also possible it applies to the ACU 200 only.

I'll see if I can find what I was thinking of.

*******
Okay, I did find this from the old Raymarine forum (miss that forum). Tho it seems to allude more to the fact that if you power the Seatalk ng network from the AP (ACU) vs. independently then if the ACU fails your whole system could go down. Since you are only having problems with the ACU, maybe it's the inverse and this proves it is an ACU problem?

This does involve an ACU400 as it happens.

Excerpt:

General comment regarding power: When considering power circuits for a vessel, consideration should be given to how the equipment within the system will be used and maintain the greatest level of system functionality in the event of a catastrophic failure of any single piece of equipment. Hence, it is considered a best practice to NOT power the SeaTalkng backbone featuring critical devices (ex. Raystar 130 GPS Sensor, etc.) from an autopilot ACU/course computer, as a catastrophic failure of the autopilot may prevent the autopilot ACU/course computer from supplying power to these system critical devices.

Link to discussion the excerpt is from:

SeaTalkNG power with ACU-400 - Best Practices

forum.raymarine.com

 

[LeoKa]

Not with ACU400.
It provides power to the NG network itself. In the troubleshooting section Raymarine specifically said that no other power source should be on the network.

 

[Frosty]

@LeoKa

Yes on only one power source for the network. But I think what they are getting at is that it is best practice to NOT use the ACU 400 to provide power to the Seatalk ng network (unless that's the only item you have on the entire network).

In other words, you completely eschew the ACU 400 as a Seatalk ng power provider (don't use it), and rather you power the Seatalk ng network from its own power drop (red Seatalk ng cord). So then you don't have two power sources (because you are right that that shouldn't be the case).

Not saying this is your problem. In fact maybe this proves it isn't because your other Seatalk ng items are still working. But it might be a change to consider anyway as best practice.

 

[LeoKa]

I can certainly give it a try, but again, I have power on all units. The MDF recognizes the ACU400 on the network. When I run the software update, it shows it there. Only when I search for data from it, it will not appear.

Here is the section about the power connection from the ACU400 installation manual. This is what I followed.

11.14 SeaTalk NG power switch
The ACU can provide power to the SeaTalk NG backbone. This will provide
power to equipment connected to the backbone (e.g. SeaTalk NG autopilot
control head and instrument displays).
Important:
• The SeaTalk NG backbone must have a single power supply connection,
if your SeaTalk NG backbone is supplied power directly then you must
ensure that the SeaTalk NG power switch on your ACU is switched Off.
• The SeaTalk NG power supply fuse MUST be rated as per the value
shown on the ACU connector panel.
Note:
The ACU-100, ACU-150 and SPX-5 autopilot control units cannot supply
power to the SeaTalk NG backbone.

 

[Frosty]

Fair enough. I just had that little mention in the back of my mind, that it's better to power the Seatalk ng network from its own power connection (red and black Seatalk cord provided) than from the ACU. But it's definitely an option to power it from the ACU.

I think what Chuck was getting at was that IF you have numerous things on the Seatalk ng network (I do, even in a small system), then you run the risk of if the ACU goes out, your whole network goes down.

This has probably turned out to be an unrelated tangent (tho if it were me I would still choose to power the network from its own power drop, and not from the ACU). But this doesn't seem to be your problem right at the moment, it doesn't sound like.

Sorry for the sidetrack.

 

[LeoKa]

I have submitted a troubleshooting request to Raymarine today. Let's see what they come up with? I'll post it, when they do.

 

[tpbrady]

Looking at my Raymarine documentation I would try this:

To discover which model display you have follow the steps
below:
From the homescreen:
1. Select Set-up.
2. Select Maintenance.
3. Select Diagnostics
4. Select Select Device.
5. Search the Network column for the 'This Device' entry.
6. The Device column for this record will list the model of your installed components.

This should list all the components installed on your STNg network. If the ACU400 is missing then it is not reporting on the network. That would lead you to check to see if the cable connections are seated properly and the cable hasn’t been damaged. After that there is not much else you can do other than ship the ACU400 off for repair. Do you have a NMEA 2000 network and is it connected to the STNg network?

 

[LeoKa]

Do you have a NMEA 2000 network and is it connected to the STNg network?

No, I do not have nmea 2000 anything on the network.
I used to connect a Garmin plotter with Raymarine adapter, but it is disconnected now.

At the network test, the ACU400 does show up on the list. So, it is talking to the network.
See photos.

 

[tpbrady]

When you get the “No Pilot” message is it on the P70 or Axiom 7 or does it show up on both?

 

[Frosty]

I hope you aren't getting tired of my tangents here, but I noticed in your screen shots "Software 3.15." I'm not sure what device that refers to though. Lighthouse operating system on your Axiom? (or perhaps it's something else)

Here is why I bring it up. This doesn't apply anymore, but with the earlier versions of Lighthouse (definitely 3.x; maybe some of the early 4.x) when you did an update it was critical to update the autopilot components in a certain order vs. just doing it all at once.

The EV sensor had to be updated before the ACU, or something wouldn't work right (not sure what, but something with the AP). So the way you would do it was when you went to update software, and you would get the list of possible updates (green squares on a list of things on the MFD as you are updating) you would "uncheck" everything but the EV sensor, then run the update.

Then you would run it again and update everything else (including the ACU).

Here is an excerpt from the old Raymarine forum. Again though, this no longer applies on the very newest Lighthouse updates, but did apply in the past (or presumably now if you are still on an older version for any reason).

 

[LeoKa]

When you get the “No Pilot” message is it on the P70 or Axiom 7 or does it show up on both?

Only on the p70Rs. Axiom offers autopilot control on screen, when the system is working properly. I do not see that option now.

 

[LeoKa]

Question:
I have EV-1 sensor, which comes with ACU400. Looks active, but I do not see it on the devices list. Does it have to appear, or it is just a part in the full setup? Do you have this in your system?

 

[DDW]

You should see the EV-1 on the device list. If it is down, then the autopilot and heading information will not appear to function. Probably the thing to look at first. You are running a VERY old version of LH, is there a reason for that?

 

[LeoKa]

Yes, the LH is a last year version. I decided not to pay for the update, since there are no plans for much cruising for few years. The charts are still good for the Columbia River.

EV-1 shows active on the device, but I do not see it on the network.

 

[LeoKa]

I tested different different connectors on the NG block, where the ACU400 and EV-1 is sharing the network. It looks like that EV-1 is not talking to the network. This could be the reason for my troubles.

 

[boomerang]

I tested different different connectors on the NG block, where the ACU400 and EV-1 is sharing the network. It looks like that EV-1 is not talking to the network. This could be the reason for my troubles.

That's why I mentioned earlier if you could get your hands on another heading sensor and install it either nmea 2000 or nmea 0183, the ACU would stop faulting once it saw a heading sentence. Try swapping tees with the one where the EV-1 connects.

 

[LeoKa]

That's why I mentioned earlier if you could get your hands on another heading sensor and install it either nmea 2000 or nmea 0183, the ACU would stop faulting once it saw a heading sentence. Try swapping tees with the one where the EV-1 connects.

Are you saying that any brand heading sensor could serve this trouble-shooting, or it has to be Raymarine?

 

[Frosty]

Yes, the LH is a last year version. I decided not to pay for the update, since there are no plans for much cruising for few years. The charts are still good for the Columbia River.

EV-1 shows active on the device, but I do not see it on the network.

It's unfortunate that Raymarine named both their charts and their operating system "Lighthouse." I was referring to operating system above.

So do you have an older version of Lighthouse operating system? If so, I really wonder if what I mentioned in post #15 is valid. Did you do an update at all? (From older to newer-but-still-older?)

Maybe something about your system is different, but I don't have to pay for Lighthouse OS updates. (Might be different for Lighthouse chart updates, not sure.) I can download them for free from Raymarine, put them on an SD card, and then pop them into the Axiom in order to update (apparently you can also do it over wi-fi, but I'm more of a "keep the data on my hard drive just in case" sort of person, so I do it that way).

I started on something like Lighthouse 3.8 (operating system) and am now up to the latest which I think is 4.7 (operating system). (I'm not normally one who must update constantly, but they have added some useful things.) Starting sometime in the "4's" you no longer have to update the Autpilot EV sensor first; but before that you did -- or else something wonky could happen.

 

[MV Cricket]

I have submitted a troubleshooting request to Raymarine today. Let's see what they come up with? I'll post it, when they do.

I was going to suggest this. I have found them to be amazingly fast responding. Buddies of mine have B&G...nightmare customer support.

 

[boomerang]

Are you saying that any brand heading sensor could serve this trouble-shooting, or it has to be Raymarine?

It's worth a try, Again, I've done it many times with Raymarines previous Smart Pilot models, just by adding a compass sensor via nmea 0183. It's worth trying on the Evolution series if you have a sensor handy. Since nothing is seeing the EV-1 on the network, I would really scrutinize the EV-1's drop cable and tee. Either might be sending power to light the indicator but not allowing CANbuss communications if one is faulty.

 

[LeoKa]

So do you have an older version of Lighthouse operating system? If so, I really wonder if what I mentioned in post #15 is valid. Did you do an update at all? (From older to newer-but-still-older?)

No, I was not precise enough. I was referring to the charts Premium subscription. That is a year old.
The OS is 4.09.167 now. I think this is the latest.

 

[Frosty]

No, I was not precise enough. I was referring to the charts Premium subscription. That is a year old.
The OS is 4.09.167 now. I think this is the latest.

Okay, gotcha. Why they named their OS and their charts the same thing is beyond me!

And if you are on the latest OS, you are past the point where you had to update the AP's EV before the ACU, so that seems to also not be relevant.

 

[LeoKa]

I think it is the EV-1. I went out and bought a brand new spur cable and connected it. It lids up, but no data comes out of it. The terminal on the block is functioning, because other devices to the same terminal work fine.
Let's see what Raymarine will offer? I don't know how much a repair for this could cost, besides shipping, but a new unit is around $700.
Either way, I also ordered and Garmin heading sensor, because I can connect that to my old Garmin plotter. This plotter can be connected to the SeaTalkNG network with an adapter. Once it arrives, I will connect them all and see, if ACU400 can receive data from the Garmin sensor?
Wish me luck.

 

[Mambo42]

If they don't react to your e-mail request you can just give them a call. I had some problems with my RMK10, gave them a call and the guy that answered the phone was awesome. He not only solved that problem, but also many other problems I had. I had lost my GPD datum quite a few times lately, problems with the autopilot being kicked out, he solved them all. It may take a while before you get someone on the line, but when you do they are more than helpful, I spent almost an hour on the phone with them. Must say, absolutely great service.
Phone number is 1-800-539-5539

 

[LeoKa]

That is encouraging. Some brands are really a joke, when it comes to cust. service and/or troubleshooting.
So far, there is no answer to my ticket. Maybe it is the weekend.
When you say call, you are recommending to call Raymarine directly, or their service/repair center?