MPSL and Timers: Energy Consumption, Accuracy and Calibration

[Omid]

Hello my friends,

I have been developing applications using MPSL and timers and PPI for time-sensitive tasks like synchronized radio communication.

Now, I have a few questions regarding the timer options available and their pros and cons.

1. As far as I know, assuming that the interrupts are enabled, the MPSL can only return interrupts for TIMER0. I know that I can configure the TIMER instances, but I am not sure if the MPSL will operate using my configured TIMER0, or all the configs will be override once MPSL is initiated (or softdevice).

2. I suppose that TIMER0 is a power-hungry timer, and I am wondering if configuring it into lower frequency like 32KHz range (if possible) would make it an energy efficient timer like the RTC or the kernel timer?

3. I know that I can configure TIMER1. If TIMER0 is not accessible, I am wondering if configuring TIMER1 into a lower frequency like 32KHz range  would make it an energy efficient timer like the RTC or the kernel timer?

4. Is it possible to get MPSL timer callback from other timers? Let's say the RTC timer?

5. I have seen that the energy-efficient timers like RTC can be calibrated to improve on their accuracy; for this, should I just do a configuration setup in the project configuration or I need to develop a code for. If it is just a configuration set up, could you tell me what recent Kconfig I need to use? I have found "NRF_SDH_CLOCK_LF_RC_CTIV". 

6. In general, is using MPSL a good idea to implement energy efficient proprietary communication protocols? or it introduces significant energy consumption? I mean is there a significant extra energy cost just because of using the MPSL and requesting time slots, considering that I reset the timers, radio, PPI peripherals immediately after they are done with the tasks.

7. Does Zephyr RTOS k_work and k_timer work based on the RTC timer? If we do calibration, if it is going to affect the kernel timing?

---

Assume that I need to get the MPSL callbacks, and therefore I am enabling the interrupts in the above cases!

[Elfving]

Hello Blue, 

That was quite the barrage of questions :) I'll get back to you once I get my answers ready.

Regards,

Elfving

[Hung Bui]

Hi Blue, 

I'm taking over the ticket from Håkon and will try to answer your questions here: 

1. As far as I know, assuming that the interrupts are enabled, the MPSL can only return interrupts for TIMER0. I know that I can configure the TIMER instances, but I am not sure if the MPSL will operate using my configured TIMER0, or all the configs will be override once MPSL is initiated (or softdevice).

1. It's mentioned in the documentation : 
the application is granted access to the TIMER0 peripheral for the length of the timeslot. This timer is started from zero at the start of the timeslot and is configured to run at 1 MHz. The recommended practice is to set up a timer interrupt that expires before the timeslot expires, with enough time left for the timeslot to do any clean-up actions before the timeslot ends. Such a timer interrupt can also be used to request an extension of the timeslot, but there must still be enough time to clean up if the extension is not granted.

So the MPSL will configure and start TIMER0 before handling to the application at the beginning of a new timeslot. It's up to the application to choose what to do with it, but the recommended practice is mentioned above. The MPSL expect that you clean up before the timeslot is over, meaning you need to disable the interrupt and clear the event if you already setup the TIMER0 CC interrupt. If you change the configuration of TIMER0, you may want to return it like when it is a the start of the Timeslot before the Timeslot is over.

You are free to use other TIMER if you need as they not handled by MPSL. 

2. I suppose that TIMER0 is a power-hungry timer, and I am wondering if configuring it into lower frequency like 32KHz range (if possible) would make it an energy efficient timer like the RTC or the kernel timer?

No, it's not possible. TIMER0 will always use HFCLK as the clock source and that will draw high current. But normally inside a timeslot, you will do radio activity and that would require HFCLK anyway. You should exit the timeslot when there is no radio activity. There is an option to turn off TIMER0 and use RTC to keep track of the time to know when the timeslot expires. But as I said, normally inside a timeslot you would do radio activity and that requires HFCLK. 

3. I know that I can configure TIMER1. If TIMER0 is not accessible, I am wondering if configuring TIMER1 into a lower frequency like 32KHz range  would make it an energy efficient timer like the RTC or the kernel timer?

Same as 2. If you want to save power don't use TIMER, user RTC. 

4. Is it possible to get MPSL timer callback from other timers? Let's say the RTC timer?

No, the MPSL doesn't have this option. 

5. I have seen that the energy-efficient timers like RTC can be calibrated to improve on their accuracy; for this, should I just do a configuration setup in the project configuration or I need to develop a code for. If it is just a configuration set up, could you tell me what recent Kconfig I need to use? I have found "NRF_SDH_CLOCK_LF_RC_CTIV". 

You should use CONFIG_CLOCK_CONTROL_* configuration, please take a look at this ticket:  nrf52840 RC Oscillator | k_uptime_get() | Time drift issue 

6. In general, is using MPSL a good idea to implement energy efficient proprietary communication protocols? or it introduces significant energy consumption? I mean is there a significant extra energy cost just because of using the MPSL and requesting time slots, considering that I reset the timers, radio, PPI peripherals immediately after they are done with the tasks.

Please explain to us what you are planning to do with the MPSL ? If configure correctly I don't see any extra current compare to when you run the protocols separately. The trick here is to only request the timeslot for the period of time that you need it. Then exit timeslot and let MPSL schedule the next timeslot. This way the majority of the time there is only a RTC (that the MPSL uses for scheduling) running. 

7. Does Zephyr RTOS k_work and k_timer work based on the RTC timer? If we do calibration, if it is going to affect the kernel timing?

Yes they run on RTC1. You can find some info here:  Zephyr & RTC  Please be noted that you only calibrate the LFCLK when you are running on internal RC. If your LFCLK uses external crystal , there is no calibration. The calibration for RC is just to keep it at the accuracy of 500ppm, it doesn't make it any higher accuracy or change the timing.