Timesync and BLE mesh functionalities not working together on nRF52840-DK board

[iotracking]

Hello,

Our application is to create BLE mesh network with multiple nodes, each node is having sensor. Each node will send sensor value and timestamp over the mesh network and there is a mobile application connected with one destination node which is collecting all information for further analysis. For timestamp, it is required to synchronized the time value in milliseconds in all the mesh nodes. So all nodes are having same timer value.

nRF Connect SDK version: v2.2.0

Hardware: nRF52840-DK Evaluation board

For BLE mesh, we are taking reference of ble_peripheral_lbs_coex example (available in samples\bluetooth\mesh\). It is working fine with multiple nodes in standalone.

To synchronize the time, we are using Timesync example same as mentioned in one of the post ( Wireless timer synchronization among nRF5 devices ). It is working fine with multiple nodes in standalone. 

Now, as per our requirement we need both as single application so we integrate time sync code into BLE mesh example code and compiled successfully. After integration, we are observing MPSL_TIMESLOT_SIGNAL_BLOCKED message continuously on serial terminal and time synchronization is not working. During this, mesh packet is able to transmit and receive on the mesh nodes.

We increased BLE mesh scan interval from 30 ms to 2000 ms. After this, Timesync is started working but BLE mesh stopped working.

Is there any way to work both functionalities(BLE mesh and Timesync) simultaneously? or is there any other way to synchronize the time(in milliseconds) on all the nodes over mesh?

It would be highly appreciated if we could get some response.

Thanks !!!

[AHaug]

Hi,

We've picked up your case and are looking into the issue, however I don't have anything constructive for you as of now (waiting for some input about the topic from the Mesh team). I will get back to you early next week if we have any existing ways or samples that integrates BLE Mesh and Timesync simultaneously

Apologies for the inconvenience

Kind regards,
Andreas 

[iotracking]

Hello Andreas,

Thanks for your response and efforts. Looking forward for your response.

Thanks !!!

[AHaug]

Hi,

I brought up the questions with the blog author and the Mesh team and this is what we landed on

1. As far as we know we don't have any official or unofficial support for how to get this to work in NCS, but it might be possible to create a priority solution based on the method in the blog post.
2. One item that might cause some issues is the question about how much the PRX (the device that listen to the time master) has be in RX. The timesync code as it is now is not optimized w.r.t. radio time. The sender does not use the radio too much, but the receiver tries to allocate as much time as possible to listening for sync packs. This will conflict with Mesh due to Mesh also wanting to be as much as possible in RX
3. With regards to the time resolution. Theoretically it should be sufficient to send one pack roughly every second to achieve 1ms sync. But this will depend on that the sync sender and receiver gets enough radio time to exchange one sync message. 

I believe this should answer your questions about getting both functionalities to work simultaneously. In short, it might be possible but we don't have any support for Mesh and timesync simultaneously in NCS out of the box

Let me know if this answers your question

Kind regards,
Andreas

[iotracking]

Hello Andreas,

Thanks for you response and detailed information. I have some queries. Please try to address them.

1) Can you point us out the code where we can see/change priority in Timesync code?
2) Same, point us out priority configuration in Mesh and Peripheral coex example code?
3) Is it feasible if we can send mesh packet and timesync packet on different RF channel?
4) Is it feasible if we can combine timesync packet with mesh interval packet which will send during mesh interval?

Thanks and Regards !!!

[AHaug]

Hi,

iotracking said:

1) Can you point us out the code where we can see/change priority in Timesync code?

Timeslot priority is set here:

1. https://github.com/nordic-auko/nRF5-ble-timesync-demo/blob/master/ncs/timesync_sample/src/timesync/time_sync.c#L146
2. https://github.com/nordic-auko/nRF5-ble-timesync-demo/blob/master/ncs/timesync_sample/src/timesync/time_sync.c#L158

iotracking said:

2) Same, point us out priority configuration in Mesh and Peripheral coex example code?

It's a bit different w.r.t priority In NCS when you combine BLe and Bluetooth Mesh. The two runs in parallell, i.e you set up Mesh, and then you set up the advertising/connection/whatever you intend to use BLE for, and then it becomes scheduled so that Mesh is used whenever there is "surplus radio capacity" for Mesh

With the two latest versions of NCS it is (to my understanding) set up such that scanning uses the free, available radio time in between other activity, so you will get close to 100% radio usage when you combine Mesh with BLE.

I would recommend you to have a look at  developer.nordicsemi.com/.../scheduling.html for the full documentation for how the SoftDevice Controller does its priority and scheduling

iotracking said:

3) Is it feasible if we can send mesh packet and timesync packet on different RF channel?

When a timeslot is granted, you can use the radio however you wish within that timeslot. That includes using different frequencies.

iotracking said:

4) Is it feasible if we can combine timesync packet with mesh interval packet which will send during mesh interval?

I'm not quite sure if I understand 100% what you want to do which leads you to ask this question, but if the motivation is to put something proprietary on top of the existing Mesh traffic, then the answer is no. By doing so you will break the qualification that the Mesh stack in NCS has, and you can't "expand on it" by adding another feature. In addition there are no general "timing" in Mesh, so you would not be able to time it so that you can fit within an interval or.

We would recommend you to choose a frequency for sync messages and let the Mesh stack get the rest of the time. A guesstimation for for how much time you could give the timesync part of the application is around 10% of the time. Do note with a disclaimer that you might find better results with other windows, but the I believe that 90% of the time available  should be sufficient for the Mesh stack.

Let me know if this answers your questions,

Kind regards,
Andreas

[iotracking]

Hello Andreas,

Thanks for your detailed response. We are working on it.

Thanks & Regards !!!

[AHaug]

Happy to help! 

Let me know if it works out for you

Kind regards,
Andreas

[iotracking]

Hello Andreas,

We have integrated all 3 functionalities, Time Synchronization + node communication over BLE Mesh + BLE peripheral, and tested with 5 nrf52840 DK boards on the field. We have tuned the BLE scan and advertisement interval for all 3 functionalities and it started working. Now, we observed some of the limitations during so much testing on the field, mentioned below. We tested with 5 DK boards; the distance between each node is 10 meters.

1. Time synchronization takes random time to get synchronized with all 5 nodes. As per our testing, we observed a minimum time of approx. 1 minute and a maximum time of approx. 5 minutes. Maximum time can be beyond 5 minutes. This is not acceptable in our case.

2. Sometimes mesh packet takes more time to travel from 1st node to 5th node.

To overcome these limitations, we are thinking of 2 different solutions and we need your suggestions.

1. Run BLE and Zigbee concurrently on the nRF52840 chipset. Time synchronization and BLE peripheral will be run on BLE and node communication will be run on Zigbee. We know that Radio is going to share between 2 protocols but we feel that Zigbee will be active only during node communication, not like BLE mesh.

2. Run the BLE stack on the nRF52840 chipset and run the Zigbee stack separately on another nRF52840 chipset. In this case, 2 chipsets are required on a single system.

We prefer to go with solution number 1. Please share your thoughts.

Looking forward to your response.

Thanks & Regards !!!