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 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. 

[David]

Hi Bjørn,

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

best regards

[bjorn-spockeli]

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