Chorus Explorer Tile: BLE tracking tiles

Published on 2025-08-19 by boatplugs

I came across these bluetooth low energy tracking tiles one day and they immediately piqued my interest due to their size, apparently capabilities and my lack of knowledge regarding bluetooth. So to get started I did my initial investigations and took the damn thing apart...

This Chorus Explorer tile is a Bluetooth Low Energy (BLE) tracking tile that uses an advertisement beacon protocol, it is designed to be deployed in enterprise logistics environments to provide tracking and monitoring of ~things~

photo of the chorus tile with a QR code on it

On the back of the tile you can notice the string: "c380ce26919e", this is the Unique Identifier (UID) for this tile and can also be seen in the following screenshot from my phone as the device address. Inside the device is a the DFN8 packaged IN100 microcontroller by InPlay. This MCU provides low-power bluetooth capabilities and some ADC features for connected sensors.

a screenshot of nRFConnect showing the BLE advertisement a marked photo of the PCB showing the pinout and traces

IN100 Datasheet

Here's some example advertisements from the device that I captured using my Pixel 8 and the nRFConnect + nRFLogger apps:

2025-08-19 14:09:34.816, -48 dBm, 0x13FFE0000F19059E9126CE80C3661D00005FB60A
2025-08-19 14:09:28.777, -49 dBm, 0x13FFE0000F19059E9126CE80C3651D00005FAE0A
2025-08-19 14:09:22.737, -48 dBm, 0x13FFE0000F19059E9126CE80C3641D00005FB60A
2025-08-19 14:09:16.693, -54 dBm, 0x13FFE0000F19059E9126CE80C3631D00005FB30A
2025-08-19 14:09:10.646, -50 dBm, 0x13FFE0000F19059E9126CE80C3621D00005FB30A

So what the hell does any of this junk mean?

First I'm going to need to learn a bit about BLE Advertisement packets...

The core specification of bluetooth says that the first two bytes of a packet are the length and datatype. So lets break these out then we can deal with what's left:

13:ff:e0:00:0f:19:05:9e:91:26:ce:80:c3:66:1d:00:00:5f:b6:0a

What we're left with is: e0:00:0f:19:05:9e:91:26:ce:80:c3:bb:07:00:00:5f:a9:0a

Using the bluetooth core spec supplement we learn what the manufacturer specific data type means:

The Manufacturer Specific data type is used for manufacturer specific data. The first two data octets shall contain a company identifier from Assigned Numbers. The interpretation of any other octets within the data shall be defined by the manufacturer specified by the company identifier.

Bluetooth Data-type specifications

Cool! So lets chop off the first two octets and figure out what the manufacturer is...

manufacturer: e0:00 = 0x00E0 (Google)

We can refer to the Bluetooth assigned numbers spec to figure out what company is referenced

(do a ctrl+f for 0x00E0)

After that we're left with the remaining data, now lets dig into the manufacturer's spec and see if we can tear this down even further!

Eddystone?

So... what is the manufacturer's spec??

Well, I can speculate based off a few things but we can also refer to the documentation that is provided for configuring and deploying the IN100:

https://cdn.sparkfun.com/assets/b/e/d/a/f/NanoBeacon_Config_Tool_User_Guide_EN.pdf https://github.com/google/eddystone/blob/master/protocol-specification.md

given the available documentation it looks like this chip supports three types of advertisement beacons: iBeacon (apple proprietary), Eddystone (google proprietary), or custom.

and based on our advertisement data so far I would say it's likely using the Google Eddystone spec. but it could still be using something custom. So lets try to rule out eddystone as the protocol of choice.

So if I dig into that spec I should be able to understand this leftover data.

For starters, the Eddystone protocol tries to adhere to the core bluetooth specification, so we can assume the first octet of our remaining data is the length and the following octet is the data type?

Eddystone advertisement data apparently follows Length-Type-Value logic which means the length value indicates the length of the datatype AND payload. So I'll keep that in mind as I dissect this

0f:19:05:9e:91:26:ce:80:c3:bb:07:00:00:5f:a9:0a

Remaining 14 octets + the datatype byte == 15

That seems to check out. But what doesn't is the rest of the Eddystone spec.

I get the feeling that Chorus stuck with the basic eddystone config and stuffed their own data onto the end of the manufacturer's data.

Another thing to note is that this chip does offer encryption capabilities but I'm under the impression that it's not used due to the seemingly linear progression of the data seen at the end of the frames (truncating up to the end of the UID for clarity):

66:1d:00:00:5f:b6:0a
65:1d:00:00:5f:ae:0a
64:1d:00:00:5f:b6:0a
63:1d:00:00:5f:b3:0a
62:1d:00:00:5f:b3:0a

If I was a betting gal I'd wager that we've got either one or two values packed into here.

My guess is that since there are no additional sensors on the device that it's likely broadcasting a timestamp or number of advertisements since powered on. Or maybe even both of those values?

For starters it looks like the first octet is being incremented each time there's a new packet while the last couple of octets have some sort of consistency?

Anyway, I'll leave you with this mystery until I figure out more ;)

References: