TCP termination for the Xirgo protocol; multiple positions over a single TCP stream

chuyskywalkera year ago

I'm working on an ESP32 LilyGo-T-SIM7000G tracker and I initially tried to code this up with the OSM protocol which worked, but the HTTP library was...notoriously slow and unreliable. Something like a 10% failure rate when I started summing up things. Worst, though, was that when it failed it would do so by hanging for a solid 75 seconds.

I've since transitioned to a TCP protocol and happened to land on the Xirgo out of sheer "throw a rock and see what you hit" nature. (Honestly, too many protocols to try and figure out the best one, soooo....)

What I am having trouble with it getting multiple position reports in without "flashing" the UI on/off-line status for the tracker. In the UI, as this is a TCP protocol (I found this in my searching on these forums for solutions), when the device disconnects, it's considered offline. I can very reliable .connect(), .print(), and .stop() the connection and the reporting works as I'd expect: each position goes into the server just fine. The UI flashes online/offline back and forth though, which looks goofy.

Where I'm stuck is this -- if I leave the TCP connection open, the UI keeps the device online, but only the first position report is registered. The remaining are never added to the database.

Most protocols seem to have a particular stop bit; I tried the protocols plain ## and also a version where I add a CRLF ##\r\n to it, but in every case, the first reported position is all the gets added.

Traccar is getting the reports, they show up in the logs, but they don't seem to parse as the normal id: 123456789012345, time: 2023... type message does not trigger for them.

Here's a log where I reconnect every time:

2023-07-02 22:58:34  INFO: [T407c2de0] connected
2023-07-02 22:58:34  INFO: [T407c2de0: xirgo < 172.58.19.95] 24243132333435363738393031323334352c343030312c323032332f30372f30332c30353a35383a32372c33372e3732343039322c2d3132322e3238353337302c302e30302c302e30302c302e302c372c302e302c302e302c312c31392c312c3023230d0a
2023-07-02 22:58:34  INFO: [T407c2de0] id: 123456789012345, time: 2023-07-02 22:58:27, lat: 37.72409, lon: -122.28537, course: 0.0
2023-07-02 22:58:34  INFO: [T407c2de0] disconnected
2023-07-02 22:58:40  INFO: [Te56f39f0] connected
2023-07-02 22:58:40  INFO: [Te56f39f0: xirgo < 172.58.19.220] 24243132333435363738393031323334352c343030312c323032332f30372f30332c30353a35383a33382c33372e3733343039322c2d3132322e3238353337302c2d302e31302c302e30302c302e302c382c302e302c302e302c312c32302c312c3023230d0a
2023-07-02 22:58:40  INFO: [Te56f39f0] id: 123456789012345, time: 2023-07-02 22:58:38, lat: 37.73409, lon: -122.28537, course: 0.0
2023-07-02 22:58:40  INFO: [Te56f39f0] disconnected
2023-07-02 22:58:46  INFO: [Tca01da14] connected
2023-07-02 22:58:46  INFO: [Tca01da14: xirgo < 172.58.19.86] 24243132333435363738393031323334352c343030312c323032332f30372f30332c30353a35383a34352c33372e3734343039322c2d3132322e3238353337302c2d302e32302c302e30302c302e302c372c302e302c302e302c312c32312c312c3023230d0a
2023-07-02 22:58:46  INFO: [Tca01da14] id: 123456789012345, time: 2023-07-02 22:58:45, lat: 37.74409, lon: -122.28537, course: 0.0
2023-07-02 22:58:46  INFO: [Tca01da14] disconnected
2023-07-02 22:58:54  INFO: [Te0a0fa6c] connected
2023-07-02 22:58:54  INFO: [Te0a0fa6c: xirgo < 172.58.19.164] 24243132333435363738393031323334352c343030312c323032332f30372f30332c30353a35383a35312c33372e3735343039322c2d3132322e3238353337302c2d302e32302c302e30302c302e302c382c302e302c302e302c312c32322c312c3023230d0a
2023-07-02 22:58:54  INFO: [Te0a0fa6c] id: 123456789012345, time: 2023-07-02 22:58:51, lat: 37.75409, lon: -122.28537, course: 0.0
2023-07-02 22:58:54  INFO: [Te0a0fa6c] disconnected

Here's a log where I leave the connection open and just client.print() after each GPS acquisition.

2023-07-02 23:02:10  INFO: [T29f15c1b: xirgo < 172.58.38.229] 24243132333435363738393031323334352c343030312c323032332f30372f30332c30363a30323a30392c33372e3634343037332c2d3132322e3238353335352c2d332e31302c302e30302c302e302c362c302e302c302e302c312c31312c312c3023230d0a
2023-07-02 23:02:11  INFO: [T29f15c1b] id: 123456789012345, time: 2023-07-02 23:02:09, lat: 37.64407, lon: -122.28536, course: 0.0
2023-07-02 23:02:15  INFO: [T29f15c1b: xirgo < 172.58.38.229] 24243132333435363738393031323334352c343030312c323032332f30372f30332c30363a30323a31352c33372e3635343037372c2d3132322e3238353335352c2d322e31302c302e30302c302e302c362c302e302c302e302c312c31322c312c3023230d0a
2023-07-02 23:02:20  INFO: [T29f15c1b: xirgo < 172.58.38.229] 24243132333435363738393031323334352c343030312c323032332f30372f30332c30363a30323a32302c33372e3636343038312c2d3132322e3238353335352c2d312e36302c302e30302c302e302c362c302e302c302e302c312c31332c312c3023230d0a
2023-07-02 23:02:25  INFO: [T29f15c1b: xirgo < 172.58.38.229] 24243132333435363738393031323334352c343030312c323032332f30372f30332c30363a30323a32352c33372e3637343038312c2d3132322e3238353335352c2d312e36302c302e30302c302e302c362c302e302c302e302c312c31342c312c3023230d0a
2023-07-02 23:02:30  INFO: [T29f15c1b: xirgo < 172.58.38.229] 24243132333435363738393031323334352c343030312c323032332f30372f30332c30363a30323a33302c33372e3638343038312c2d3132322e3238353335352c2d312e37302c302e30302c302e302c352c302e302c302e302c312c31352c312c3023230d0a

Never shows the "parsed" message after the first report.

What am I missing here to get traccar to see multiple position reports in a single TCP stream?

I checked the protocol doc, but it doesn't really say. And my Java isn't strong enough to suss out what clue I might be missing while looking at the decoder to figure out what I'm missing.

Thanks!

Anton Tananaeva year ago

Are you sure those are all the lines from the log? There's nothing else in between?

Anton Tananaeva year ago

Actually I found the error. You have "0d0a" at the end of each message, which shouldn't be there.

Anton Tananaeva year ago

You should simply use ##.

chuyskywalkera year ago

doh! >.<

I could have sworn I ran it with just the plain ending -- I even wrote that I saw the same result. I guess I did not (I suspect I was using client.println() which adds a sneaky \r\n...)

So, yeah, leaving the connection open and chopping the \r\n off it's parsing correctly repeatedly now.

Thanks for push to double check.