Radio Test Example at high duty cycles

[hjeanmccurry]

I'm running the radio_test example on an nRF52840, but when I try different modulation duty cycles, it seems to work fine for everything less than 94% however 94% itself starts to get erratic (the pulse width and period vary by quite as bit and the carrier pokes above the spectrum curve) and 95 and above seem to subtract 48-50% from the requested duty cycle (95% is about the same as 47-48% and 99% is about 49-50%). This happens with both ble and regular nrf radios at 1Mbit. 2Mbit is similar, but this time its 89-99% that modulate at ~46-50% duty cycles. That doubling can't be a coincidence. Does it stem from the downtime giving too little time for the radio to shut down and start up again?

For reference this is on SDK v17, just running the bare example.

[Håkon Alseth]

Hi,

 

I'm running the radio_test example on an nRF52840, but when I try different modulation duty cycles, it seems to work fine for everything less than 94% however 94% itself starts to get erratic (the pulse width and period vary by quite as bit and the carrier pokes above the spectrum curve) and 95 and above seem to subtract 48-50% from the requested duty cycle (95% is about the same as 47-48% and 99% is about 49-50%). This happens with both ble and regular nrf radios at 1Mbit. 2Mbit is similar, but this time its 89-99% that modulate at ~46-50% duty cycles. That doubling can't be a coincidence. Does it stem from the downtime giving too little time for the radio to shut down and start up again?

Looking at the function, I think I know the source of your issue.

It seems that the radio ramp up time isn't taken into consideration, which also is switched to fast mode (40 us) in some modes; and "legacy" mode in others (130 to 140 us).

This is not modulated data, but has a direct impact on the timing of the signal. For the duty cycle to be correct on-air, we have to input a value that both respects the on-air duty cycle and gives the radio enough time to successfully ramp up.

We could add this ramp up time to the equation, but that will then give you a duty cycle that isn't correct.

Lets say that a packet uses 2 ms, and you want to have 10 % DC -> wait time = (2ms/0.10) - 2 ms = 18 ms.

If we account for 140 us ramp up in this equation, we get:

2.14 ms, 10 % DC -> wait time = (2.14ms / 0.10) - 2.14 = 19.26 ms.

By adjusting for the radio ramp up time, the firmware will run as expected, but yield wrong results; the above will give a 9% DC as an example.

 

In the case that you need 100 % DC, I would recommend that you use command "start_tx_modulated_carrier".

Having a duty cycle > 80 % needs manual tuning (depending on radio mode, payload length etc), so we should have restricted this function to this limit.

 

However: there's a bug in the duty cycle handling of the ieee 802.15.4 mode, because the size of the payload is 127 byte (+ 6 byte overhead).

This can be fixed by patching radio_test.c::radio_modulated_tx_carrier_duty_cycle():

    #ifdef USE_MORE_RADIO_MODES
    uint32_t total_payload_size = 1 + 5 + sizeof(m_tx_packet);

    if (mode == NRF_RADIO_MODE_IEEE802154_250KBIT) 
    {
        total_payload_size = 5 + 1 + IEEE_MAX_PAYLOAD_LEN + 1;
    }
    #else
    // 1 byte preamble, 5 byte address (BALEN + PREFIX), and sizeof(payload), no CRC
    const uint32_t total_payload_size     = 1 + 5 + sizeof(m_tx_packet);
    #endif

 

Kind regards,

Håkon