Frequency hopping experiments on the NRF24

[Phil_G]

Hi Max, dont worry about the display changing, thats normal and expected.
Do you have the 3v3 caps at the transmitter module power pins? and the 3v3 reg fed from switched battery?
It may be swamping - try shrouding the tx aerial with your hand, see if the rx led changes.
I'm convinced that 99% of NRF problems are due to power supply noise.
As an experiment you could try reducing the transmitter power output, again see if the rx led changes.

Code: Select all

radio.setPALevel(RF24_PA_MAX); delayMicroseconds(500); // RF24_PA_MIN, RF24_PA_LOW, RF24_PA_HIGH or RF24_PA_MAX

On the transmitters I've found its best to route the battery neg and switched pos wires first to the RF module regulator input, and then on to the Arduino, and to avoid taking the RF module neg 'through' a Nano - ie not to take battery neg to one Nano GND and use the other Nano GND to power the module. Caps of 100µF in parallel with a 100n, mounted across the 3v3 input pins of the NRF24 itself. The 3v3 regulator (for the tx RF module) I always power directly from switched battery, not from the Arduino 5v. All precautions to keep the supply noise down

I'm convinced its the transmitter power supply Max.
I cant over-emphasize how important a good, clean supply is - it simply doesnt work properly otherwise.
On a high power module a single 18650 doesnt give any overhead for the 3v3 regulator, the AMS1117 datasheet says "down to 1 volt dropout" so the input should be 4.3v minimum. On a receiver we get away with it because of the low current draw but the +PA transmitter module takes huge current pulses, which when already below dropout will be causing the 3v3 to momentarily collapse. Could you try it on 2S with the switched battery connections going first to the 3v3 reg input, and then on to the Nano Vin/Gnd?

Shielding the Tx aerial did not seem to make a difference, even unscrewing it did not until I put a wall in between, but then it went into failsafe mode.

Its not good to run these modules without an aerial Max, it can blow the PA.

[MaxZ]

Will do, but prob. tomorrow. Any comment on the measured (?) stable frame rate?

Edit:, I am guessing the "stable frame rate" is due to the Servotimer library included in the rx code, it will maintain that frame rate constant, but the PWM is not necessarily refreshed by a transmitted package from the tx, right?

[MaxZ]

Right, more experimenting, but less result. I replaced the battery with a 2s lipo, rerouted the wiring from the battery to the 3v3 regulator, and from there to the raw connection on the RF-Nano. If anything, the result is less. The led comes on permanently or in a very slow blink, and only when I cover the entire tx aerial with my hand it starts to flash again, but at about the same frequency as before, also not at 10 Hz as specified ( I can still count the flashes, and that would not be possible at 10 Hz for me).
Uncovering the aerial again and walking away with the rx does not change anything, even when I am outside my house.
I changed the capacitor combo on the regulator to one of the set Phil kindly provided, with a 370 uF C, but that did not make any difference.
I have yet to try the reduction of the RF level in the code, but that is a bit more involved.
I am leaving this weekend for a short holiday, so I may postpone that..

Cheers,
Max.

[MaxZ]

Phil, my code is a personalized version of your Enc_v5_nrf24_250k_5ms_fhss_tx, last revised by you on 27/5, downloaded by me on 5/6. Should I use that for the test you are proposing? IIRC the next version you published contained the WDT and fail safe from the tx.

Yes I did make some changes, but the only time consuming part could be the extra saving to eeprom of the trim values, but that only happens when I am releasing the trim button.

I must confess I discovered just now that I left some serial traffic in there I was using to test the code on my pc, could that be the culprit? I will delete it anyway and try again.

Cheers,
Max.

Edit: I removed the Serial stuff, no change

[MaxZ]

Next test. I took a virgin RF-Nano as Phil suggested, and uploaded Phil's code as described in my previous post, after I changed the radio config details and swapped the CE, CSN pins. The resulting flashing frequency is about 50 flashes in 12 seconds, so about 4 Hz. It is the same as when I use the tx and observe this on the receiver.

Cheers,
Max.

[MaxZ]

Try the latest code in both your rx and your test Rf-nano transmitter?

I tested that, no visible improvement. I also did a test with a new RF-Nano for the rx with only the led soldered in place, and I can see a marginal improvement. But as far as I can count the flashes with the naked eye the flash frequency is more like 5 Hz than 10Hz

I have to stop further testing for a while, I'm out for a week's (e)biking. I am staying in The Netherlands though, so I am at least familiar with the rules for social distancing

Cheers,
Max.

[MaxZ]

Hi guys, I am back in town. After a weeks holiday, and 3 busy days of preparing and selling our caravan, it is time to pick up my NRF24 experimenting.

First result: I swapped the high power HF unit for another one (looks exactly the same bar the screen printing), and the swamping problems are gone. The Rx behaves ok regardless of distance, from very close to two stories down in the living room. Also changing the 2s battery to a single cell (18650) does not make any difference, note that I did NOT change the adapter.

But still the "slow blink" on the rx led remains the same. I changed the rx code to toggle the led on/off every 100 frames instead of 10, to make it easier to count the flash periods (1 Hz). I did this on my rx version and tested it with my tx version. My version blinks at about 0.7 Hz.

The flashing is very regular, but of course it's averaged over 100 frames.

I have been attempting to work out what happens if for some reason the loop in the tx code is too slow, and the wait at the end for the syncing signal from the ISR is zero, but the way I interpret it is that the ISR will send out packages at a rate of 5 ms regardless, and the receiver will count those to set the flashing rate of the led, so I cannot see that as a valid cause to slow down the flash. The only result I can see is that the servo data will not be refreshed every 20ms all the time. Am I right? If so, what could then possibly be the cause?

Cheers,
Max.

[Shaun]

Hi Max,
I can't offer any tech advice but I've built 2 NRF sets now using Phil's exact setup as described and unmodified code so I know they work brilliantly. One Tx has had about 1 hrs flight time problem free. The other just bench tested but again no issues and just as reliable as my Spektrum DX18

Cheers

Shaun.

[MaxZ]

Hi Shaun,
I am not doubting that for one moment! But I would like to understand why things happen the way they do, so I am doing these experiments and asking all those questions.

As for making changes to the code, that is one of my main joys and interests in these arduino projects, to see if I can customize them to work in the way I would prefer it. Which is not saying that the original code is unsuitable in any way.

I should add that I connected a servo to my setup, and all is well, the difference in the frame repetition rate does not have any noticeable effect on it's functioning. Mind you, I am not using any super sensitive digital servos.....

Cheers,
Max.

[WernerL]

Have you ever noticed swamping Werner?

No, I have not seen any swamping on my systems.

My transmitters use the same nRF24+PA+LNA board, but my receivers are different. I use nRF24LE1 modules (LE1 has a built-in 8051 microcontroller), and nRF24 modules from CDEByte (external microcontroller). Maybe the swamping is an issue on the RFDuino?

Regarding sending the same packet twice: I believe this is just some left-over from a reference design where all this RC code was derived from. Maybe they had designed the original code for a diversity system; but then I do not have any idea how this could work.

It would be interesting to add logging to the system, so that we could analyse after a flight what actually happened. How many lost packets, etc. Then we could also try the 1 or 2 packet transmit, and if we have high resolution time stamps we could see if there is ever a situation where the 2nd packet was actually used.
If the 2nd packet is useless anyway, then removing it is a good idea as to not pollute the airwaves any more than necessary.

cheers, Werner