Watch Protocol Oddity

Rob9 months ago

Hi,

I have a new device TK913 (these were always 2G, but I have a 4G variant) - I don't know if it's a clone.
The badge is TKMARS and the encoded Manufacturer ID is "SG"
It's using the Watch protocol as expected.

But I have found a protocol oddity - probably a bug on the vendor side.

Here's a "UD" Message

[SG*9139008196*006A*UD,030324,144946,A,53.179907,N,4.073607,W,2.259,020,140,8,60,92,0,50,00000000,1,1,234,30,25630,4344332,15,,00]

Battery is at data index [12] according to the protocol document and has a value I agree with at 92%
Steps = 0 and rolling (whatever that is, maybe IMU) is 50.

But when the movement stop, after a few minutes I get an "LK" message every 5 minutes as expected

[SG*9139008196*0009*LK,0,92,0]

But here the battery (92%) is at data index [1] and not as the protocol document states (below) at data index [2]:

[CS*YYYYYYYYYY*LEN*LK,steps,rolling times,the percentage of battery amount]
    Example:[SG*8800000015*000D*LK,50,100,100]

As such, when the device is not moving, the event report is with battery level = 0

I'm sure this kind kind of thing is common for these cheap devices.

Have you seen this before? any work arounds you can think of?

Here's my firmware details below from a "check..." SMS.

Cheers, Rob

TK913(70ELASE)_V_3.0 2023/08/30
ID:9139008196
IP:my.ip.add.ress:5093
BAT:92%
APN:hologram,,
GPS:5
LTE:15
,,,
Anton Tananaev9 months ago

Is there a reason this is in the server forum and not devices?

Rob9 months ago

Hi Anton,

No reason - I certianly meant to click the devices forum.... my apologies., I have a few tabs open.
Feel free to move it if you can? or I can copy/paste/delete a new entry.

Thank you.

Rob9 months ago

I'm currently running the following patch - with a fixup for the above firmware bug.
I don't have another TK913 or another watch-protocol device that I can test alongside it however.

But the code is here in case it's useful for others, Cheers

--- a/src/main/java/org/traccar/protocol/WatchProtocolDecoder.java
+++ b/src/main/java/org/traccar/protocol/WatchProtocolDecoder.java
@@ -256,8 +256,23 @@ public class WatchProtocolDecoder extends BaseProtocolDecoder {

                     getLastLocation(position, null);

-                    position.set(Position.KEY_BATTERY_LEVEL, Integer.parseInt(values[2]));
-                    position.set(Position.KEY_STEPS, Integer.parseInt(values[0]));
+                    int steps = Integer.parseInt(values[0]);
+                    int rolling = Integer.parseInt(values[1]);
+                    int battery = Integer.parseInt(values[2]);
+
+                    position.set(Position.KEY_STEPS, steps);
+                    /*
+                        according to the docs the data order should be [steps, rolling, battery]
+                        but some versions have a bug which mises this up. This aims to catch the error
+                     */
+                    if (steps == 0 && battery == 0 && rolling > 0) {
+                        // fixup use rolling value as battery
+                        position.set(Position.KEY_BATTERY_LEVEL, rolling);
+                    } else {
+                        // per protocol
+                        position.set(Position.KEY_BATTERY_LEVEL, battery);
+
+                    }

                     return position;
                 }
diff --git a/src/test/java/org/traccar/protocol/WatchProtocolDecoderTest.java b/src/test/java/org/traccar/protocol/WatchProtocolDecoderTest.java
index 5fd0ede44..42ee71b04 100644
--- a/src/test/java/org/traccar/protocol/WatchProtocolDecoderTest.java
+++ b/src/test/java/org/traccar/protocol/WatchProtocolDecoderTest.java
@@ -17,6 +17,13 @@ public class WatchProtocolDecoderTest extends ProtocolTest {

         var decoder = inject(new WatchProtocolDecoder(null));

+        // test NON-standard battery index in LK message
+        verifyAttribute(decoder, buffer("[SG*9139008196*0009*LK,0,93,0]"), "batteryLevel", 93);
+
+        // test standard battery index in LK message
+        verifyAttribute(decoder, buffer("[SG*9139008196*0009*LK,0,50,25]"), "batteryLevel", 25);
+
Berbigou7 months ago

Hi @Rob,
I also own a TK913 device and I have the same problem.
As I know nothing in Java, would you mind send me your tracker-server.jar ?
mine is (in docker): 3746306 Apr 11 20:32 /opt/traccar/tracker-server.jar
It would really be kind of you
Many thanks from France.

My device:

TK913(70SALASCD)_V_2.0 2024/03/11
ID:0123456
IP:my.own.traccar:5093
BAT:95%
APN:<myapn>,,
GPS:15
LTE:27
,,,
Rob6 months ago

Hi,
Yes - email me
[redacted]

Anton Tananaev6 months ago

We don't allow personal contact details on the forum.

Rob6 months ago

Sorry Anton.
how do I get in touch with Berbigou?, I'm happy to help them.

Anton Tananaev6 months ago

You can post anything you need on the forum.

Rob6 months ago

@Berbigou, I'll post a docker image here. what arch do you need? amd64 or arm64?

Berbigou6 months ago

Hi Rob, you're great ! I would need arm64 (for a Bananapi-M5 with armbian 6.6.16-current-meson64 aarch64 GNU/Linux) !

Berbigou6 months ago

Hi Rob,
how are you ?
Can you help me with my tracker-server.jar, please ?

Many thanks

Alex4 months ago

Hello
I understand the code more or less. But I can not find the path to change the the code. And if I would find the directory, I don't know how to build an own Docker image to fix the battery status for me actually.

Is there a plan to add these changes to the major release?

Best regards

Alex4 months ago

Okay, now I am at the point to build my own docker file with my own zip. I changed the lines like Rob's example. But now I think there is a step to compile the code or somethong like that to build my own .zip file. Could anyone help me with that step?

Sorry for those noob questions. But I am trying to learn. and I think it could help others to read those hint here :)

Anton Tananaev4 months ago

Have you checked the official documentation?

https://www.traccar.org/build/