10 second delay after PB-GATT completed until first Mesh Proxy Service advertisement

[JonasJ]

Hi,

After provisioning a device using PB-GATT there is a 10 second delay after the PB-GATT connection is closed and the first Mesh Proxy Service advertisement is sent.

When the PB-GATT connection is closed the stack will end up in sd_state_evt_handler in mesh_provisionee.c after both the mesh stack and softdevice has been disabled.

The code will go on and call proxy_node_id_enable() -> adv_start() -> mesh_adv_start() -> sd_ble_gap_adv_start() and timeslot_restart().

I suspect that the issue is with timeslot_restart() as it's configured to request maximum 10 second timeslots by default (TIMESLOT_MAX_LENGTH_US). If this value is changed to 7 seconds I see a 7 second delay instead.

This issue can be seen by provisioning a device with light_switch_server_nrf52832_xxAA_s132_6.1.0_merged.hex from SDK for Mesh v3.1.0 using the nRF Mesh iOS app.

Attach is a pcap file that shows this behavior. Compare the time between packet 155 and 156, there is a delay of 10 seconds.

From the Mesh Profile v1.0.1, section 7.2.2.2.3 "Advertising with Node Identity"

"If PB-GATT is supported and Mesh Proxy Service is exposed, immediately after provisioning is completed
using PB-GATT (see Section 5.2.2), the Mesh Proxy Service shall start advertising with Node Identity
using the provisioned network."

provision_light_switch_server.pcapng

Thanks.

[Bjørn Kvaale]

We are aware of this bug in the mesh sdk v3.1.0. I will let you know when we find a workaround or fix.

For now, it can be a good idea to decrease the connection interval in the FW code to min & max values of 30 ms to 60 ms for example (see MIN_CONN_INTERVAL & MAX_CONN_INTERVAL) in nrf_mesh_config_examples.h.

Beware however, that the mesh stack shares the timeslot with the softdevice (softdevice is used for the GATT connection). By setting the connection interval so low, you will achieve quicker identification & provisioning times, but you will also make the GATT communication use up more of the timeslot. This leaves less time for the mesh stack to operate, which limits the amount of time the proxy node connected to the phone is able to communicate with the mesh network. Therefore, you can expect less throughput between the proxy node & the nodes it is connected to.

You will need to figure out a good balance of communication speed between the phone & the proxy node vs. the proxy node & the mesh network by testing different values for min & max connection intervals.

[JonasJ]

Thanks.

That would speed things up once the connection is established, but the 10 second delay would still be there regardless of the connection interval parameters, right?

[Bjørn Kvaale]

Yes, the 10 second delay will still be there.

[Hung Bui]

Hi, 

Just an update for the case, we found a bug in our SDK v3.1 that caused the issue.

If you add scanner_disable(); inside nrf_mesh_disable() function, it would reduce the provisioning time.

It was an issue that disabling mesh was not immediately disable the timeslot but wait until it's finished. With scanner_disable we can terminate the session right away and reduce the provisioning time (when switching from provisioning to configuration). 

[JonasJ]

Thanks.

I've verified it and the delay is below 1 second now.