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

BLE Scan Packet Receive Latency When Done Along Side Mesh.

Hi,

Scenario:  Scanning  non mesh BLE packet with different stacks.

H/W Device -  nRF52DK

Observation:

Case 1. Non Mesh BLE Stack (Soft device):: Here able to receive scan packets in less than 1 sec interval.

Case 2. Mesh stack device                          : Here the scan packets are received around 10 to 15 secs of interval..

Is this expected behavior in mesh stack? Is there any way to decreases the latency between the reception of scan packets when done along with mesh?

Note: There is no difference in the advertisement frequency/packet in both the cases.

Parents Reply Children
  • 1. It seems we actually get scan responses through the mesh.

    2. So it is a matter of sending out the requests to have full-fledged active scanning functionality in the mesh. A small step, but very valuable because it does not introduce unnecessary competition wrt the radio peripheral, reduces code base, and likely causes fewer timing issues with other devices. Can you point us towards where/how you would implement it preferably in the mesh code so we are future-proof with respect to your implementation? We're assuming you will add it anyway in the near future. :-)

  • Hi,

    Sorry for the late reply, and thank you for the request!

    For you to change the mesh stack code is not a particularly good idea, as it would render the QDIDs void. (I.e. you need to qualify the modified mesh stack.) What that means in practice is that you will have to use the SoftDevice API for active scanning.

    I guess you could minimize the time spent outside of the mesh stack by only do active scanning for a short period of time, directly after having received a scannable advertisement through the mesh callback. (So that on the next advertisement you will get to scan.)

    Regards,
    Terje

  • Which QDID? https://launchstudio.bluetooth.com/ListingDetails/59560 QDID 111537 is limited to nRF5 MESH SDK 2.0.1. Anyway, it's not relevant for us.

    https://www.bluetooth.com/bluetooth-technology/topology-options/le-mesh/mesh-faq/

    Can I qualify my existing Bluetooth products with low-energy functionality for Bluetooth mesh?

    No, existing products cannot be qualified for Bluetooth mesh. However, those products may already have the inherent ability to be added onto a mesh network.

    Hence, we will not qualify them, but we will add the ability to function in a mesh. This means we can indeed make changes and provide a better customer experience in general. .

  • Hi,

    Right. So it seems in that case you are good. For the record, nRF5 SDK for Mesh v3.1.0 is still covered by QDID 111537 which was filed for v2.0.1. I must admit I am a bit confused as to what constitutes a change requiring requalification, but my general recommendation is still to not touch the mesh stack if you can avoid it.

    I received an experimental patch (with support for active scanning) from one of our Mesh developers, but I see that you already got that a couple days ago in a separate (private) thread. I will leave you to that thread for now. When the issues discovered for that patch is solved then maybe we might share it here or in another public thread (as an unofficial patch, that is.) Unfortunately we do not have any immediate plans to merge that behavior into the nRF5 SDK for Mesh.

    Regards,
    Terje

  • Yes that is right.

    Sorry for the late replsy 

    Regards

    Sivaguru Ravi

Related