I bought a nRF24L01+ and I'm trying to have it read different channels. This is the code:
#include <SPI.h>
#include "nRF24L01.h"
#include "RF24.h"
#include "printf.h"
#define CE_PIN 333 /// Change it for your board
#define CSN_PIN 333 /// Change it for your board
RF24 radio(CE_PIN, CSN_PIN);
const char tohex[] = {'0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'};
uint64_t pipe = 0x00AA;
byte buff[32];
byte chan=1;
byte len = 32;
byte addr_len = 2;
void set_nrf(){
radio.setDataRate(RF24_250KBPS);
radio.setCRCLength(RF24_CRC_DISABLED);
radio.setAddressWidth(addr_len);
radio.setPayloadSize(len);
radio.setChannel(chan);
radio.openReadingPipe(1, pipe);
radio.startListening();
}
void setup() {
Serial.begin(57600);
printf_begin();
radio.begin();
set_nrf();
}
long t1 = 0;
long t2 = 0;
long tr = 0;
void loop() {
byte in;
if (Serial.available() >0) {
in = Serial.read();
if (in == 'w') {
chan+=1;
radio.setChannel(chan);
Serial.print("\nSet chan: ");
Serial.print(chan);
}
if (in == 's') {
chan-=1;
radio.setChannel(chan);
Serial.print("\nSet chan: ");
Serial.print(chan);
}
if (in == 'q') {
Serial.print("\n");
radio.printDetails();
}
}
while (radio.available()) {
t2 = t1;
t1 = micros();
tr+=1;
radio.read(&buff, sizeof(buff) );
Serial.print("\n");
Serial.print(tr);
Serial.print("\tms: ");
Serial.print(millis());
Serial.print("\tCh: ");
Serial.print(chan);
Serial.print("\tGet data: ");
for (byte i=0; i++; i>=sizeof(buff)){
Serial.print(tohex[(byte)buff[i]>>4]);
Serial.print(tohex[(byte)buff[i]&0x0f]);
}
}
}
The Serial monitor outputs the following stuff:
1769 ms: 9399 Ch: 1 Get data:
1770 ms: 9404 Ch: 1 Get data:
1771 ms: 9409 Ch: 1 Get data:
But there is no data.. Also, typing 'w' and 's' doesn't do anything.
Also, my CE pin is connected to 8, and my CSN to 7. But when I define the pins this way, the serial monitor doesn't output anything :S. (When using a random number, 333, it displays the stuff mentioned above.
If I DO define the right pins ( 7 and 8 ), the channel switching ('w' and 's' in serial monitor) DOES work, but the serial monitor stays blank (meaning radio.available is probably not 'true'). For some odd reason, when I pull out the VCC pin, it immediately starts outputting the blank data stuff again. So is there a short circuit or something?
What am I doing wrong? And why would radio be 'available' if it's not even properly connected?
The "channel" is the frequency the radio works at. Both radios need to use the same channel. I don't know if you need to restart listening (or sending) if you change the channel. You should read the Nordic datasheet.
@Robin2: I'm using the TMRh20 library. And I only have one nRF24, which I'm trying to use to scan all sorts of data on different channels.
@Whandall: Stupid mistake indeed, this seems to partly solve my problem. I'm getting a bunch of 0's at each channel now.
Also, I connected a 10uF capacitor from the 3,3 Vcc point to the GND. But this basically means that the capacitor is also connecting the 3.3V pin from the Arduino to the GND of the Arduino.. is this correct?
This didn't solve my problem.
For some reason when everything is connected, nothing happens in my serial monitor. It's as if there is a short circuit. Once I pull the RF module out, the 0's start appearing. I'm at a loss here.
HyperC:
I only have one nRF24, which I'm trying to use to scan all sorts of data on different channels.
Why not start by proving it works in the normal way with a pair of devices? Then you have a solid foundation from which to experiment.
I don't think nRF24s are "general purpose" 2.4GHz radios. AFAIK they are specifically designed to talk to each other and include all sorts of complex stuff to make that as reliable as possible in an environment where there can be a lot of competing radio signals.
Robin2:
I don't think nRF24s are "general purpose" 2.4GHz radios. AFAIK they are specifically designed to talk to each other and include all sorts of complex stuff to make that as reliable as possible in an environment where there can be a lot of competing radio signals.
Now, since I want to try the same thing with a slightly different drone (a FAZE 2.0), I need to know wether this is possible. I opened up the drone and found that there is a XN297 chip in there: http://www.datasheetspdf.com/PDF/XN297/963169/8
I don't know how they decided that the BK2423 is a 'clone' of the nRF24 chip, but despite the Chinese documentation, the XN297 really looks similar to the nRF24 as well :P. Any ideas on this?
So yeah, that's the project. Also, I think the problem with the nRF24 module is because I use a UNO (with pins output just 50mA.. while it needs about 250mA). So I'm getting an external power source to see if that helps!
I would suggest looking at the source of available().
A solid knowledge of the documented/standard features will be useful to explore and use sniffing applications,
so you should study the datasheet until you understand every note in it, you want to go beyond.
I understand, and I have gone through the documentation. But I'd also just like to learn on the go.
Apart from that, the documentation of the XN297 is in Chinese.
I've been hopping through all channels, but not one channel is receiving any data.
What is the function of the 'reading pipe' for the nRF24 module? Should it be in line with the sending device (the remote controller)?
Also, will there only be RF data in the air when there is a connection between 2 nodes? I guess when playing around with a remote controller there should constantly be RF data transmitted right?
Whandall:
You can sense RF data in the 2.4GHz range, the 32 byte limit of the packets makes it pretty useless as a general sniffer.
Why is that? Payload length shouldn't really matter at this point? And to see if it actually works, I just want it to catch SOME rf packets. Why doesn't it see anything?
If does show device info, but could it still be that it doesn't receive enough power?
While you can run something like a promiscuous mode by using a special 2 byte address and no checksum,
you will see only a small part (data) of a small part of packets (pramble and address).
I don't know the bit-wire-protocol of standard WiFi traffic, but I doubt you have a chance to grab any of those.
Ah great, the Poor Man's scanner seems to work and detect both wifi and the remote controller!
So you're saying the 32 byte address is not realistic? But then why did the guys at PHDays manage to see the RC using the same setup? http://blog.ptsecurity.com/2016/06/phd-vi-how-they-stole-our-drone.html
HyperC:
So you're saying the 32 byte address is not realistic?
I did not say something like that.
Whandall:
You can sense RF data in the 2.4GHz range, the 32 byte limit of the packets makes it pretty useless as a general sniffer.
You can see the drone packets because it is using a nNF clone (using 2-5 address bytes and less than 33 byte data).
If I were to do it, the first step would be to find out the used pipe address and channel via scanner and sniffer, then the packet format. Then I would try to understand the packet format.
I have some devices with Atmega 328s and Cypress2.4GHz transceivers. The guy who developed them uses them with Spektrum R/C equipment.
From studying the Cypress CYRF6936 and the Nordic nRF24L01+ datasheets my conclusion is that the two types are quite incompatible (presumably deliberately).
That leads me to expect that you will only be successful if your drone is using a transceiver that is compatible with the nRF24. And it seems to follow from that that it will work exactly as you expect an nRF24 to behave. You just need to figure out the addresses that are being used. And with 5byte values you may have your work cut out.
I am even more convinced that your first step should be to establish working communication between two Arduinos with an nRF24 each.
One thing you may want to watch for is the possibility that the drone's transceiver is compatible with the older nRF24L01. The nRF24L01+ datasheet has some advice about compatibility.
First of all, thanks for helping me out guys. Really appreciate it.
@Whandall: With the Poor man's sniffer I found that the transmitter is broadcasting on 'wlan' channels 12 and 13. This means the frequency has to be somewhere between 2.456 and 2.483. I'm surprised its bandwidth is this wide (or could it be all noise).
How do I choose/find out the 'pipe' address I should be using? I'm using 0x00AA right now, but it doesn't seem to pick up the controller. I couldn't find it in the data sheet.
@Robin2: The XN297 is indeed a clone on the nRF (https://sigrok.org/wiki/Protocol_decoder:Nrf24l01). What's the best procedure for finding out the address? Sadly I only have one Arduino to work with, so I can't try to make a connection between two. I agree that that would've been a good first step.
