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

[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

[einar]

Hi

Yes I can confirm that input is more difficult than output. The DALI driver we are working with is monitoring incoming DALI bus activity through gpio callbacks (the bus is fairly slow btw at 2400 bps), saving this in a buffer. The function we have to run at least every 5ms then forwards this to the main function.

Personally I don't think it is critical to miss one or two of these 5ms function calls, maybe the other function that should be called every 10ms might be more critical as it has to do with the timing of the bus interface. The documentation of the DALI driver on the other hand states very clearly that these timing criteria have to be met, and that the driver must have the highest priority in the system. So if we want to do our best to meet these criteria using the timeslot API, how would we best approach that?

And maybe more important, how busy should we expect the cpu to be with mesh? Both regarding overall cpu usage and the size of single timeslots.

-Einar

[PaKa]

have you considered using the ADC with easydma to sample the pin on the 5ms rate? That would give you all the input data without having to use the CPU in timing critical parts at all. Will use more RAM of course and you can't toggle output pins in the read loop though. I have never looked at DALI but I know the ADC option has been used for sampling input sequences by others.

[einar]

Hi PaKa, thanks for the suggestion!

We have actually considered this as an option yes, but I doubt this would be compatible with the driver we are working with, so this would mean writing our own driver from scratch.