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

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

JonasJ — Sun, 28 Apr 2019 18:55:00 GMT

Thanks, this worked as expected.

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

Bjørn Kvaale — Thu, 25 Apr 2019 12:36:37 GMT

It seems this workaround was slightly unstable, as figured out internally & thanks to JonasJ in this case! We have a new workaround. In the bearer_handler.c file found under mesh/bearer/src/bearer_handler.c, you can make these changes inside the bearer_handler_stop() function:

--- a/mesh/bearer/src/bearer_handler.c
+++ b/mesh/bearer/src/bearer_handler.c
@@ -319,10 +319,14 @@ uint32_t bearer_handler_stop(bearer_handler_stopped_cb_t cb)
         /* Will stop the timeslot when the current action ends. */
         m_stopped_callback = cb;
         m_stopped = true;
-        if (timeslot_session_is_active())
+        if (timeslot_is_in_ts())
         {
             timeslot_trigger();
         }
+        else if (timeslot_session_is_active())
+        {
+            timeslot_stop();
+        }
         else
         {
             notify_stop();

Update: As can be seen in this case, one should also replace action_switch() in bearer_handler_timer_irq_handler() with this code:

 if (m_stopped)
        {
            timeslot_stop();
        }
        else
        {
            action_switch();
        }

This ensures that the 10 second delay works in both PB-ADV & PB-GATT. Without this extra code, the 10 second delay is still present in PB-ADV.

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

JonasJ — Wed, 06 Mar 2019 20:14:56 GMT

Thanks.

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

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

Hung Bui — Wed, 06 Mar 2019 15:37:56 GMT

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

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

Bjørn Kvaale — Fri, 01 Mar 2019 08:22:26 GMT

Yes, the 10 second delay will still be there.

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

JonasJ — Wed, 27 Feb 2019 19:28:56 GMT

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?

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

Bjørn Kvaale — Mon, 25 Feb 2019 15:03:18 GMT

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.