Error rate more important in Long range 125k than in normal mode 1M

[David]

We made the test with your demo SDK on the board :

                PCA10056 1.0.0 2018.46
                PCA10056 1.1.0 2019.26

We modify the code to gate the trace ( see the attach file)radio_test-1.zip

And the result are that in 1 Mbits (NO long range) this quite perfect , in Long range 125Kbit we have between 3 and 4 over 1000 packet lost !!!

Do you know how to explain this ?

the details of the results below

Best regards

 

################################
Payload 256
Data rate: RADIO_MODE_MODE_Ble_LR125Kbit
TX power: RADIO_TXPOWER_TXPOWER_Neg20dBm
Transmission pattern: TRANSMIT_PATTERN_11110000
Start Channel:  0
Duty cycle:     50 percent

counter_TX: 29313
counter_CRC_OK: 29227
counter_CRC_ERROR: 0

29227/29313 = 0,997066148


################################
Payload 256
Data rate: RADIO_MODE_MODE_Ble_LR125Kbit
TX power: RADIO_TXPOWER_TXPOWER_Neg8dBm
Transmission pattern: TRANSMIT_PATTERN_11110000
Start Channel:  40
Duty cycle:     50 percent

counter_TX: 10779
counter_CRC_OK: 10774
counter_CRC_ERROR: 1

(10774+1)/10779=0,999628908

################################
Payload 256
Data rate: RADIO_MODE_MODE_Ble_LR125Kbit
TX power: RADIO_TXPOWER_TXPOWER_Neg8dBm
Transmission pattern: TRANSMIT_PATTERN_11110000
Start Channel:    0
Duty cycle:    90 percent

counter_TX: 27706
counter_CRC_OK: 27624
counter_CRC_ERROR: 1

(27624+1)/27706 = 0,997076446

################################
Payload 5
Data rate: RADIO_MODE_MODE_Ble_LR125Kbit
TX power: RADIO_TXPOWER_TXPOWER_Neg8dBm
Transmission pattern: TRANSMIT_PATTERN_11110000
Start Channel:    40
Duty cycle:    50 percent

counter_TX: 37984
counter_CRC_OK: 37977
counter_CRC_ERROR: 0

37977/37984 = 0,99815712

################################
Payload 15
Data rate: RADIO_MODE_MODE_Ble_LR125Kbit
TX power: RADIO_TXPOWER_TXPOWER_Neg8dBm
Transmission pattern: TRANSMIT_PATTERN_11110000
Start Channel:    40
Duty cycle:    50 percent

counter_TX: 26552
counter_CRC_OK: 26548
counter_CRC_ERROR: 0

26548/26552 = 0,999849352

################################
Payload 15
Data rate: RADIO_MODE_MODE_Ble_1Mbit
TX power: RADIO_TXPOWER_TXPOWER_Neg8dBm
Transmission pattern: TRANSMIT_PATTERN_11110000
Start Channel:    40
Duty cycle:    50 percent

counter_TX: 40091
counter_CRC_OK: 40090
counter_CRC_ERROR: 0

40090/40091 = 0,999975057

################################
Payload 256
Data rate: RADIO_MODE_MODE_Ble_1Mbit
TX power: RADIO_TXPOWER_TXPOWER_Neg8dBm
Transmission pattern: TRANSMIT_PATTERN_11110000
Start Channel:    40
Duty cycle:    50 percent


counter_TX: 30934
counter_CRC_OK: 30934
counter_CRC_ERROR: 0

30934/30934 = 1

[bjorn-spockeli]

Hi David, 

I think there could  is an error in how the timer delay is calculated in radio_modulated_tx_carrier_duty_cycle()

When you select the RADIO_MODE_MODE_Ble_LR500Kbit or RADIO_MODE_MODE_Ble_LR125Kbit, then the 

radio_config() functio will set the CRCCNF register so that a CRC of length 3 is used. While when selecting the 

RADIO_MODE_MODE_Ble_2Mbit or RADIO_MODE_MODE_Ble_1Mbit, then the CRCCNF is set to the following

NRF_RADIO->CRCCNF = (RADIO_CRCCNF_LEN_Disabled << RADIO_CRCCNF_LEN_Pos);

So going back to radio_modulated_tx_carrier_duty_cycle() we see that the total_payload_size is calculated assuming that there is no CRC, when its 3 bytes in reality when using the 500Kbit and 125Kbit modes. This 

