Spectrum measurements with DTM firmware

RE: Spectrum measurements with DTM firmware

Asbjørn — Thu, 26 Feb 2015 12:24:40 GMT

Glad it worked out. Thanks for the update.

RE: Spectrum measurements with DTM firmware

Samuele Forconi — Wed, 25 Feb 2015 15:10:18 GMT

Hi, we have performed the same tests with another spectrum analyzer and it turns out that the spur that we were observing was introduced by spectrum analyzer! We have used a better spectrum analyzer and with this one the spur is not present anymore... maybe it was due to a problem with the previous spectrum analyzer that we were using.

Thanks anyway for your support.

RE: Spectrum measurements with DTM firmware

Asbjørn — Tue, 24 Feb 2015 11:48:13 GMT

The DTM test that you are running is just fine and the radio_test is also what we are using. Regarding the zoomed in picture. I mean, are you able to set the span of the measurement equipment to 50 MHz and set the center of the span just over where the spur is? This will help identify where in frequency it accurately is and what the level is. With 1 GHz span it's inaccurate with regard to frequency and also, it could easily be affected by the noise floor. There shouldn't be a spur there from our radio in TX mode, not should there be a spur there if you are in receive mode on channel 2. It could be that the code puts the radio into receive mode on channel 77-78, then you could see such a spur, but not with a 30 dB attenuator. The receiver local oscillator on this board is -56 dBm to -57 dBm, but you need a short span to make the measurement accurate.

RE: Spectrum measurements with DTM firmware

Samuele Forconi — Mon, 23 Feb 2015 14:03:33 GMT

Hi, as I have written in my previous posts, we are actually using the nRFGo PCA10005 board (SMA connector), directly connected with the Aaronia HF-60105 spectrum analyzer.

We have tried 2 different firmware:

a slightly modified version of the DTM firmware (modified to perform only the TRANSMITTER_TEST, without UART communication)
a slightly modified version of the radio_test firmware (modified to perform only the TX_CARRIER_TEST withou UART communication).

I have posted above the code of the main.c of both firmwares. I have also attached a zoomed image of the measured spur (in the image the nRFGO was set to transmit on frequency 2402MHz).

Currently we can't understand the spur on TXFreq + 430MHz that appears on the spectrum measurement.

Do you have a reference test firmware that we could try to load on the nRFGO to perform such test?

Thanks for your support. Samuele.

RE: Spectrum measurements with DTM firmware

Asbjørn — Mon, 23 Feb 2015 13:34:38 GMT

During TX only there shouldn't be any spur there from the nRF51. The LO is only visible in receive mode. The spur is a little high in frequency as well for receive mode on channel 2.403 MHz. The LO frequency is (8/7)* (2400 + channel_numer + 2). So if you are listening on channel 3 the equation would be: (8/7) * (2400 + 3 +2) ~= 2.748 MHz.

Could you try reducing the span and "zooming" in on the spur itself. That might give you a more accurate reading for where the spur actually is located and also the level of the spur.

RE: Spectrum measurements with DTM firmware

Samuele Forconi — Thu, 19 Feb 2015 16:04:06 GMT

Hi, we have made some other tests using also a basic version of the radio_test firmware to perform the TX_CARRIER_TEST. We have removed the attenuator between the nRFGo and the spectrum analyzer and programmed the nRF51 with a TX power of -30 dBm (see attached image).

This is the code we have used for the test:

#include <stdint.h>
#include <stdbool.h>
#include "boards.h"
#include "nrf.h"
#include "nrf51_bitfields.h"

static uint8_t mode_     = RADIO_MODE_MODE_Nrf_1Mbit;
static uint8_t txpower_  = RADIO_TXPOWER_TXPOWER_Neg30dBm;
static uint8_t channel_  = 2;

int main(void)
{
    // Initialization
    NRF_RNG->TASKS_START = 1;    
    // Start 16 MHz crystal oscillator
    NRF_CLOCK->EVENTS_HFCLKSTARTED  = 0;
    NRF_CLOCK->TASKS_HFCLKSTART     = 1;
    // Wait for the external oscillator to start up
    while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0)
    {
        // Do nothing.
    }
    
    // Radio disable
    NRF_RADIO->SHORTS          = 0;
    NRF_RADIO->EVENTS_DISABLED = 0;
    NRF_RADIO->TEST            = 0;
    NRF_RADIO->TASKS_DISABLE   = 1;
    while (NRF_RADIO->EVENTS_DISABLED == 0)
    {
        // Do nothing.
    }
    NRF_RADIO->EVENTS_DISABLED = 0;
    
    // Perform test
    NRF_RADIO->SHORTS     = RADIO_SHORTS_READY_START_Msk;
    NRF_RADIO->TXPOWER    = (txpower_ << RADIO_TXPOWER_TXPOWER_Pos);    
    NRF_RADIO->MODE       = (mode_ << RADIO_MODE_MODE_Pos);
    NRF_RADIO->FREQUENCY  = channel_;
    NRF_RADIO->TEST       = (RADIO_TEST_CONST_CARRIER_Enabled << RADIO_TEST_CONST_CARRIER_Pos) \
                        | (RADIO_TEST_PLL_LOCK_Enabled << RADIO_TEST_PLL_LOCK_Pos);

    NRF_RADIO->TASKS_TXEN = 1;

    while(1)
    {
        // Do nothing.
    }
}

The same spur, as described in the previous post, is still present also with this radio test software.

Do you have any suggestions/explanations for this radio behaviour?

Zoomed image of the spur: