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

[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.

[run_ar]

Thank you for the detailed feedback. I have registered this internally.

[Turbo J]

Expected behaviour: A filter -even a digital one- will only attenuate the signal, and the factor depends on how "far" the frequencies are off each other. That means a very strong signal will be "visible" (above noise floor) even when a few channels apart.