nRF52840 BLE connection frequently disconnects in OTA test use CMW500's connect mode

[RongLinQin]

Hi Nordic support:

         We previously submitted a case about OTA testing in CMW500 connection mode. Following is that case:

 Could we use CMW500's connection mode to test nRF52840's BLE RF? 

         We tried OTA testing with the CMW500 connection mode again, the BLE connection frequently dropping during the test. Our BLE application base on "nrf5_sdk_17.1.0_ddde560\examples\ble_peripheral\ble_app_uart".    During the test, the power was gradually reduced. When the power is reduced to the point where the BER becomes non-zero,  ble application's ble_event_handler received event 0x2A  "#define BLE_HCI_DIFFERENT_TRANSACTION_COLLISION        0x2A  " , then the BLE connection dropped.

        Could you give us some guide for CMW500 OTA test in connection mode? How could we avoid the 0x2A error to prevent the ble connection from dropping?

 Following picture is nRF52840 OTA test log

       

Thanks!

BRs

Qin, Rong-Lin 

          

[RongLinQin]

Hi Asbjørn:

    We would like to test the BLE OTA TIS of the nRF52840 over air. Currently, we use a wired serial port for testing, which requires breaking the enclosure to route out the serial lines, so we want to perform the test over air.

     We captured the sniff log "sniff_nRF52840_CMW500.7z" using nRF Sniffer; each file corresponds to a complete connection cycle from establishment to disconnection. Could you help to check whether the LL_FEATURE_REQ/RSP cause  disconnection? Is it possible to modify the Nordic SDK code to prevent this disconnect issue?

      Thanks!

     sniff_nRF52840_CMW500.7z

BRs

Qin, Rong-Lin

[RongLinQin]

Hi Asbjørn:

       We also captured logs from another BLE door lock from other manufacture which can run CMW5000 BLE OTA test normally. Could you help us to check these log?

       Thanks!

other_ble_device_test_ok.7z

BRs

Qin, Rong-Lin

[Asbjørn]

Hello Rong-Lin,

In nrf52840_sniffer_1 for example:

The central/cmw send a follow up feature request before the first one is completed and this is the violation. It seems the link is operating at the RSSI limit for one of them and central seems to be losing packages. The spec says you can request ll features multiple times, but you have to finish one exchange before next is initiated and this is what is not kept. 

We cannot create a softdevice/BLE controller to accommodate this by bending the specification. From our point of view it will come back as we are violating the specification and create more questions and issues. Having a test HCI out there for this purpose is a matter of risk assessment from our point of view. If we were to release such a controller it is a higher risk that some will end up using it in production unintentionally or intentionally. 

With regards to the another BLE vendor door lock. Don't know what sort of radio product that is inside that, but it is of course possible to bend the specification which could explain this, but I don't think it is a Nordic radio inside that door lock.

Best regards

Asbjørn