GPS Synchronization and External Clock

[NicS]

Hello everybody,

my task is to synchronize my PXI system to the GPS timebase and after that use an atomic clock (10 MHz output signal) as external CLK IN. After the first synchronization to the GPS. the GPS signal may not be available anymore, however its very important that the time base in the device does not drift significantly. For hardware there is a PXI chassis with 6682H module for GPS reception and 5653/5603/5622 combination for the measurement data acquisition available.

As I am quite new to Labview and the PXI system, it would be very kind if someone could give me some comment on the solution I have thought about and help me solve the problems I still have.

The idea would be to have to atomic clock connected to all CLK INs of the PXI at all time. For the GPS synchronization I would use the "niSync Set Time Reference" function to first set the board clock to GPS. After the self testing (the device is not being moved during the GPS sync) I would like to stop using the GPS.

After that the external atomic clock. should be used as fro the calculation of the frequency increments and determination of the relative time. I suppose if I set back the Reference time to free running, it would still use the last calculated frequency increments derived from GPS?

Is there any other solution than to set the time reference to PPS? Problem is, I only have a 10 MHz signal available.

Thank you very much for any help

[Topper_Harley]

Hi NicS,

that's a pretty ambitious project for a LabVIEW beginner that you try to accomplish. It is always a good idea to start off with examples and tutorials provided by NI and the community:

Use NI-Sync to Send a Sample Clock and Start Trigger to a DAQmx Device

https://decibel.ni.com/content/docs/DOC-3421

Leveraging NI-Sync to Synchronize DAQmx Devices

http://www.ni.com/white-paper/9308/en

Introduction to Distributed Clock Synchronization and the IEEE 1588 Precision Time Protocol

http://www.ni.com/white-paper/2822/en

To me your solution sound as if you wanted to change the synchronisation clock from GPS to your atomic clock. Using your atomic clock as sample clock and starting the acquisition with a trigger seems like an easier solution to me. The trigger would create a timestamp with your PXIe-6682H device. The timestamp provides you with a reference time an you do not have to swap clocks.

[NicS]

Hi Topper Harley,

first of all thanks for your quick and helpful reply as well as the attached links.

So if I understand you correctly, you would solve the problem like this:

Always use the atomic clock as external trigger, i.e. by connecting it to the "10 MHz REF IN" of the PCIe-1075 chassis. Is it correct, that this would overide the system clocks for all PXI subsystems then? Meaning the system clock of the PXI is completely constrained by the external 10 MHz signal and it will not drift from the atomic clock (only a constant time offset to the atomic clock exists).

Now to achieve the GPS synchronization, I would only have to get a GPS timestamp from the 6682H and log it togther with the system time. This would then give me the offset of the system time to the GPS time and allow me to correct it in the postprocessing of the measurement. Therefore for writing down the measurement data I only have rely on the PXI system and not the GPS time.

It would be great if you could give me some feedback if I understood you correctly and if the solution above described works.

Thanks!

[Topper_Harley]

Please do not confuse the terms trigger and clock. You can use your atomic clock as a reference clock. With your GPS hardware you can create a timestamp, for example when a trigger occurs.

I am sorry to not be able to give you an approval on your design as it is up to you to fully understand the matter.

Synchronization Basics

http://www.ni.com/white-paper/9652/en

[AlejandroZepeda · Accepted solution]

Hi.

When the PXI-6682 is trying to synchronize to a source (GPS, 1588, PPS), it first does a big adjustment to its timebase, to eliminate the initial offset from the source, and then does small adjustments to the clock driving the timekeeper, to keep in sync with the source.

In this case, you have a 10MHz atomic source which you trust, so you do not want/need the small adjustments, you only want to make the initial big adjustment, and then just run based on the provided 10MHz clock.

