Metropolix External Clock Issues

I’ve recently bought the Metropolix and find it wiggling the displayed clock a bit when being clocked by Pamela’s output.

It’s around .3 bpm so I can’t hear the difference, but it’s doing it constantly.

Haven’t had time to check it with other clocking sources, buts it’s annoying a bit. What can be done about it?

I think the idea is that it’s an analog clock and thus Metropolix is constantly taking an estimated reading of the timing. In theory, an analog clock can’t be as “perfect” as a digital clock in any circumstance (nor can a digital estimated reading be), so I don’t think this suggests that anything is wrong. Mine used to do the same thing when I clocked with Pam’s but more like 0.1.

Be on the lookout: I started noticing timing errors when Pam’s was the primary, so I made Mx the primary and that fixed it. It would happen after both were running for a long time, like maybe 5-10 minutes straight.

Well, when Mx is primary Pam’s respond to it as a perfect clock, but I am sure I’ve just watched the Q&A video that explicitly states that the Mx clock is digital and uses internal 384 pulses to calculate ratchets and slide times.

If it’s just the display flickering it’s ok, but it’s the clock - then there will be trouble with the internal stuff going on

First, there is no analog clock in either of these modules.

The Metropolix clock is interrupt driven, meaning that when Metropolix receives a pulse on the clock input, it handles the clock IMMEDIATELY. If you plot this on a high res scope, you will see that it’s rock solid. Both the Internal and External Clock response on Metropolix have very tight internal timing.

This could be jitter with your source clock, Try using an analog LFO (low Hz square wave) to clock the Metropolix and see how the display reacts. Sometime there is just a but of jitter on the display, due to the nature of calculating it based on very short time intervals. But remember that ever clock pulse that comes in is handled immediately.

2 Likes

Thanks for clarifying, I was theorizing that the clock output of Pam’s and input of Metropolix is analog and thus can’t be as precise as a clock that was digital start to finish, maybe that’s the wrong idea.

That’s an interesting idea, to try using a different source than Pam’s to send Metropolix clock and see if there is any decimal fluctuation in the clock. I’ve read people saying that Pam’s isn’t exactly the most solid clock being made.

But Pam’s doesn’t round to a decimal, it always displays an integer value for its BPM, right? So you wouldn’t know if its estimates were fluctuating slightly…?

Thank you for clarification.
I guess if the Mx clock receives a pulse on every external clock tick and calculates everything without trouble AND I have been ok with that specific external clock jitter in my system with other modules for some time, then I just won’t be looking at the BPM display for too long :slight_smile: