Frequency Hopping with Arduino uno R3 nRF24l01+

Hello,

First, thanks to this forum who helped me !

I work on a project with two arduino uno R3 and two nRF24l01+ modules. I would set Frequency Hopping for the communication scheme. I thought of something like this for the transmitter :

      radio.setChannel(5); set channel 5 for communicate
      radio.write(data); // send data on the channel 5
      delayMicroseconds(3772); // wait for 3772 microsecond
      radio.setChannel(36); // set channel 36 for communicate
      radio.write(data);
      delayMicroseconds(3772);
      radio.setChannel(30);
      radio.write(data);
      delayMicroseconds(3772);
      radio.setChannel(24);
      radio.write(data);
      delayMicroseconds(3772);
      radio.setChannel(18);
      radio.write(data);
      delayMicroseconds(3772);
      ...

I'm not working on the receiver for now. I am interested in any information or assistance. This is my first topic, i guess i didnt do a mistake.

Regards,

Hal

Hal As a basic idea, it could work, but it would be much nicer to create a sequencer that uses micros() to get its timing rather than delay...

I would consider using ONE byte of your 'data' payload to announce the channel number that will be coming up next

I initially had an idea based on this topic HERE which would use a set-up channel (80 for example) which would announce the sequence of the channels that will be used in the hop, in your example this would be 5,36,30,24,18, this way all receivers would know what channels to expect... but this totally relies on the receivers being able to hear this set-up channel. I originally thought just announce the set-up once, but it could be used more regularly as part of the timed hopping sequence

for example Set-up channel data Channel A data.. ... Channel F data.. Set-up channel data again...

I think with normal FHSS the channel DOES NOT change after every packet sent (as your example Hal) but instead the data is sent in its regular timed sequences, and either every XX packets or XX ms the channel will change

The big big problem is that the receivers must know what is coming up next, where it is in the sequence, not to change to late (if a packet or moment gets missed) or indeed changing too early and missing a packet(s)

If someone has got a great solution for this we would be grateful, especially if it is a solution that is easy to understand and is not out of depth of understanding of these nifty little jiggers !

Bob

mcnobby: I was would consider using ONE byte of your 'data' payload to announce the channel number that will be coming up next

I wonder if secure miltary systems broadcast the next channel? But I have no idea how they work. Perhaps it could be broadcast in code if the time to break the code would be longer than the time between frequency changes.

@ha147, what is the purpose of your frequency hopping?

...R

Hi, Did you GOOGLE...

nrf24l01 frequency hopping

Tom.... :)

Robin2: I wonder if secure miltary systems broadcast the next channel? But I have no idea how they work. Perhaps it could be broadcast in code if the time to break the code would be longer than the time between frequency changes.

@ha147, what is the purpose of your frequency hopping?

...R

I dont think we need to worry too much about security since the NRF24L01 use pipe addresses ;) From my limited knowledge, frequency hopping (FHSS) is used so that you are not continually transmitting on the same channel, if you are using the NRF24L01 LNA+PA versions set to high power mode and transmit on one channel you are in breach of FCC regulations (as far as I understand), there may be other reasons too (like sharing bandwidth)

mcnobby: I dont think we need to worry too much about security since the NRF24L01 use pipe addresses ;)

I am going to be a pedant and point out that they are not "pipe addresses". They are just "addresses". Pipes are a different concept to enable the receiving nRF24 to keep track of messages with different addresses - like sorting correspondence into different file pockets. Unfortunately some of the nRF24 tutorials use the name "pipe" for the variable that holds the address.

And my comment about security was semi-facetious. But there was a serious element to it. If the military do NOT transmit the next frequency (for security reasons) how do they arrange for the TX and RX always to be on the appropriate frequency.

...R

TomGeorge: Did you GOOGLE...

nrf24l01 frequency hopping

Prompted by you I did and I did not see anything useful. Have you found something?

...R

