Queclink GV56: CAN data in GTERI is ignored and several GTCAN fields are skipped

Hello Anton,

I am using a Queclink GV56 with the GL200 protocol. The device reports protocol version 4F1206 (4F identifies the GV56 and 1206 is protocol version 12.06).

The device sends valid +RESP:GTCAN and +RESP:GTERI messages, but Traccar only decodes part of the CAN information. There is no decoder exception. The messages are accepted, but several reported values never appear in the position attributes or API.

GTERI with embedded CAN data

This is a real message with the IMEI, VIN and coordinates anonymized:

+RESP:GTERI,4F1206,123456789012345,,00000004,12935,10,1,1,0.0,126,968.1,4.000000,36.000000,20260731180607,,,,,00,362251.1,,,,100,110000,,0,203EFFFF,AAAAAAAAAAAAAAAAA,0,H3621460,1325.34,,,,,,,,447.02,388.73,58.29,39.69,,0080,,80,8.64,0.55,11FFFFFF,,,,,,,,,369785,763036,3747,446.48,0.00,2.74,72933,,,,,,0000,318,2,,,0,20260731180830,DB1E$

The ERI mask is 00000004, so bit 2 is set and CAN data is included after the normal GTERI fields.

Current master explicitly returns without decoding that block:

if (BitUtil.check(mask, 2)) {
    return positions; // can data not supported
}

Source:

https://github.com/traccar/traccar/blob/master/src/main/java/org/traccar/protocol/Gl200TextProtocolDecoder.java#L1031-L1033

As a result, the GPS position is decoded, but all CAN information carried inside GTERI is discarded.

Standalone GTCAN report

The device also sends the CAN information separately:

+RESP:GTCAN,4F1206,123456789012345,,0,0,203EFFFF,AAAAAAAAAAAAAAAAA,0,H3621460,1325.34,,,,,,,,447.02,388.73,58.29,39.69,,0080,,80,8.64,0.55,11FFFFFF,,,,,,,,,369785,763036,3747,446.48,0.00,2.74,72933,,,,,,0000,318,2,,,0,,,20260731180316,DB1B$

Report mask: 203EFFFF

Enabled bits:

0-15, 17-21 and 29

CAN report expansion mask: 11FFFFFF

Enabled bits:

0-24 and 28

The main GTCAN decoder correctly handles several fields, including VIN, ignition, total distance, total fuel used, engine hours, driving time, idle time, idle fuel consumption, indicators, doors and overspeed values.

However, several non-empty expansion fields are currently consumed using index += 1 and are not stored as position attributes.

For this packet, the ignored values are:

The relevant section is here:

https://github.com/traccar/traccar/blob/master/src/main/java/org/traccar/protocol/Gl200TextProtocolDecoder.java#L663-L730

For example:

if (BitUtil.check(reportMaskExt, 8)) {
    index += 1; // pedal breaking factor
}
if (BitUtil.check(reportMaskExt, 9)) {
    index += 1; // engine breaking factor
}

The same happens with kick-down counts and times, effective engine-speed time, cruise-control time, brake applications, rapid braking, rapid acceleration, engine torque, service distance and DTC data.

Expected result

It would be useful if:

1. CAN data embedded in +RESP:GTERI could be decoded and added to the GTERI position, preferably by reusing the existing GTCAN decoding logic.
2. The available GTCAN expansion values could be stored as position attributes instead of being skipped.

This would allow the vehicle data already reported by the GV56 to be available through the Traccar API.

Protocol documentation

I have the official Queclink document:

GV56 @Track Air Interface Protocol
Document: TRACGV56AN018
Version: R18.06

Relevant sections:

• +RESP:GTERI: printed pages 164–167, PDF pages 165–168.
• ERI mask bit 2 indicates that CAN data is included in GTERI.
• +RESP:GTCAN: section 3.3.10, starting on printed page 289, PDF page 290.
• The GTCAN section documents the main report mask, CAN report expansion mask and the fields listed above.

The packet structure from protocol 4F1206 matches the field order documented in R18.06.

The Queclink document is marked confidential, so I cannot attach it to a public GitHub issue. I will send the protocol PDF separately to the Traccar support email and reference this issue number.

Thank you.