Measuring speed with Input Capture Mode [STM32 & CubeMx] - Page 1
Forum section: electronics / general

author: XaviPacheco
author_rank: Regular Contributor
timestamp: September 23, 2018, 05:32:27 am
content: I'm trying to measure low speeds with a 1 PPR (pulse per revolution) sensor. For low PPRs, using the Period Measurement Method is suggested. If I get the period of the signal, then I can apply the formula:RPM = 6000/(Pulse Period)This is what I have:In CubeMx I've set Timer 2, Channel 3 Input Capture Mode. My APB2 frequency is 1 MHz. The TIM2 prescaler is 1000 and the counter period is 10000. Everytime a pulse is given, a falling edge occurs.Now, in the code I have:void HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef *htim){if(htim->Instance == TIM2){inputCaptureVal = __HAL_TIM_GetCounter(htim);__HAL_TIM_SetCounter(htim,0);}}I'm pretty new using the Input Capture Mode, so I'm not sure of this. Does __HAL_TIM_GetCounter(htim) actually tell the period of the input signal? So I can simply say RPM = 6000/inputCaptureVal?

author: Kleinstein
author_rank: Super Contributor
timestamp: September 23, 2018, 09:24:02 am
content: The input capture gives you a time stamp, like getting a picture of a clock taken at the input capture event. This can be time from starting the timer, but this can add uncertainties from the start process.So to get the period one usually uses the difference in time between 2 adjacent time stamps, with timer continuously running. Here is usually gets simpler when the timer runs all the way to a 16 bit or 32 bit boundary - this makes including possible timer overflows easier by using the way an overflow with unsigned numbers is handled in C.

author: Rerouter
author_rank: Super Contributor
timestamp: September 23, 2018, 10:26:48 am
content: I've not used an STM32 yet, but I'll take a shot that the peripherals work pretty much the same.The simplest way is to measure the difference between 2 timestamps, and have an interrupt fire when the timer overflows so you can add that to your difference count. This way your safe from rollovers, Equally when I last approached this, I also built in a timeout feature to discard under certain speed,

author: dgtl
author_rank: Regular Contributor
timestamp: September 23, 2018, 01:47:25 pm
content: RPM = 6000/period => RPM/60 = 100/period => 100 pulses per round.Now everything depends on what speed the thing is spinning, that you are measuring.1) there are 2 solutions, depending on your pulse rate. For fast signals, set up the timer as pulse counter. The timer is just clocked from your external signal and counts the edges. Then set up another timer to give IRQs; in those IRQs read out the counter value and subtract the last one. This is your pulses-per-timer-interval. This solution inherently averages the periods, so you may get better precision and less jitter without extra filtering. But the other timer IRQ must be much slower to make any sense.The other solution is what you tried - set up one timer and have it capture the timer value on pulse edge. You also need to enable the capture interrupt to get IRQ when capture happens. In every irq read out the captured value from capture register (not timer counter register!) and subtract the last value read in earlier interrupt. For this thing to work, you need much faster timer rate than your measured signal.2) you do not have to handle the rollover when you are using the same unsigned data type for all variables used in the subtraction as the timer is (ie uint16_t for 16-bit timer). The subtraction rolls over the other way when the timer has rolled over inbetween and the result is correct. This is called modular arithmetic. Do not worry about any rollovers.

author: XaviPacheco
author_rank: Regular Contributor
timestamp: September 23, 2018, 08:22:51 pm
content: What about the PWM input method where two channels are needed to capture the rising and falling edge? What are the pro/cons on using the input capture mode where just one channel is enough?