BLE beacons Receiving

[salembream]

Hi,
I am wondering if NRF24L01 can be used to receive other (standard) BLE beacons?
If it is possible, any guidelines to implement it ?

[2bndy5]

This library doesn't officially support it, but all the tools you need are there in the fake_ble module. Have a look at the source code for https://github.com/floe/BTLE library. Most importantly, remember that the nRF24L01 can only capture 32 bytes and the BLE payloads occupy a large chunk of that in an arbitrary Mac address and 24-bit CRC (not to mention the required data structures used by various BLE specifications).

Last time I printed out all the incoming BLE data, I was overwhelmed and gave up.

You will definitely need to write a function that decodes the BLE data structures present in the incoming BLE payload (after comparing the included CRC with the rest of the payload, then dewhitening the payload using FakeBLE.whiten() while still on the channel that the payload was received).

[salembream]

I think it depends on the packets we want to receive, I will check if it is short enough then may I give it a try.

Thanks for the valuable information, much appreciated.

[2bndy5]

I forgot to mention that BLE payloads are transmitted in little endian. The fake_ble module has functions that can reverse it back to big endian. This might need to be addressed before doing CRC validation.

[2bndy5]

@salembream Obviously, you scratched an itch I've had since releasing the fake_ble module back in v1.2.0. Were you thinking of making a contribution to this library or are you just going to implement this feature in your own app(s)? I have in mind an API for this feature by overriding the RF24.available() & RF24.read() methods.

[2bndy5]

I put together a example script that should better describe the initial process using a constructed payload from the fake_ble_test example. Please note that I ran this script using my rf24-network branch (2 optional parameters have been added to address_repr() in the rf24 module).

from nrf24l01_fake_ble_test import *  # we'll use some assets from the example
from circuitpython_nrf24l01.fake_ble import crc24_ble, reverse_bits
from circuitpython_nrf24l01.rf24 import address_repr  # for readable results

print("Preparing an outgoing payload to examine")
pl = nrf._make_payload(chunk(battery_service.buffer, 0x16))
print("raw payload data including CRC:\n\t", address_repr(pl, False, " "))
white = nrf.whiten(pl)
print("whitened payload data (using active channel):\n\t", address_repr(white, False, " "))
rev = reverse_bits(white)
print("reversed payload data:\n\t", address_repr(rev, False, " "))
print("data is now ready for transmitting to BLE reciever\n")

print("using payload data to re-assemble raw payload data as if it was received")
rev2 = reverse_bits(rev)
print("reversed payload data:\n\t", address_repr(rev2, False, " "))
dewhite = nrf.whiten(rev2)
print("dewhitened payload data (using same active channel):\n\t", address_repr(dewhite, False, " "))
print("comparing CRC from payload to a re-calculated CRC")
print("checksum", "validated" if crc24_ble(dewhite[:-3]) == dewhite[-3:] else "is invalid")

This script's output is

Adafruit CircuitPython 6.3.0 on 2021-06-01; Adafruit Feather RP2040 with rp2040
>>> from ble_rx_tutorial import *
    nRF24L01 fake BLE beacon test
    Run master() to broadcast the device name, pa_level, & battery charge
    Run send_temp() to broadcast the device name & a temperature
    Run send_url() to broadcast a custom URL link
Preparing an outgoing payload to examine
raw payload data including CRC:
         42 0e b8 97 21 29 52 4a 02 01 05 04 16 0f 18 55 eb cf 8c
whitened payload data (using active channel):
         cf dc ef 36 1c 8e 34 fa 77 30 14 4c 80 78 e0 b6 ad 26 27
reversed payload data:
         f3 3b f7 6c 38 71 2c 5f ee 0c 28 32 01 1e 07 6d b5 64 e4
data is now ready for transmitting to BLE reciever

using payload data to re-assemble raw payload data as if it was received
reversed payload data:
         cf dc ef 36 1c 8e 34 fa 77 30 14 4c 80 78 e0 b6 ad 26 27
