Raymarine forum

Full Version: [CA11] Smart transducers giving erratic depth readings
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
As part of a comprehensive electronics upgrade -- system includes Two Axioms, Evolution autopilot, Quantum 2, and multiple i70s and i60 displays -- I installed two new STng smart transducers.. a DT800 and DST800 (A22111 and A22112). I realize that these can't both be operated at the same time without interference, so have only connected one at a time to the STng backbone.

Both transducers are giving me fluctuating depth readings when the boat is sitting still. For example, actual water depth in my slip is about 10.5ft, and about 90% of the time, this is the value I see displayed on my instruments. However, every few minutes, the displayed depth will decrease suddenly, remain (erroneously) low for anywhere from a few seconds to a minute or so, and then gradually revert to the correct 10.5ft reading. The erroneous/low reading is usually 8.5-9ft, but I have seen it drop as low as about 5ft a few times.

I've experienced the same behavior while at anchor in multiple locations. Again, only one transducer is connected at any given time, but both behave the same way. There are no other sounders/fishfinders on the boat, and no other boats nearby when I've been anchored.

The boat is a sailing catamaran, with no keel or other underwater appendages in the vicinity of the transducers. Transducers are mounted in the same location as factory-installed analog B&G transducers (including an older NMEA0183 DT800), which had been functioning perfectly. I've tried a few ferrite chokes snapped onto the STng cable a few inches from the transducer, but didn't see any change/improvement.

I see the same fluctuating depth readings on my i70s and Axioms, and also on a Vesper Watchmate AIS. Since (I believe) all of these are simply displaying/repeating the data that they receive via STng from the smart transducers, that suggests that both transducers are sending erratic data out over the network. Would you agree?

Any troubleshooting help would be greatly appreciated.
Welcome to the Raymarine Forum jetx,

Q. I see the same fluctuating depth readings on my i70s and Axioms, and also on a Vesper Watchmate AIS. Since (I believe) all of these are simply displaying/repeating the data that they receive via STng from the smart transducers, that suggests that both transducers are sending erratic data out over the network. Would you agree?
A. It would appear so. Installations which were performed by a Certified Raymarine Installer include onboard warranty. If this upgrade was performed by a Certified Raymarine Installer, then it would be recommended that the installer be contacted to return to the boat to view and record data on the NMEA 2000 backbone to verify what is actually being transmitted on the backbone when the problem is observed. How repeatable is the reported issue?
Thank you, Chuck. I have an excellent installer, but he unfortunately isn't Raymarine Certified. I believe I can capture/record NMEA2000 traffic from the Axiom myself if that's helpful. Are there any tips or instructions for doing that efficiently?

In terms of repeatability, the erratic depth readings / fluctuations typically occur many times per hour. I'd guess that the average time between occurrences is something like 10 minutes, but I've seen it happen multiple times in one minute, and also seen it go up to maybe an hour or two without any fluctuations. I haven't found any particular action or sequence of events -- powering other devices on/off, physically rerouting wires, etc -- that triggers them immediately though.

Besides capturing the N2K traffic, are there any other troubleshooting steps I can take to look for anything that would cause (two different, brand new) smart transducers to output erroneous data?

We have seen some instances where some third party NMEA 2000 devices and engine systems will repeat received data and then re-transmit it with a higher priority than that from the Raymarine equipment. Such possibilities may be avoided by using the Data Sources feature of one of the i70 MFIDs to utilize a manually selected Depth data source rather than relying on the system to automatically select a data source. Data source selections via one device capable of such will establish the data sources to be used by the entire system of Raymarine products.

Should the problem persist after configuring the Data Sources feature as suggested above, then the system's Data Master MFD may be commanded to log data (HOME->SETTINGS->NETWORK->DIAGNOSTICS->NMEA DEVICES & MESSAGES->NMEA MESSAGES->START RECORDING / STOP RECORDING) from the system's NMEA 2000 backbone to a microSD memory card which is located within the MFD's memory card reader or a connected Raymarine remote card reader. It would be recommended that approximately ten seconds of data be recorded when the system is functioning properly and that approximately 30 seconds of data be recorded when the system is not functioning properly. The NMEA 2000 logs may then be attached to this thread for further analysis and/or to accompany a problem report.

The following additional diagnostic data would also be helpful:
- a system diagram (hand drawn will generally suffice) identifying the makes and models of each of the marine electronics devices within the system (including computers / tablets running navigational planning / chartplotting applications) may be be requested to support an investigation. The diagram should additionally identify how these devices have been interfaced to one another.

- the system's Ethernet and SeaTalkng / NMEA 2000 device data (HOME->SET-UP->NETWORK->DIAGNOSTICS->PRODUCT INFO->SAVE DATA)

It is recommended that a blank microSD memory card be used for collecting the data / files specified above, as it will then be easier to identify which files should be attached to your response.

As there is a possibility that the reported issue may be resulting from sonar interacting with the keel, a quick test was also recommended. It is recommended that the DST800's insert be removed and then re-insert such that its indexing arrow be oriented 180 degrees from its normal reference and that the dockside depth performance be tested again.
Hoping to get back to the boat in the next few days to try this and do the NMEA2000 logging you suggested.

Thanks again.

Thanks for the additional information. Given your vessel type, I too wouldn't expect any difference in performance, but it will be interesting to learn of any differences when tested.
Hi Chuck, and hope you had a good weekend! I got to the boat and carried out the troubleshooting steps you suggested. Here are the results.

First, I manually selected the DT800 (though the Axiom lists it as a DT200?) as source for depth information. FWIW, there were no other devices listed as providers of depth data. -- No change (still saw depth fluctuations).

Second, I rotated the DT800 180 degrees -- No change.

Third, I captured N2k logs and system data as you suggested. I've attached four files...

1) Saved "product info" data
2) N2k log - normal depth readings
3) N2k log - fluctuating depth readings. Erroneous depth readings start about 6 seconds in, and then go back to normal 8 or 9 seconds later.
4) N2k and Raynet network diagram

While capturing these logs, I deliberately had several devices powered off -- ACU400, Fusion stereo, B&G VHF, and Vesper AIS -- to reduce extraneous network traffic, and hopefully eliminate a few "suspects" as we're troubleshooting. However, I have observed the same fluctuating depth behavior with all of these devices powered on. As mentioned before, there is no sonar transducer in the system, and there are also no computers connected anywhere.

I can't interpret much of what's in the logs, but skimming the second one, it certainly appears that the DT800 is broadcasting incorrect depth numbers intermittently (as does my DST850, which was not connected during this test). Any help figuring out what's causing this is greatly appreciated!

Thanks for the requested supporting information. A problem report will be logged accordingly seek investigation of this issue by Raymarine and Airmar's engineering teams.
Great... thank you, Chuck.
Pages: 1 2
Reference URL's