Radio Test Example at high duty cycles

RE: Radio Test Example at high duty cycles

Håkon Alseth — Mon, 26 Apr 2021 09:11:11 GMT

Hi,

[quote user="hjeanmccurry"]However, what i'm still wondering about is why it has the behavior it does for the highest duty cycles. Is it a fallback mode to give it enough time to ramp up and down? Why does it basically delete ~50% from the cycle rather than, say, limit the duty cycle to the smallest possible value based on mode, payload, etc and return a warning/error? The quibbles of sample code and the very low level of control given by the socs?[/quote]

The timing calculated for the actual RF payload, including ramp-up time, will be higher than the timers capture/compare value, so you get a timer triggered before the radio is done, thus the next one will then start the radio again. This will give you a approx. 50% DC. The limitations in this function is clearly a issue from our side, which I'll report internally.

Kind regards,

Håkon

RE: Radio Test Example at high duty cycles

hjeanmccurry — Fri, 23 Apr 2021 14:25:11 GMT

Thank you for your response, Håkon. That's about what I thought... However, what i'm still wondering about is why it has the behavior it does for the highest duty cycles. Is it a fallback mode to give it enough time to ramp up and down? Why does it basically delete ~50% from the cycle rather than, say, limit the duty cycle to the smallest possible value based on mode, payload, etc and return a warning/error? The quibbles of sample code and the very low level of control given by the socs?

RE: Radio Test Example at high duty cycles

Håkon Alseth — Fri, 23 Apr 2021 10:37:45 GMT

Hi,

[quote user=""]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?[/quote]

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