Timing requirements for BT Mesh

[einar]

Hello Nordic supporters!

We are developing a system using BT Mesh alongside a software DALI protocol driver with certain timing requirements.

Right now we're trying to figure out how strict the timing requirements of BT Mesh are compared to normal BLE, and how they would interact with the DALI requirements. We were thinking there could be a difference since BT Mesh is advertising based and not connection based. We would appreciate some help in finding exact numbers.

For the driver we're considering, these timing requirements are given:

• One function must be called at least every 5ms by the user application and must not be blocked (e.g. through storage of persistent data).
• Another function should be called every 10ms to ensure functionality

During these function calls the driver would be doing bit-banging on the gpio, which we would like to not have interrupted by the BT part of the code.

Do you think these requirements could realistically be satisfied while running BT Mesh on an nRF52840?

Thank you in advance,

Einar

[Edvin]

Hello,

Since the nRF52840 only has one core, and the softdevice controller (Bluetooth LE stack) has top priority, there is no way to guarantee that you will be able to call your functions at exactly every 5 ms. If a packet is coming in, the Bluetooth stack will take over the CPU for some time. 

On the nRF5340, on the other hand, you will have a bit better control. All radio functionality is running on a separate core, and you can set the bitbanging priority higher than the priority for communication between the application core and the network core (radio core). 

Alternatively, the nRF54L15 also have separate cores. The BLE stack is running on the application core, pretty much like the nRF52840, but in addition, you have a separate core that is intended for stuff like this. You can use this for bitbanging, and this core will not be interrupted at all. You can set it up to only report the results from the bitbanging to the application core. 

Best regards,

Edvin

[einar]

Hi Edvin!

Yes, we are aware of the differences between nRF52 / 53 / 54, but we are more interested in the timing requirements of BT Mesh vs BLE.

We were hoping that the timing would be more lenient in mesh, since the communication happens through the advertising bearer, so you don't have to maintain a connection. Seeing that BT Mesh is able to run alongside BLE in the Bluetooth Mesh Coexistence sample, we were optimistic that this could be possible.

But you're saying this is not the case?

We were also wondering if the Timeslot API could be an option?

-Einar

[Edvin]

Hello Einar,

einar said:

Seeing that BT Mesh is able to run alongside BLE in the Bluetooth Mesh Coexistence sample, we were optimistic that this could be possible.

That is an interesting point.

While Mesh is not that intensive, in form of a connection interval, it is also asynchronous, meaning it doesn't know when a new packet will arrive. So we can't guarantee that it will not show up in the timeslots where you want to bitbang the DALI protocol.

However, as you say, it is possible to maintain a Bluetooth LE Connection concurrently with Mesh, and that connection is very rigid. 

The way that is set up is that it uses something called timeslots, where the bluetooth controller (the non-mesh part of it) is the master. The Mesh stack then requests timeslots from the softdevice controller, in between the connection events. One would think that in theory, it would be possible to do something similar where your application, instead of the softdevice would handle similar requests. Although not trivial.

Let me discuss this with our Mesh team, hopefully tomorrow, and I will get back to you!

Best regards,

Edvin

[einar]

Hello, have you made any progress on this with the Mesh team?

Edvin said:

One would think that in theory, it would be possible to do something similar where your application, instead of the softdevice would handle similar requests.

If this could be possible it would be very helpful to our application, so we are eagerly awaiting updates!

Best regards,

Einar

[Edvin]

Hello,

Yes, sorry for the late reply. 

What exactly are you doing in your interrupts? Are you checking the current state of some GPIO(s) that updates once every 5ms? Or are you going to set the state of an output pin every 5ms? We are discussing what is possible and not, and particularly if you have some flash operations ongoing, it is difficult to maintain the 5ms interval of your interrupt. At least if it is very critical that all of these are not missed. Compared to a BLE connection, that can handle packet loss during flash operations, the entire CPU has to wait until flash operations are done before it can resume. 

So the softdevice can handle this, but I don't know whether this is the case for DALI bitbanging. What happens if you loose one or two 5ms interrupts in a row? 

And are you using these for GPIO input or output? Because output it is possible to automate, and make it run without the use of CPU, but as an input, it is more difficult. 

Best regards,

Edvin