How to Decode BLE Advertising Data in the Field

You’re standing on a factory floor, a customer is watching, and a BLE sensor that worked perfectly in the lab isn’t showing up on the gateway. Or it’s showing up with the wrong service UUID. Or it’s broadcasting a name that doesn’t match the firmware you flashed last week. Your laptop with Wireshark is back at the office. You’ve got your phone, maybe a portable sniffer in your bag, and about fifteen minutes before the customer starts asking hard questions.

Here’s the thing most firmware engineers discover the hard way: you don’t need a lab to decode BLE advertising data. You need a method. A repeatable, systematic workflow that turns raw hex bytes into a clear answer: “here’s what’s wrong, here’s why.” This guide gives you that method.

Your Field Toolkit: Phone First, Sniffer When Needed

Your primary tool is already in your pocket. nRF Connect for Mobile (iOS and Android) is the gold standard for Bluetooth scanner debugging in the field. It shows raw advertising data bytes, reports advertising type, and distinguishes between advertising data and scan response data. Install it now if you haven’t already.

LightBlue and BLE Scanner are decent alternatives, but nRF Connect’s raw data view is the most complete and reliable for decode work.

When to escalate to a portable sniffer: Phone apps are passive scanners. They only see what the phone’s BLE stack decides to surface. If the device uses BLE 5.0 extended advertising on Coded PHY, if you need precise advertising interval timing, or if you suspect PHY-level issues, you need hardware. A Nordic nRF52840 dongle running nRF Sniffer, or a dedicated tool like an Ellisys Bluetooth Tracker, captures everything on the air, including PDU types and channel information that phone apps abstract away.

One more thing: Download the Bluetooth SIG Assigned Numbers page for Generic Access Profile and save it offline. You will reference this constantly. It’s the lookup table for every AD Type code you’ll encounter.

BLE Advertising Packet Anatomy: The Quick Refresher

Every BLE advertising packet on the air follows this structure:

| Preamble | Access Address | PDU | CRC |
| (1 byte) | (4 bytes)      |     | (3 bytes) |

You’ll never see the Preamble, Access Address, or CRC in a phone app. The BLE stack strips those. What you see is the PDU, and specifically the AdvData portion of it.

The Advertising PDU itself breaks down as:

| Header (2 bytes) | AdvA (6 bytes) | AdvData (0–31 bytes) |
|  PDU type + len   | Advertiser addr | <-- This is what we decode

The AdvData field is a sequence of LTV (Length–Type–Value) structures packed end to end. That’s the payload you’ll parse.

BLE 5.0+ extended advertising changes the picture. Legacy advertising (ADV_IND, ADV_NONCONN_IND, etc.) caps AdvData at 31 bytes. Extended advertising introduces ADV_EXT_IND on primary channels, which points to AUX_ADV_IND on secondary channels. These auxiliary PDUs support up to 254 bytes per fragment and can chain for even more data. Most phone apps show you the reassembled data transparently, but they may not tell you which PDU type carried it. This matters when a device is using extended advertising and an older phone can’t see the secondary channel PDUs at all. If a device seems invisible to one phone but visible to another, this is often why.

Decoding the LTV Structure Byte by Byte

Every AD structure inside AdvData follows the same pattern:

| Length (1 byte) | AD Type (1 byte) | AD Data (Length-1 bytes) |

The Length byte counts the AD Type byte plus the value bytes, not itself. This trips people up constantly.

Let’s decode a real-world advertising payload. Suppose nRF Connect shows this raw hex for a temperature sensor:

02 01 06 07 09 54 65 6D 70 2D 41 03 03 1A 18 09 FF 4C 00 02 15 AA BB CC DD

Parse it segment by segment:

Segment 1: 02 01 06

• Length: 0x02 → 2 bytes follow
• AD Type: 0x01 → Flags
• Value: 0x06 → LE General Discoverable + BR/EDR Not Supported

Segment 2: 07 09 54 65 6D 70 2D 41

• Length: 0x07 → 7 bytes follow
• AD Type: 0x09 → Complete Local Name
• Value: 54 65 6D 70 2D 41 → ASCII: “Temp-A”

Segment 3: 03 03 1A 18

• Length: 0x03 → 3 bytes follow
• AD Type: 0x03 → Complete List of 16-bit Service UUIDs
• Value: 1A 18 → UUID 0x181A (little-endian!) → Environmental Sensing Service

Segment 4: 09 FF 4C 00 02 15 AA BB CC DD

• Length: 0x09 → 9 bytes follow
• AD Type: 0xFF → Manufacturer Specific Data
• Value: 4C 00 → Company ID 0x004C (Apple) in little-endian, followed by 02 15 AA BB CC DD (proprietary payload)

