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

proxy_server example connection very slow after reboot

I've been trying out the light_switch proxy_server example. Currently I am using a BLE debugging tool on MacOS to send raw bytes to the Mesh Proxy Data In characteristic to interact with the GATT Proxy Server in the proxy_server example. In the process I do the following: 

1) In the provisioner I configure the proxy_server node to publish health_server status once every second. 

2) I connect to the proxy_server node from my laptop.

3) I subscribe to the "Mesh Proxy Data Out" characteristic.

4) I send a manually encoded message on the "Mesh Proxy Data In" characteristic per Mesh Specification section 6 to configure the GATT Proxy filter to be "blacklist, no address" -- which essentially allows all packets to pass the filter. 

5) After doing the steps above, I am able to receive data packets on the "Mesh Proxy Data Out" characteristic once every second (i.e. I can receive the health_server publications). Everything works exactly as expected so far. 

In the process, steps 2-5 finish almost instantaneously. I then reset the proxy_server node. Upon reboot, the node recognizes that it has already been provisioned, and remembers all the provisioning data from before. I then try to repeat step 2-5 above. However, this time, the connection is very sluggish -- step 3 and 4 takes multiple seconds to finish. Moreover, for step 5, I am only able to receive a packet update every 2 seconds. This is because each packet transfer now takes ~2 seconds to finish (measured from the point when 'sd_ble_gatts_hvx()' is called in 'mesh_gatt.c' to the point when 'MESH_GATT_EVT_TYPE_TX_COMPLETE' is received in 'proxy.c'). Therefore GATT Proxy TX cannot keep up with the every-second frequency of the heath_server updates. 

I have verified that the GAP connection parameters before and after the reset are the same: min_conn_interval=12, max_conn_interval=12, slave_latency=0, conn_sup_timeout=200. Since the soft device source code is not available, I'm not sure how I should proceed to debug from here. Is there a way to get more information/log on the events/timing happening in the soft device?  

Thanks so much!

Parents
  • Hi, 

     

    We are not sure what could be wrong. It looks more like the connection interval could be adjusted to 2seconds. A sniffer trace can really tell what happens there. Another possibility that mesh stack could consume a large amount of timeslot, causing the  BLE softdevice missing a lot of connection event thus resulting in slow notification update. 

    A sniffer trace would be very useful. 

    You can also check the connection parameter when you get connected by adding a breakpoint in mesh_gatt_on_ble_evt on BLE_GAP_EVT_CONNECTED event and check the parameter in p_ble_evt->gap_evt. You should also check for BLE_GAP_EVT_CONN_PARAM_UPDATE event if any 

     

Reply
  • Hi, 

     

    We are not sure what could be wrong. It looks more like the connection interval could be adjusted to 2seconds. A sniffer trace can really tell what happens there. Another possibility that mesh stack could consume a large amount of timeslot, causing the  BLE softdevice missing a lot of connection event thus resulting in slow notification update. 

    A sniffer trace would be very useful. 

    You can also check the connection parameter when you get connected by adding a breakpoint in mesh_gatt_on_ble_evt on BLE_GAP_EVT_CONNECTED event and check the parameter in p_ble_evt->gap_evt. You should also check for BLE_GAP_EVT_CONN_PARAM_UPDATE event if any 

     

Children
  • Thanks for the answer! Sorry for the radio silence – I was kept away from this project for a bit.

    I noticed that the slow connection was due to connection parameter configurations. Upon first booting up, and before reset, the connection params are kept as the default (i.e. sd_ble_gap_ppcp_set is never called). After reset, however, the connection params are set to longer intervals – hence the slower connection and data rate. 

    Though this doesn't fully explain the issue, as there should still be enough bandwidth even with the longer interval. At this point I'm happy to just keep the connection params as the default, and come back to the issue later. Thanks for the pointers! 

Related