# measure with scope 2 signals from independent systems

I have 2 independent boards which output a signal ('signal A') to a main computer . Each board has its own oscillator. Each board does not 'know' of the other board existence. Both boards receive as input some data signal, from which they produce 'signal A'. Signal A should be sync to each other (in some kind of error I want to check).

I want to compare this signal A in both boards and verify its sync. While measuring using the scope, both signals has jitters and are very 'jumpy'. I'm using each board gnd for the probe gnd so the measurement should be ok. I'm using one of the signals as trigger.

I was thinking maybe the problem is with the measuring itself, as I do not have a common reference signal (trigger signal) to measure both signals in reference to it and both boards are actually dependent sub-systems in my whole system.

Am I right?

Any ideas?

• Does your scope have an internal trigger you can use? This may help. Commented Jul 23, 2017 at 14:41
• So many issues you are not describing: 1) Old/new scope: Older scopes have only 1 trace and display 2 signals either by alternating between them or by "chop" mode. 2) Grounding: Any system needs to have common grounds. Else you need to take extraordinary measures such as optical isolators. 3) Ground loops: Every system is susceptible to ground loops. Especially systems that are spatially spread out and / or use power from different sources. 4)Jitter:Any finite state machine (processor, computer, logic) independently clocked will introduce jitter with respect to another finite state machine. Commented Jul 23, 2017 at 15:33

You say that both boards A and B get a common data signal from which they are both able to generate the output SYNC signal. You have to think carefully about the process of how the boards derive the sync signal from the data signal. If that derivation process is in any way done with the local oscillator on the board as a base reference then you will have jitter between the SYNCs from the two boards.

The reason for the jitter is that the the oscillator on one board will have at a minimum one clock cycle of uncertainty (could be many more) of how the sampling of the data signal is done to how the SYNC can be generated. In addition the two oscillators will most certainly be out of phase and slightly different frequency. This adds to the sampling jitter as mentioned in the previous sentence.

If the data signal decoding and SYNC signal generation was not at all dependent on the oscillator then there is much greater chance that the two SYNCs would be more in line with each other. But there is highly likely for there to still be jitter due to the variations of circuit delays and voltage thresholds in the two separate boards. Even things like variation in the power supply voltage in one board can shift circuit delays and thresholds.

Most systems are much more complex than looking at just the effect of a single oscillator clock. If the "data signal" is fed into an MCU and software is involved in the detection of the data and the subsequent generation of the SYNC signal then the jitter may be even more pronounced due to factors related to code fetch caching, software loop times and interrupt latencies.

If it is required that the SYNC outputs be in very close synchronization there needs to very careful evaluation of the design techniques used. If the oscillators have to be a fundamental part of the system at each board then it is normal to need to use a PLL technology the lock the oscillator to frequency characteristic of the input data signal. This can remove the uncertainty due to differences in oscillator phase and frequency provided the data signal has sufficient preamble built into it to cover the PLL sync and lock times.

In addition you would try to find ways to eliminate gross jitter caused by using software to decode and generate signals. Instead use as simple of analog and digital circuits that are purpose designed to assure deterministic behavior in the data decoding and sync generation process.

This is all a high level overview of the problem. There are many complex and detailed techniques that engineers have devised over the years to eliminate or work around jitter (i.e. non deterministic behavior). It is even possible to have MCU software involved in such algorithms with very careful design. But with that said these days it would be more typical to see FPGAs used for such designs where ample parallel logic can be deployed to perform the digital task and many such parts contain sophisticated DPLLs that can provide good clocking synchronization.

• Thank you very much for your through answer. Indeed, I'm using FPGA with local oscillator on board (and internal PLL in the FPGA) to sample the input data signal and produce a sync signal. BUT, this sync signal is in charge of outputting data from each boards. Both data should be time aligned. I'm trying to find the timing error in alignment, that is why I've used a scope to measure the difference between the sync signals. Is my measuring method correct do you think? Commented Jul 23, 2017 at 17:05
• Furthermore, what do you mean by 'a minimum one clock cycle of uncertainty of how the sampling of the data signal is done to how the SYNC can be generated' ? I do not understand. Both local clocks have 50ppm diversion, so I guess the worst can be 100ppm between boards. Isn't it? Commented Jul 24, 2017 at 6:48
• @roy.me - The one clock of minimum uncertainty that I speak of is the synchronization of the input data message to the OSC that creates the clock that samples the message. The one clock minimum would come into play when the message decode to SYNC output generation was a simple logic state machine design that was clocked directly by the OSC frequency. It could be many more OSC clocks if the circuit has divided clocks, multistage flip-flops iin the decoder or if the data message decode pattern was more complex time wise that one sample period time. Commented Jul 24, 2017 at 15:40
• (adding to above) The sampling uncertainty and/or latency in the circuit of the board is a separate issue from the actual frequency and phase error of the OSC signals of the two boards. These latter add to the total jitter that you can expect to see between the two boards. [[Note]]. I see no issue with your measuring methods but you would probably want to ensure that both of the "boards" share a good low impedance GND connection between them so that the scope probes to the two systems are not making that common GND connection. Commented Jul 24, 2017 at 15:47
• (continued from above) Comparing the jitter of the syncs should include adding additional signal traces from one end or the other so you can begin to gain insight as to what behavior of your circuit contributes to the jitter. One obvious starting point is to add the OSC signal to see how it varies against the sync signal that you are triggering the scope upon. Commented Jul 24, 2017 at 15:51