Garmin GST43 to B&G Triton 2

Did you ever resolve this problem ?
I am in the same boat (metaphorically), replacing an old Silva transducer with the GST 43 because it fitted the same thru-hull fitting. The B&G Triton recognizes the transducer, however only shows temperature and no speed. The Garmin documentation states that the GST43 needs to be initialized to correlate SOG with Speed Through Water, but there is no option in the B&G Triton to do this. Monitoring the NMEA 2000 traffic from the GST43, it appears as though the speed data (PGN 128259) is unavailable (data is 0xFF).

From Garmin: "The GST43 will need to have a Garmin product installed on the NMEA bus to run the calibration process and start sending speed data. This could be a GMI20,GNX or Chartplotter. Once the cal process has been ran the display is not needed and could be removed from the bus. This is not unlike other manufactures sensors calibration processes where specific types of calibration are needed across the NMEA 2000 network and NMEA 2000 doesn’t support the calibration process. This is done using proprietary PGNs for the calibration which is what Garmin has done."

Firstly it is just a paddlewheel sensor, it SHOULD need NO calibration to correlate Speed Through Water to Speed Over Ground (SOG) as they are not directly related.

Given the density of saltwater, area & number of paddlewheel blades the vendor knows how many pulses per second correspond to knots of boat speed. My old Silva speed transducer which the GST43 replaced, did not need end user calibration to work,

Secondly what's the point of NMEA 2000 if vendors insist on using proprietary PGN's that prevent true integration of equipment from different vendors.

Finally, just because the GST 43 has not been calibrated to correlate SOG with Speed Through Water doesn't mean that it should send 0xFF (Data Not Available) as the value for boat speed in the PGN 128259 message. Absurd logic by Garmin engineers.

I thought I'd answer my own question and post my observations here.

Firstly, no help whatsoever from Garmin. One of their technicians emailed the following reply:

"As previously discussed in the email chain, the device will not send data until it has been initialized. this is designed to be conducted through a Garmin chart plotter as we like people to purchase Garmin devices."

Another technician tried to correct the first statement with:

"The system is not designed this way because we want to sell Garmin Devices. The system is designed this way since there is no standard PGN in NMEA2000 for calibration of transducers. It is a bit unfortunate that the GST10 doesn’t send anything until it is calibrated but the idea was that it is better to send nothing than a totally wrong speed."

This could be read either of two ways, firstly that Garmin designs their sensors to only work with their Displays and MFD's or that because of limitations with the NMEA 2000 protocols, they had to devise some other mechanism for initializing their devices.

If Garmin genuinely wanted to ensure interoperability with other vendor's MFD's & Displays then they would publish their proprietary protocols. As they haven't and show no desire to do so, then one can only hold the first statement to be true, that Garmin sensors are designed to only work with Garmin MFD's and Displays.

So much for an Open Standard !

In any case criticism must also be levelled at NMEA for even allowing proprietary PGN's in the standard. If NMEA truly had customers in mind (which clearly they don't), then they shouldn't certify products that use proprietary PGN's.

So hang on, here we go.

Firstly in response to a request for PGN 126996 (Product Information), the Garmin GST-10/GST-43 responds with:

03 14 F0 19 40 86 14 05 5A 66 47 53
03 14 F0 19 41 54 31 30 00 00 00 00
03 14 F0 19 42 00 00 00 00 00 00 00
03 14 F0 19 43 00 00 00 00 00 00 00
03 14 F0 19 44 00 00 00 00 00 00 00
03 14 F0 19 45 00 00 32 2E 31 30 00
03 14 F0 19 46 00 00 00 00 00 00 00
03 14 F0 19 47 00 00 00 00 00 00 00
03 14 F0 19 48 00 00 00 00 00 00 00
03 14 F0 19 49 00 00 00 00 00 00 31
03 14 F0 19 4A 2E 30 00 00 00 00 00
03 14 F0 19 4B 00 00 00 00 00 00 00
03 14 F0 19 4C 00 00 00 00 00 00 00
03 14 F0 19 4D 00 00 00 00 00 00 00
03 14 F0 19 4E 00 00 00 33 39 30 34
03 14 F0 19 4F 32 35 31 30 32 39 00
03 14 F0 19 50 00 00 00 00 00 00 00
03 14 F0 19 51 00 00 00 00 00 00 00
03 14 F0 19 52 00 00 00 00 00 00 00
03 14 F0 19 53 01 01 FF FF FF FF FF