void radio_modulated_tx_carrier_duty_cycle(uint8_t txpower,
                                           uint8_t mode,
                                           uint8_t channel,
                                           uint8_t duty_cycle)
{
    // Lookup table with time per byte in each radio MODE
    // Mapped per NRF_RADIO->MODE available on nRF5-series devices @ref <insert ref to mode register>
    static const uint8_t time_in_us_per_byte[16] =
    {8, 4, 32, 8, 4, 64, 16, 0, 0, 0, 0, 0, 0, 0, 0, 32};
    // 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);
    const uint32_t total_time_per_payload = time_in_us_per_byte[mode] * total_payload_size;
    // Duty cycle = 100 * Time_on / (time_on + time_off), we need to calculate "time_off" for delay.
    // In addition, the timer includes the "total_time_per_payload", so we need to add this to the total timer cycle.
    uint32_t delay_time = total_time_per_payload +
                          ((100 * total_time_per_payload -
                            (total_time_per_payload * duty_cycle)) / duty_cycle);

So could you try to alter total_payload_size to account for this 3 byte CRC, i.e.

// 1 byte preamble, 5 byte address (BALEN + PREFIX), and sizeof(payload), 3 byte CRC
const uint32_t total_payload_size     = 1 + 5 + sizeof(m_tx_packet) + 3;

and see if that results in less invalid packets?

Best regards

Bjørn

[David]

I Bjørn,

Since the answer of Nicolas did you have some news about the problem we are facing ?

Best regards

[bjorn-spockeli]

Hi David, 

I apologize for the late reply. 

I am able to reproduce the issue with two nRF52840 DKs( one v1.0.0 2018.17 and one v1.1.0 2019.19), i.e. I am seeing packets not being received correctly independently of TX output power, duty cycle and frame transmission time 

I thought that it could be due to [Errata 191] RADIO: High packet error rate in BLE Long Range mode so I tried adding the workaround to radio_config(), i.e. 

    case RADIO_MODE_MODE_Ble_LR500Kbit:
    case RADIO_MODE_MODE_Ble_LR125Kbit:
    {
        // Workaround for Errata 191
        *(volatile uint32_t *) 0x40001740 = ((*((volatile uint32_t *) 0x40001740)) & 0x7FFF00FF) | 0x80000000 | (((uint32_t)(196)) << 8);

        // Packet configuration:
        // S1 size = 0 bits, S0 size = 0 bytes, payload length size = 8 bits, 10-bit preamble.
        NRF_RADIO->PCNF0 = (0UL << RADIO_PCNF0_S1LEN_Pos) |
                           (0UL << RADIO_PCNF0_S0LEN_Pos) |
                           (RADIO_PCNF0_PLEN_LongRange << RADIO_PCNF0_PLEN_Pos) |
                           (2UL << RADIO_PCNF0_CILEN_Pos) |
                           (3UL << RADIO_PCNF0_TERMLEN_Pos) |
                           (RADIO_PCNF0_CRCINC_Exclude << RADIO_PCNF0_CRCINC_Pos) |
                           (RADIO_LENGTH_LENGTH_FIELD << RADIO_PCNF0_LFLEN_Pos);
        NRF_RADIO->PCNF1 = (RADIO_PCNF1_WHITEEN_Enabled << RADIO_PCNF1_WHITEEN_Pos) |
                           (RADIO_PCNF1_ENDIAN_Little << RADIO_PCNF1_ENDIAN_Pos) |
                           (3UL << RADIO_PCNF1_BALEN_Pos) |
                           (0UL << RADIO_PCNF1_STATLEN_Pos) |
                           ((sizeof(m_tx_packet) - 1) << RADIO_PCNF1_MAXLEN_Pos);

        // Set fast ramp-up time.
        NRF_RADIO->MODECNF0 |= (RADIO_MODECNF0_RU_Fast << RADIO_MODECNF0_RU_Pos);

        // Set CRC length; CRC calculation does not include the address field.
        NRF_RADIO->CRCCNF = (RADIO_CRCCNF_LEN_Three << RADIO_CRCCNF_LEN_Pos) |
                            (RADIO_CRCCNF_SKIPADDR_Skip << RADIO_CRCCNF_SKIPADDR_Pos);
    } break;

However, I did not see any improvement here in my setup. I am not aware of any other known issues that might cause this so I will discuss the behavior we're seeing with the RADIO designers and see if they have any idea to what the cause might be. 

I also wanted to ask a couple of question related to your observations:

Our investigation seem to indicate that the frame is correctly sended, as it is received on one board, but not on second board.
The board that did not receive the frame is controlled to be in Rx (with hardware debug trace on gpio) but the address event is never generated (hardware trace : address event coupled with a PPI channel to a gpio) .

Does the first board receive all packets, i.e.counter_TX == counter_CRC_OK? Does the second board generate the CRC_OK event? The address field in the generated modulated RF packet will be random, but if you leave the DAP and DAB registers to their default value, then you should get an ADRESS match on both devices. 

Whatever the tests conditions there is always 3 to 4 frames lost for 1000 in Long range 125 kBit mode, while the 1st Mbit mode work perfectly.

Second identified limitation : the Long range 500 Kbit mode does not support the static frame length as it cause an CRC error status while the frame is good.

Could you elaborate a bit on the above statement? 

Best regards

Bjørn

[ubicore]

Hi Bjorn,

About the 125kbit Long range mode:
When you use the TRANSMIT_PATTERN_11110000 the address is fixed, not random.

case TRANSMIT_PATTERN_11110000:
 NRF_RADIO->PREFIX0 = 0xF0;
 NRF_RADIO->BASE0 = 0xF0F0F0F0;Code

With two board in Rx mode, some packet are missing (not received) on the two board but not at the same time.

I did not see any correlation between the moments when the packets are not received on the two board.
 Sometime one is received on one side but not on second. Sometime it is the inverse.
 This seem to suggest that the problem could be in the Rx side of the Long range module

About the 500kbit Long range mode:
If you use proprietary format with an only static packet lenght:

PCNF0_LFLEN = 0
PCNF1_STATLEN = YourPacketPayloadSize
PCNF1_MAXLEN = YourPacketPayloadSize

The packet are received, but CRC indicate an error status on something like 90 or 99% of the transmitted packets.

Best regards

Nicolas

[run_ar]

Hi Nicolas,

Do you also see this package loss if you test it in an RF chamber?

Br, Runar

[ubicore]

Hi Br, Runar,

We do the test wired with a coaxial cable and attenuator
Whatever the test conditions, there can not be more loss in "phy coded" / 125 KB than in 1 Mbit

Best regards

Nicolas