1
\$\begingroup\$

I need to oversample the encoder input. Currently the single channel resolution is 2500 pulse/rev, thus combined channel resolution is 5000 pulse/rev. I need more or less 10 times higher resolution.

I've configured TIM1 as the quadrature encoder input, so I think I have no control on that peripheral. What I can think of is that another timer can be dynamically configured to give 10 nearly equal time based interrupts between two physical encoder interrupts. If the dynamic timer can't give 10 pulses (because of a possible acceleration), then it might give rest of the interrupts immediately and reconfigure it's period accordingly.

Is there an easy way (known library/configuration) for that purpose?

\$\endgroup\$
6
  • \$\begingroup\$ That sounds like an XY problem, you're trying to implement a PLL to multiply the frequency by 10, what is the goal that requires this? \$\endgroup\$
    – bobflux
    Commented Jun 5, 2021 at 9:28
  • \$\begingroup\$ Correct, it's a PLL implementation after all. However, XY problem determination does not quite fit the question. Oversampling is offered by commercial products, so it's a well known necessity. Here is what I've found on the internet, which is quite different from my case but perfectly explains the usecase. \$\endgroup\$
    – ceremcem
    Commented Jun 5, 2021 at 10:03
  • \$\begingroup\$ How will oversampling help if you are already generating an interrupt on the encoder output pulse when it changes state? Maybe you aren't? Maybe you should? \$\endgroup\$
    – Andy aka
    Commented Jun 5, 2021 at 10:07
  • 1
    \$\begingroup\$ If you need 50000 ppr and your encoder is only giving you 5000, there's nothing you can do after the fact to fix it -- the information is already gone. You need a different encoder. \$\endgroup\$
    – Dave Tweed
    Commented Jun 5, 2021 at 10:21
  • \$\begingroup\$ @Andyaka What I thought is a kind of combination of two: The helper timer will generate 10 interrupts per physical pulse and physical pulse interrupt will be used to check that value. For example, our timer is misconfigured and generated 8 pulses until then. In the physical pulse interrupt, we'll call the helper timer interrupt handler 2 times manually. \$\endgroup\$
    – ceremcem
    Commented Jun 5, 2021 at 10:22

1 Answer 1

Reset to default
1
\$\begingroup\$

It's possible to configure a timer in input capture mode to measure the frequency of the encoder pulses, which allows determination of speed. Of course, if the acceleration isn't zero, then you get measurement errors. Some kind of algorithm may predict the acceleration and compensate the speed measurement errors. The success depends on the fitness of your algorithm to the dynamics of your system.

In addition to frequency measurement, some other logic must also determine the direction of rotation. Maybe another timer in encoder mode, or some external logic circuit can be used.

Position measurement is even harder. Between the pulses (call it the silent time), you also need a good prediction for speed. This may be relatively easy when you have constant speed, but gets more and more complicated if your speed & acceleration aren't constant.

If your encoder isn't continuously rotating (if the speed becomes zero), I can't imagine a way to over-sample the position, as you are always in the silent time. If you have a good mathematical model of your system, maybe you can make some predictions.

But after some point, the problem becomes a system dynamics & control theory problem. As your accuracy depends of the performance of your prediction algorithms, I doubt that you can rely on that additional resolution you think you will achieve. If there is too much uncertainty in those predicted/over-sampled bits, it means you don't actually have them.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Some automotive microcontrollers have this feature built into their timers. They don't so much multiply the resolution but you tell it to estimate a point based on time between two hardware events. If we assume shaft rp/m of 12000 which equates to 200Hz. You want to divide the period by 50000 which equates to 10MHz or 100ns. Even for a reasonably fast microcontroller, that doesn't leave much time to compute the timer value. Assuming a 100MHz cpu, that's 10 instructions if you're lucky. Having hardware assist makes it much easier to achieve. \$\endgroup\$
    – Kartman
    Commented Jun 5, 2021 at 10:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.