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 

          

[Asbjørn]

Hello,

We've had other customers seeing issues with maintaining a link with the CMW and seen that in some situations the CMW will send two LL_FEATURE_REQ to the DUT and this breaks the connection as it is a violation of the BLE spec. I cannot for sure say that this is the same that you observe, but the description is very very similar. You'd have to get in touch with R&S to follow this with them in this case.

Best regards

Asbjørn

[RongLinQin]

Hi Asbjørn:

     Thanks for your information,

      We are now checking it with R&S FAE, Looks like they have not any idea for that, but they said they will check it internally.

       And for this message - LL_FEATURE_ REQ sent two time and violate BLE spec. not sure if there is any workaround which we can overcome this issue, e.g. in app layer, just return ok and not do anything for this message, would you please help check and give comment?

Thanks a lot.

Best Regards

[Asbjørn]

Hi,

I can't prove that it is the  LL_FEATURE_ REQ sent twice that is causing the behavior you're seeing in this case based on the information I have received, but we have seen others have similar experiences with R&S and  LL_FEATURE_ REQ. There's no workaround for it as it would be a specification violation to ignore the double request. Is there a log from the R&S that will print the commands sent and received? There it should be possible to see what sort of messages are going from the CMW just prior to the disconnect. That will also show if it actually is the double  LL_FEATURE_ REQ that I suspect or if it is something else.

Best regards

Asbjørn

[RongLinQin]

Hi Asbjørn:

      Following info is feedback from R&S：

       The 'Connection mode' measurement on the CMW platform uses the LL_Feature_Req/Rsp as the mechanism to perform receiver (PER) measurements.
       So, we are using this measurement mode as a way of allowing customers to test RF performance OTA.
However, in order to allow this mode of operation to work means ‘bending the rules’ of the Core Specification – I.e. it has been done by design and not by accident.

       If we didn't do this then the measurement would not be possible.

      Other devices don't have a issue with this approach.

       We have already discussed it with the Nordic engineering team.

BRs

Qin, Rong-Lin

[Asbjørn]

Hello Rong-Lin,

thanks for the update and yes, this is correct and there are no plans from Nordic point of view to change the behaviour of our SoftDevice. 

What is it you would like to test? PER of your system? Is there another approach that would allow you to find the information and verification you want?

Best regards

Asbjørn

[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