TK20G weird speed

Hello,

I am testing a TK20G with tk103 protocol.

I can see the positions are fine, but speeds are about half of what I was doing.
Here is an exemple of what it sent.

(864768010934344,BP05,140217,A,5042.83898N,00424.76967E,71.322,111424,178.02,117.40,11,18)
(864768010934344,BP05,140217,A,5042.66220N,00424.76853E,58.845,111434,182.70,112.10,11,19)
(864768010934344,BP05,140217,A,5042.49024N,00424.75398E,61.348,111444,183.39,115.10,11,19)
(864768010934344,BP05,140217,A,5042.31714N,00424.73856E,62.801,111454,183.07,115.50,11,19)
(864768010934344,BP05,140217,A,5042.13698N,00424.74320E,65.388,111504,176.17,109.10,11,20)
(864768010934344,BP05,140217,A,5041.96002N,00424.76046E,64.568,111514,176.17,116.90,11,20)

In traccar, it's shows 61.3 for the third position by time (shown as 61.348 here). While my speed was more 115.10 or something like that.

By default for TK103 protocol Traccar assumes that speed is in km/h, so it converts it to knots.

You can control it by "tk103.speed" parameter in the config. Available options include "kmh", "mph" and "kn".

But then it affects all tk103 devices, most of which are in km/h.
I should test the T580W in a car to see if it shows the same behavior. Then, as suggested with the wifi positioning topic on that device (on github), it might maybe make sense to split the 2 protocols and create a vjoy protocol.

Currently it's configured globally, but it's technically possible to implement it per device.

Obviously, but then the switch would need to appear on the user interface and be stored somewhere in the DB, so that's a quite heavy change.

Not really. That was the main reason for adding attributes to device model. Check this example:

Gt06ProtocolEncoder.java#L61

Indeed, that's a possibility, but that's quite less "user friendly".

I don't see any better way.

Well, the user friendly way is: "edit device" -> "device speed format" with km/h,kn,mph
But as I said, this is a way bigger change as you have to do that for each device, protocol wise.

The problem is that each protocol can have some small configuration like this, and adding each of them to the UI separately is just not practical.

That's why the UI should look at the protocol and only propose the useful configurations for the type of device. Which is why it's a quite deep change. Although it might be easy with a table containing all the type of special configs every protocol supports, but the names have to be standardized.

Each protocol has its own configuration. For your one it's speed units. For GT06 it's commands format and timezone. For one other protocol it's reports format string (2 of them). There is no unified list of parameters.

I know that we can show user only parameters for his device, but by maintainability I means the code that needs to handle all that specifics for each protocol.

Yes, it's less maintainable in a code point of view. Though it's better from a user perspective. Maybe a patch for the tk103 adding the attribute would be nice enough.
The problem is also to document all those small configuration changes.