Something’s not working the way you expect, and you’re not totally sure where the problem lives. Maybe your peripheral isn’t showing up in scans. Maybe it shows up, but your app won’t recognize it. Maybe everything looks fine and you just want to confirm the peripheral is broadcasting what you think it’s broadcasting before you move on. Either way, the advertising packet is the first place to look, and LightBlue will show you exactly what’s in it.
The nice thing about checking the advertising packet first is that it takes about two minutes and rules out an entire category of problems. A service UUID that didn’t make it into the packet. Manufacturer data in the wrong format. A device that isn’t marking itself as connectable. These are common; they’re easy to confirm, and finding them here saves you from going down a much longer path in your code.
If you’ve never used LightBlue before, start with the LightBlue How-To Guide. Otherwise, let’s get into it.
Finding Your Device in LightBlue
Open LightBlue and navigate to the Peripherals tab. LightBlue will begin scanning automatically and populate the list with nearby BLE devices.
Find your peripheral in the list. If it broadcasts a name, it will appear there. Many peripherals do not broadcast a name by default and will show as unnamed. If that is the case, use signal strength to confirm you have the right device. Move closer to the peripheral and watch for the RSSI value to strengthen. The device with the strongest signal relative to your position is almost certainly yours.
On Android, you can tap a device without connecting to open its advertisement data directly. On iOS, you may need to connect first before the advertisement data view is available.
Reading the Advertisement Data
Once you have accessed the advertisement data view, LightBlue organizes what the peripheral is broadcasting into labeled fields. Here is what each one tells you.
Device Name: The human-readable name the peripheral is broadcasting, if it includes one. Not all peripherals broadcast a name, and some broadcast a shortened version. If your app uses device name to identify peripherals, this is where to confirm it matches exactly what your filtering logic expects.
Manufacturer Data: Raw bytes provided by the peripheral manufacturer. The peripheral’s firmware entirely defines the format. If your peripheral is using this field to broadcast a serial number, device type, or other identifying information, you will see it here as a hex string. Confirming it requires knowing the expected byte structure from your firmware spec.
Service UUIDs: The service UUIDs the peripheral is actively advertising. This is what scanForPeripherals(withServices:) on iOS and the equivalent scan filter on Android match against. If your BLE scan filter is not finding the device, check this field first. The UUID your app is filtering on needs to appear here exactly.
Service Data: Custom data associated with a specific service UUID, structured as a key-value pair. If your peripheral is using this field for pre-connection identification, you will see the service UUID alongside the associated data payload.
Transmit(Tx) Power: The peripheral’s transmit power level, if it includes this value in its advertising packet. Not all peripherals broadcast this. When present, it can be used alongside RSSI to estimate path loss.
Connectable Status: A simple flag indicating whether the peripheral is currently accepting connections. If this reads as not connectable and you are expecting to connect, something is wrong on the peripheral side.
Evaluating Your Advertisement Data Against Expectations
With the advertisement data in front of you, the question is whether it matches your expectations.
One thing to establish first: BLE advertising can span two packets, the primary advertising packet and the scan response. LightBlue shows data from both, but they are separate. A field that looks missing from the advertising packet may be present in the scan response, or vice versa. Work through what you’re seeing with that in mind.
A few things to surface here:
- Service UUIDs are the most frequent mismatch, a UUID that is correct in the firmware spec but formatted differently than what the app is filtering on, or a service that the peripheral is not advertising at all because it did not fit in the main packet and ended up in the overflow area. If you are not seeing a UUID you expect, check whether it might be appearing under a different field than anticipated.
- Manufacturer data problems tend to show up as a field that is present but contains unexpected bytes, like endianness issues, an extra manufacturer ID prefix that the parsing logic is not accounting for, or a payload length that does not match the expected format.
- Connectable status is worth checking any time connection attempts are failing unexpectedly. A BLE peripheral not advertising as connectable will be visible in a scan and then refuse connections. This can look like a central-side problem when it is actually a peripheral configuration issue.
If everything in the advertisement data looks correct and the problem persists, the issue is not in what the peripheral is broadcasting. That shifts the focus to how the app is handling what it receives.
Where to Go Next
If the advertisement data does not match what you expect, the fix lives on the peripheral side. Debugging BLE Peripherals with LightBlue walks through how to isolate and diagnose peripheral-side issues systematically.
If the advertisement data looks correct but your app still is not behaving as expected, the problem is in how the central is handling what it receives. Debugging BLE Centrals with LightBlue covers the most common central-side failure points and how to work through them.
