nRF52832: Switching frequency leads to unpredicted behaviour

[Lukas Krupp]

Hello everyone,

I experienced some weird behaviour with nRF52832 on the nRF52 DK when transmitting packets on different frequencies. If I switch e.g. between frequency channel 72 (2.472 GHz) and channel 5 (2.405 GHz) and let another nRF52832 listen on channel 69 (2.469 GHz) it seems to receive a packet although there should not be anything on this channel. Does anyone have an idea why this happens? 

Thank you in advance.

Best regards,

Lukas

[run_ar]

Adjacent channels are not completely blocked by the receiver. Depending on which frequencies the de-modulator operates on you could receive a signal that is sent on another channel than the one your receiver is dialed to, which is what seems to be happening in this case.

Update: Can you confirm how you receive the packet? Are you measuring the RSSI? Do you get an address match? is the CRC ok?

[Lukas Krupp]

Thank you for your answer.

The packet reception is basically realized like in the ESB protocol. Even the address is the same.

I receive an address match and the CRC is right too.

But: I just noticed, that the corresponding RSSI values of the wrong receptions clearly differ from those on the right frequencies. I can use this knowledge to sort the wrong packets out.

[run_ar]

Did you try to transmitt on only channel 72 or only channel 5? Did you still receives a packet on channel 69?

[Lukas Krupp]

Yes, I tried transmitting on only one of the two channels. Nothing was received on channel 69. So it must be the switching which causes this issue.

[run_ar]

Thanks, can you confirm which channel you tried this with? Only 5, Only 72 or both? I have to admit it sounds like this is an issue with your Software, I have not heard of any issues like this with HW so that would be quite surprising.

[Lukas Krupp]

The sender hops through a hopping table with 73 unique entries with hopping distances of  about 30 to 40 channels per hop and I switch the channel approximately 570 times per second. The behaviour will be the same on almost every channel when tuning the receiver to the corresponding frequency and letting it wait until the sender transmits on this specific channel. I will receive the right packets but with an extremely reduced RSSI value on random frequency switches like in the case of channel 69.

EDIT 1: I also tried to reproduce the issue with the ESB protocol examples of the current SDK. It remains the same. I added the following hopping table as a global array in nrf_esb.c:

ht_01[] = {69,34,78,43,11,52,20,61,29,73,38,6,47,15,56,24,65,33,77,42,10,51,
19,60,28,72,37,5,46,14,55,23,64, 32,76,41,9,50,18,59,27,71,36,4,45,13,54,22,
63,31,75,40,8,49,17,58,26,70,35,3,44,12,53,21,62,30,74,39,7,48,16,57,25} 

Then I added the global variable 

uint32_t freq_counter = 0;

 to nrf_esb.c and changed the following in function start_tx_transaction():

NRF_RADIO->FREQUENCY = ht_01[freq_counter];
freq_counter++;
freq_counter %= 72;

to hop through the table.

Then I changed the frequency of the receiver in function nrf_esb_start_rx() to

NRF_RADIO->FREQUENCY = 69;

and replaced channel 69 in the hopping table by another channel. After starting the TX and RX example I was able to see the LEDs on the receiving board blink although no packets were transmitted on channel 69. The CRC is also right and if you watch the m_rx_packet_buffer you can see that a valid payload is in there after the reception. 

EDIT 2: I think the solution to the problem is the distance between the boards. My receiver and transmitter are directly facing each other with a distance of only 2 cm. If I put them further apart (app. 50cm) from each other the receiver operates as it should.