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

Willy AE 21 days 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 21 days ago

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

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

Willy AE 21 days 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."