NRF24L01 registers working but still no communication

Wireless & IoT
1

Hello,

We are able to set(write) and read out registers of the nordic with our SPI configuration. (checked it with logic analyser and RS232 terminal).

But there’s still no communication between the NRF24L01 modules.

These are the values we set in the configuration registers :

we have 1 module for transmitting and 1 module for receiving(1 direction for the moment)

Registers for the transmitter:

Naam			Hex
CONFIG			0x08
EN_AA			0x3F
EN_RXADDR		0x3F
SETUP_AW			0x03
SETUP_RETR		0x00
RF_CH			0x08
RF_SETUP			0x07
STATUS			0x70
TX_ADDR			0xBBBBBBBBBB
RX_ADDR_PO		0xBBBBBBBBBB
DYNPD			0x00
FEATURE			0x00
CONFIG			0x0A

Register for the Receiver :

Name			Hex
CONFIG			0x09
EN_AA			0x3F
EN_RXADDR			0x3F
SETUP_AW			0x03
SETUP_RETR			0x00
RF_CH			0x08
RF_SETUP			0x06
STATUS			0x70
RX_ADDR_PO		0xBBBBBBBBBB
TX_ADDR			0xBBBBBBBBBB
RX_PW_PO		0x02
DYNPD			0x00
FEATURE			0x00
CONFIG			0x0B

After we wrote these values we read out the values and compared them with the values we wrote earlier, and they were equal.

After booting up we also set CE high of the receiver.

For the transmitter we followed this sequence for sending data.

-Clear Status register (clear interrupts write ‘1’)

-Flush TX

-Write 2 byte data to W_TX_PAYLOAD

-Pulse CE high for more then 10µSec.

There is still no communication (we dont get an interrupt at the receivers end)

btw: we checked our antenna with a spectrum analyser and we clearly saw the carrier.

Can anyone help us?

Thanks in advance

2

Did you design yourself the module ? Because it’s hard to obtain a great impedance match.

In this case, did you test test the receiver with analyser spectrum to check if you have a carrier at the same frequency ?

3

Are you getting the TX_DS interrupt when you transmit a packet from the TX unit? If not, you have no shot at communication. That’s the first thing to test once you are sure you can communicate to the 24L01 over SPI. Initially, this should be done with all of the Enhanced Shockburst functions turned off so you’re not relying on auto-ack/auto-retransmit.

4

Yes, if we send a package we got an interrupt at Transmit side and if we read out the STATUS register we see that TX_DS = 1.

RX_DS = 0 and MAX_RT = 0.

This test was without AUTO_ACK.

We also did a test with the AUTO_ACK ON.

We also got an INT from IRQ but if i read out the status the MAX_RT = 1.

TX_DS = 0 and RX_DS = 0.

So there is no communication between the nRF24L01 modules.

We used the register values like in my previous post.

5

The one obvious mistake I see is that the PWR_UP bit in the CONFIG register (bit 1 of register 0) is not set. I’m surprised you even got the TX_DS interrupt with this bit cleared.

6

at the end we set the POWER UP

For transmitter is this A = 1010 where POWER UP = 1

For Receiver is this B = 1011 Where POWER UP = 1

7

Did you configure the RX_PW_P* register for the pipe you’re receiving on (it looks like you’re using pipe 0, so it would be RX_PW_P0, register 0x11)? If you don’t, its default width is 0, which means that the pipe is disabled for receiving. The value of this register must match exactly the number of bytes you send in the payload from the TX (unless you have dynamic payload length enabled).

8

at receiver side :

RX_PW_P0 I place in the register 0x02 = 2 bytes

The Hex values are the values that i put in the register next to it.

The Hex values aren’t the address of the register.

so dynamic payload packet length wont be enabled then i think.

9

Megazoom:
The Hex values are the values that i put in the register next to it.

The Hex values aren’t the address of the register.

I understand that. I didn't see a value for that register in your table when I wrote my last post.

Have you tried switching the two units to check to see if they both at least have the capacity to transmit (and verified that on the spectrum analyzer)? If they both can transmit at relatively equal levels as measured by your analyzer, then the problem is almost certainly not hardware (unless the RF receiver circuitry is burned out on one or both of your modules).

10

Euhm we tested with the spectrum analayser and we have one problem

if we place module 1 on channel 8 to send we send on 2.412GHz

if we place module 2 on channel 8 to send we send on 2.403Ghz

Can that be a problem?

or is the channel not important for receiving signals?

11

Those measurements would indicate that the separation is around 9 MHz, which would possibly explain why your devices aren’t working. You could always try changing the RF channel on the TX unit until you can get the other to receive packets.

12

we tried that but with no success. maybe i give it tomorrow another shot.

what do you think of the configuration? is that correct at both sides? or?

Thx for the replies you gave already.

13

The only thing I’m not sure about is where you said,

Megazoom:
at the end we set the POWER UP

For transmitter is this A = 1010 where POWER UP = 1

For Receiver is this B = 1011 Where POWER UP = 1

You do have to make sure you leave at least 1.5 ms from the time you set this bit until you try to send or receive anything. There is also a delay of 120 us required from when you bring CE high at the receiver.

My other suggestion is to just try using as many default settings as possible to rule out writing registers incorrectly.

14

Ok thanks for the tips.

I test them tomorrow and i report back on the forum.

I hope the problem is solved :!:

15

We tried to switch channel at transmitter side continously so there must be a packet that gets through, and get caught by the receiver.We also poll the Carry Detect continously at receiver side and somethimes we have a CD = 1.This happens also when we are not sending with the transmitter so it seems we have interference from another device. Right?

We also tried communication with as much default values in the registers of the Nordic as possible. Still no luck…

Does anyone have anymore tips or suggestions to try?

16

You should be able to look through the RF spectrum on your analyzer and find a frequency range that is pretty quiet. Try sending receiving on that channel (hopefully you won’t see CD set when you’re not transmitting).

Other than that, I don’t have much more to offer. I know that my include library for the 24L01 works, as do my tutorials. You could try porting my code to your particular architecture and see if it works for you. It’s available on my website.

17

I’ve got some simple PIC18F test code you could try:

http://www.leonheller.com/MiRF%20V2/MiR … F4520).zip

Leon

18

Ok it works we have communication thx for all info and help you gave us.

this topic can be closed.

19

What did the issue end up being, if you don’t mind me asking?

20

when nRF24L01 power up, if you only want to try send/receive, just do this:

In PRX side:

Set RX_PW_P0(RX Payload width) =>WriteReg(W_REGISTER|RX_PW_P0,RX_LEN)

=>WriteReg(0x20|0x11,5)

Set to PRX & Power Up:

=>WriteReg(W_REGISTER|CONFIG,ENCRC|CRC2BYTES|PWR_UP|PRX)

=>WriteReg(0x20|0x00,0x0F)

RF_CE_SetHi

In PTX side:

Set to PTX and Power Up:

=>WriteReg(0x20|0x00,0x0E)

Send data:WriteReg(0xA0,“ABCDE”)

length should be equal to RX_PW_P0 in PRX side