NRF24L01 Frequency Hopping synchronization

Using Arduino Programming Questions
#1

Hello everybody.

Im currently working on creating an FHSS code for NRF24L01 modules which have this function that you can change the channel. I have the following TX code:

#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>
#include <DHT.h>

#define DHTPIN 4       
#define DHTTYPE DHT22   

typedef struct {  
  float temperature;
  float humidity;
} PACKET;

typedef struct {  
  float temp;
  float hum;
} ACK_PACKET;

PACKET packet; 
ACK_PACKET ack_packet;

unsigned int flag = 0;
const byte addresses[][6] = {"00001", "00002"};
byte hoppingPattern[]={110, 100, 120, 108 , 99 , 89, 123 , 111 , 105}; 
byte ptrHopping = 0;

DHT dht(DHTPIN, DHTTYPE);
RF24 radio (7, 8);

void setup() {
  Serial.begin(9600);
  dht.begin();
  radio.begin();
  delay(100);
  radio.openReadingPipe(1, addresses[0]); //Reading From Pipe 00001
  radio.openWritingPipe(addresses[1]); // Writing To Pipe 00002
  radio.setPALevel(RF24_PA_MIN);
  radio.setDataRate(RF24_250KBPS);
  radio.setAutoAck(1);
  radio.enableAckPayload();
  radio.enableDynamicPayloads();
  radio.setChannel(hoppingPattern[ptrHopping]); //0-124
  delay(2000);  
}

void loop() {  

  packet.temperature= dht.readTemperature();
  packet.humidity = dht.readHumidity();

  radio.stopListening();
  radio.write( &packet, sizeof(packet));
  Serial.print("Data sent: ");
  Serial.print(packet.temperature);
  Serial.print(" , ");
  Serial.print(packet.humidity);
  Serial.print("On channel:");
  Serial.println(hoppingPattern[ptrHopping]);

  ptrHopping ++;
  if( ptrHopping > sizeof(hoppingPattern)-1){
    ptrHopping = 0;
  }

}

The problem that i have is that i dont know how can i synchronize the RX to “hop” on the same channel as the transmitter in the same time.

I found some code on github : GitHub - Max-62/nRF24L01-Frequency-Hopping-FHSS but i really dont understand what is going on…

#2

Why do you want to do that?
Especially as you seem to have no idea how that could be done.

NRF24L01+s are non-standard enough to protect against inexperienced attackers.

Channel hopping (particularly by using a fixed list) is not much better than not hopping,
but probably a whole lot more complex and failure prone.

#3

Its a school project , thats why i want tot do , and its more like a proof of concept.

#4

Then you should do your homework/project/whatever.

You will learn much less if somebody tells you how it can be done.

And even here (where people sometimes solve alien problems just for fun),
you will have a much better response if your code shows that you tried to solve the problem.
Adding an basically unused array does not count IMHO.

Good luck!

#5

I was just asking for sugestions.I tried using autoAck function from RF24 library to change the channel when the ack is recieved but i never receive an ack.

#6

The code you posted does not check whether the transmit was successful
and does not care about AutoAck data.

Good luck!

#7

OK. As has been pointed out, you should not get a ready made answer.
However, just to get you started:

  1. A transmitter gets an acknowledgment back when the receiver gets a packet. (standard behaviour)
  2. In the non-synchronised state, the transmitter and the receiver should agree on a hopping schedule.
  3. Once the hopping schedule expires, the transmitter must send another hopping schedule.
  4. if there is a failure, both parts revert to the non-synchronised state.

EDIT 1

Crossed with 2 previous posts.

EDIT 2

It is a pity that the exercise was not something even more useful like synchronising two battery powered NRF24L01 based parts parts, ensuring the receiver and transmitter periodically wake up more or less together, communicate, then sleep again. All that with minimum unused on time , and a recovery algorithm which designed to minimise power loss during resynchronisation.

#8

6v6gt:
4) if there is a failure, both parts revert to the non-synchronised state.

There needs to be a pre-arranged default channel that both sides can revert to when they fail to make contact.

There should also be a means to deal with the situation where either the Tx or the Rx goes offline without warning for whatever reason - for example a power failure or program crash.

A large supply of coffee for late night debugging sessions will also be useful.

...R

#9