nRF24L01+ modules like the one shown above are a great way to send data wirelessly between your projects. They can be found on many websites for less than $1.50 a piece and many libraries exist for them. After having thoroughly looked at the Bluetooth Low Energy (BLE) specifications, [Dimitry] managed to find a way to broadcast BLE data with an nRF24L01+.
Luckily enough, BLE and nRF24L01+ data packets have the same preambles. However, the latter can’t send more than 32 bytes in a packet and can’t hop between frequencies as fast as the BLE specification wants. [Dimitry] found the solution when he discovered that he could send unsolicited advertisements on three specific channels. In the end, considering the 32 bytes the nRF24L01+ can send, you’ll need to use 3 bytes for the CRC, 2 for the packet header, 6 for the MAC address and 5 for devices attributes. This leaves us with 16 bytes of pure data or 14 bytes to split between data and name if you want your project to have one.
I’m glad to see these super-cheap modules getting some attention, even more amazing they’re being re-purposed to run what I had thought was an entirely different protocol.
Curious: Does that mean these chips were based loosely on BT specifications or were an early iteration of it altogether? Or maybe someone just didn’t feel like paying BT royalties and rolled their own..
i think they just run on similar frequencies, modulation, channel width and data rate. its probibly just coincidence. then you just create a packet that looks close enough like the one that ble is supposed to receive, and ble doesnt know the difference for the most part.
ISM sets the frequency range, and most of the ISM radios similar if not identical modulation. But something with a small simple protocol that can move data from
a to b can be made much cheaper than something the need several 100K of code
to support the BT spec
Nordic Semiconductor was heavily involved in writing the BLE specification. I’d bet they just reused a lot of the work they’d done on developing their nRF24L chips.
Ah thank you, I had no idea they were involved in that, that’s a very good clue as to how these came to be IMHO since they already had some of the development done that direction.
This could also be a strategy for co-existence.
Since nRF24L01+ and BTLE use the same modulation scheme and frequencies, that means the nRF can unintentionally receive BTLE data; and so it must be capable of reliably distinguishing and ignoring that data.
That’s easier if it shares the same preamble, and partial header up to the address. It can properly sync to the beginning of each BTLE packet, examine the address, see it doesn’t match, and ignore the rest of the packet.
If for example the nRF used a different preamble, it would have no idea where BTLE packets start. As a result, it would often start trying to parse BTLE packets in the *middle*, based on finding its preamble anywhere in the packet. And although the probability is low that the following data successfully mimics a valid nRF packet, it’s a still needless source of error.
The nRF24L radios predate BLE. But swap the two in your argument and your logic holds. BLE used the same header as the nRF radios to help with coexistence.
It’s important to note that BLE is almost completely different from classic Bluetooth. It was previously known as Nokia Wibree, and then given slight tweaks to become BLE.
The Nordic radios aren’t speaking classic Bluetooth, they’re speaking almost-Wibree, which is almost-BLE, and it’s close enough to work.
so it’s one way only ?? still pretty impressive
[Dmitry], if you’re reading: What’s the non-Nordic hardware you were trying? I don’t need to communicate with Bluetooth. Just eliminating that 130uS PLL settling time would be helpful to me.
A7125: http://www.elecfreaks.com/wiki/index.php?title=2.4G_Wireless_easy_radio_A7125
Dear Dmitry,
were you able to investigate BLE on A7125?
best regards
Does anyone know what the operating range is, if you pair one of these with PCB antenna with a module that has PA+LNA and external antenna?
Outdoors with no obstructions, it can be hundreds of feet. Indoors is highly variable, but I can give a specific example with that hardware.
I performed a test where two modules were set up to try to exchange packets at 0.25 second intervals, and toggle a LED each time a complete bidirectional exchange occurred. Enhanced Shockburst (auto-retransmit) was disabled, because I didn’t want the hardware transparently hiding lost packets from me; and plain Shockburst (checksumming) was enabled, so that any corrupt packet would be rejected. Speed was set to 2Mbps (fastest but also least sensitive), and TX power set to max. Walls were wood and painted drywall. A significant number of obstacles that could block or reflect signals were present – steel utility shelving, filing cabinets, etc. The main module with the PA+LNA+external antenna was left stationary, and the other module with PCB antenna moved around. No special care was taken to place the stationary module in an optimal position, in fact, I’d say it was clearly suboptimal.
At a distance of about 15 feet, I found the first “null” – a location that, depending on exact position, communications were unreliable or impossible. Moving the module even an inch, or rotating it in place, resolved it. With increasing distance, the frequency and size of nulls also increased. But excluding these, there was not a complete loss of communications up to the maximum distance I tested, of about 50 feet; and at that distance there were still more usable locations than nulls.
I recorded the position of some of these nulls. Then, I moved the stationary module and retested. This resulted in essentially a completely different set of nulls, at different locations. Placing moving obstacles (humans) between modules would also produce different nulls, but I didn’t test this.
I’m sure after reading this you’ll see that communications cannot be quantified by range alone in an indoor environment!
My goal is to have 100% coverage in my home. Based on the results of this test, I concluded I should do the following; listed in order of decreasing priority, and ascending difficulty:
1) Optimize the main module location.
2) Have two main modules, some distance apart, for spatial diversity; switching between them each time there is a failure. If both RF modules are connected to the same MCU via SPI, there is a practical limit in the distance. But in my case, the MCU for the RF module merely acts as a bridge between that module and a computer. And since it’s connected to the computer via Ethernet, I can simply duplicate the existing bridge; then place them at any optimal locations, even opposite ends of the house if I so desire.
That should get me very close to 100%, with the final bit supplied by:
3) Allowing a very simple form of mesh communication, which will be used only when neither direct path to a main module works.
Most of the functional blocks for this are already done and tested in isolation. Almost time to tie them all together and see how it works. :)
Thanks for your reply. You describe exactly what I was interested in. Specifically: some sort of home automation. The situation is very real: there’s just little control of the central node and no control of how the others are placed.
Some years ago I have seen demonstrations with low power 2.4GHz from TI and Microchip. They both had some problems what worried me. Even if the modules were close(say 1-2m) you could still block communication by having a person between them or even a glass of water close to one of the modules.I wonder if a central module with better antenna and diversity will solve this problem.
Mesh is not an option when only the central node is not battery power, but antenna diversity with two modules seems like a great idea.
I have played a lot with some hope modules in the 868MHz band, never had problems like this. But the modules were higher power and the antenna was bigger.
You’re welcome. Antenna diversity and mesh are variations on a theme – routing around obstacles, and areas of destructive interference due to reflections. While I’m using both in a hybrid scheme, you don’t have to. The simple central nodes I’ve described are identical in both hardware and firmware, so if two aren’t quite sufficient, you could add a third. It’s also possible to set the central nodes to different channels for frequency diversity. If one channel suddenly becomes blocked by interference, the other will (hopefully) still function. Finally, if you don’t need the full 2Mbps speed, setting the nRF to a lower speed increases RX sensitivity; the datasheet claims 12dBm improvement at the lowest speed.
For better coverage of the house I just use more base stations. I use a module with the LNA + PA on the base station and just have one at each end of the house, for the other units I just use lower powered the PCB antenna version and have full coverage of the house.
It’s so…. small! kudos on the design there.
I think it would work better with a three-dimensional antenna. Maybe something that ends up looking like a air-core inductor… a little closer to isotropic, since the applications for these devices will often involve them oriented in multiple dimensions.
I’ve seen those before in cheap eBay OBDII adapters…
What would I need to make an NES controller using this?
Quick question.
Is it possible to send data from LE module to Android? (1 char)
I’d like to use this nRF21L01+ module as following:
* Phone finds module, connects to it (as if it was a BT device)
* Module sends commands to that phone (on button clicks)
* App on my phone receives these commands and does necessary operations.
Except the module will not know that there is a phone there. (unless you can sniff BLE traffic, but that isn’t covered here)
ARGH! These are unfree ideas in so many aspects. You can’t sell things that use this “research”. So if you want to use this you need to reimplement it yourself.
He could have used GPLv3 which at least allows commercial usage. But it’s his code, his decision. Here is the license,
“All the code as well as the research that went into this and is published here is under this license: you may use it in any way you please if and only if it is for non-commercial purposes, you must provide a link to this page as well. Any commercial use must be discussed with me.”
Or you can just do as he asks and discuss your commercial application with him.
That “license” may apply to the code, but once he published his “research” in the public, unless it’s patent protected (hint: it isn’t), then anyone may use it however they please. The BLE people may take offense to a commercial product using this concept, though….
seems like floe is able to receive(!) BTLE packets with this module!
can someone confirm this?
Best regards.
https://github.com/floe/BTLE
how to eliminate packet congestion in the nrf24l01 receiver?
Is any one knows that nRF24 has RSSI or not..
No, it does not have RSSI.
can we use RF and ble of nrf24lo1 both simultaneously