Clock Input Tempo Detection

This is something that has stumped me for a while now.

What is the best way to go about handling “Clock Input Tempo Detection”? The goal isn’t to just advance a sequence every time a GPIO pin goes HIGH. That is easy. What I find difficult is accurately syncing an internal clock to an external one.

For example, take some analog clock signal from a separate piece of hardware (ei. +5v trig/gate) as an input into an MCU GPIO, and sync an internal clock signal to it.

There are loads and loads of open source euro modules out there that do this, but I have yet to find an explanation of the concepts for coding one yourself.

I have absolutely no idea how this is traditionally done, but here’s where I’d start researching:

yeah this has always been what I end up finding as the solution, the PLL.

I know the mutable stuff uses this approach, but I have never been able to understand the implementation in the code :grimacing:

I have been looking at some open-source modules like the 4MS SCM, and I am starting to think that just using a Timer that counts the number of ticks between two rising edges of an external clock pulse, and then just dividing that down to get a multiplication of the external clock is the best way to go… Perhaps a phased locked loop is best when you need to match the frequency of a high frequency signal? :man_shrugging:

I agree with @scottc11. Using a timer is a simple solution that should work fine.

In general, if you have a slow input to measure, you count the time between edges with the system clock. If you have a really fast input, you count edges over a fixed time interval. The hardware timers in the Daisy processor are more than capable of both operating modes, running at the system clock rate.

Then it is just a math exercise to average or interpolate the period/frequency, divide it, multiply it, phase shift it, or whatever, to compute your internal event or sequencer clock period. You can use the next incoming edge to reset or resynchronize your internal clock to the input.

I had a lot of experience with PLL’s in my previous life. I honestly can’t think of a scenario where a PLL would be a more appropriate solution, unless I don’t understand the context. Perhaps if you were trying to recover a tempo from an actual note stream, rather than a tempo signal …

If the goal is to synchronize to an external ‘beat’ or tempo I could see a PLL as a good solution, although it might be implemented in software instead of circuitry.

I’m confused as to what you are trying to do. In your initial question, you referred to an “analog clock signal” - in what sense is it analog? Are you going to read it via an AD port or just a regular old GPIO pin?

Even though I’m confused, I thought this link:
might be helpful, if only by clarifying the issues-problem. See the left hand menu item:
Beat Detection Algorithm
for more details. It’s all in Matlab. They mention 'We adapted a beat detection algorithm from the MIT Media Lab to Matlab for our project. " - I don’t know what it originally was written in.

Just linking another related thread Tep Tempo with LED

By analog I just mean some arbitrary clock signal coming from another piece of hardware which gets read by a GPIO.

I am aiming to synchronize my sequencer (controlled by an MCU) to an external clock. My sequencer has a “resolution” of 96 PPQN - so each external clock signal the MCU receives needs to be broken down into 96 sub-steps / ticks.

I want to say the beat detection stuff is perhaps overkill for this problem? Because that algorithm / approach is all about detecting peaks in a signal and then pulling out time information between each peak etc. but idk :man_shrugging: - the same math applies for sure

After doing some reading into STM32 Timers (Mastering STM32, great book) I am pretty sure that setting up a Timer in Input Capture mode will probably do the trick.

I guess you could accomplish “Input Capture” in a less fancy way by just reading the timer every time the GPIO Interrupt fires, but I wonder if there are any latency issues with this approach :thinking:.

I agree, the beat detection stuff is overkill, because you are starting with a clock signal. To my mind it’s a digital clock signal, but I’m not going to argue about that - it’s a deep-subtle difference. I think the timer approach that scottc11 suggested above could work, the PLL approach (either software or hardware) would be the ‘general solution’.