LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

NI6602 Set another timebase

Hey,

I'm using NI6602 Countercard to read external signales and for two of the eight channels I use two of the internal clocks (100khz and 20MHz). Now I'd like to set a better timebase (from another NI Card) to increase the accuracy of the clocks which is at the moment (100ppm pm 0.01%, see NI6602 specs, page 2)

My Questions: Is this possible and if so how do I do it?

 

NI6602 specs

 

For Configuration and Reading of the NI6602 channels I use Daqmx Channels, Read Daqmx Channel etc.

Do you need more information for helping me?

 

Best regards,

Christian

0 Kudos
Message 1 of 9
(3,609 Views)

Hi ChristianT,

 

I think all what you want is to use an external clock from another DAQ card, which has a better clock accuracy. Here is a link how you could realize this configuration:

 

http://www.ni.com/example/30009/en/

 

I hope this helps.

 

Regards Anoj

Anoj Mubarak
National Instruments
0 Kudos
Message 2 of 9
(3,560 Views)

Hello and thanks for your reply,

 

what I want to do is using the OCXO Clock from NI 6674T as an Input for the 100kHz und 20MHz Clocks from NI6602 Module. So that I got with the 6602 two Clocks 100kHz and 20MHz wiith the accuracy of the NI6674T OCXO Clock (5ppb in 24h).

 

I was hopping to archieve this with a setting in a VI or Propertynode but by know I worse if this is possible then it wont be so easy?

 

best regards

christian

 

NI 6674T Manual

0 Kudos
Message 3 of 9
(3,521 Views)

Hi Christian,

According to the NI 660X manual, the base clock accuracy of the PXI-6602 is based on PXI_Clk10.  You can overdrive PXI_Clk10 with the PXIe-6674T OCXO by routing Oscillator to PXI_Clk10_In.  Look at the "Route Clock.vi" example for 6674T as a starting point.  Note: The PXIe-6674T will need to be in the system timing slot to overdrive PXI_Clk10.

Hope this helps,
-Tyler

0 Kudos
Message 4 of 9
(3,497 Views)

Hello and thanks TylerK for your reply,

 

I've also played with this around but this was obviously not enough.

 

why?

I give you here some numbers which I've collected with NI660X and routed 6674T OCXO Clock to PXI_Clk10_In.

On the first channel is the internal 20MHz Clock which should use (after your explanation and example) the OCXO **bleep**.

I read the signal with an external 1kHz Clock.

 

The first value should be between 0 and 20k and in the last run it was 4840. So far so good.

The second value should be increased by 20k and I expect 24840, but I got  24841. The difference 1 is not much, but for longer time the difference is getting bigger and bigger.

If I look  to the accuracy of the OCXO Clock (in the specs) then I cant understand that. Therefore they can only be one explanation (?)  that your suggestion is not doing the whole trick and the OCXO is not used for the internal clocks.

 

If you wonder that the external clock is the problem: No, because I've also other external clocks on other channel of 6602 card and they have the correct  values I would expect. The problem is only with the internal 100kHz, 20Mhz and 80MHz clock.

 

And yes the 6674T is in the right slot.

 

Any Ideas?

0 Kudos
Message 5 of 9
(3,484 Views)

 

It still sounds to me like you're seeing the slight difference between two independent timebases.  I'd also like to ask some questions about part of your last post:

 

If you wonder that the external clock is the problem: No, because I've also other external clocks on other channel of 6602 card and they have the correct  values I would expect. The problem is only with the internal 100kHz, 20Mhz and 80MHz clock.

 

Can you describe in greater detail how you've come to rule out the external 1 kHz clock?   Is the 1 kHz clock derived from the same source as the clocks going to the other counter channel or is it independent?  What measurement is done on the other counter channel, and where are the source and sample clock coming from?

 

My initial reaction is to view this as a simple difference between the 1 kHz external clock and your DAQ device clock.  Your summary for why you trust your 1 kHz clock doesn't have enough details for me to be convinced otherwise yet.  Just trying to get better evidence before ruling out suspects.

 

 

-Kevin P

  

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 9
(3,468 Views)

Hi Kevin,

 

then ask 🙂

 

The setup looks like this:

4 Channels are using the 20MHz internal clock, the other are connect to a external clock with different frequencies which also is also used to as readout-trigger (1kHz) to the 6602 card.

All external clocks are from one device with one clock which is divided to different frequencies.

 

Now the external clock has a limited accuracy and therefore also the signal which controls the readout of 6602 is not perfect. But what I do NOT understand is that all external clocks have always the expected values and the values of the internal clocks do not. I'm also worried abot the fact, that every 5-10 readout the difference is increased by one.

 

I give you an example:

Please ignore first col: (TimeStamp).

Channel 00: external 100Hz clock

Channel 01: internal 20MHz clock

Channel 02: external 100kHz clock.

Channel 03: internal 20MHz clock.

Channel 04: external 5kHz clock

Channel 05: internal 20MHz clock

 

each 1ms the counter card read the the current value (buffered counting by an external 1kHz clock)

 

please note: that in the case for internal clocks (here only 20Mhz but it happens also with the other internal clocks) that differnece between expected and obtained value is getting bigger with timebut not with external signals.

this is point which really worries me.

 

Example:

example.png

0 Kudos
Message 7 of 9
(3,461 Views)

Thanks for the details, very helpful! 

 

Let me make sure I've got it straight:  

1. your single common shared sample clock for all counter channels is a 1 kHz external clock

2. your counters are all performing buffered edge counting, and all use the same external 1 kHz clock for sampling

3. the signals being *counted* are different on ecah of the counter channels.  Some are internal 6602 board clocks.  Some are external clock signals.

4. all of those external clock signals are derived from a single common timebase by dividing down, as is the 1 kHz sample clock

 

   If all those things are right then I believe you're dealing with exactly what I suspected.  All the inaccurate external signals you measure show ideal and perfect-looking count differences because the sampling interval has the exact same inaccuracy as the signal being measured.  This is due to their being derived from a single common timebase. 

   When you sample the newly more accurate 6602 clocks (being driven by the accurate PXI_Clk10) with those inaccurate sample intervals, you are essentially measuring the inaccuracy of the external sample clock itself.  Your sample intervals are just slightly longer than exactly 1.0000000000 msec.  It appears you get one extra count every ~140000 counts or about 7 ppm discrepancy.  Not surprising at all.

 

I'd suggest one of the following approaches:

 

A. use one of your remaining counters to generate an accurate 1 kHz sample clock to be shared by all counter measurement channels. 

B. use one of your remaining counters to measure the external 1 kHz clock intervals being used for sampling.  Really, your channels 1,3,5 are already doing exactly that in the example you described.

 

 

Another sanity check I'd recommend is to try the same measurement on the 6602, but without the 6674T in the timing slot.  The results should be a little different b/c the 6602's own internal timebase is pretty unlikely to be exactly as accurate as the 6674T.  This'll help you to confirm that using the 6674T is really having an effect, as it should.

 

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 8 of 9
(3,436 Views)

Hi,

 

thanks for you answer and sry for the long response time.

your answer triggered a major discussion between me and my supervisor.

 

If this is discussion is been settled I'll will accept this answer or make a futher post here.

 

best regards

christian

0 Kudos
Message 9 of 9
(3,401 Views)