This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Can we implment PWM Analyzer on SDK 11?

I need to implement a PWM analyzer. I looked at the example in SDK 6 and it's fairly easy to follow. When I tried it, it doesn't look like GPIOTE handler gets called frequently enough. Is there a better recommendation to calculate duty cycle other than using GPIOTE that will do a good job sensing the rise and drop?

Parents
  • The peripherals use a 16 MHz clock, which is a limiting factor when measurements are performed using PPI. Using GPIOTE and a timer connected via PPI as the pwm_analyzer example in SDK 6 is a sensible way of doing the measurements. You can also use a comparator instead of GPIOTE.

    If the frequency of the PWM signal you are analyzing is too high compared to what you are measuring with, you could consider low pass filtering the PWM signal and using the ADC. This will have a few disadvantages, though. It will require an external RC filter and will have lower accuracy.

    A few questions:

    • What is the maximum frequency of the PWM signal you need to analyze?
    • Are you using nRF52 or nRF51?
  • Yes, there should be a timer. You will use the timer and GPIOTE (or COMP) and connect them together using PPI.

    With a frequency of 25 kHz it should not be a problem to time two consecutive transitions. However you may not be able to do so if your interrupt routine cannot run fast enough, which may be the case if there are other higher priority interrupts executing at the same time. Given that you will have enough time most of the time you could probably take a few measurements close in time and process them, to see if the measurement is bogus or valid.

Reply
  • Yes, there should be a timer. You will use the timer and GPIOTE (or COMP) and connect them together using PPI.

    With a frequency of 25 kHz it should not be a problem to time two consecutive transitions. However you may not be able to do so if your interrupt routine cannot run fast enough, which may be the case if there are other higher priority interrupts executing at the same time. Given that you will have enough time most of the time you could probably take a few measurements close in time and process them, to see if the measurement is bogus or valid.

Children
No Data
Related