RF-24G performance problems

Wireless & IoT
1

I built a pair of boards based on an Atmel ATtiny44 to drive some RF-24G’s that I purchased. I configured one board to transmit, and the other to receive, and plugged the receiving board into a computer via serial. I am running the radios in “shockburst” mode, with an 8-bit address, a 16-bit CRC, and a 6-byte payload. While I am getting packets across, there are a few problems:

  • I only receive packets if the transmitter is plugged into the bench power supply (not a battery). If I connect a ground line from the bench to a battery-powered board occasionally lets a packet or two through, but not reliably.

  • I’m only getting about 70% of packets anyway - and they come in predictable waves: I receive approximately 20 packets, then drop 10, then get 20.

  • The performance seems highly dependent on my body’s proximity to the transmitter. Sometimes, even when the transmitter is on the bench power supply, no packets will come through. But if I put my hands or arms near the transmitter, packets start flowing in.

Do you have any suggestions for how I might debug this problem? Have you experienced anything like it?

Thanks,

Charlie

2

Are you using C or asm? Are these the 24L01 or the 2401 modules? Are you using SPI or bit bang serial to communicate with the module?

Look at the code I posted in the projects forum. It might give you some ideas. I did this with two atmega 8515’s.

If you post your code and/or schematic someone may be able to help you, otherwise its a guessing game.

I have found that noise can be a problem with these modules. If you decrease the clock frequency it will help decrease the noise. Also, if you are using the internal clock of the tiny44 you will find that it is not as reliable as an external crystal or oscillator. This could be your problem.

Regards…

3

Thanks for the reply, newbie123.

Are you using C or asm? Are these the 24L01 or the 2401 modules? Are you using SPI or bit bang serial to communicate with the module?

I’m using ASM, have nRF2401’s, and am doing software bit-bang SPI. Here is a schematic, the code, and a picture of my boards:

http://yerk.org/tc1/tmp/nordic_debug/

I have found that noise can be a problem with these modules. If you decrease the clock frequency it will help decrease the noise. Also, if you are using the internal clock of the tiny44 you will find that it is not as reliable as an external crystal or oscillator. This could be your problem.

I am using the internal clock at 8MHz. I’ll try decreasing to 1MHz to see if this makes a difference.

Should the clock stability of the microcontroller matter, if all of the timing delays are above the timing limits imposed by the nRF2401? I mean, so long as the clock does not drift to a speed so fast that it exceeds the nRF2401’s timing limitations.

cheers,

Charlie

4

yourcelf:
Thanks for the reply, newbie123.

Are you using C or asm? Are these the 24L01 or the 2401 modules? Are you using SPI or bit bang serial to communicate with the module?

I’m using ASM, have nRF2401’s, and am doing software bit-bang SPI. Here is a schematic, the code, and a picture of my boards:

http://yerk.org/tc1/tmp/nordic_debug/

I have found that noise can be a problem with these modules. If you decrease the clock frequency it will help decrease the noise. Also, if you are using the internal clock of the tiny44 you will find that it is not as reliable as an external crystal or oscillator. This could be your problem.

I am using the internal clock at 8MHz. I’ll try decreasing to 1MHz to see if this makes a difference.

Should the clock stability of the microcontroller matter, if all of the timing delays are above the timing limits imposed by the nRF2401? I mean, so long as the clock does not drift to a speed so fast that it exceeds the nRF2401’s timing limitations.

cheers,

Charlie

You don’t appear to be using it, but your shockburst transmit delay would be too short. You need to include the preamble, address and crc bits in the calculation. It’s going to be more than 229uS… though you seem to have a 300mS delay at the moment!

Have you tried a different channel?

What kind of battery?

Orin.

5

you didn’t initialize the stack pointer!

this is the first thing that should be done at reset.

Reset:

          ldi    r16, HIGH(RAMEND)	;set up stack pointer HIGH
          out   SPH, r16              	       ; 
          ldi    r16, LOW(RAMEND)	;set up stack pointer LOW
          out   SPL, r16              	       ;

I don’t like using the internal clock.

I would try an external oscillator or crystal (no more than 4 MHz)

Of course you will have to recalculate the timing for all delays.

That is easily done with avrdelaycalc.exe. I always check the timing in avrstudio’s simulator, just to be 100% certain.

I briefly looked at the code, it seems to be ok.

here is another example using avr in asm:

http://www.serasidis.gr/circuits/TRW-24 … eivers.htm

Good Luck

6

you didn’t initialize the stack pointer!

Doh! Indeed. But alas, fixing this doesn’t fix the problem. I’ve updated the code here (I also removed the unused and confusingly named “shockburst_transmit_delay” - thanks for pointing it out, Orin): http://yerk.org/tc1/tmp/nordic_debug

I tried reducing the clockspeed to 1MHz (still using the internal clock) - this doesn’t seem to change anything. I don’t have any low-speed crystals to hook up at the moment - I’ll consider getting some (I usually only use crystals for speeds higher than 8MHz; I’ve never had a problem with the internal RC circuit before).

Have you tried a different channel?

Several. It doesn’t seem to make a difference either way. Interestingly, I don’t see a spike in the neighborhood of 2.4GHz on a spectrum analyzer when I run the transmitting board. Perhaps the short burst of transmission followed by long delays makes the signal too spotty for the analyzer to pick up. Or perhaps this is just a symptom of a bigger as yet unidentified problem. I might try writing some code for direct mode to see if I can get more solid evidence that the transmitter is actually putting out.

It would also be interesting to try testing the transceivers somewhere with less 2.4GHz interference (wifi, bluetooth, etc) than is present in the lab where I’m working.

What kind of battery?

9V (regulated to 3.3V). And unfortunately, it seems that the performance has deteriorated further since a few days ago (even using the old code). I’m only getting the occasional rare packet through now, regardless of power connections or hand positions.

Of course you will have to recalculate the timing for all delays.

That is easily done with avrdelaycalc.exe

Neat idea! But I don’t have a windows machine currently. So I wrote a little python script that calculates delay routines: http://yerk.org/tc1/tmp/nordic_debug/avr_delay.py

If nothing else comes out of the exercise, at least I’ll have that. Thanks for the suggestion, newbie123!