1. Topics
  2. Long-Term Bluetooth Mesh Reliability

Long-Term Bluetooth Mesh Reliability

Martin <ma@...>
 

Hi,
I am wondering if someone has already made experiments regarding the
long-term reliability of Bluetooth Mesh in Zephyr OS?

The reason why I am asking is this: I am on the latest master and I
use a Mesh setup consisting of ~10 devices (PCA10040 + PCA10059) with
an adjusted samples/boards/nrf52/mesh which additionally sends
heartbeat messages and at the same time blinks an LED (realized by a
timer that submits a work item which lights it, waits and switches it
off again). What I have been observing is the following: Devices that
only send a hertbeat message every 10 seconds run quite stable for
some days, but need to be power-cycled at some point in time (no
heartbeat messages, no LED blinking). Devices with higher load (e.g.
relay enabled, deliberately sending a higher amount of mesh messages)
are not responding within hours (no messages whatsoever, no LED
blinking). Even when taking pressure out of the mesh (not deliberately
sending messages anymore), they do not come back to life before I
power-cycle them.

Does someone possibly have an explanation for the issues I am
encountering or some tips regarding what I can try to tweak? I am
still trying to debug this issue but right now my results are not
meaningful expect that no new output appears in the serial console as
soon as the devices stop responding. On an older revision, I
presumably was hit by #12726 (paused execution and saw that next
pointer of queue was pointing to the current element), but could not
reproduce that I am still hit by it with the latest master.

Thanks,
Martin
Johan Hedberg
 

Hi Martin,

On 17 Feb 2019, at 14.07, Martin <ma@...> wrote:
I am wondering if someone has already made experiments regarding the
long-term reliability of Bluetooth Mesh in Zephyr OS?

The reason why I am asking is this: I am on the latest master and I
use a Mesh setup consisting of ~10 devices (PCA10040 + PCA10059) with
an adjusted samples/boards/nrf52/mesh which additionally sends
heartbeat messages and at the same time blinks an LED (realized by a
timer that submits a work item which lights it, waits and switches it
off again). What I have been observing is the following: Devices that
only send a hertbeat message every 10 seconds run quite stable for
some days, but need to be power-cycled at some point in time (no
heartbeat messages, no LED blinking). Devices with higher load (e.g.
relay enabled, deliberately sending a higher amount of mesh messages)
are not responding within hours (no messages whatsoever, no LED
blinking). Even when taking pressure out of the mesh (not deliberately
sending messages anymore), they do not come back to life before I
power-cycle them.

Does someone possibly have an explanation for the issues I am
encountering or some tips regarding what I can try to tweak? I am
still trying to debug this issue but right now my results are not
meaningful expect that no new output appears in the serial console as
soon as the devices stop responding. On an older revision, I
presumably was hit by #12726 (paused execution and saw that next
pointer of queue was pointing to the current element), but could not
reproduce that I am still hit by it with the latest master.
I’m not aware of any such issues (long term usage instability), at least not in the Bluetooth/Mesh code itself, however you might want to retest together with #13431 which was merged yesterday, in case the cause of your issues is a stack overflow.

Johan
Martin <ma@...>
 

Hi Johan,
thanks - that's good to know for sure. No luck unfortunately, my
device is still not responding after some time. I have set
CONFIG_DEBUG=y and from my understanding the application seems to run
into an usage fault, which is not printed on UART unfortunately. If
you are interested, I have attached myself to bug #12726 which seems
to be about the same thing.

Best,
Martin

Am So., 17. Feb. 2019 um 15:59 Uhr schrieb Hedberg, Johan
<johan.hedberg@...>:


Hi Martin,

On 17 Feb 2019, at 14.07, Martin <ma@...> wrote:
I am wondering if someone has already made experiments regarding the
long-term reliability of Bluetooth Mesh in Zephyr OS?

The reason why I am asking is this: I am on the latest master and I
use a Mesh setup consisting of ~10 devices (PCA10040 + PCA10059) with
an adjusted samples/boards/nrf52/mesh which additionally sends
heartbeat messages and at the same time blinks an LED (realized by a
timer that submits a work item which lights it, waits and switches it
off again). What I have been observing is the following: Devices that
only send a hertbeat message every 10 seconds run quite stable for
some days, but need to be power-cycled at some point in time (no
heartbeat messages, no LED blinking). Devices with higher load (e.g.
relay enabled, deliberately sending a higher amount of mesh messages)
are not responding within hours (no messages whatsoever, no LED
blinking). Even when taking pressure out of the mesh (not deliberately
sending messages anymore), they do not come back to life before I
power-cycle them.

Does someone possibly have an explanation for the issues I am
encountering or some tips regarding what I can try to tweak? I am
still trying to debug this issue but right now my results are not
meaningful expect that no new output appears in the serial console as
soon as the devices stop responding. On an older revision, I
presumably was hit by #12726 (paused execution and saw that next
pointer of queue was pointing to the current element), but could not
reproduce that I am still hit by it with the latest master.
I’m not aware of any such issues (long term usage instability), at least not in the Bluetooth/Mesh code itself, however you might want to retest together with #13431 which was merged yesterday, in case the cause of your issues is a stack overflow.

Johan
1 - 3 of 3