Causes of Clock drift and return?

[bchang32]

Hello,

I am running 'vi's that takes timestamps between two chassis running at the same frequency. I have the 10MHz backplane of one being sent to the other via a timing module to synchronize. I have a trigger from a third chassis that is sent to both to take a timestamp (it is length matched to both).

When I compare multiple timestamps between them, for some reason, I'll occasionally get a drift of a consistent nanosecond amount (52ns). Other times it'll be exact (0 time difference). Does anyone know what could be causing this behavior as well as how to fix this?

Thank you

[RTSLVU]

Maybe Windows is NOT a Real Time Operating System?

[bchang32]

I dont think thats the cause? Wouldn't that cause more than just occasional ~50 ns second delays? Wouldn't that be on the microsecond scale?

Also, we're not having it interact with Windows at all. We're having the cables go to the 6674T (one to the backplane to synchronize and the other to the flexRio). (The FlexRio takes the timestamp via an ETI before sending it to the vi, not the windows OS).

[rolfk]

10 Mhz backplane clock and 52ns difference? Sounds like a perfect half phase shift, so the trigger polarity may have been setup wrong on one side or there maybe some unintended clock inversion somehow.

[bchang32]

interesting. I will delve down deeper into this. What throws a wrench in this/complicates this is that its not constant. It occurs at certain times/luck of the draw of when I take timestamps.

[mcduff]

Just guessing, this is @kevin_price territory.

1. You have sample clocks that are synced to the 10 MHz backplane, every now and then I assume they need to re-sync to the clock, there may be some jitter involved in this.
2. Check the cable connecting the chassis, depending on its length, condition, there may be some odd degradation in the signal that leads to jitter.

mcduff

[rolfk]

---

@bchang32 wrote:

interesting. I will delve down deeper into this. What throws a wrench in this/complicates this is that its not constant. It occurs at certain times/luck of the draw of when I take timestamps.

---

That would indicate more into what mcduff mentions. Degraded/deformed clock signals that may tickle the synchronization circuitry in a wrong way. 

[bchang32 · Accepted solution]

Update: turns out it was the cable length. I was told that having mismatched cables was only picosecond delay, but dielectrics matter a lot. The rule of thumb is apparently 6 inches is 1 ns.

[rolfk]

Not sure where you got the picoseconds. 6” in 1ns is 150000 km per second which is half the light speed. Electron signals don’t move much faster than that in any conductive material. Electrons itself move even slower.

If you want < 10 ps delay difference line length need the be at most 1mm different and same impedance!

[bchang32]

The picosecond was just someone going off their head. We got the 6"/ns from https://www.edn.com/electronics-blogs/all-aboard-/4426188/Rule-of-Thumb--3-Signal-speed-on-an-interc... which seemed more accurate (granted what was the most important factor was the dielectrics).

Yup, we get a negligible delay with our new setup of length matched cables. We're at 200MHz so we only have 5 ns resolution anyway.