Background

In a previous post, I discussed the details of a BLE datalogging platform, dubbed the “SWGE Inspector”. During a recent visit to Galaxy’s Edge, I was able to test out the initial hardware setup. In this post we’ll discuss the methodology, the data, some possible interpretations, and look into some potential areas of improvement.

Setup

Hardware

The sensor platform was modified to include an nRF51822-based BLE packet sniffer from Adafruit. This prevented the original Bluetooth dongle from performing double-duty and instead solely as a connection point to the monitoring app, Stardust. It also had the advantage of producing a pcap-compatible file with useful metadata like BLE packet RSSI, channel, and status flags. Unfortunately, the sniffer had no attachment point for an external antenna, so the chip antenna’s performance had to suffice. The platform was otherwise as described.

Additionally, an Android device running a patched version of Play Disney Parks v2.21.1 was used to log app communication both between the Datapad native and web layer and between the Datapad and beacon system. The logging patch was adapted from the one described in this post. This Android device also ran Stardust.

Software

The SWGE Inspector’s Pi 4 ran a copy of SwgeInspector whose primary function was to ingest data from the sensor suite and log them unmodified to a file with timestamps, and to serve basic statistics to Stardust.

On a remote desktop, a copy of SwgeDatapadEmulator hosted a WebSocket server for the patched Datapad to communicate with. It timestamped and saved all socket activity generated by the logging patch.

After the data had been collected, the data was processed by the Unpacker project in SwgeInspector.

Data Processing

All told, the 3-hour jaunt at Galaxy’s Edge generated about 100 megabytes of raw data.

Time synchronizing

The Pi 4 has neither an RTC nor backup battery, so as long as power is disconnected, the system clock is frozen in time. This is typically remediated by connecting to an NTP server at boot, but the airgapped Pi remained unconnected throughout the trip. Luckily, the constant stream of GPS-synchronized UTC timestamps from the GPS allows the offset between the system time and UTC to be determined. Clock drift on the Pi 4 has been measured by others online to be up to 12 seconds per day in some conditions without an internet connection. While this could be corrected for using the UTC timestamps throughout the trip, I didn’t correct for it — a second or two over the three hours at the park shouldn’t skew the results too much.

GPS

All of the incoming packets are timestamped, but I also wanted them to be position-stamped so they can be plotted on a map. When the GPS has a fix, it will emit coordinates at 1 Hz, but more often than not, BLE packets and Datapad log packets are received by the system at some instant between two coordinate fixes. The easiest solution was to commit GIS heresy and linearly interpolate between the two GPS fixes nearest in time at the instant the packets are received.

I also filtered out fixes that had fewer than 10 satellites providing the fix. Only 4 are required for a basic fix, but 10 was arbitrarily chosen as a good compromise between keeping many points while discarding low-quality indoor points.

Datapad internally does not work directly with GPS fixes and instead uses the beacons for positioning (as described in the D-Beacon post). This means that beacon locations aren’t natively given geographic coordinates, and instead are given 2D plane coordinates local to the Datapad map image of your park (the map that’s displayed in the map tab of Datapad). Every set of plane coordinates is given an ID, which is referenced elsewhere when the location is needed:

// Excerpt of map-location-data-wdw.json
"d6T9eMCYs1kCcFx5Esbb": {
    "id": "72057615512826119",
    "x": 0.14887291667593763,
    "y": 0.49989224539017885
}

Beacons are mapped to locations in yet another file:

// Excerpt of map-object-data-wdw.json
"4bVkyPJvdWG7ud5fLUQz": {
    "beaconId": "72057602627875400",
    "id": "72057615512826119",
    "locationId": "72057615512826119",
    "name": "blp-02e4b-04",
    "priority": "HIGH",
    "type": "BeaconMarker"
}

At Hollywood Studios, the map image looks like the following with beacons plotted (resized 25%, click to enlarge):

A mapping between Datapad’s 2D plane coordinates was manually created by overlaying the Datapad map on a map with known physical boundaries, and calculating the offset. The process was eyeballed, and the maps don’t quite overlap (the Datapad map is somewhat stylized), but nothing should be off by more than a handful of feet.

BLE

The BLE packets I’m interested in are likely in this format, the beacon format discovered by some other brilliant folks to emulate droid “reaction” location beacons:

In Wireshark, we can display only packets that have a valid CRC (as computed by the sniffer) and are advertising with a Company ID of 0x0183, which is the Company ID assigned to Walt Disney by the Bluetooth SIG. The resulting filter would be:

(nordic_ble.crcok == 1) && (btcommon.eir_ad.entry.company_id == 0x0183)