dewhitened payload data (using same active channel):
         42 0e b8 97 21 29 52 4a 02 01 05 04 16 0f 18 55 eb cf 8c
comparing CRC from payload to a re-calculated CRC
checksum validated

From there, you know for sure that the first 8 bytes will be the BLE spec's required flags (first 2 bytes) and the randomly generated 6 byte MAC address (bytes 3 - 8). The last 3 bytes are the CRC checksum. Everything in between is BLE data structures. In fact the second byte (byte 2) is the total size of the BLE data. This size does include the size of the MAC address, but it does not include the 24-bit CRC and the first 2 bytes of the payload.

Knowledge for decoding data structures

All BLE data structures begin with a byte that describes the size of the entire structure (as an int). This beginning byte is not counted as part of the data structure size. The data structures have to be "packaged" into chunks. Each chunk begins (after the size byte) with a byte describing chunk's type.

02 01 05

Above is the required flags that describe the BLE device. 0x02 is the size of the structure, 0x01 is the type of the chunk, and 0x05 is the flags that indicates the device is discoverable but cannot be bonded/paired. IIRC, this required data doesn't have to immediately follow the MAC address, but that's just how I did it (I think it was to be consistent with Floe's BLE lib).

About Service Data Structures

Usually 0x16 is passed to chunk() function when packaging the data. The only other common chunk type is 0xFF (which I think encompasses all custom/user-defined chunk types). I'll come back to this at the end.

Service Data structures proceed to have the service data UUID number (in little endian) after the byte about chunk type. The FakeBLE module only uses 3 service data specifications (which all use 2 byte long UUID numbers) because that's all that can be crammed into a 32 byte payload. I used the battery_service variable in the fake_ble_test because it is the simplest format.

>>> address_repr(chunk(battery_service.buffer, 0x16), False, " ")
'04 16 0f 18 55'

• byte 1 (0x04) is the size of the packaged data. Notice that the size doesn't actually count itself
• byte 2 (0x16) is the chunk type. We should only be looking for 0x16 or 0xFF (see also below about BLE device name and TX-ing PA Level)
• bytes 3-4 (0x0F18) is the little endian Service Data's UUID number for the Battery Service (0x180F)
• byte 5 (0x55) is the Service Data's value. In this example, we used 85% as the data value. Float data will be a little harder to decode because it uses an exponential format. URL data (using Google's Eddystone Protocol) will be typical string parsing but with some URL parts (like "www" and ".com") replaced with an Eddystone "byte code".

Non-Service data structures

The BLE device name and TX-ing PA Level also follow this structure as they are data defined by the BLE general specs (not individual Service Data specs). However, instead of passing 0x16 or 0xFF to chunk() as the chunk type, the BLE device name uses 0x08 for "short names" (I think 0x09 is for "complete names"), and the TX-ing PA Level uses 0x0A.

>>> chunk(b'fake ble', 0x08)
bytearray(b'\t\x08fake ble')
>>> address_repr(chunk(b'fake ble', 0x08), False, " ")
'09 08 66 61 6b 65 20 62 6c 65'

[salembream]

Oh, thanks for your great efforts!
I was planning to tinker with it in near future once I get the hardware.
If after testing I get any idea I will try to contribute it :D .
If this feature becomes common and many people want/use it, maybe an optional dependency added for a library like https://github.com/citruz/beacontools, to make it responsible for parsing and getting ready-to-use data from the raw packets.

thanks!

[2bndy5]

I would like to use some kind of stable parsing (my initial attempts seem a bit buggy ATM). However, that lib requires CPython libs available via pip and doesn't seem optimized for microcontrollers' (which can't use pip) limited memory. Again, the nRF24L01 can only handle 32 byte maximum (BLE payloads can be actually much larger), so I have to keep working around that limitation also.

Remember this BLE implementation is an extreme hack of the BLE specs ("here be dragons"). The radio simply wasn't designed to be fully BLE compliant (unlike the nRF5x predecessors).

[2bndy5]

Preliminary support for receiving BLE data is now supported in v2.1.0 of this lib.