RF transmission problem with nRF52840 QFAA

RE: RF transmission problem with nRF52840 QFAA

Einar Thorsrud — Mon, 14 Oct 2024 13:29:10 GMT

Hi Gabriele,

I see you are getting feedback on your hardware design in the private ticket.

[quote user="GabrieleParoli"]I don't have any accessible microcontroller pins that I can connect to a UART-USB converter to control it from a terminal. Is there a way in the test code that uses BLE to utilize a single channel and thus a single frequency, or is frequency hopping between channels mandatory?[/quote]

Frequency hopping is mandatory in Bluetooth (thoug you don't have to advertise on all channels).

[quote user="GabrieleParoli"]From what I've read online, they suggested using masks in the 'ble_advertising_start' function to transmit only on one channel, but I tried that and didn’t notice any difference.[/quote]

I don't think that will help much. Even if you only advertice on a single channel the advertising packet is short in time and this is not appropriate for simple RF testing.

Regarding radio test without UART, you could use the radio test sample from the nRF Connect SDK and do the adjustments described in this post to control it via Segger RTT as long as you have a Segger debugger (which could be a DK using the debug out port).

Note that you can also use RTT logging in the nRF5 SDK, in order to understand more about what is happening in your application. The ble_app_hrs sample support it out of the box if you set NRF_LOG_BACKEND_RTT_ENABLED in sdk_config.h to 1 (you also need to make sure NRF_LOG_ENABLED is 1 in case you have set that to 0 before).

[quote user="GabrieleParoli"]Regarding the debug pin toggle inside the 'heart_rate_meas_timeout_handler' function, I tried changing the HEART_RATE_MEAS_INTERVAL several times, and each time I reprogrammed the microcontroller, I saw the toggle frequency of the pin change as well (I tried 500ms and 50ms). If necessary, I can run more tests next week.[/quote]

This would happen also if the device reset after the HEART_RATE_MEAS_INTERVAL elabsed once and then an error reset the board. That may not be the case, and probably it is not, but it is worth ruling out. Either with a LED toggling only at startup, or even better by getting logging up and running (you can use RTT as mentionned as you don't have access to pins for UART).

RE: RF transmission problem with nRF52840 QFAA

GabrieleParoli — Fri, 11 Oct 2024 20:29:09 GMT

Thank you very much, Einar, for the information. The problem with using the radio test example code is that on the board I need to test, I don't have any accessible microcontroller pins that I can connect to a UART-USB converter to control it from a terminal. Is there a way in the test code that uses BLE to utilize a single channel and thus a single frequency, or is frequency hopping between channels mandatory? From what I've read online, they suggested using masks in the 'ble_advertising_start' function to transmit only on one channel, but I tried that and didn’t notice any difference. Let me know if this option exists so that we can know exactly what to expect on the spectrum analyzer.

Regarding the debug pin toggle inside the 'heart_rate_meas_timeout_handler' function, I tried changing the HEART_RATE_MEAS_INTERVAL several times, and each time I reprogrammed the microcontroller, I saw the toggle frequency of the pin change as well (I tried 500ms and 50ms). If necessary, I can run more tests next week.

Let me know, and thanks again for your help!

Gabriele

RE: RF transmission problem with nRF52840 QFAA

Einar Thorsrud — Fri, 11 Oct 2024 15:33:58 GMT

Hi,

We will review your hardware files and reply back on that in the private ticked after the weekend, but I am also interested in basic debugging as there could be non-RF related issues here as well (for instance indicated by your measurement of DEC3, I would expect you see somethign there when the radio is active), and basic debugging may tell us things about that. Essentially verifying that the application runs without error.

[quote user="GabrieleParoli"]Regarding the possibility of generating a fixed carrier frequency, is that possible?[/quote]

Yes. You can use the radio test example for that. You only need to modify the UART pins to match your hardware (some pins you can access and hook up to a UART-USB bridge or similar), and then controll it via UART. This is the exampe that we normally recomend for basic radio testing.

[quote user="GabrieleParoli"]I added a pin toggle in the heart_rate_meas_timeout_handler function to see if the firmware runs correctly on the microprocessor.[/quote]

That is a good indication. However, can you also check with a debugger? If you have not checked, it coudl for instance be that the device is in a reset loop where the pin is toggeled before resetting (though in that case it would be unlikely that the frequency of the toggling would match the correct frequency which is 1 Hz here unless you have modified it (the HEART_RATE_MEAS_INTERVAL is 1000 ms). If you have problems debugging or observing logging, a simple way to check this is to also add pin toggling in the start of main that would toggle on every reset. If yo see the pin in heart_rate_meas_timeout_handler toggle continiously and the one in the start of main only once, that would indicate that the application is working (and that we need to focus on your hardware design).

[quote user="GabrieleParoli"]Do you know what the DEC3 pin is connected to? The internet mentions it is something related to RF, but it doesn’t specify what exactly. Also, what is DEC1 connected to?[/quote]

We have not documented this publicaly so I cannot share details.

RE: RF transmission problem with nRF52840 QFAA

GabrieleParoli — Fri, 11 Oct 2024 14:40:49 GMT

Ok, done!
Regarding the possibility of generating a fixed carrier frequency, is that possible?
I'm connecting the antenna connector directly to the spectrum analyzer, so no RF is being generated at all from the microcontroller.

Thanks!

RE: RF transmission problem with nRF52840 QFAA

ketiljo — Fri, 11 Oct 2024 14:32:41 GMT

Can you open a new private case, upload the schematic and gerber files and refer to this case please?

RE: RF transmission problem with nRF52840 QFAA

GabrieleParoli — Fri, 11 Oct 2024 13:51:36 GMT

As mentioned earlier, I am using the example code 'ble_app_hrs'. I added a pin toggle in the heart_rate_meas_timeout_handler function to see if the firmware runs correctly on the microprocessor. Once the code is loaded (no errors), we see the debug pin I just described continuing to toggle high and low, but the Bluetooth is not detected. Using a spectrum analyzer, we are not seeing any spikes around 2.4GHz, which we do see when using the evaluation board.

When looking at the microprocessor pins with an oscilloscope, we see that DEC3 behaves differently on our board, staying fixed at 3.3V, while on the evaluation board, it is around 3V with small spikes downwards at 5Hz (we use a dedicated DC/DC power supply on our board; it is possible that this is the reason?).

Do you know what the DEC3 pin is connected to? The internet mentions it is something related to RF, but it doesn’t specify what exactly. Also, what is DEC1 connected to?

Another thing I wanted to ask is if it is possible to generate a fixed carrier frequency, which would help make debugging easier.

Let me know, thanks!

RE: RF transmission problem with nRF52840 QFAA

Einar Thorsrud — Fri, 11 Oct 2024 13:32:48 GMT

Hi,

[quote user="GabrieleParoli"]On our board, the QFAA microprocessor is connected to an external LF clock of 32kHz[/quote]

I see. Then you can ignore my comment about configuring for using LFRC.

[quote user="GabrieleParoli"]In order to get BLE working, is it necessary to activate the external 32MHz clock using SEGGER Embedded?[/quote]

No, the BLE stack will automatically start the HFXO when it needs an accurate clock.

[quote user="GabrieleParoli"]Setting NRF_SDH_CLOCK_LF_SRC to 0 as suggested by the link you shared made the situation worse[/quote]

How did it make the situation worse? Can you elaborate? Also, can you explain about what you have found during debugging? Does the application start? If it does, does it run without issues, or do you see any errors?

RE: RF transmission problem with nRF52840 QFAA

GabrieleParoli — Fri, 11 Oct 2024 13:26:27 GMT

Hi, let me explain the situation better. On our board, the QFAA microprocessor is connected to an external LF clock of 32kHz and an external HF clock of 32MHz. In order to get BLE working, is it necessary to activate the external 32MHz clock using SEGGER Embedded? I’m attaching a photo of the settings I have in the sdh_config.h file, and they are the same ones that work on the evaluation board. Setting NRF_SDH_CLOCK_LF_SRC to 0 as suggested by the link you shared made the situation worse. If I want to select the external clocks, which lines of code should I change? Thanks!

// <h> Clock - SoftDevice clock configuration

//==========================================================
// <o> NRF_SDH_CLOCK_LF_SRC  - SoftDevice clock source.
 
// <0=> NRF_CLOCK_LF_SRC_RC 
// <1=> NRF_CLOCK_LF_SRC_XTAL 
// <2=> NRF_CLOCK_LF_SRC_SYNTH 

#ifndef NRF_SDH_CLOCK_LF_SRC
#define NRF_SDH_CLOCK_LF_SRC 1
#endif

// <o> NRF_SDH_CLOCK_LF_RC_CTIV - SoftDevice calibration timer interval. 
#ifndef NRF_SDH_CLOCK_LF_RC_CTIV
#define NRF_SDH_CLOCK_LF_RC_CTIV 0
#endif

// <o> NRF_SDH_CLOCK_LF_RC_TEMP_CTIV - SoftDevice calibration timer interval under constant temperature. 
// <i> How often (in number of calibration intervals) the RC oscillator shall be calibrated
// <i>  if the temperature has not changed.

#ifndef NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 0
#endif

// <o> NRF_SDH_CLOCK_LF_ACCURACY  - External clock accuracy used in the LL to compute timing.
 
// <0=> NRF_CLOCK_LF_ACCURACY_250_PPM 
// <1=> NRF_CLOCK_LF_ACCURACY_500_PPM 
// <2=> NRF_CLOCK_LF_ACCURACY_150_PPM 
// <3=> NRF_CLOCK_LF_ACCURACY_100_PPM 
// <4=> NRF_CLOCK_LF_ACCURACY_75_PPM 
// <5=> NRF_CLOCK_LF_ACCURACY_50_PPM 
// <6=> NRF_CLOCK_LF_ACCURACY_30_PPM 
// <7=> NRF_CLOCK_LF_ACCURACY_20_PPM 
// <8=> NRF_CLOCK_LF_ACCURACY_10_PPM 
// <9=> NRF_CLOCK_LF_ACCURACY_5_PPM 
// <10=> NRF_CLOCK_LF_ACCURACY_2_PPM 
// <11=> NRF_CLOCK_LF_ACCURACY_1_PPM 

#ifndef NRF_SDH_CLOCK_LF_ACCURACY
#define NRF_SDH_CLOCK_LF_ACCURACY 7
#endif

RE: RF transmission problem with nRF52840 QFAA

Einar Thorsrud — Fri, 11 Oct 2024 12:16:48 GMT

Hi,

[quote user=""]What could be causing this?[/quote]

Have you done any debuggging to see what happens on your devices? A typical reason for example projects not running out of the box on custom boards is that they enable the optional 32.768 kHz ocillator. That needs to be disabled as explained in this post if the the crystal is not used on the board.

[quote user=""]Is there anything I need to configure differently since I’m using a QFAA instead of a QIAA, or should Bluetooth communication work the same way?[/quote]

The package variant should not matter when it comes to this.