A034 NMEA2000 wind data fails on Garmin chartplotter—-fixed

[Anonymous]

I have a number of Raymarine Seatalk1 instruments + AIS which are input to an A034 which is connected to a Garmin Echomap 65CV chartplotter via NMEA2000. Some of the N2K data is accepted by the Garmin (HDM, DPT, MTW, AIS). However apparent wind data fails to appear, as shown in the attached screenshots. To confirm that the fault is peculiar to the A034, I connected the NMEA0183 data output by the A034 to an Actisense NGW-1 which then converted it to N2K. With the NGW-1, the Garmin works as expected. (The NMEA183 MWV strings look fine and work in OpenCPN.) Clearly there is something within the Quark PGN, or missing from the PGN, that Garmin objects to, or is pedantic about. (Going back the other direction, the NGW-1 is more tolerant and can read the A034 N2K wind data.)
A typical NMEA183 string is: $IIMWV,129.0,R,8.1,N,A*3E

Wind is important on a yacht. I first raised this issue with Quark in October but have not yet received a meaningful response, so I hope this additional detail will stimulate someone to look at it.

Also, the water speed does not appear on the Garmin via N2K.
A typical NMEA183 water speed string output by A034 from SeaTalk1 (with boat stationary) is :
$IIVHW,,T,,M,0.0,N,,K*7B
$IIVHW,,T,,M,0.00,N,,K*4B

[Quark Elec]

Hi Chiko,

I will forward your information to our engineering team and reply asap. Thanks for your patient.

[Anonymous]

Since I’ve had no response whatsoever from a Quark-Elec engineer about this issue, I’ve dived into the N2K packets myself.
First obstacle: the advertised PCDIN output does not work on this A034. So I used a RPi+CANHAT to capture the N2K messages. Here’s a sample:

pi@openplotter:~ $ candump -ta can0
(1613708264.832049) can0 19F50381 [7] 57 00 00 FF FF 04 FF
(1613708264.834229) can0 09F11281 [8] 58 FF FF FF 7F FF 7F FD
(1613708264.840687) can0 09F80201 [8] FF FC 16 F1 00 00 FF FF
(1613708264.841252) can0 09F80101 [8] 97 66 80 E7 8C AF 3A 68
(1613708264.869850) can0 19F50381 [7] 59 00 00 FF FF 04 FF
(1613708264.872236) can0 09F11281 [8] 5A FF FF FF 7F FF 7F FD
(1613708264.940702) can0 09F80101 [8] 97 66 80 E7 8C AF 3A 68
(1613708264.942196) can0 0DF80281 [8] 5B FC 00 00 FF FF FF FF
(1613708264.944172) can0 0DF01081 [8] 5B 00 AD 2A 00 00 00 00
(1613708264.946205) can0 0DF80181 [8] 00 00 00 00 00 00 00 00
(1613708264.955010) can0 19FD0781 [8] 5C 80 1F 72 FF 7F FF FF
(1613708264.997909) can0 19FD0781 [8] 5D 80 ED 71 FF 7F FF FF
(1613708265.040705) can0 09F80101 [8] 97 66 80 E7 8C AF 3A 68
(1613708265.058775) can0 19FD0281 [6] 5E 88 02 1B 6E 02
(1613708265.102645) can0 09F80201 [8] FF FC 16 F1 00 00 FF FF
(device 0x81 is the A034; device 01 is the Garmin)

The surprising thing is that the wind (0x9FD02/130306) and water speed (0x9F503/128259) PGNs have less that 8 data bytes (and ONLY these problematic PGNs have less than 8). My understanding was that for NMEA 2000 they should be padded to 8 bytes.

So what happens if I manually pad them to 8 data bytes with FF (signfying no data):
pi@openplotter:~ $ cansend can0 19FD0281#D20101558702
– as output by A034; nothing on Garmin display

pi@openplotter:~ $ cansend can0 19FD0281#D20101558702FFFF
– padded to 8 data bytes;  wind appears on Garmin chartplotter!!!

How about speed?
pi@openplotter:~ $ cansend can0 19F50381#FD0000FFFF04FF
– as output by A034; nothing on Garmin

pi@openplotter:~ $ cansend can0 19F50381#FD0000FFFF04FFFF
– padded; shows water speed on Garmin!

So that fixes wind and speed. As noted at the start of this post, the vessel heading/compass DOES appear on the Garmin via N2K. No prizes for correctly guessing that the A034 does in fact send 8 data bytes for the heading PGN (9F112/127250).

While the CAN bus may allow messages with less than 8 data bytes (with suitable DLC), the question is ‘should you?’ for this application. It seems to me that the NMEA2000 definitions have declared the (currently) unused bits as ‘Reserved’, so as to always make up the 8 data bytes (for these short PGNs).
As a case in point, for PGN 128259 (speed) in V1.3 of the standard (which the A034 declares itself to be following), the last 16 bits are ‘Reserved’. But V2.1 of the standard has introduced ‘Speed direction’ in some of those formerly reserved bits. (ref: canboat/analyzer -explain). The Garmin chartplotter follows NMEA2000 V2.1 so will see an incomplete PGN coming from the A034 if the data is truncated rather than padded (ie no ‘speed direction’ field even if it is 0xFF ie unavailable).

I really want to like the Quark device – it has potential – but it is currently incompatible with my recent (2019) Garmin chartplotter, apparently for the reasons above. I’d also really like to hear back from a Quark-Elec engineer about making this straightforward fix.

[Quark Elec]

Hi Chiko, our engineer team were working on this issue after your first posting. we really appareicate the additional information you provided. We can confirm the new firmware has been released and it should fix this issue. Thank you again for these very helpful contributions.

[Author]

Posts