Problems capturing a 3.5MHz signal

[derekfountain]

I have a clock signal from my retro computer (a ZX Spectrum). I'm capturing at 7MHz, and I can see the 3.5MHz clock signal looking like this:

That's spot on. :)

But scrolling along the capture a bit, it starts to miss a few cycles:

I can't see any obvious pattern or reason why it would do that.

Scrolling to another section of the capture it goes completely wrong:

It's completely lost the clock signal, and the Z80 decoding is now totally wrong.

I'm probably doing something wrong here, I've not used a logic analyser before. Has anyone got any idea what I'm doing wrong?

[gusmanb]

What you see is totally normal because you have ignored two basics on the device:

1- You must capture twice the speed of your signals if you want a good capture. The clock of the source and the clock of the analyzer can have some skew, maybe the spectrum is not running exactly at 3.5Mhz but at 3.500010, that small deviation gets accumulated during time, so it will reach a moment where the capture gets "in sync" and sees only one of the phases. And also, you must understand that is not the same the speed of a data signal than a clock, when a data signal is labeled for 3.5Mhz means that it will change 3.5 million of times per second, BUT, on a clock the signal will change two times, one for the positive phase and other for the negative, so if your clock is 3.5Mhz, taking into account both phases you get 7Mhz, so the minimum recomendable should be to capture at 14Mhz if you really care about the clock (are you checking the ULA stretching? if no, then you should ignore the clock as the spectrum's ULA will start and stop it at will, I bet you that some of those that you see is the ULA not sending a clock signal, that's the "contended memory", when the ULA accesses the RAM to produce the video output, if the Z80 tries to access the lower memory then it stops its clock for some cycles.).

2-7Mhz has jitter. The software is already warning you about it, when you select 7Mhz it tells you that there will be a 2% of jitter:

What this means? Well, the pico has a fixed clock and the PIO speed is adjusted to the one you request, but this is not 100% real, the pico under the hood divides the frequency by 2/4/8/16 and so on, and the "leftovers" of the frequency are adjusted by stretching some clocks.

So, if now you add both, you have the recipe to see exactly what you see, as you have a single sample per clock phase, and the requested frequency has jitter, it gets in sync and then you are capturing only a single phase of the clock.

Also, beware that when using the multianalyzer mode there can be a +1 sample of difference between the master and the slave analyzers, so is even more crytical to capture always twice the speed of your signals.

Capture at 14Mhz and you will be ok :)

[derekfountain]

Thanks for your reply. :)

I was mostly aware of the frequency issues you describe, but I wasn't really sure, so thanks for the explanation. I had tried capturing at 14MHz, but it seemed to make things worse. I tried again. Here's the 3.5MHz clock from that capture:

At 14MHz the signal is no longer a square wave. I have the Spectrum's clock on my oscilloscope, and it's really a saw-tooth type of signal. But I would have thought the logic analyser could do better, especially as when I scroll along a bit I see it goes way off again:

The jitter at 14MHz is about 2%. Is that bad enough to have this affect?

I tried capturing at 33,950,000Hz, which gives a jitter of about 1.1%. That gives this:

It never seems to go wrong, I don't get the big gaps in the trace I do when I use lower frequencies, so that must be good. But it's still not the square wave I'm expecting.

Am I still using the device incorrectly? What else can I try?

I'm not looking for the Spectrum's ULA contention pattern, I have made a device which plugs into the back of the Spectrum. Although it mostly works, it occasionally makes the Spectrum crash, so it's a Z80 decode I really need so I can see where it's going wrong. The pattern when the ULA stops the Z80's clock should be very obvious, but that's not what I'm seeing at the moment.

[gusmanb]

Have you checked the signal voltage? Think that you are using the analyzer with a level shifter, if you have it set to 5v and the peak signal of the clock is lower, it will not capture it properly being a sawtooth. If I recall it right the 48k clock had a 3v peak voltage, so most of the signal will be treated as a low value. You could try to set the analyzer that has the clock signal to use 3.3v as VREF instead of 5v, in theory the TXU0104 is versatile enough to handle voltages up to 6.5v even if the vref for the input is lower (never tried it, so is under your responsability :) ).

[derekfountain]

Yes, that clock voltage peaks at 3v2, so that might explain what I'm seeing. I'm not keen to change the reference and risk damaging the level shifter.

I'll mark this as the answer. Since the clock signal isn't digital, and I'm still learning, this isn't really a fair test anyway. But thanks for your help. :)