Of the 140,313 packets captured at the park, this narrows our investigation down to 6,094, or about 4%. Following the packet format we’re interested in, we expect the manufacturer-specific data to be 6 bytes long, so tacking an extra (len(btcommon.eir_ad.entry.data) == 6) onto the filter brings us down to 1,461 packets. Here’s a breakdown of the packets by device type:

A few packets were captured with the Location and Droid beacon types, but the majority of packets are of a new unknown type, 0x10. Across the packets, only two bytes seem to be variable:

On a hunch, since the byte at offset 0x4 varied the most, I figured it must be related to the location of the beacon. Inspecting the resources in Datapad, beacon-data.json looks promising: it contains entries mapping app installations to “waypoint IDs”, which seem to be small integers.

// Excerpt of beacon-data.json
"CDqjl4fc0gqjsKxsS3op": {
    "id": "72057602627875400",
    "installationsUnlocked": [
        "72057602627878469"
    ],
    "name": "blp-02e4b-04",
    "playExperienceNameDLR": "dlr-dl-swge-blp-02e4b-04",
    "playExperienceNameWDW": "wdw-dhs-swge-blp-02e4b-04",
    "type": "Sensor",
    "waypointId": 61
}

Plotting both the packets and the beacons on a map near the Droid Depot and connecting packets to beacons using the byte at offset 0x4 as the waypoint ID yields the following:

• Blue points indicate packets
• Red points indicate beacons, their names, and locations as defined by Datapad
• Cyan points indicate orphan points which don’t correlate to any known waypoint ID
  • Since orphans appear in clumps, I assume a few new beacons are transmitting waypoint IDs that haven’t made their way into production as of Datapad v2.21.1

That’s progress! Here are two more maps, a detail shot of the marketplace and one of the entire park.

(Overview map resized 25%, click to enlarge)

That leaves one byte unknown at offset 0x5. Only 3 values were observed: 0xA1, 0xBA, and 0xBF. Following the standard set by the droid-related beacons (minimum RSSI as a signed byte), we would get minimum RSSIs of -95, -70, and -65, respectively. I assume that would indicate the minimum RSSI required to incorporate that beacon into beacon-based navigation or to interact with the installation. All of the values are reasonable, but the exact meaning is still unknown.

I compiled a table of the physical addresses of the Bluetooth radios that theoretically map to each beacon, but the table is rather long, so it’s in Appendix 1.

Going Forward

Hardware

The number of packets captured by the sniffer was disappointing for three hours of deliberately covering and re-tracing as much area on foot as possible. Adding an external antenna to the Adafruit sniffer is impossible, but another nRF51822-based device that incorporates an external antenna could be reflashed to use the sniffer firmware. Relocating the device outside of a backpack, or reducing the number of obstructions between the receiving radio and beacon (for example, the Pelican case and other PCBs), would also likely improve the received packet count. I was impressed, however, that some of the beacons were received so far away — one possible explanation is that the beacon radio is transmitting at a relatively high power, or another is that the radio spectrum was in the perfect condition at that moment to be heard over the noise at great length.

The Pi 4 was computational overkill for the required task. Sipping 4W while active, I got about 10 to 15 hours of battery life while at the park. The Pi also dumped 4W of heat into the case, theoretically reducing the SNR of the Bluetooth radios. Although the Pi was set to throttle the CPU at 50 degrees C, the heat dissipation and power consumption could be dramatically reduced by moving the task to a microcontroller. Since the task boiled down to ingesting serial streams and dumping them to an SD card, most microcontrollers with multiple high-performance serial lanes would work. Luckily, all of the radio and IMU boards used in the Inspector have versions without the USB-to-serial converter and expose a serial connection directly.

The clock drift of the Pi 4 wasn’t measured, but if a longer trip to the park is planned, it’d be a good idea to install a proper RTC module into whatever device is timestamping the incoming data.

Software

The Wireshark filter that produced these packets left over 4,000 packets advertising the Walt Disney company ID unaccounted for. Since they don’t seem to follow the format of a typical beacon advertisement, it’s possible that they’re show control messages to and from installations. These would be an interesting payload to dissect in the future.

Although the IMU data wasn’t utilized this time, it could be used in the future to augment the GPS data, both to improve location accuracy indoors and to prevent the need to filter out all GPS fixes under a certain satellite count.

I plan to use the beacon information to revise the SWGE Inspector for another trip to the park, next time using a local copy of the beacon locations to estimate position, emulating the Datapad functionality.

Appendix 1: Beacon MAC/Physical Address Table

Among the 79 physical addresses received that advertised the Walt Disney company ID and the Beacon magic header, 77 different waypoints were found. 8 waypoints were orphans as of v2.21.1.