nRF51822 carrier-only test mode

[florentb]

I am testing the DTM mode on the nRF51822_QFAA, and I use the carrier-only test with the following command :

dtm_init();    
dtm_cmd(LE_TRANSMITTER_TEST, 39, CARRIER_TEST, DTM_PKT_VENDORSPECIFIC);
while(1);

The result, with a spectrum analyzer (radiated test), looks like this:

While this seems within spec, is it normal to have the two additionnal peaks, 165kHz apart from the carrier?

Or is it caused by a PCB / design issue?

I am sure these are not coming from my spectrum analyzer, as I reproduced it with several analyzers and also with several nRF devices with different antennas.

[bjorn-spockeli]

I assume this is a custom board? No, you're not supposed to see two additional peaks 165kHz from the center frequency. I am pretty sure that this is noise that is modulated onto the carrier. How are you powering the board? It could be noise from the boards power supply, I suggest using a battery or an external power supply and then redo the measurement

[florentb]

Yes, I tested it on several custom boards. It's not the power supply (same results with a battery + LDO).

What I found out is that CPU activity has a strong influence on the spectral purity of the carrier. Depending on the instructions that you execute after entering test-mode, you will get different results - from a clean carrier (sleep mode), to a heavily modulated carrier (if you execute various code). Sometimes you will get only few peaks (as previously).

Using code in SDK10\examples\dtm\direct_test_mode\main.c, the results are very bad, as you execute a lot of various code after entering constant-carrier mode. Can you try reproduce that on a Nordic dev board?

[florentb]

Also, check devzone.nordicsemi.com/.../ where other people had the same issue. It is clearly related to CPU activity..

Now that might not be an issue for the certification, but the Nordic-provided DTM code should definitely use sleep-mode when performing constant-carrier tests.

[bjorn-spockeli]

I have discussed this with one of our RF engineers: Its not the CPU activity itself, but the fact that the application resides in flash and is read by the CPU. The Flash and the Radio uses the same power supply, so if there is a lot flash activity this will cause noise which in turn gets modulated onto the carrier. This looks pretty bad when you set the chip to transmit with a constant carrier and measure it with a spectral analyzer with peak-hold over time, but will have very little impact during normal operation(i.e. with a modulated carrier), since these peaks will drown in the modulated carrier.

Thus, this is not an issue with certification, but I will convey the feedback to the SKD team.