ZtrackPro : Payload description

Hello All,

I own a ZtrackPro. I use the last firmware version 1.9 and i don’t find payload description on Zane website : https://ztrackmap.com/support/

Do you know where i can find this description ?
I don’t find it in the forum (Frame lenght is 11 bytes on port 204)


I think you must ask to the support off your device.
They have for their other device’s zTrack_One a nice manual with explain off the decode.
But for their ZtrackPro device it looks like they have the manual but not clickable.
So mail/call “ztrackmap” and ask them for the manual to download.
We don’t have it here :slight_smile:

Maybe you can use the same decoder as zTraack-One see page 6 or 7 in de manual.

That shows:

 if( bytes[8] & 80)
   temp /= -10;
   temp /= 10;

I’m quite sure they wanted hexadecimal 0x80 (decimal 128), not decimal 80 in that if condition there. (See next post.)


The ZtrackOne decoder works well, products are very similar.

àrjanvanb, i will test the sensor in my Freezer in order to reproduce the bug. I will update this thread with the results.


I was wrong: the device is also using packed binary-decimal encoding, and only using 3 out of the 4 nibbles for that. So, looking at the full code, it only uses 12 out of 16 bits for the value, and then (2 out of) the remaining 4 bits for the sign:

temp = (bytes[8] & 0x0F) * 100;
temp += ((bytes[9] & 0xF0) >> 4 ) * 10;
temp += bytes[9] & 0x0F;

if( bytes[8] & 80)
  temp /= -10;
  temp /= 10;

Aside: this also implies that the temperature range is only -99.9 thru 99.9. What a weird encoding. (Two bytes could easily store a much larger range from -32,768 thru 32,767, and would need less magic to decode.)

Now, the decimal value 80 translates to the binary bit pattern %01010000 (whereas the hexadecimal 0x80 is binary %10000000). In the manual, it says:

- 1. character indicates negative or positive temperature (0 – positive, 1 – negative)
- 2. and 3. character is integer part of temperature
- 4. character is fractional part of temperature

So, it seems only the rightmost bit of those 4 leftmost bits matters. (Binary %00010000, or decimal 16, or hexadecimal 0x10.) Indeed, “a character” 1 matches one of the two bits in the decimal value 80, not caring about the other bit.

Still: it smells that the bit pattern has 2 ones! (And that a decimal constant is used, while hexadecimal constants are used for all other bitwise operators in that example.) So don’t just test for negative temperatures; bugs like this would especially affect positive values that erroneously happen to match that bit pattern.

In short: I guess it will work as expected, though I would have used the more strict and less confusing bit pattern 0x10 (also reserving the other 3 bits for future use).

I have done test in my Freezer : Temperature is bloqued to 0.1°C

2020-05-24 08_23_03-The Things Network Console

I will ask Zane for an up to date decoder !


That’s not caused by the decoder; you’re seeing the same bytes 10 01 in the payload for that temperature for all 3 uplinks. So, that’s caused by the device.

I see. I asked to Zane support I’m waiting for an answer

I update the thread just for writing that i have no answer from Zane.

1 Like