Fake BLE device on nRF24l01
This article is 90% based on the “Bit-Banging” Bluetooth Low Energy Note . It all started with the fact that it was necessary to launch the now widespread transceivers on the Nordic nRF24l01 chip. In the process of searching for examples of working with them, I came across the above article. Being the owner of a phone with Bluetooth 4.0 support (which includes Bluetooth Low Energy), I thought: why not try to repeat the experiment?
What the device looks like and what kind of circuit it will not describe. On the Internet, including Russian, it is full of information on the described radio modules. I can only say that in my case, the NXP LPC1343 microcontroller was used for control (for it, the firmware is presented below).
As usual, miracles do not happen: the example did not want to work as it is. Firstly, there is an obvious formatting corruption on the page, and secondly, you can immediately see that there is a problem with the length byte. What other typos and inaccuracies are present in the description, I could only guess. However, after short edits everything worked.
The BLE device is very different from all the other “blue cloves”, it’s enough to mention that the standard device search in Android does not look for BLE: for their review, separate applications are required. BLE devices are a separate branch in Bluetooth technology, in fact, this is another standard. Apparently, it was developed with an eye to the possibilities of low-power transceivers at 2.4 GHz. Hence the final similarity.
And the similarities are as follows:
But here are the differences:
It is because of the last point of a full-fledged BLE protocol that it will not be possible to raise it. However, we can compile the correct Broadcast package that is involved in the device search process.
Package Code:
The program does only one thing: it initializes the radio module in a special way, compiles a packet and sends it. This is enough for the phone to show the device in search.
After my phone saw the application, the question immediately arose: is it possible to somehow use this "fake"?
Limitations in the nRF24l01 chip do not make it possible to raise a full-fledged BLE protocol and end with the fact that the phone “sees” something, but cannot work with it in any way. Accordingly, the transfer of data to the device is swept away immediately, but what about the transfer of data to the phone? The phone determines the name and poppy address, and this is already some kind of information, and what else?
And you can also transfer our data. To do this, add additional fields to the buffer. The tag MANUFACTURER_DATA = 0xFF is best suited for this. No more than 32 bytes of data can be transferred at a time (limitation of the nRF24l01 module), while part of them is spent on transmitting BLE service structures. About 32-6-3-3 = 20 bytes remain in the net. Of these, 2 bytes will go to the header, so there can be 18 bytes of “our” data. But it is worth considering that I gave this calculation for an unnamed device.
Theoretically, this hack can be used in real devices. The cost of nRF24l01 is dramatically lower than true-BLE modules. It is possible to transfer data from any sensors to the smartphone, and as with BLE, the sensors can be battery powered.
If you take a bunch of the most primitive ATtiny13 and nRF24l01, you get a penny device. Having placed a dozen or a hundred of these in a large room (for example, a shopping center), you can deploy a local positioning system, which in the application will accurately show where the owner of the phone is.
Unfortunately, the question is open for me: what will be the consumption of the smartphone itself. Still, communication with the device is not established, you have to constantly scan. Maybe someone is familiar with the topic and can comment.
In addition, I investigated the possibility of implementing the interaction of nRF24l01 with ANT + devices. Here, unfortunately, everything is lost. If the synchronization byte in BLE and nRF24l01 are the same, then nothing will work in the case of the ANT protocol: the latter has a different vector from them.
Description
What the device looks like and what kind of circuit it will not describe. On the Internet, including Russian, it is full of information on the described radio modules. I can only say that in my case, the NXP LPC1343 microcontroller was used for control (for it, the firmware is presented below).
As usual, miracles do not happen: the example did not want to work as it is. Firstly, there is an obvious formatting corruption on the page, and secondly, you can immediately see that there is a problem with the length byte. What other typos and inaccuracies are present in the description, I could only guess. However, after short edits everything worked.
The BLE device is very different from all the other “blue cloves”, it’s enough to mention that the standard device search in Android does not look for BLE: for their review, separate applications are required. BLE devices are a separate branch in Bluetooth technology, in fact, this is another standard. Apparently, it was developed with an eye to the possibilities of low-power transceivers at 2.4 GHz. Hence the final similarity.
And the similarities are as follows:
- The same operating frequencies 2.4GHz with support for 1Mbps speed and intersecting channel grid.
- Identical bytes start bytes 10101010 or 01010101 (preamble).
- Same signal modulation: GFSK .
- Ability to set nRF24l01 addressing by 4 bytes.
But here are the differences:
- Different CRC algorithms. Fortunately, in nRF24l01 you can turn it off and do the calculation programmatically in the microcontroller.
- nRF24l01 disables PLL after each transmission . This puts the pig in the implementation of the protocol, as restarting PLL takes a decent amount of time.
- BLE supports data packets up to 39 bytes long. For nRF24l01, this value is limited to 32 bytes.
It is because of the last point of a full-fledged BLE protocol that it will not be possible to raise it. However, we can compile the correct Broadcast package that is involved in the device search process.
Package Code:
buf[L++] = 0x42; //PDU type, given address is random
buf[L++] = 0x11; //17 bytes of payload
buf[L++] = MY_MAC_0;//0xEF
buf[L++] = MY_MAC_1;//0xFF
buf[L++] = MY_MAC_2;//0xC0
buf[L++] = MY_MAC_3;//0xAA
buf[L++] = MY_MAC_4;//0x18
buf[L++] = MY_MAC_5;//0x00
buf[L++] = 2; //flags (LE-only, limited discovery mode)
buf[L++] = 0x01;
buf[L++] = 0x05;
buf[L++] = 7; //name
buf[L++] = 0x08;
buf[L++] = 'n';
buf[L++] = 'R';
buf[L++] = 'F';
buf[L++] = ' ';
buf[L++] = 'L';
buf[L++] = 'E';
buf[L++] = 0x55; //CRC start value: 0x555555
buf[L++] = 0x55;
buf[L++] = 0x55;
//...
btLePacketEncode(buf, L, chLe[ch]); // crc calculate
The program does only one thing: it initializes the radio module in a special way, compiles a packet and sends it. This is enough for the phone to show the device in search.
How to use
After my phone saw the application, the question immediately arose: is it possible to somehow use this "fake"?
Limitations in the nRF24l01 chip do not make it possible to raise a full-fledged BLE protocol and end with the fact that the phone “sees” something, but cannot work with it in any way. Accordingly, the transfer of data to the device is swept away immediately, but what about the transfer of data to the phone? The phone determines the name and poppy address, and this is already some kind of information, and what else?
And you can also transfer our data. To do this, add additional fields to the buffer. The tag MANUFACTURER_DATA = 0xFF is best suited for this. No more than 32 bytes of data can be transferred at a time (limitation of the nRF24l01 module), while part of them is spent on transmitting BLE service structures. About 32-6-3-3 = 20 bytes remain in the net. Of these, 2 bytes will go to the header, so there can be 18 bytes of “our” data. But it is worth considering that I gave this calculation for an unnamed device.
Applications
Theoretically, this hack can be used in real devices. The cost of nRF24l01 is dramatically lower than true-BLE modules. It is possible to transfer data from any sensors to the smartphone, and as with BLE, the sensors can be battery powered.
If you take a bunch of the most primitive ATtiny13 and nRF24l01, you get a penny device. Having placed a dozen or a hundred of these in a large room (for example, a shopping center), you can deploy a local positioning system, which in the application will accurately show where the owner of the phone is.
Unfortunately, the question is open for me: what will be the consumption of the smartphone itself. Still, communication with the device is not established, you have to constantly scan. Maybe someone is familiar with the topic and can comment.
ANT +
In addition, I investigated the possibility of implementing the interaction of nRF24l01 with ANT + devices. Here, unfortunately, everything is lost. If the synchronization byte in BLE and nRF24l01 are the same, then nothing will work in the case of the ANT protocol: the latter has a different vector from them.
References
- Original article: “Bit-Banging” Bluetooth Low Energy
- A modified version of the BluetoothLeGatt utility . Added output of the package body when searching. In this body, the data transmitted by the application is visible. The utility operation screen is presented above.
- The source code for working with the module.
- Binary with firmware microcontroller LPC1343 (USB-SPI bridge).