While faking BLE advertising beacons using an nRF24L01+ module is nothing new, it’s become a heck of a lot easier now that [Pranav Gulati] has written some library code and a few examples for it.
[Pranav]’s work is based on [Dmitry Grinberg]’s epic bit-banging BLE research that we featured way back in 2013. And while the advertisement channel in BLE is limited in the amount of data it can send, a $1 nRF24 module and a power-thrifty microcontroller would be great for a battery-powered device that needs to send small amount of data infrequently for a really long time.
We’re not 100% sure where [Pranav] is going to take this project. Honestly, the library looks like it’s ready to use right now. If you’ve been holding off on making your own BLE-enabled flock of birds, or even if you just want to mess around with the protocol, your life has gotten a lot easier.
I have played with the mbed implementation of this. I cannot say i have found a good application for it. Sure, you can make some sensors and and get the data directly on the phone if you write an app. But there is a significant delay and you are very limited to what you can send.
At the same time you could add another “beacon” that listens to the data and spits it to an openwrt router that can post it on the net. (or ESP or whatever you want). So for n+1 cost you get access to the data from anywhere and using one of the free services allows you to skip the whole app/webpage making.
Neat idea, so there is a mesh of nRF24L01+ connected sensor nodes and one node is a gateway via the ESP, or is it more of a fan configuration with all of the sensor nodes being monitored by the one gateway?
Like this, https://hackaday.io/project/2492-micromesh-iot-mesh-network ?
But what is the difference, the advantage?
I haven’t done both things at the same time. I did make some NRF sensor nodes continuing development from this http://www.electrobob.com/stockie/ where the network topology is a star (not mesh). With a PA/LNA central node you get quire some range. I was thinking that the nodes can be beacons(picked up by smartphone directly) and at the same time the star center can pick up the data and upload it somewhere. So you get both the independent beacons and the upload to internet thing.
In the meantime i gave up the NRF (bad quality) and moved to RFM75(equivalent)+XMEGA32E5 which works much better. I have made some modules similar to yours (not published yet). I am pretty sure i will give up the 2.4GHz low power and move to something like the RFM69 because the 2.4Ghz band works ok 99% of the time. The 1% when it does not work will frustrate me a lot.
* the project in your link is not your I guess.
Nice. I’ve done a very similar board (though has space for ESP8266 or NRF24L01 and ATtiny rather than ATMega), but haven’t had the time to do any software. And there’s also now a conflict of interest with my day job… :(
the mesh network sort of application is interesting, and is worth exploring. We could look at atleast single hop networks with a gateway and that too with the BLE advertising beacons, so at any point a person could get significant amount of sensor data relayed to him on his phone.
i’m excited about these ideas (hoping to find collaborators)
-An awesome library that can have all its books tagged with really low range and therefore low power beacons with book identifying information. Now a user can open his smartphone and enter a book name and get directed to the live location of the book.(i havent mentioned the exact framework though ;-) ) this should be good since i can never find the book i need in a library *sigh* just because they are not sorted and kept in the correct shelf
-custom home sensor network and its data collection directly on the phone
I highly doubt the library idea would work. There are too many books in too small space.
Normally BLE isimited to a few simultaneous nodes, not many
i kinda agree with you, CSMA/CA ,though is used to prevent just that.Also BLE advertising on the other hand is ACKless and its a send and forget thing for the radio if each node makes sure that it is sensing the carrier before transmitting collisions can be avoided. nRF24 has only a carrier sense feature, its yet to be tested as to how effective it is.
Also making it really low range and low power will enable the books to only transmit their information to the nearest wired node, meaning possibly at every shelf meaning approximately 100 books per wired node or possibly 100 nodes per wi-fi enabled node ( yayy!! ESP8266 :-p )
since the transmit time for each beacon packet is roughly (130us~200us) a CSMA/CA might just work.
i wouldnt just simply shoot it down,but well i wouldn’t try it anytime soon myself …LOL
When you put it that way, sounds simpler to get a librarian and guard with a tazer and make sure that the books get put in place. Bogdan http://www.electrobob.com
I am leaning towards a star connection and a gateway. This way the individual sensors only need to power up to collect data and not waste power doing anything else. It is easier to located the gateway(s) at a power outlet and have it stay up and a a beacon/web server etc.
agreed , a home sensor network will indeed be awesome, plus this way you can actually see the sensor data on the phone so it’s a plus
Not trying to be a grinch here, but in what way is this different from my own Arduino BTLE library for the nRF24L01+ from two years ago? Which is even part of the official Arduino library repo? See: https://github.com/floe/BTLE
i couldnt find your repo until now,good work!! check out the examples in the repo
(github.com/pranavgulati/RF24BLE) and tell me if you find it more useful and with additional features and flexibility for the programmer to control the packet.
i hope you like it :-)
Great! and it is GPL!
1) Can this receive without transmitting? Is passive listening of BLE possible with these modules? (to save power)
2) Can this transmit without receiving? Sort of broadcast?
Yes, send and receive are independent from each other. Of course, they don’t work simultaneously.
Thanks for your quick reply.
Just to be clear, I was not talking about the library, software or the chip communication being limited to half-duplex.
My question is really about the radio interface being able to passively listen without ever turning on the transmitter radio side.
The transmitter has probably the highest power drain and if we are only interested in receiving periodic broadcasts (from an outdoor temperature sensor), there is no reason for the receiver to acknowledge or otherwise send any packet, and thus could remain off, hence passively listening, like if it was FM.
Is that what you meant with your reply?
By the way, if passively listening, I guess the module would pick up noise from any sourrounding BLE devices, like a nearby smartphone with Bluetooth on, can you confirm that?
Check the data sheet of the radio, RX is a bit higher power than TX… At least for the original chip.
In BLE terms, “passive listening” is called scanning. It should pick up any BLE advertisements in the area.
Thanks, and “scanning” is like sniffing?
I would say this product, https://www.adafruit.com/products/2269 , since it is designed for sniffing, does not turn on the transmitter at any time, right?
Yes the module can receive without transmitting, that is no ack is required.
Similarly the transmitter works independently without having to receive first.(though a carrier sense is possible)
The module will pick up any advertisement made on the BLE channel but the library/software will reject a packet if it isnt a 32byte packet since a 32 byte packet has 3 byte crc which will be absent if a longer packet is sent.
Therefore in effect the receiver will receive only those packets that are either created by the library,or are specifically sent for this device (since normal phones/BLE devices dont generally transmit 32 byte packets until programmed to do so )
As advertising packets are variable payload, it’d be better to allow packets that are _less_ than 32 bytes long. I’ve not looked at the library code, but I hope it filters on access address to avoid receiving non-advertising packets.
I agree with Alphatek, it should be left to the user to decide if filtering is needed or not, that way it the module could be turned into a sniffer, like these ones https://www.adafruit.com/products/2269
yes the packets can be much less than 32 bytes,it’s just that the last 3 bytes need to be the CRC as per the ble standard and that’s about it (32 bytes is the maximum limit,including the CRC) sorry for the confusion
the filtering is done essentially on whether a packet is valid or not (via CRC). The library by default listens on a pre-specified advertising address and pre-specified BLE channels ( specified by the BLE standard documentation) and hence automatically filters packets not intended for advertisements.
now a pro-user could actually go inside the library and change the listening address but it is not exposed for the common user due to the library being a ‘BLE beacon receiver/transmitter’ and changing that address will make the chip to not listen to BLE advertisements.
>Therefore in effect the receiver will receive only those packets that are either created by the library,or are specifically sent for this device (since normal phones/BLE devices dont generally transmit 32 byte packets until programmed to do so )
That is good to know, so I would not get noise from them.
As a side note, is there a way to passively determine the presence of a nearby Bluetooth device? (passively as in: without interacting with it in any way, no transmission, just listening/sniffing).
What about WiFi?
Most of these those devices come with proprietary (closed source) firmware so it is not easy to analyse if there are ways to do that. Even if the protocol forbids it (for example, bypass carrier sensing), there may be good use cases to do it anyway. Like pushing raw audio data (streaming) directly over a radio interface (like WiFi), and have another device receive the raw data, without Ethernet nor IP stacks, just a digital radio link.
yes BLE devices are supposed to advertise their service descriptors and other flags when turned on and they use the same address for advertising, so in theory ,yes it is possible to ‘passively’ determine presence of nearby BLE devices.
Even if the protocol forbids it (for example, bypass carrier sensing), there may be good use cases to do it anyway. Like pushing raw audio data (streaming) directly over a radio interface (like WiFi), and have another device receive the raw data, without Ethernet nor IP stacks, just a digital radio link.
didnt understand the use of wifi or the BLE device in question.
an answer to the best of my understanding and context….
But yes if the smartphone OS provides an API to send custom BLE advertising packets ( most likely true for iOS ) then yes you could send raw data with appropriate buffers at the receiving end (audio playback will be awesome!!)