There is a way to make the PXI-6682 do this.  You will have to configure it to assume that PXI_CLK10 is good and no adjustments are necessary. There is no call in the standard NI Sync API to do this, so you will have to get the VI that configures the board to do this from the .llb used for clock disciplining (in which the PXI-6682 also does not make small adjustments to its timebase, but assumes that PXI_Clk10 is 'good').

You can get the .llb from here: http://joule.ni.com/nidu/cds/view/p/id/2318/lang/en

The VI you need is mdevClkDisc.llb\_clkDisc_niSync_advancedAttribute_set_bool.vi

Set the "niSync attribute" input to "Clk10 Disciplining Enabled" and the "value" input to TRUE, as shown in the attached image.  The offset from time reference should then be <10ns and constant.  Give that a try and let us know how it goes.

Note that once you do this, the PXI-6682 will not be able to make adjustments to its timekeeper. It will be running entirely on the provided 10MHz reference clock. Therefore, if the 10MHz clock does actually drift from GPS, there will be nothing that the 6682 can do about it.  If you do get into this situation, one thing you can do is set the time reference to free running, set the time to something that is off by say, 60 seconds, then set the time reference back to GPS.  That should get it back on track.

Hope this helps.

Alejandro

[NicS]

Thanks AlejandroZepeda,

your suggestion really solved the problem. Its a pity theres no standard call for this in the documented NI-Sync API.

Cheers,

Nic

[NicS]

Hi Alejandro,

I just ran some tests using the proposed solution, using timestamping of the atomic clocks PPS signal to check whether the PXI and the clock are synchronous. It looks like order how the two functions are called is important. First the time reference has to be set to GPS, then the mdevClkDisc.llb has to be called. If doing it that way the device reported zero drift after a night of measurements.

Just wanted to add this information if somebody else may be interested in the solution.

Thanks again for your help,

Nic

[AlejandroZepeda]

Hi.

I am surpised to read you had to do it this way.  If you sync the board to GPS first, and then make it use the non-adjustable clock, you might end up with a constant offset (no drifting) that you cannot get rid of (other than with the procedure of setting it to free running, changing the time and setting it back to GPS).

What behavior are you seeing if you set disciplined clock mode first and set GPS as the time reference second?

Alejandro

[NicS]

Thanks again for your interest in the problem.

So when I first set the time reference to GPS and afterwards enable the clock disciplining there is indeed an offset of around 100 nanoseconds (May this be somehow caused by the clock period of the 10 MHz signal?). So far I have not found a way to get rid of the offset. However the system always stays in sync with the external 10 MHz signal, the timestamps of the PPS signal of the atomic clock are always spaced exactly 1 second apart. A second indicator that the system seems to be in sync with the atomic clock, is that an long term linear drift from the GPS can be observed. Anyways, I just started wondering how important the synchronization to GPS actually is, since the offset from the system can always be observed and logged. Hence a correction of the measurement data afterwards should be quite simple.

When I switch things around, first enabling clock disciplining and then setting the time reference to GPS the initial offset to GPS is zero. However the system is not in sync with the external 10 MHz. Jumps in the order of around 100 microseconds appear.

Another question concerns the two properties “Synchronization Clk Properties -> Synchronization Clock Source”. So far I have not found any useful information about what they do. Setting them to the 10 PXI clock (which is routed to the external atomic clock) or not does not seem to make any difference.

Cheers,

Nic

[AlejandroZepeda]

Hi.

Sorry for the delay in responding. I was out of the office when you last posted, and I must have missed the notification.

The "Synchronization Clock Source" property only applies for the signal-based timing & sync boards (PXI-665x and PXIe-667x boards), and it has no effect on the PXI-6682.

I am concerned about what you observe when first enabling clk disciplining and setting the time reference to GPS second.  What is the nature of these ~100us jumps?  So, it seems to be locked and suddenly jumps by that much (rather than linearly drifting)?  Do the jumps happen periodically?  Are the jumps always in the same direction?

Regards,

Alejandro