nRF Connect SDK Mesh Publishes inconsistent number of packets

[pquevedo]

Using nRF Connect SDK v1.2.0 on nRF52840 DK (PCA10056)

We are evaluating the nRF Connect SDK on the 52840 until our 5340 PDK arrives. While running the mesh light example (nrf/samples/bluetooth/mesh/light) I'm noticing the message transmit count should be 3 (that is the message is repeated 3 times on each advertising channels in succession using the same mesh sequence number). However when using an Ellisys bluetooth capture device to sniff these out i'm seeing what appears to be a random number of messages being broadcasted each time. Each publication seems to vary between 1-6 messages. Running the same hardware but using the nRF Mesh SDK (v3.1.0) I have not observed this problem. 

Its a bit unclear to me how the number of packets to be sent by the advertising bearer is even enforced. It looks it just turns on advertising for a bit, goes to sleep and then turns it off (zephyr/subsys/bluetooth/mesh/adv.c::adv_thread). The calculation of the advertising duration isn't really clear and kinda looks like its advertising for too long. For 3 transmissions at a 20msec interval its using a duration of 120msec according to the logs. 

[Joakim Jakobsen]

Hi.

That sounds strange. The node should only publish the message as many times as defined in by the number of retransmits.

I will try to test the example and see if I can reproduce this.

Have you made any changes to the example?

Best regards,
Joakim

[pquevedo]

I set it up for a periodic transmission, Other than that no. 

I reached out to the zephyr community via slack and a developer there gave me this response:

zephyr-developer: Hey, the advertising count mechanism is super inaccurate, I'm afraid. As you point out, it's just sleeping, and trying to account for the worst case. In the controller, the advertisements always get a randomized delay of 0-10ms added to their interval (spec requirement). Additionally, it'll account for 30ms of blocking events before the advertisements are able to start. This is the best we can do with HCI without extensions or extended advertising. The latter was recently added to the host API though, so it should be possible to improve the performance and accuracy significantly by changing to that API now, as it includes a "count" parameter

pquevedo: Thanks for the quick reply, is the move to the extended advertising api something in the works? Not sure if the Zephyr BLE controller supports that . Any idea about the nordic proprietary controller?

zephyr-developer: No one's working on the mesh part of it at the moment, I think. There's no proper support for it in the zephyr controller yet, but the nordic controller has it. Personally, I'd like to wait until the zephyr controller has it before I work on it in the mesh. Nordic's proprietary controller has a couple of other issues to iron out before it's suitable for mesh

What I've taken away from this is that the architectural choice to have the BLE Mesh Stack sit atop the BLE Host controller means its constrained to the HCI interface for communications. Therefore it doesn't use the timeslot/MPSL module to achieve the BLE Mesh timing performance currently offered by the nRF5_Mesh_SDK. I guess I'll wait to see if that changes in the future but this seems like a huge obstacle in adopting the nRF5340. Please correct me if i'm wrong as I really would like to move to that hardware platform at some point.