The 10 AD Types You’ll See 90% of the Time

Critical endianness reminder: Every multi-byte numeric value (UUIDs, company IDs, appearance codes) is transmitted little-endian in BLE advertising. The raw bytes 1A 18 mean UUID 0x181A, not 0x1A18. For 128-bit UUIDs, you must reverse the entire 16-byte sequence before comparing it to what’s in your firmware spec or the Bluetooth SIG registry. This single fact accounts for the majority of “the UUID doesn’t match” panic in the field.

The 4-Step Field Decode Workflow

Here’s the repeatable process. Do it the same way every time and you’ll find the problem faster than you expect.

Step 1: Capture

Open nRF Connect. Start scanning. Locate your target device by name, MAC address, or signal strength (stand close to it). Tap the device entry and look for the raw advertising data. nRF Connect shows this as a hex string under the “ADVERTISING DATA” or “RAW” section. Screenshot it or copy the hex. Also note: is there a separate Scan Response? Capture that too.

Step 2: Identify the PDU Context

Check what nRF Connect reports about the advertising type. Is it Legacy or Extended? Which PHY: 1M, 2M, or Coded? What’s the advertising interval? This frames your expectations. A legacy PDU can’t carry more than 31 bytes of AdvData. If your firmware is supposed to broadcast 40 bytes of service data, and the device is using legacy advertising, you’ve already found the problem.

Step 3: Parse LTV Segments

Starting at byte 0 of the AdvData hex, walk through each LTV block. Build a simple table:

If at any point the next length byte points past the end of the payload, or lands you in the middle of what should be a different field, you’ve found a structural error, likely an off-by-one length bug in firmware.

Step 4: Cross-Reference and Diagnose

Compare your parsed table against the firmware advertising configuration or device spec. Check for:

• Missing fields: Is the service UUID absent? Is the device name not being broadcast? (Check if it’s in the scan response instead.)
• Wrong values: Does the company ID in 0xFF match your organization, or did someone leave a test value in?
• Structural errors: Here’s a subtle one. Consider this broken payload:

02 01 06 08 09 54 65 6D 70 2D 41 03 03 1A 18

The second segment has length 0x08, which means 8 bytes follow. But the name “Temp-A” is only 6 characters, so the AD Type + value is 7 bytes. That length should be 0x07. Because it says 0x08, the parser consumes one extra byte, the 0x03 that should start the next segment, as part of the name. The third segment then starts at 0x03 1A 18, which parses as length 3, AD Type 0x1A (“Advertising Interval”), value 0x18. The service UUID has vanished. One byte off, completely wrong interpretation. This is exactly the kind of bug you find in the field.

Bluetooth Scanner Debugging Pitfalls That Waste Hours

Endianness errors are the #1 time sink. Before you file a bug report saying the UUID is wrong, reverse the byte order. Then check again.

Scan Response vs. Advertising Data confusion. Some apps (including nRF Connect in certain views) merge advertising data and scan response data into a single display. If you’re checking whether a field is present in the advertisement itself, because a passive scanner that doesn’t send scan requests needs to see it, you must confirm which payload carries it. nRF Connect lets you differentiate, but you have to look.

Invisible extended advertising. If a device uses BLE 5.0 extended advertising on Coded PHY or 2M PHY for the secondary channel, older phones (roughly pre-2020) may not support those PHYs. The device is advertising. Your phone just can’t hear it. Test with a known BLE 5.0+ capable phone, or use a sniffer.

Manufacturer Specific Data (0xFF) is opaque. The first two bytes are the company ID (little-endian, per the SIG registry). Everything after is proprietary. Don’t try to guess the format. Get the vendor’s documentation or your own firmware spec.

Flags (0x01) absent in extended advertising. The Bluetooth Core Specification says Flags are not required in extended advertising PDUs. If you’re validating a BLE 5.0 device and Flags are missing, that’s compliant behavior, not a bug.

Turn This Into Muscle Memory

The workflow is simple: Capture → Identify PDU type → Parse LTV → Cross-reference spec. The more you do it, the faster it gets. After a few sessions, you’ll recognize 02 01 06 as Flags and 0xFF as Manufacturer Specific Data at a glance, without looking anything up.

Keep the AD Type reference table on your phone. Screenshot it, bookmark the SIG Assigned Numbers page, or print a pocket card. When you’re on a factory floor with a misbehaving device and fifteen minutes on the clock, the difference between having a method and not having one is the difference between a solved problem and an embarrassing callback.

Hubble Network enables BLE devices to transmit data directly to satellites—no gateways, no infrastructure buildout. See how it works →