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

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

bjorn-spockeli — Tue, 29 Oct 2019 11:57:44 GMT

Hi David,

as stated in the mail, you'll find the radio_test example with the Errata 191 and 172 workarounds added in the radio_test_orpheo.zip below:

devzone.nordicsemi.com/.../radio_5F00_test_5F00_orpheo.zip

I did some tests with both 15 and 256 byte payloads on 125kbit mode and the results look very promising. Note that adding the workaround for errata 172 on the nRF52840 trades away sensitivity for improved selectivity and rejection.

Results from one of the tests:

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: 50 percent

counter_TX: 12717
counter_CRC_OK: 12717
counter_CRC_ERROR: 0

12717/12717= 1

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

bjorn-spockeli — Tue, 22 Oct 2019 14:14:02 GMT

Hi David,

the feedback I got from R&D was the following:

CRC error count is low so its mainly lost EVENT_ADDRESS, which indicates sync on the packet was not achieved successfully.

The 125Kbit synch is optimized to keep BLE links up and running in as heavy noise and interferer environment as possible,
which means keeping PER << 30% for as long as possible as signal to noise and interferer level goes down.
To achieve this the synch must be as "greedy" as possible, accepting very garbled versions of the synchronization word.
This increases the probability of occasionally locking to a false pattern, when listening to an "empty" channel for long periods,i.e. 100 us or longer.

Hence, it is not unlikely that the PER when using 125Kbit mode could be slightly higher compared to 1Mbit when used in a scenario with a strong signal level and low attenuation.

However, if the signal power is dropped to a level where the 1MBle looses 50% of the packages, then you should see a significant performance improvement with the 125Kbit mode as a consequence of the synch accepting very garbled versions of the synchronization word.

Best regards

Bjørn

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

David — Mon, 21 Oct 2019 15:39:31 GMT

Hi Bjørn,

this sound good, I'm waiting some good news for tomorrow.

best regards

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

bjorn-spockeli — Mon, 21 Oct 2019 15:36:43 GMT

Hi Nicolas,

Runar covered fro me while I was away from Wednesday last week. R&D is looking into the issue, I have forwarded the correspondence we've had here on DevZone. Will provide an update tomorrow.

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

ubicore — Thu, 17 Oct 2019 11:03:33 GMT

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

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

run_ar — Thu, 17 Oct 2019 06:44:41 GMT

Hi Nicolas,

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

Br, Runar

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

ubicore — Wed, 16 Oct 2019 10:26:47 GMT

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

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

bjorn-spockeli — Tue, 15 Oct 2019 20:54:24 GMT

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

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

David — Mon, 14 Oct 2019 14:22:24 GMT

I Bjørn,

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

Best regards

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

ubicore — Thu, 10 Oct 2019 09:05:09 GMT

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

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

bjorn-spockeli — Tue, 08 Oct 2019 14:38:42 GMT

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