Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

accurate timestamping 6608 counter intervals with gps irig-b

Solved!
Go to solution

We have a 6608 timer/counter that forms the basis of an astronomical photometer. We have TTL signals coming in on five channels, and have an IRIG-B gps clock. After much help from NI, we now have loops that have precisely timed durations (our "integration times"). The problem is our GPS time stamping. While we have a GPS timestamp for each of these "integration times", the actual times of these events (which, if the integration time was 1s should increment a second at a time) wander around by +/-0.75s. We just cannot figure out how to get this timestamp to reflect reality. The loops bang out the (correct) counts every second, but the clock cannot keep up (though it sometimes does for a few integrations in a row). We need someone to associate the exact start of an integration period with an exact clock time (we understand there are harware limitations at the ms level).

 

cheers,

tom harrison

0 Kudos
Message 1 of 5
(5,828 Views)
Solution
Accepted by topic author harrison1261

Hi, Tom Harrison.

 

There is a KnowledgeBase article that presents a solution to this exact issue:  PXI-6608 Not Recognizing IRIG-B Signals For GPS Time

 

Things to check:

(1)  Make sure your IRIG-B signal is the "DC Level" type.

(2)  Make sure your IRIG-B signal is compatible with the PXI-6608.

(3)  Make sure to attach the synchronization signal to the synchronization line of the real-time clock.

 

For more information on GPS-based synchronization with the 6008, read through this KnowledgeBase.

 

I hope you're having a great day!

Regards,

Sara Lewandroski
Applications Engineer | National Instruments
0 Kudos
Message 2 of 5
(5,813 Views)

We know how to read the clock, as my post indicated. We have had to construct a very specific architecture to read accurate time intervals since windows finds such things abhorrant. this works. inside one of these loops we call for the gps time. this gets delivered and our "integration time" gets time stamped. but these time stamps wander all over the place (by +/-0.75 seconds for a 1 second integration). what we need is some way to get a more precise timestamping. i suspect this is related to windows not letting us have the time when we ask for it (as in our original problem where our requested integration timed loops had durations that were not what we requested due to windows housekeeping issues).

 

-tom

 

ps. i did not mean to hit "solved", as we have read that gps document many times. we are trying to find earth sized planets, and therefore need high precision timing to accurately time exoplanet transits (just one of the myriad of things we need fairly precise timing for in astronomy).

0 Kudos
Message 3 of 5
(5,799 Views)

Out of curiosity, did you take a look at the PXI-6682 for your IRIG application? If so, what made you choose the 6608?

 

Thanks, 

0 Kudos
Message 4 of 5
(5,783 Views)
four years ago when i describe to the NI folks what i wanted to do, this is the path they sent me down. i wish now that i had a linux-based or "real-time" system since all of our trouble is really do to windows and its horrible timing issues. i also wish i had a much faster CPU. but that is neither here or there, i have what i have.
0 Kudos
Message 5 of 5
(5,772 Views)