This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

No Improvement of BLT 5 Long Range Mode

Hi, 

We have a product composes of a central and a peripheral which uses Nrf52840 as their MCU and communicate with each other via BLE. The peripheral will send some data and transfer audio captured by microphone to the central in real time. Currently they work perfectly.

Now I wanna implement long range mode to improve the distance performance.

However, modifying the firmware of the central and wearable for the implementation of the long range mode, I did the range test by comparing the two sets of the product(one is current version, the other one is of updated firmware), it seems that there is no distance improvement....

(By the way, the approach I conduct the range test is : I let the central and peripheral works, fixing the position of the central, and then move the peripheral away from the central, until the bluetooth connection is disconnected between the two)

Here I attach the codes of which I modified for long range mode, could you help me to check if there is something I miss?  Or there is some other causes can explain this?

(Peripheral)

(Central)

Parents Reply Children
  • Hi Simonr, I've checked the source code of BLE long-range demo you mentioned above. I had some findings:

    (1)The SDK of demo is 15.0 while my project uses 15.2, therefore a lot of definition of API is different.

    (2)The demo has the setting which is p_advertising->adv_params.properties.type = BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED when the channel is CODED_PHY, while my case is BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED

    (3) In Demo, adv_params.primary_phy     = BLE_GAP_PHY_CODED, while my current setting is adv_params.primary_phy     = BLE_GAP_PHY_1MBPS.

    So, I changed the adv_params.primary_phy from 1MBPS to CODED. However, after implementing the change,  they cannot establish the connection normally. 

    Do you have any suggestion how to find the root cause of this? (I mean the cause of cannot connect to each other, and, and distance improvement is not obvious)

  • BK said:
    The demo has the setting which is p_advertising->adv_params.properties.type = BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED when the channel is CODED_PHY, while my case is BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED

     I think you wrote the same thing twice here. What is the ADV_TYPE in your application?

    What is your advertising flag set as? This needs to be BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE for the peripheral to work in long-range mode.

    For the application to connect when primary PHY is set to CODED_PHY both the peripheral and central must have the same primary PHY. There could be a number of issues in your application(s), but I can't see what it is from the snippets you've uploaded. I also ought to link to this case, as this range issue was caused by a combination of a bad antenna and a less than optimal testing environment.

    Best regards,

    Simon

  • Hi Simon, sorry that's my mistake.

    (1)Actually I mean it's BLE_GAP_ADV_TYPE_EXTENDED_CONNECTABLE_NONSCANNABLE_UNDIRECTED in Demo whereas my application is BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED.

    (2)And yes, my advertising flag is set to be BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE.

    (3)Is that OK to set primary channel to 1MBPS and secondary channel to CODED for long range mode for the peripheral? Or they both have to be set to CODED?  

    (4)Is that OK to set scan_phys to BLE_GAP_PHY_AUTO for long range mode for the central? Or it has to be set to BLE_GAP_PHY_CODED? 

     

Related