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 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.

Reply
  • 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.

Children
  • 1.5 sec is quite high. The advertising interval of Mesh network by default is 20ms. 

    Could you try to test with unmodified light switch example ? 

    I assume you have only 2 node in the network and they talk directly to each other ( in range of each other) ? 

  • Yes, there are only 2 nodes talking to each other directly.

    With the original examples (1 proxy server / 1 proxy client) response times were from 0.03 sec to 4-5 sec.

    Snippet from client debug terminal log:

    <t:    7063363>, main.c,  183, Button 0 pressed

    <t:    7221192>, main.c,  143, server status received

  • OK, but you didn't mentioned that they were both proxy nodes. 

    Do you do advertising on the proxy nodes ? Please make sure they are advertising with long interval (suggest to have 500ms). You can check the advertising interval using nRFConnect on the phone. 

    Please try again with the demo we have here. All of them are proxy nodes, we don't see that much of latency.  We do have some modification to improve the mesh performance in the SDK_PATCH folder.

    It made for the nRFThingy, but if you can just comment out those function to control the LED you should be able to use it on a nRF52DK. 

Related