This PGN is transmitted as a NMEA Fast Packet. The 4th byte in each message is the monotonically increasing sequence number, the 5th byte in the first message (86 hex) indicates that there are 134 data bytes. These decode as:

NMEA 2000 Database Version: 1.300
Manufacturers Product Code: 26202
Model ID: GST10
Model Software Version: 2.10
Model Version: 1.0
Model Serial Number: 3904251029
NMEA 2000 Certification Level: 1
NMEA 2000 Network Load Equivalence: 1

An uninitialized GST10/GST/43 periodically transmits the following PGN 126720 (Manufacturers Proprietary PGN):

03 FF EF 1D A0 0F E5 98 56 05 04 04
03 FF EF 1D A1 01 00 00 00 01 00 00
03 FF EF 1D A2 00 00 FF FF FF FF FF

This PGN is also transmitted as a NMEA Fast Packet, again the 4th byte is the monotonically increasing sequence number, the 5th byte in the first message (0F hex) indicates 15 bytes are transmitted.

My guess at decoding is the following:

E5 98 contains the manufacturer code (11 bits), a reserved field (3 bits) and industry code (3 bits) which decodes as:
Manufacturer: 229 (Garmin)
Industry: 4 (Marine)

56 05 04 04 must be device specific command numbers and field numbers.

In the second message the fifth byte 01 indicates that the device is uninitialized.

After initialization, the following PGN 126720 is transmitted:

03 FF EF 1D 80 0F E5 98 56 05 04 04
03 FF EF 1D 81 03 00 00 00 01 00 00
03 FF EF 1D 82 00 00 FF FF FF FF FF

The observable difference is the fifth byte in the second message is now 03 which presumably indicates the device has been configured.

To initialize the GST10/GST43 the following PGN 61184 (Manufacturers Proprietary Single Frame Addressed Message) is transmitted to the device:

01 03 EF 1C E5 98 58 05 04 04 34 01

Again E5 98 contains the manufacturer code, reserved field and industry code.

58 05 04 04 must indicate the device specific command numbers and field numbers.

Note the similarity with PGN 126720 message which contains 56 05 04 04, so one could assume that 56 is the command number for retrieving the state of the device and 58 the command for initializing the device.

The last two bytes 34 01 are a 16 bit unsigned integer with the value of 308 which is the configured speed value in hundredths of m/s which is equivalent to the inputted value of 6 knots.

Once again, shame on NMEA and shame on Garmin !

Steven, thanks for posting all that, but I strongly object to this idea:

"If NMEA truly had customers in mind (which clearly they don't), then they shouldn't certify products that use proprietary PGN's."

Without proprietary PGN's, NMEA 2000 would have been badly hobbled from the get-go. Writing standard PGNs is slow and hard, and the committees that do it will never catch up with all that's possible for the network.

For instance boaters would only be getting N2K control of audio now if Fusion had not been allowed to pioneer such control years ago.

Then again, I have been lamenting the lack of cross brand basic sensor calibration for a decade, and NMEA regrets its early promotion of the "plug and play" phrase because sometimes things are much more nuanced.

Awesome reverse engineering there, Steven! I'm looking to replicate the exact same thing - to configure a GST10 for use on a Zeus2. My plan B is using a DST-2 but that's only 1Hz.

Doesn't a Garmin plotter send a message to GST10 when you hit "Start calibration" though? You know, so it knows to start measuring? Or does it just calibrate against the maximum paddlewheel speed of the last few minutes, if you send the PGN 61184 ?

From the screens it seems to tell you to stop the boat before entering the calibration speed, so it probably doesn't calibrate in real time.