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

[ubicore]

Hi Bjørn,

(I did the test for David)

I try to add a 3 to the total_payload_size, but same result.

Probably the problem is more complex than a timer delay...


We do a lot of test from the beginin of year with differents software (SDK and our proprietary implementation of FHSS based on zephyr OS) and the result is alway the same :
- with same tx power
- with same windows duration
- with same or different frame transmission time

=> in 1Mbit, no problem (even with maximum payload size)
=> in Long range some frame are lost (even with minimum payload size)


Our investigation seem to indicate that the frame is corectly 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) .

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.

Best regards

Nicolas