Older mil comms use a timing signal to sync all parties (AWACS still use this for Have Quick hopping comms) - But newer ones are available. These use GPS for accurate timing and pre-loaded 'keys' that contain the sequence (or an encrypted version of it). These keys are usually changed daily.

I messed with FHSS on NRF24 a couple of years ago and found that I could reliably maintain a good signal with 4 hops per second.

To do this I had a list of channels I wanted to use and a random sequece generator in the PRX, not the TRX.

The TRX was programmed to ping the RX every 250ms. The rx would then select the new channel from the list randomly, use a simple encryption to obfusacte the channel and then send result in the ack packet back to the PTX. This new channel would be used for data and to communicate the next hop channel.

This meant that I could use as many channels as I wanted (tested it with 30 in the list).

Any adversary would have to be able to decrypt the ack within a very short space of time before the info was useless. The sequence was not repeating and more difficult to predict and compromise.

This also has the advantage of acting as a heartbeat to confirm the PTX and PRX are up and running.

I am sure there are flaws in this approach and I never did try a fast rate of hopping, but for just getting data from my greenhouse to my bedroom, I considered this secure enough! :)

Thanks at all !

@mcnobby :

i understand your communication scheme, but in mine i dont want to broadcast the next channel. The receiver and the transmitter knows the sequence of hopping.

But thanks for the sequencer, i will study that !

:)

And for the pipes adresses, i think they are vulnerable by BF (brute-force) attacks after demodulation.

@Robin2

I would like to Frequency hopping with low cost chip, for the "knowledge" if you want. And to know if my approach was naive (basic? dumb?) and in this case if someone could help me.

@TomGeorge

Ha ! Here you are Captain Obvious!

@ skywatch

Thanks for the flaws !

So my approach is basic but it is a way (not the better) to explore ?

The receiver and the transmitter knows the sequence of hopping.

That is necessary, if you want communication to be relatively immune to channel noise.

Try it and let us know how it works.

While channel hopping, if the Tx and Rx get out of sync how can they ever re-establish communication?

...R

The RX sits on a frequency until it recognizes the transmitter's unique code, then the pre-programmed sequence of channels is followed from there.

In my original application HERE it was important to keep the data as continuous as possible, so losing a channel change would mean it might sit on the same channel waiting for data until the sequence came back round again

So Robin2's comment is quite an important one, and a nutty issue I have been trying to get my head around

My application (from link) was working in a non-ack UDP-style mode, so the transmitter was only ever transmitting and the receiver only ever receiving, to ensure there are no breaks in the data

With DMX (for lighting) it is important to keep the data flowing otherwise you would see jerkiness in dimming and fixture movement. I was using one transmitter and several receivers all listening on the same channel, hence I disabled acking since this would only complicate things and slow data flow down

Other users apps might be somewhat different and use bidirectional data or acking, or maybe even slower data than my throughput (512 bytes x 25Hz min) Bob

mcnobby: My application (from link) was working in a non-ack UDP-style mode, so the transmitter was only ever transmitting and the receiver only ever receiving, to ensure there are no breaks in the data

With DMX (for lighting) it is important to keep the data flowing otherwise you would see jerkiness in dimming and fixture movement. I was using one transmitter and several receivers all listening on the same channel, hence I disabled acking since this would only complicate things and slow data flow down

This may be slightly off-topic for this Thread but I don't understand why one would need frequency hopping for that type of application.

Using acknowledgement allows the nRF24 to re-try failed messages and it would probably be practical to send a separate message to each RX so that the ack process can be enabled for all of them.

...R

Robin2: This may be slightly off-topic for this Thread but I don't understand why one would need frequency hopping for that type of application.

Mainly because it is a continuous data transmission application, and I intentionally kept at the low power range to avoid doing the same at a higher power (which would contravene FCC regs, so I believe...) but you CAN do continuous data transmission at higher power levels if you frequency hop (so I believe...)

If it still interests you and if it's not too late, I would have created something that you will probably find interesting. https://github.com/Max-62/nRF24L01-Frequency-Hopping-FHSS

Regards