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

BLE mesh message confirmation

Hi,

I have to transfer messages every 100ms and to receive confirmation about successfull reception.

Message is sent from the phone and should make two hoos and return back a confirmation.

I am testing with original examples in sdk v15 but problem is that confirmation is comming after 1-3 seconds. What could be a reason for this? Or du you have an examole that could work the way i wrote.

Thanks

Julius

Parents
  • Hi Julius, 

     

    Could you tell a little bit more about your set up ? 

    As far as I understand you have something like this: 

     

    Phone <-> Proxy node <-> First Hop node <-> Second Hop node <-> End node 

    And it takes about 1-3 seconds for the phone to get the acknowledge from the End node after sending the initial command ? 

    We are suspecting the short connection interval on the BLE connection betwen Phone and the proxy node causing this problem. Could you check what the connection interval is on that connection ?

    Could you also check what is the average time it take for a packet from the Phone to get to End node ? Also the time it take for a reliable packet from the Proxy node to End node. 

     

     

  • Setup looks like this: Phone <-> First Hop node (with proxy feature) <-> End node

    First node and phone communication seems to be alright. The problem is that first hop node is not receiving all the data that is sent from end node (4 bytes of data @ 100ms intervals) via “unreliable” send function. Only 40 – 50% of total send data is received.

    Connection settings are default from “light switch proxy server” example in Mesh SDK 2.0.1. 

    #define MIN_CONN_INTERVAL MSEC_TO_UNITS(250, UNIT_1_25_MS)

    #define MAX_CONN_INTERVAL MSEC_TO_UNITS(1000, UNIT_1_25_MS)

  • Hi Julius, 

    Thanks for clarifying your setup. 

    Please be aware that even though we have the preferred Max and Min connection interval however, most phones will ignore it and decide the connection interval based on its own policy. We need to see the actual connection interval, either by using a sniffer or check the parameter in BLE_GAP_EVT_CONNECTED event. To be able to achieve long connection interval, the proxy node better to send a connection parameter request. 

    We do notice some unexpected affect of the gatt bearer on the adv-mesh operation on the proxy node. We have some bug fixes that will comes in the next SDK. Some of them already included in the demo we have here. I would suggest you to have a look at those file included in the SDK_patch folder. The demo has a pretty similar setup as you have. You can see the video of the demo here

    Please let us khow if using those patches helps.

Reply
  • Hi Julius, 

    Thanks for clarifying your setup. 

    Please be aware that even though we have the preferred Max and Min connection interval however, most phones will ignore it and decide the connection interval based on its own policy. We need to see the actual connection interval, either by using a sniffer or check the parameter in BLE_GAP_EVT_CONNECTED event. To be able to achieve long connection interval, the proxy node better to send a connection parameter request. 

    We do notice some unexpected affect of the gatt bearer on the adv-mesh operation on the proxy node. We have some bug fixes that will comes in the next SDK. Some of them already included in the demo we have here. I would suggest you to have a look at those file included in the SDK_patch folder. The demo has a pretty similar setup as you have. You can see the video of the demo here

    Please let us khow if using those patches helps.

Children
  • Hi Hung,

    When we use android phone to connect we have: 

    <t:    5494718>, mesh_gatt.c,  885, Connection intervals: min 39; max 39.

    When the iphone is used on connected event we get:

    <t:     502556>, mesh_gatt.c,  885, Connection intervals: min 24; max 24.

    and then BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST happens and parameters change to:

    <t:     527111>, mesh_gatt.c,  948, Connection intervals: min 0; max 0.

    Either way, using android or iphone doesn't have any impact on mesh communication behaviour. Still approx. half of packets are lost.

    I will further investigate the source you have provided and post here if there are any positive results.

    Update:

    After updating files from provided examples 51% of packets are lost while connected to android device & 72% lost while connected to iphone.

    Gediminas

  • Hi Gediminas, 

     

    Connection interval of 39 (48.75ms) and 24 (30ms) is pretty short. I would suggest to request the phone to change to say 500ms connection interval. To do that you would need to call connection parameter update request sd_ble_gap_conn_param_update() and wait for the central to accept and update the connection. 

  • Hi,

    to be clear, changing connection interval didn't do much. It's the connection between mesh devices that is lagging (taking a long time), when sending data via client/server models. Any ideas on that?

  • Hi Gediminas, 

    As you described, the issue you observed related to the proxy node. The problem of the proxy node is that it has to serve the BLE connection. If the BLE connection interval is too short, it will block the Mesh activity. 

    Have you tried to test with and without phone connection do you have the same latency ? What is the lagging time do you have ? Do you see the same problem when testing with the light switch example ? 

    When you mentioned changing the connection interval didn't do much, how did you check if the connection interval was actually  changed to the value you wanted ? 

  • Hi Hung,

    I was just trying out mesh connection without any phone connected, i didn't have any impact on the communication between the mesh nodes: response time is from 0.03 sec to 1.5 sec and more (if I am calculating right from the output log):

    <t:    8983684>, access.c,  477, TX: [aop: 0x00C1]  - msg sent

    <t:    9030493>, access.c,  291, RX: [aop: 0x00C4] - response from the node

    Regarding changing the interval, i just called sd_ble_gap_conn_param_update() after connection.

Related