nRF52832: Switching frequency leads to unpredicted behaviour

RE: nRF52832: Switching frequency leads to unpredicted behaviour

Turbo J — Fri, 23 Mar 2018 09:05:40 GMT

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.

RE: nRF52832: Switching frequency leads to unpredicted behaviour

run_ar — Fri, 23 Mar 2018 08:25:40 GMT

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

RE: nRF52832: Switching frequency leads to unpredicted behaviour

Lukas Krupp — Wed, 21 Mar 2018 09:07:31 GMT

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.

RE: nRF52832: Switching frequency leads to unpredicted behaviour

run_ar — Wed, 21 Mar 2018 07:44:28 GMT

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.

RE: nRF52832: Switching frequency leads to unpredicted behaviour

Lukas Krupp — Tue, 20 Mar 2018 13:27:30 GMT

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.

RE: nRF52832: Switching frequency leads to unpredicted behaviour

run_ar — Tue, 20 Mar 2018 13:02:34 GMT

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

RE: nRF52832: Switching frequency leads to unpredicted behaviour

Lukas Krupp — Tue, 20 Mar 2018 12:05:07 GMT

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.

RE: nRF52832: Switching frequency leads to unpredicted behaviour

run_ar — Mon, 19 Mar 2018 13:58:46 GMT

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?