3

I'm trying to figure out if there is an efficient way of figuring out a pipe address of an rf24 radio. In order for two radios to communicate, they have to be on the same channel and have the same read and write pipe addresses.

The only approach I can think of now is by using brute force, the easiest way to eliminate the number of searches is to know at least the radio channel--I think that's the easy part. In theory (I guess), I could set my "searching" radio to the correct channel, the set it to only "listen", and then try one address after another. But that's inefficient, since the address can be any 40-bit hex value. So there are 2^40 possible keys--I don't want to spend 2 weeks at a time trying to find "listen" address.

Is there a better way? Is there maybe a way to send a signal to a channel and get all pipe addresses available on that channel? Basically anything but my method.

Edit 1:

I wonder if there is a way to modify a scanner like this one: https://github.com/TMRh20/RF24/blob/master/examples/scanner/scanner.ino so that it captures all of the "visible" packets for a given channel, and then find out the address. According to nRF24L01(+) specifications "packet contains a preamble, address, packet control, payload and CRC field". This would narrow down the number of possible addresses to very few.

Robert
  • 41
  • 1
  • 1
  • 3

3 Answers3

4

Or you can do the following:

Although the device/node-address is specified as 5 bytes eq. 40bits, you can specify just the first byte. In this case, the remaining 4 bytes become part of the payload.

Then, you have to listen only to 256 keys (2^8) instead of 2^40.

data
  • 41
  • 2
0

Big caveat, I have never used an nRF24L01 and have only just now skimmed the datasheet, so what I'm saying might be nonsense.

It seems like you want to be able to use 'any' pipe address for your project but want to be able to 'commission' devices into your network simply. I see three areas you are trying to tackle at once:

  1. Pipe address resolution (and possibly choice)
  2. Channel choice
  3. Finding & joining a network.

Things I am going to assume:

  • Choosing the actual values for the pipe addresses is out of scope.

Recommendations

I recommend you:

  • Choose a special (or set of special) pipe addresses to be used to advertise the network information on (e.g. perhaps of the 0xCAFEF00D variety)
  • Regularly advertise (i.e. beacon) the information necessary to connect on a single channel in a read-only way. E.g. this would advertise the pipe address that the beaconing node is reading on.
  • Have your 'joining' nodes listen for this information to find out the address they should write to.
  • When a node joins, it should include the information necessary to write back to it. Perhaps also there should be another negotiation here where the beaconing & joining nodes negotiate a set of alternative pipe addresses to use.
  • Extend your implementation to utilise multiple channels (perhaps just for data or perhaps for both data and network management).

Multiple channels

It is wise to use multiple channels, mainly to avoid multipath interference. However, it usually comes with the tradeoff of having to perform your network management multiple times (i.e. that whole 'search for a network, negotiate a connection etc' process from above). I would recommend getting something working on one channel first, but keep the multiple channel problems in mind. Once you are starting on the multiple channel features it would be wise to once again have a subset of channels (or just one) for network management to simplify the searching process.

Doddie
  • 1,393
  • 13
  • 21
  • I believe I didn't now how to properly articulate my question. What I'm trying to build was a packet sniffer. All I need is just the pipe address of any 2.4ghz transceiver. So, far I was able to use Node.js to build a channel scanner, so I can find all used channels in close proximity. But apparently this is as far as I can take nRF24L01. I posted a possible answer below. Thank you for trying! – Robert Jul 09 '16 at 18:24
0

I think I figured out my answer.

  • In order to view all addresses in the channel from different sources, I have receive all available packets, since (as mentioned in edit to my question), payload packets contain pipe addresses. In order to do that a receiver has to be put into a “promiscuous mode”. The problem is that nRF24L01 does not support that.

  • There is a way to have a "error prone" packet sniffing with nRF24L01 explained here: http://yveaux.blogspot.nl/2014/07/nrf24l01-sniffer-part-1.html

  • A receiver (or a transceiver in this case) that supports “promiscuous mode” and therefore allows for packet sniffing is esp8266 http://wp.dejvino.com/2015/02/how-to-use-an-esp8266-a-jumpstart-tutorial/

Robert
  • 41
  • 1
  • 1
  • 3
  • Mostly good, but the mention of the ESP8266 is a bit misleading - it won't receive the kinds of transmissions at issue here, but rather only much wider band wifi ones. – Chris Stratton Oct 02 '17 at 17:39