ST-902 (SinoTrack) — binary frames never decoded, "Unknown device" and endless reconnect loop

Willy AE 6 hours ago

Hello,

I have two identical SinoTrack ST-902 trackers pointed at my self-hosted Traccar instance (6.x, H02 protocol, port 5013):

  • One sends the text format *HQ,ID,...# and works perfectly (decoded, position up to date).
  • The other sends a binary format (7e0100002c...7e) that is never decoded — no id: line ever appears in the logs for this device, despite an established TCP connection and frames being sent regularly (~every 30-90s).

Representative log excerpt:

2026-09-28 15:28:14  INFO: [Tfc3bab31] connected
2026-09-28 15:28:14  INFO: [Tfc3bab31: h02 < 51.194.212.5] 7e0100002c019171897092004b000000003730313132542d333030000000000000000000000000000000313839373039320131383937303932927e
2026-09-28 15:28:55  INFO: [Tfc3bab31: h02 < 51.194.212.5] 7e00030000019171897092004ec77e
2026-09-28 15:29:43  INFO: [Tfc3bab31] disconnected

And later, on a different session:

2026-09-28 15:53:46  WARN: Unknown device - 7e7e010000 (38.147.134.198)

The device keeps reconnecting in a loop (a new TCP session every 1-2 minutes), and no position is ever accepted.

The device ID appears in plain text inside the frame (19171897092, decoded from hex: ...0191718970920...), so the data seems to be present, just misparsed/misaligned by the H02 decoder.

Is this a known binary variant different from the standard supported H02 binary format? Any idea what's going wrong with the frame splitting?

Thanks in advance.
Willy

Anton Tananaev 6 hours ago

You're using the wrong protocol. Check this page:

https://www.traccar.org/clones/

Willy AE 5 hours ago

"The issue is resolved — the actual cause was a wrong protocol configuration on our server side, not a network/SIM issue on your end. Thanks for your help, you can close this ticket."