AltBeacon ignores pdu type of my beacon packages

Question

I'm using AltBeacon library to work with my beacons (provided by Shenzhen Minew Technologies Co., Ltd.). I use following

beaconManager.getBeaconParsers().add(new BeaconParser().
            setBeaconLayout("m:2-3=0215,i:4-19,i:20-21,i:22-23,p:24-24"));

to set layout. In my logcat I see RSSI values coming from my beacons like:

06-21 01:50:27.091  13496-13507/com.example.tkobilov.minewtestapp D/BluetoothAdapter﹕ onScanResult() - Device=CD:A6:29:2F:08:26 RSSI=-73
06-21 01:50:27.503  13496-13508/com.example.tkobilov.minewtestapp D/BluetoothAdapter﹕ onScanResult() - Device=D3:EB:21:87:9D:7E RSSI=-58
06-21 01:50:27.508  13496-13582/com.example.tkobilov.minewtestapp D/BluetoothAdapter﹕ onScanResult() - Device=D3:EB:21:87:9D:7E RSSI=-59

However in

protected Beacon fromScanData(byte[] bytesToProcess, int rssi, BluetoothDevice device, Beacon beacon) {

    BleAdvertisement advert = new BleAdvertisement(bytesToProcess);
    Pdu pduToParse = null;
    for (Pdu pdu: advert.getPdus()) {
        if (pdu.getType() == Pdu.GATT_SERVICE_UUID_PDU_TYPE ||
                pdu.getType() == Pdu.MANUFACTURER_DATA_PDU_TYPE) {
            pduToParse = pdu;
            if (LogManager.isVerboseLoggingEnabled()) {
                LogManager.d(TAG, "Processing pdu type %02X: %s with startIndex: %d, endIndex: %d", pdu.getType(), bytesToHex(bytesToProcess), pdu.getStartIndex(), pdu.getEndIndex());
            }
            break;
        }
        else {
            if (LogManager.isVerboseLoggingEnabled()) {
                LogManager.d(TAG, "Ignoring pdu type %02X", pdu.getType());
            }
        }

I every time come to "Ignoring pdu type...". I checked bytesToProcess array. Every time it has just 1st and 2nd nonzero values. Other values are zero. BeaconCFG application recommended by Minew founds these beacons without any problems but I need AltBeacon for my project. What might be the reason of this?

My LogCat output:

D/BluetoothDevice﹕ mAddress: EE:74:8B:CA:DB:F1 D/BluetoothAdapter﹕ onScanResult() - Device=EE:74:8B:CA:DB:F1 RSSI=-52 D/CycledLeScannerForJellyBeanMr2﹕ got record D/BluetoothDevice﹕ mAddress: EE:74:8B:CA:DB:F1 D/BeaconParser﹕ Ignoring pdu type 01 D/BeaconParser﹕ Ignoring pdu type 0A D/BeaconParser﹕ No PDUs to process in this packet. D/BeaconParser﹕ No PDUs to process in this packet. D/BeaconParser﹕ Ignoring pdu type 0A D/BeaconParser﹕ Ignoring pdu type 01 D/BeaconParser﹕ No PDUs to process in this packet. D/BeaconParser﹕ No PDUs to process in this packet. D/BluetoothAdapter﹕ onScanResult() - Device=ED:EE:AD:02:1B:30 RSSI=-62 D/CycledLeScannerForJellyBeanMr2﹕ got record D/BluetoothDevice﹕ mAddress: ED:EE:AD:02:1B:30 D/BluetoothAdapter﹕ onScanResult() - Device=ED:EE:AD:02:1B:30 RSSI=-62 D/CycledLeScannerForJellyBeanMr2﹕ got record D/BluetoothDevice﹕ mAddress: ED:EE:AD:02:1B:30 D/BeaconParser﹕ Ignoring pdu type 01 D/BeaconParser﹕ No PDUs to process in this packet. D/BeaconParser﹕ Ignoring pdu type 01 D/BeaconParser﹕ No PDUs to process in this packet. D/BeaconParser﹕ Ignoring pdu type 0A D/BeaconParser﹕ No PDUs to process in this packet. D/BeaconParser﹕ Ignoring pdu type 0A D/BeaconParser﹕ No PDUs to process in this packet. D/CycledLeScanner﹕ Waiting to stop scan cycle for another 98 milliseconds D/CycledLeScanner﹕ Done with scan cycle D/BluetoothAdapter﹕ isEnabled D/CycledLeScanner﹕ stopping bluetooth le scan D/BluetoothAdapter﹕ stopLeScan() D/CycledLeScanner﹕ starting a new scan cycle D/BluetoothAdapter﹕ isEnabled D/CycledLeScanner﹕ starting a new bluetooth le scan D/BluetoothAdapter﹕ startLeScan(): null D/BluetoothAdapter﹕ onClientRegistered() - status=0 clientIf=1 D/CycledLeScanner﹕ Waiting to stop scan cycle for another 1100 milliseconds

Content of my PDUs

D/CycledLeScanner﹕ Waiting to stop scan cycle for another 1100 milliseconds D/CycledLeScanner﹕ Scan started D/BluetoothAdapter﹕ onScanResult() - Device=EE:74:8B:CA:DB:F1 RSSI=-63 D/CycledLeScannerForJellyBeanMr2﹕ got record D/BluetoothDevice﹕ mAddress: EE:74:8B:CA:DB:F1 D/BeaconParser﹕ Ignoring pdu type 01 D/BeaconParser﹕ No PDUs to process in this packet -- 02 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 seen D/BeaconParser﹕ Ignoring pdu type 01 D/BeaconParser﹕ No PDUs to process in this packet -- 02 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 seen D/BluetoothAdapter﹕ onScanResult() - Device=EE:74:8B:CA:DB:F1 RSSI=-63

Answer 1

There are two main ways to read the identifiers from a Bluetooth LE beacon:

1. The Android Beacon Library and similar SDKs detect beacons by looking at Bluetooth LE advertisement packets without making a Bluetooth LE connection to the beacon device -- this is the standard mechanism for detecting bluetooth beacons in an app.

2. Configuration apps like iBeaconCFG typically establish a Bluetooth LE connection to the device to read and set beacon identifiers and other configuration parameters using GATT. This configuration mechanism is non-standard, and actually stops the beacon from transmitting while the connection is established. For this reason, this secondary means of detecting a beacon is not appropriate for apps to use. It is only useful for initial configuration of the beacon.

Based on the information reported in the question and comments, it appears that the Philips v387 Android device has a problem with its bluetooth stack where it is unable to detect beacons using the first mechanism. (It reports incorrectly that the advertisement packets that it reads contain all zeros.) That means this device will simply not be able to run apps that detect beacons. The fact that it reportedly works with a configuration app likely means that it can successfully establish a GATT connection to configure beacons.

The Philips v387 Android device cannot be used to detect beacons in a general purpose app. It may, however, be used to configure beacons that are connectable using a GATT interface.

Answer 2

Finally as a workaround I see a way to check PDUs and generate fake beacon object with a real MACs, RSSIs and beacon names if adv packages are wrong. In this case I can't use Major, Minor and TxPower but RSSI and beacon names are available.