Fake BLE device on nRF24l01
This article is 90% based on the Bluetooth Low Energy “Bit-Banging” note. It all started with the fact that it took to launch the now common 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 its scheme I will not describe. On the Internet, including the Russian-language, 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 (the firmware below is presented for it).
As usual, miracles do not happen: the example did not want to work in the form “as it is”. Firstly, there is an obvious damage to the formatting on the page, and secondly, it is immediately obvious 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 other “blue teeth”, it is enough to mention that the standard Android device search does not look for BLE: separate applications are required for their review. BLE devices are a separate branch in Bluetooth technology; in fact, this is another standard. Apparently, it was developed with an eye on the capabilities 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 the full-fledged BLE protocol that will not work. However, we can create the correct Broadcast-package, which participates in the process of searching for a device.
Package Composition Code:
The program does only one thing: it initializes the radio module in a special way, makes a packet and sends it. This is enough for the phone to show the device in the search.
After my phone saw the application, the question immediately arose: is it possible to somehow use this “fake”?
Constraints in the nRF24l01 chip do not provide an opportunity 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 MAC address, and this is already some information, but 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. Data at a time can transmit no more than 32 bytes (limiting the module nRF24l01), while some of them are spent on the transfer of service structures BLE. The net remainder is about 32-6-3-3 = 20 bytes. Of these, 2 bytes will go to the header, so “our” data may be 18 bytes. But it is worth considering that I gave this calculation for a nameless device.
Theoretically, this hack can be used in real devices. The cost of nRF24l01 is dramatically lower than true-BLE modules. You can transfer data from any sensors to your smartphone, and, as is the case with BLE, sensors can be battery-powered.
If you take a bunch of the primitive ATtiny13 and nRF24l01, you get a device of a penny value. By placing a dozen or hundreds of such in a large room (for example, a shopping center), you can deploy a local positioning system, which in the application will show exactly where the owner of the phone is located.
Unfortunately, the question is open for me: what will be the consumption of the smartphone itself. Still, the connection with the device is not installed, you have to constantly carry out the scan. Maybe someone is familiar with the topic and will be able to comment.
In the appendage, investigated the possibility of implementing the interaction nRF24l01 with ANT + devices. Here, unfortunately, all is lost. If the synchronization byte in BLE and nRF24l01 is the same, then nothing will work in the case of the ANT protocol: the latter has a different vector.
Description
What the device looks like and what its scheme I will not describe. On the Internet, including the Russian-language, 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 (the firmware below is presented for it).
As usual, miracles do not happen: the example did not want to work in the form “as it is”. Firstly, there is an obvious damage to the formatting on the page, and secondly, it is immediately obvious 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 other “blue teeth”, it is enough to mention that the standard Android device search does not look for BLE: separate applications are required for their review. BLE devices are a separate branch in Bluetooth technology; in fact, this is another standard. Apparently, it was developed with an eye on the capabilities of low-power transceivers at 2.4 GHz. Hence the final similarity.
')
And the similarities are as follows:
- Same 2.4GHz operating frequencies with 1Mbps speed and cross channel grid.
- The same bytes starting bytes 10101010 or 01010101 (preamble).
- Same signal modulation: GFSK .
- The ability to set in nRF24l01 addressing 4 bytes.
But here are the differences:
- Different CRC algorithms. Fortunately in nRF24l01, you can disable it and do the calculation programmatically in the microcontroller.
- nRF24l01 after each transmission disables the PLL . This puts a pig in the implementation of the protocol, because restarting PLL requires decent time.
- BLE supports data packets with a length of up to 39 bytes. For nRF24l01, this value is limited to 32 bytes.
It is because of the last point of the full-fledged BLE protocol that will not work. However, we can create the correct Broadcast-package, which participates in the process of searching for a device.
Package Composition 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, makes a packet and sends it. This is enough for the phone to show the device in the search.
How to use
After my phone saw the application, the question immediately arose: is it possible to somehow use this “fake”?
Constraints in the nRF24l01 chip do not provide an opportunity 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 MAC address, and this is already some information, but 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. Data at a time can transmit no more than 32 bytes (limiting the module nRF24l01), while some of them are spent on the transfer of service structures BLE. The net remainder is about 32-6-3-3 = 20 bytes. Of these, 2 bytes will go to the header, so “our” data may be 18 bytes. But it is worth considering that I gave this calculation for a nameless device.
Applications
Theoretically, this hack can be used in real devices. The cost of nRF24l01 is dramatically lower than true-BLE modules. You can transfer data from any sensors to your smartphone, and, as is the case with BLE, sensors can be battery-powered.
If you take a bunch of the primitive ATtiny13 and nRF24l01, you get a device of a penny value. By placing a dozen or hundreds of such in a large room (for example, a shopping center), you can deploy a local positioning system, which in the application will show exactly where the owner of the phone is located.
Unfortunately, the question is open for me: what will be the consumption of the smartphone itself. Still, the connection with the device is not installed, you have to constantly carry out the scan. Maybe someone is familiar with the topic and will be able to comment.
ANT +
In the appendage, investigated the possibility of implementing the interaction nRF24l01 with ANT + devices. Here, unfortunately, all is lost. If the synchronization byte in BLE and nRF24l01 is the same, then nothing will work in the case of the ANT protocol: the latter has a different vector.
Links
- Original article: “Bit-Banging” Bluetooth Low Energy
- A modified version of the utility BluetoothLeGatt . Added output package body when searching. In this body, the data transmitted by the application is visible. The screen of the utility is presented above.
- Source code of work with the module.
- Binary with microcontroller firmware LPC1343 (USB-SPI bridge).
Source: https://habr.com/ru/post/245671/
All Articles