Introduction

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

  1. Factory sleep mode
  2. Configuration mode
  3. Advertising mode
  4. Upgrade mode

In advertising mode, the tag will broadcast information about itself in Bluetooth advertising packets. The information depends on the advertising packet type.

At the moment, these are all the supported types that can be configured using the MikroTik Beacon Manager app:

Eddystone-TLM, Eddystone-UID, MikroTik, and iBeacon.

Bluetooth technology uses 2 types of channels (each using different frequencies) during the data exchange.

  1. Data channels dedicated to data transmission
  2. Advertise channels dedicated to advertising

There are 40 unique bands (channels) and each band has a 2 MHz separation. 37, 38, and 39 channels are used for advertising, and 0-36 are used for data transmission.

During the advertising process, the BLE advertising packet is broadcasted. This packet contains the Preamble, Access Address, PDU and CRS fields.

The Preamble and Access Address fields help the receiver detect frames. CRS field is used to check errors. PDU defines the packet itself.

MikroTik tags support legacy Non-Connectable Non-Scannable Undirected advertising (ADV_NOCONN_IND). The Payload, in this case, consists of "AdvA" (a field that contains information about the advertiser's address) and "AdvData" (a field that contains data information) fields.

1 octet = 1 byte = 8 bits

Preamble1 octet
Access-Address4 octets
PDU
  • PDU Header = 2 octets
  • PDU Payload = AdvA (6 octets)+AdvData (0...31 octets)
CRS3 octets


MikroTik packet structure

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

ManufacturerDatacompany identifier4 octets (15FF4F09)
Versionthe version of this advertisement structure1 octet (uint)
UserDatauser-configured part of the payload

1 octet (uint)

Secretoptionally encrypted (AES-ECB) part of the payload
  • secret: salt (for encryption) = 2 octets (uint)
  • secret: acceleration (acceleration in signed 8.8 fixed point format - acceleration of all 3 axis (0=x, 1=y, 2=z)) = 6 octets (uint)
  • secret: temperature (ambient temperature in Celsius in signed 8.8 fixed point format) = 2 octet (int)
  • secret: uptime (uptime in seconds) = 4 octets (uint)
  • secret: flags (bit-mask of flags) = 1 octet (uint)
  • secret: batteryPercentage (battery level in percent) = 1 octet (uint)

Please note that all multi-byte values are in little-endian. Meaning, if, for example, you want to get the temperature value and #14 and #15 octets indicate the temperature as "a1 19" → the real temperature value is going to be (0x19a1)/256 = 25.6 C.

UserData and Secret fields are configured with the help of flags. In the "UserData" section, the parameter that controls whether the "Secret" is encrypted or not is called FLAG_ENCRYPTED. When FLAG_ENCRYPTED=0, it means the secret is not encrypted (1st bit in 6th octet would be set to 0), and when FLAG_ENCRYPTED=1, it means the secret is encrypted (1st bit in 6th octet would be set to 1).

In the "Secret" section, there are 6 flags (21st octet):

  1. FLAG_REED_SWITCH (1st bit - if set to 1, shows that the reed switch was closed at the moment of advertising)
  2. FLAG_ACCEL_TILT (2nd bit - if set to 1, shows that the advertisement was sent by tilting the device)
  3. FLAG_ACCEL_FREE_FALL (3d bit - if set to 1, shows that the advertisement was sent by dropping the device)
  4. FLAG_IMPACT_X (4th bit - if set to 1, shows that there was an impact on the x-axis at the moment of advertising)
  5. FLAG_IMPACT_Y (5th bit - if set to 1, shows that there was an impact on the y-axis at the moment of advertising)
  6. FLAG_IMPACT_Z (6th bit - if set to 1, shows that there was an impact on the z-axis at the moment of advertising)

For example, if you see that the 21st octet of the hex message has "02" - it means that the device was tilted. If you see "04" - it means that the device was dropped. If you see "38" - it means that when the advertisement was sent, the accelerometer detected an impact/wake-up on all 3 x/y/z-axis (the device was thrown/pushed or in other words, Bluetooth tag movement was initiated).

MikroTik PDU Payload structure

015ManufacturerDatacompany identifier
1FFManufacturerDatacompany identifier
24FManufacturerDatacompany identifier
309ManufacturerDatacompany identifier
401Versionthe version of this advertisement structure
500UserDatauser-configured part of the payload
6xx*Secretsecret: salt
7xx*Secretsecret: salt
8xx*Secretsecret: acceleration
9xx*Secretsecret: acceleration
10xx*Secretsecret: acceleration
11xx*Secretsecret: acceleration
12xx*Secretsecret: acceleration
13xx*Secretsecret: acceleration
14xx*Secretsecret: temperature
15xx*Secretsecret: temperature
16xx*Secretsecret: uptime
17xx*Secretsecret: uptime
18xx*Secretsecret: uptime
19xx*Secretsecret: uptime
2000Secretsecret: flags
2164Secretsecret: batteryPercentage

* - can vary

iBeacon packet structure

iBeacon is one of the supported advertising packet types. You can find more information about the protocol following the link.

The PDU Payload, in this case, consists of "AdvA" (that is 6 octets long) and "AdvData" (a field that contains data information) fields. Legacy Bluetooth devices can only support 31 byte-long beacon messages. UUID is 16 byte-long (MikroTik default UID=b2b98de4-c81c-47c2-b14e-791b3e5587ec).

"AdvData" field structure:

ManufacturerDatacompany identifier4 octets (1aff4c00)
BeaconTypea secondary identifier1 octet (const)
RemainingDataLengthdefines the remaining length for the payload in bytes

1 octet (const)

UserDatauser-configured part of the payload
  • Proximity UUID (universally unique identifier) = 16 octets (uint)
  • Major Number (specific group identifier) = 2 octets (uint)
  • Minor Number (specific beacon identifier) = 2 octets (uint)
TxPowerindicates the signal strength at one meter from the device

1 octet (int)

iBeacon PDU Payload structure

01aManufacturerDatacompany identifier
1ffManufacturerDatacompany identifier
24cManufacturerDatacompany identifier
300ManufacturerDatacompany identifier
402BeaconTypea secondary identifier
515RemainingDataLengthdefines the remaining length for the payload in bytes
6b2UserDataProximity UUID
7b9UserDataProximity UUID
88dUserDataProximity UUID
9e4UserDataProximity UUID
10c8UserDataProximity UUID
111cUserDataProximity UUID
1247UserDataProximity UUID
13c2UserDataProximity UUID
14b1UserDataProximity UUID
154eUserDataProximity UUID
1679UserDataProximity UUID
171bUserDataProximity UUID
183eUserDataProximity UUID
1955UserDataProximity UUID
2087UserDataProximity UUID
21ecUserDataProximity UUID
22xx*UserDataMajor Number
23xx*UserDataMajor Number
24xx*UserDataMinor Number
25xx*UserDataMinor Number
26xx*TxPowerindicates the signal strength at one meter from the device

* - can vary

Eddystone-TLM packet structure

Eddystone-TLM is one of the supported advertising packet types. You can find more information about the protocol following the link.

The PDU Payload, in this case, consists of "AdvA" (that is 6 octets long) and "AdvData" (a field that contains data information) fields. MikroTik default CompleteUUID=03 03 aa fe; ServiceData=11 16 aa fe.

"AdvData" field structure:

CommonPayloadpart of the advertisement payload that is common for all Eddystone's frame types
  • CompleteUUID (universally unique identifier) = 4 octets (const)
  • ServiceData (16 bit UUID data type) = 4 octets (const)
  • FrameType (Value = 0x20) = 1 octet (const)
TlmPayloadEddystone-TLM frame payload
  • Version (TLM version) = 1 octet (const)
  • BatteryVoltageMv (Battery voltage, 1 mV/bit) = 2 octets (uint)
  • TemperatureC (Beacon temperature in Celsius) = 2 octets (int)
  • AdvertisementCount (Advertising PDU count) = 4 octets (uint)
  • UptimeCounter (Time since power-on or reboot) = 4 octets (uint)


Eddystone-TLM PDU Payload structure

003CommonPayloadCompleteUUID
103CommonPayloadCompleteUUID
2aaCommonPayloadCompleteUUID
3feCommonPayloadCompleteUUID
411CommonPayloadServiceData
516CommonPayloadServiceData
6aaCommonPayloadServiceData
7feCommonPayloadServiceData
820CommonPayloadFrameType
900TlmPayloadVersion
10xx*TlmPayloadBatteryVoltageMv
11xx*TlmPayloadBatteryVoltageMv
12xx*TlmPayloadTemperatureC 
13xx*TlmPayloadTemperatureC 
14xx*TlmPayloadAdvertisementCount
15xx*TlmPayloadAdvertisementCount
16xx*TlmPayloadAdvertisementCount
17xx*TlmPayloadAdvertisementCount
18xx*TlmPayloadUptimeCounter
19xx*TlmPayloadUptimeCounter
20xx*TlmPayloadUptimeCounter
21xx*TlmPayloadUptimeCounter

* - can vary

Eddystone-UID packet structure

Eddystone-UID is one of the supported advertising packet types. You can find more information about the protocol following the link.

The PDU Payload, in this case, consists of "AdvA" (that is 6 octets long) and "AdvData" (a field that contains data information) fields. MikroTik default CompleteUUID=03 03 aa fe; ServiceData=17 16 aa fe.

"AdvData" field structure:

CommonPayloadpart of the advertisement payload that is common for all Eddystone's frame types
  • CompleteUUID (universally unique identifier) = 4 octets (const)
  • ServiceData (16 bit UUID data type) = 4 octets (const)
  • FrameType (value = 0x00) = 1 octet (const)
UidPayloadEddystone-UID frame payload
  • Ranging Data (calibrated Tx power at 0 m) = 1 octet (int)
  • Nspace (unique self-assigned beacon ID namespace) = 10 octets (uint)
  • Instance (unique ID within the namespace) = 6 octets (uint)
  • RFU1 (reserved for future use, value=0x00) = 1 octet (const)
  • RFU2 (reserved for future use, value=0x00) = 1 octet (const)


Eddystone-UID PDU Payload structure

003CommonPayloadCompleteUUID
103CommonPayloadCompleteUUID
2aaCommonPayloadCompleteUUID
3feCommonPayloadCompleteUUID
417CommonPayloadServiceData
516CommonPayloadServiceData
6aaCommonPayloadServiceData
7feCommonPayloadServiceData
800CommonPayloadFrameType
9xx*UidPayloadRanging Data
10b2UidPayloadNspace
11b9UidPayloadNspace
128dUidPayloadNspace
13e4UidPayloadNspace
14c8UidPayloadNspace
151cUidPayloadNspace
1647UidPayloadNspace
17c2UidPayloadNspace
18b1UidPayloadNspace
194eUidPayloadNspace
20xx*UidPayloadInstance
21xx*UidPayloadInstance
22xx*UidPayloadInstance
23xx*UidPayloadInstance
24xx*UidPayloadInstance
25xx*UidPayloadInstance
2600UidPayloadRFU1
2700UidPayloadRFU2

* - can vary

  • No labels