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

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 

          

Parents
  • 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
Reply
  • 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
Children
No Data
Related