nRF52840 reconnection distance

I conducted a BLE test using two nRF52840 Dongles. Since I used Dongles, I based my code on the usbd example from the sample programs. During testing, the connection between the two Dongles dropped at a distance of approximately 50 meters, but reconnection was only possible at around 10 meters. This result was consistent across multiple tests. Additionally, changing PHY and TX Power did not make any difference.

Why is the reconnection distance significantly shorter than the disconnection distance?

Parents
  • Hi kimhh,

    For what it is worth, I have the same experience.

    Very often I see this in the logs:

    <wrn> [MPSL Work] bt_conn: conn 0x20006b68 failed to establish. RF noise?
    <inf> [sysworkq] ap: Disconnected: BT_HCI_ERR_CONN_FAIL_TO_ESTAB (62)

    Sometimes I instead get an early disconnect during the initial exchange of connection parameters. At which stage does the connection establishment fail for you?

    I have not found the reason for this. But here are some things that hopefully are worth mentioning.

    To find a peripheral it is crucial that the Central can hear the peripheral on at least 1 of the 3 primary advertising channels.

    If Legacy Advertising is used the connection is also established using any of those 3 channels. If Extended Advertising is used, the connection is instead established using one of the 37 data channels.

    Once a connection is up, all communication happens on the 37 data channels. So, as Elfving mentioned, if you have a lot of noise on the 3 primary advertising channels it would explain the results we have observed to some extent. But I do not buy that explanation fully. And I guess you do not either, since you have even had the time to actually test this in a shielded environment.

    When you say that you have changed PHY and TX Power, how did you do that? Have you been able to verify that your advertising messages actually are using the PHY and TX Power you have configured? What kind of advertising are you using? 

    During establishment of a Connection some parameters are exchanged between the two nodes. What I have not figured out is how the retry mechanism looks like during the initialization phase. I suspect that some moment in this phase is very sensitive when establishing connections in environments with packet loss. But it is nothing more than a clever guess from my side. I have not had the time to really dig into this. 

Reply
  • Hi kimhh,

    For what it is worth, I have the same experience.

    Very often I see this in the logs:

    <wrn> [MPSL Work] bt_conn: conn 0x20006b68 failed to establish. RF noise?
    <inf> [sysworkq] ap: Disconnected: BT_HCI_ERR_CONN_FAIL_TO_ESTAB (62)

    Sometimes I instead get an early disconnect during the initial exchange of connection parameters. At which stage does the connection establishment fail for you?

    I have not found the reason for this. But here are some things that hopefully are worth mentioning.

    To find a peripheral it is crucial that the Central can hear the peripheral on at least 1 of the 3 primary advertising channels.

    If Legacy Advertising is used the connection is also established using any of those 3 channels. If Extended Advertising is used, the connection is instead established using one of the 37 data channels.

    Once a connection is up, all communication happens on the 37 data channels. So, as Elfving mentioned, if you have a lot of noise on the 3 primary advertising channels it would explain the results we have observed to some extent. But I do not buy that explanation fully. And I guess you do not either, since you have even had the time to actually test this in a shielded environment.

    When you say that you have changed PHY and TX Power, how did you do that? Have you been able to verify that your advertising messages actually are using the PHY and TX Power you have configured? What kind of advertising are you using? 

    During establishment of a Connection some parameters are exchanged between the two nodes. What I have not figured out is how the retry mechanism looks like during the initialization phase. I suspect that some moment in this phase is very sensitive when establishing connections in environments with packet loss. But it is nothing more than a clever guess from my side. I have not had the time to really dig into this. 

Children
No Data
Related