Reading 10 MHz OCXO reference clock from PXI-6614 to externally set the reference clock of a Schroff PXIe Chassis (without timing slot)

[Witschas82]

Dear Labview-Experts,

I am rather new in working with time synchronization and hope that my question is not too stupid.

In short, I am currently developing an airborne wind lidar system that needs some time synchronization of different tasks (laser pulse trigger, scanner position, GPS PPS, etc.).

I am using a 6614 counter/timer card and a PXIe Chassis by Schroff (8 Slot). The Schroff Chassis has no timing slot but has the possibility to connect an external clock signal via BNC. Hence, I would love to use the OCXO reference clock from the 6614 to synchronize the PXIe clock. But I have no clue how I can get the clock signal (via a counter) out of the 6614. Is there any easy possibility of doing so?

In a next step, I want to produce an internal 100 kHz clock that is triggered by the PPS signal coming from the GPS module. Though I was able to generate the 100 kHz pulse train, I was not successful in triggering it with the PPS signal (that I first have to count).

If anybody has any suggestions how I could try to tackle this problem, I would be very happy to receive them. Any reply is highly appreciated. Also, to other links in the forum. I was reading a lot within the last weeks, however, I did not find something that was addressing my problems.

Thank you very much in advance and all the best,

 Benjamin

[ZYOng]

Usually it is implemented with NI-668x Timing Module. See Configuring GPS Synchronization with the NI PXI-668x Timing and Synchronization Module

[santo_13 · Accepted solution]

As you already knows, if you install 6614 in a System Timing Slot, 6614 automatically routes the OCXO to the backplane clock, but your case is challenging as you don't have that way.

As per the supported device routes, you can route the 10MHz reference clock to any of the PFI lines.

So, you can use DAQmx connect routes API to configure the card to route the 10MHz to the PFI line, then connect the PFI line to the PXI chassis 10MHz input. Note, your signal integrity may not be the best as these are not coaxial lines.

[Witschas82]

Dear Santo_13, thanks a lot for your fast and very helpful reply. The hint to the "DAQmx connect routes API" solved my problem. E.g., I routed the OCXO 10 MHz ref. clock to PFI0 (yellow line in the attached Osci picture) and directly got the clock signal that I could use to synchronize the PXIe chassis. The PXIe output clock is indicated by the orange line and is synchronized with the yellow one as it should be. When I unplugg the 10 MHz ref. clock from the PXIe, both signals are drfting in phase. So I can confirm that everything works as it should. Thank you so much.

For comparison, I used the GPS PPS signal to trigger the oscilloscope. The ref. clock jitters by about +/- 10 ns back and forth with respect to the PPS. So this is more than accurate enough for my application. 

In a next step, I would love to generate a 100 kHz clock (pulse train) using the 10 MHz ref. clock as time base and getting triggered with the PPS. Does anybody has an easy solution for that. Probably, I have to "count" the PPS with the timing card and then somehow use this signal for starting a trigger of a 100 kHz pulse train that uses the 10 MHz ref. clk. as time base. So principally, it sounds easy, but I have no clue how to say it Labview.

If it makes more sense to open a new topic, please let me know.

Thanks a lot for this for fast and great help.

All the best,

 Benjamin 

[Kevin_Price]

You can trigger off the PPS signal by making just a very few mods to the shipping example for continuous counter output.   See below

-Kevin P

[Witschas82]

Dear Kevin,

thanks a lot for your kind reply. Indeed, I implemented something similar as suggested by you:

And indeed, the very first pulses are triggered by the PPS. However, after a while, the pulses are slightly phase shifted, as the 6614 Ocxo clock is not synchronized with the PPS (which I think is also not possible). 

I made first tests, and the drift is not a lot. Maybe a few ms per hour. So I can likely live with that.

I was just wondering if it is not possible to trigger the pulse train again with every arising PPS. But I think it is not.

Anyway, thank you very much for your support and best regards,

 Benjamin 

[Kevin_Price]

No, you probably can't *directly* and reliably keep retriggering off the PPS signal.  The problem is that you're essentially going "line-to-line" with the timing requirements.  The retriggered task needs to generate exactly 100k pulses at 100 kHz (as determined by the OCXO) in exactly 1 second (as determined by the PPS).

If the OCXO runs 5 nanosec / sec faster, the 100k pulses end too soon and the first pulse of the next batch looks like a lower frequency.  (Period becomes 10.005 usec, freq ~ 99.95 kHz).  Much worse, if the OCXO runs 5 nanosec / sec slower, the 100k pulses will not yet have finished when the next PPS signal comes in.  The CO task will miss this triggering condition and you'll get no pulses at all during that second.

If you want to get really adventurous, you could measure the PPS with the OCXO and then very occasionally adjust the output frequency to correct for long-term drift effects. 

Warning!  Tweaks like this often feel really smart when you first start to implement them, then the real world steps in and kicks your simple algorithm in the nether regions and your end result is worse than the original uncorrected behavior.

Ok, caveat out of the way, here's how you could do it.  Set up a 2nd counter to do a period measurement of the PPS.  Configure it to use units of "Ticks".  Also configure it to use your 100 kHz clock as a timebase.   So now you'll be counting the # of 100 kHz cycles (as determined by your OCXO) observed within 1 second as determined by the PPS.

    Ideally, this would always be exactly 100k.  But the slight difference between the timebases will occasionally give you a different #, likely off by +/-1 from ideal.  This is your "error term" which you should accumulate.

    Now you can come up with your smart algorithm about how to react to this measured cumulative error term.  There will be some criteria you use to decide that after a certain threshold of accumulated error, you "recognize" that it's time to adjust your 100 kHz freq slightly to compensate for the discrepancy between PPS and OCXO.

It may be useful to set up a 3rd counter that performs period measurement on the PPS using the OCXO as the timebase.  This would show discrepancies from the nominal 10e6 count sooner and in finer detail which may help you fine tune your smart algorithm.

It will likely be useful for you to define your 100 kHz output using units of Ticks of the OCXO timebase.  So nominally, 50 Ticks each low & high.  But then when it's time to perform adjustments, you're already in native integer space where you can recognize that adjustments can *only* be discrete integer values of Ticks.

So there's the beginnings of a nice little theoretical idea but remember, you've also been warned about the whims of reality.

-Kevin P

[Witschas82]

Dear Kevin,

thank you so much for sharing your very advanced thoughts. I indeed tried the pulse train with finite pulses, and it happened exactly what you described. The OCXO clock is little to slow, not finished after 1 s and then, the PPS trigger is missed.

In a previous system, we used a custom-built OCXO that we could very slightly tune with a poti. With this work-around, we could make sure that the OCXO made his 100k looks before the next PPS. Such a procedure is not possible with the on-board-OCXO, right?

I may try your suggested approach, but, indeed, I am afraid of the real word problems 😉. And as mentioned above, the given accuracy might be suitable for our needs. The 9-hours test today confirmed that, in case of a free running 100 kHz, I count 154 ticks too much, which corresponds to 1.54 ms.  Considering our laser pulse rep. rate of 750 Hz, this corresponds to approximately one laser pulse per hour. For an 8-hour working day, this are about 8 laser pulses. So probably, it is not worth spending much more time on that topic.

If I do so, I will definitely post the outcome here. I am very happy to see how well the support works in this forum and would also like to contribute whenever I can.

Best regards,

Benjamin