Page History

Table of Contents

Introduction

TG-BT5-XX tags can operate in 4 different modes:

...

"AdvData" field structure (max 31 octets/bytes):

...

MikroTik PDU Payload structure

...

• - can vary

Example

An example of the payload configured in MikroTik's format (non-encrypted) would be:

...

15ff4f09 (first 4 octets) → ManufacturerData. Is the same (constant data) for every MikroTik format's payloadLength (0x15 hex-to-dec is 21). Type (0xff). Company identifier (0x4f09).

01 (5th 4th octet) → Current version of the payload's structure. Should be the same for every payload (constant data).

00 (6th 5th octet) → Indicates that the payload is not encrypted. "01" would mean it is encrypted.

cea6 (6th and 7th and 8th octets) → data used for encryptionSalt. Each new payload should have a different salt value generated. You can use this value to check whether the identical payloads are encrypted differently. The value itself does not contain any useful information. If you see that the salt value is identical for two payloads received during different time intervals, it would mean that the two payloads received are exactly identical. You can calculate the salt value using the same principle that applies to the uptime calculation (17th to 20th octets) - see below.

0000 (8th and 9th and 10th octets) → acceleration on the X-axis at the moment of the broadcast = 0 m/s². Check acceleration calculation for the Z-axis below.

0000 (10th and 11th and 12th octets) → acceleration on the Y-axis at the moment of the broadcast = 0 m/s². Check acceleration calculation for the Z-axis below.

0200 (12th and 13th and 14th octets) → acceleration on the Z-axis at the moment of the broadcast = 0.0078 m/s². To get the decimal value out of the hex format you will need to follow the steps:

• As noted before, multi-byte values are in little-endian and that means, to calculate the realm value, you will need to switch octets places (switch octets order). So the first step is to swap places for the values from 0x0200 to 0x0002. 0x0002 converted from hexadecimal to decimal is 02.
  
• Keep in mind that acceleration is in signed 8.8 fixed point format (two's complement) and that means that you basically need to divide the result by "256". The second step is to divide the value by 256 → (0x0002 hex or 02 dec)/256 = 0.0078 m/s².
• The same calculation principle applies to the acceleration for the X and Y-axis. In our example, they just happen to be 0 → 0x0000/256=0.

a01c (14th and 15th and 16th octets) → temperature detected by the tag in Celsius = 28.625 C. Temperature is in little-endian (as it is a multi-byte value) and it is insigned 16-bit integer [twos complement] 8.8 fixed point format, so so the same "formula" applies here as well:

• 0x1ca0/256=28.625 C.
  

91085700 (17th 16th to 20th19th octets) → tag's uptime in seconds = 5703825 s. 0x91085700 is in little-endian, so just swap the octets to 0x00570891 and the result is 5703825 in decimal. That is 1584.395833 hours or66-day uptime.

00 (21st 20th octet) → trigger (flag) that sent the payload. If it is "00" it means that no trigger was detected and that it is just a periodically broadcasted payload (based on the advertisement interval configured for the tag). If the value would be "04" it would mean that the device was dropped (freefalling triggered). You can find more information on the "flags" and the "Secret" section above in the packet structure section.

5f (22nd 21st octet) → battery percentage of the tag = 95 %. 0x5f from hex to dec is95.

Script for decoding

Add a new script under the "System>Scripts" tab and import the script there (for non-encrypted payloads).

...

...

...