Slave 6683H to system time

[xl600]

Can the 6683H be synchronized to the PXI controller system clock?  I have a time sync mode (Fail over or while my IRIG board is slowly slewing to its proper sync state) where I use a UDP packet for incoming time but I can't find any mention of how to get the 6683H to track that.  The users manual only mentions PPS, 1588, IRIG, and freewheel as the potential modes of operation.

My first thought was to create an internal PPS using a RT loop programmed to create a digital edge once a second.  But if there's a way to just send time to the 6683H and have it track that, it'd be far simpler and wouldn't waste.

[magpie15]

What controller are you using and is it RT?

I found this tutorial that may be useful in setting up 1588 synchronization. Specifically look at note 3 of the first step if you are running a RT OS.

http://www.ni.com/tutorial/53115/en/

[xl600]

I'm not trying to use 1588.  I am simply trying to get the 6683H board time to track the RT Controller's system clock as a fail-over mode when my IRIG source is not responding.  I have three modes of operation, depending on what is happening externally with my test system.

1.  Freerun: If I have no network connections active, I slave my RT controller to my 6683H using NI-TimeSync.  The 6683H board clock is my master clock in this mode.

2.  UDP: If my time source is active (It's a custom protocol) then I receive UDP packets from that source using my RT controller network port.  I use NI-TimeSync for that too.  I then have to get the 6683H time to track the RT controller time.  The RT controller clock is my master in this mode.

3.  IRIG: If my time source IRIG is active and in fine synchronization, I switch the 6683H to that and then use NI-TimeSync to get the RT controller clock slaved to the 6683H (Like in mode 1).

The 6683H does not have a 'custom' time source capability that I can find mentioned anywhere so mode 2 is a tricky one to implement.

[luda.mattski]

Hi xl600,

I'm trying to understand the differences between scenarios 2. and 3. above.  The RT system clock is going to have noticeably more jitter than the 6683, but it sounds like you're ultimately looking to track the timing of your measurements against the system time.  Can you just set up something in the RT code to throw a timestamp on the data you are collecting in that case and use the timebase internal to the 6683?

If you could provide a little more insight into the interaction between the RT system time and the timing on the 6683 (and your measurements), I might be able to provide a better answer.  

[xl600]

I use the 6683 to timestamp signals coming in to its PFI1 and PFI2 ports as well as time stamping PXI trigger inputs.  Those cannot be timestamped using DAQmx.

I expect approx 10X more jitter in the system time than 6683 time when the 6683 is sync'd to IRIG (Typ, I see only about 5X worse jitter).

When syncing to my custom UDP, the 6683 (Using a software timed RT loop for PPS) tracks just slightly worse than the system clock which is fine for what I need to measure in that mode.

From what I'm gathering, getting the 6683 to track the system time isn't possible in any direct manner.  So I think my PPS approach is the only way to get this done.  I'm almost done coding it so I'll have a better idea of how it behaves in a full system implementation (As opposed to my prototype).

[LindsW]

Hi xl600,

You're correct that we don't have any direct way of doing this. The only way to drive the 6683(H) board time is through the 4 supported time references. So I think the PPS method you mention would work, but I imagine it will be quite jittery. Also consider that as you switch between time references you might see a snap in time. Depending on how long your IRIG signal is down for at a time, you may have better performance just allowing the 6683 to free run during that time.

[xl600]

Yes, there's certainly a snap in time (About 50ms) when I switch from my IRIG to my UDP time source.  The 6683 does eventually catch up and I'm characterizing that now.  But I do still need to take measurements and still need both 6683 and system clocks as close as possible without the IRIG source available.

So far, the PPS output from LabView RT using a RT loop is quite stable.  I have very few RT loops running so they really don't get in each other's way.  To ensure the PPS comes out in a stable fashion, I check the global start time of the PPS loop and adjust the next wake up so that it always lands near the seconds boundary.