5922 Clock In

[annayaj]

I am using an external clock as the sample clock time base to collect data over an extended period.  I have a PXI1000B chassis with a 6682 Timing Module in Slot 2 and 2X5592 Digitizers in slots 3 and 4.  I'm collecting using the ni Scope Stream to disk Win32 example.  As background I'm measuring the Allan Deviation of an external device using the channel 0 on the digitizer in slot 3.

When I select 'External Sample Clock Timebase' from 'Internal Clock' to 'Clk In', External Time base : 10MHz, divisor: 1,  and start acquisition I get the following error:

Error - 1074135024 occurred at Property Node (arg 2) in niScope Stream to Disk Queues Win32 File IO. vi

Possible reasons:

Invalid Value for parameter or property

Device: Dev1

Property: Sample Clock Timebase Source

Invalid Value: ClkIn

Possible Values

Value: OnboardClock

Status Code: -200077

As a check I used Signal Express to make sure my external source is putting out a signal - it is - a 10MHz sine wave, 2Vpp, and the signal is within jitter and voltage specs.  I checked the latter by giving the Clk_In (Ref In) on the 5922 input a crude frequency reference - which gave an error - 'PLL could not phase lock to external clock...

The good reference doesn't cause the same problem with Signal Express.

The niScope EX External Clocking example also gives the same error.

I did wire the niScope Configure Clock vi after the property node and in between steps 4b  and 5 and have it choose Clock In as a choice but I have no idea if the 5922 is using ClkIn, as the choice before the property node is still ‘Onboard Clock’.

Eventually I'd like to use the good reference to drive both 5922 DAQs through the 6682 but a external sample clock directly to one 5922 will work for now.

I’m using LabView 8.6.1.  Sorry for the long post.  I would appreciate any suggestions.

[annayaj]

An update to my question.

With niScope Configure Clock vi in place I repeated the same test I did with Signal Express.  When there is a crude or nonexistent external reference and choosing Clock In I receive the same error message stating that the PLL could not lock to the external clock.  With a good reference I don’t receive the message.  This gives confidence that what I’m doing is correct though this leads me to a couple of questions.

1. What is the purpose of the original External Time Base Source, Rate, and Divisor in the ni Scope Stream to disk Win32?
2. When choosing Clock In with the Configure Clock vi is the expected default parameter a 10 MHz sine or square wave?

Thanks again.

[dansch]

Hello annayaj,

The short answer is that you are getting the error because the NI 5922 does not support an external sample clock (though it does support an external reference clock). The following images come from the NI 5922 Specifications and the NI High-Speed Digitizers Help (Devices » NI 5922 Overview » Clocking), respectively:

As you can see, only the onboard clock is specified as a sample clock source, and from the block diagram, you can see that the CLK_IN line only feeds in as a reference clock source. The sample clock will always use the 120 MHz onboard oscillator. The NI 5922 is actually a bit different from most of the other digitizers, especially those that actually "stream to disk" at high rates, in that it utilizes a Flex ADC architecture (block diagram shown below).

With this architecture, we are forced to always sample using the 120 MHz onboard timebase. In the Stream to Disk example you are using, digitizers such as the PXIe-5122 are more commonly used, and this digitizer supports using an external sample clock.

To address the rest of your issue, I believe that when you have been setting the Configure Clock VI, you have actually been setting your reference clock source (the top input you are wiring into is labeled "reference (input) clock source"). Since you feed the signal into your CLK_IN front panel SMB connector, it is actually using this signal as a reference clock to PLL the onboard 120 MHz clock to. When you give it a low quality signal for this reference clock, you get a PLL error because this reference clock you are feeding into the PLL is not of high enough quality. One of the reasons this is so confusing is that the niScope Configure Clock VI was created to be used with non-SMC-based digitizers (ie- legacy devices such as the NI 5102, 5112, 5620, 5621, and 5911) in order to synchronize those boards. The VI is not really useful when dealing with the newer SMC-based digitizers, especialy since T-Clock is a much better method of synchronizing these types of cards.

Hope this helps, and please let me know if there is anything else I can explain in more detail. Regards,

[annayaj]

Thanks Danial.  I see that my terminology was incorrect.  I am providing a reference clock which is used by the internal sample clock to lock.  Two questions I still have:

1.  I did a few tests by varying the reference frequency.  I saw that my signal of interest changed accordingly with how I varied my reference clock so it looks like the 5922 is using the external reference (to PLL the internal sample clock).  Is it safe to say that a high quality external reference (I have a GPS disciplined rubidium oscillator with a 10MHz output) will reduce issues of drift in the sample clock as opposed to using no reference?

2.  So if I had a PXIe-5122 I would not get the same error when I select 'External Sample Clock Timebase' from 'Internal Clock' to 'Clk In' since the 5122 is capable of using an external clock?This is using the niScope EX External Clocking example?

Thanks.

[dansch]

You are correct that using the reference clock would be ideal for the reasons you mentioned. I do not think drift is as much of a concern as stability, but both should be reduced by using a higher quality reference clock. By default, the card does not lock to a reference clock; however, the default reference clock if you enabled it would be the PXI 10 MHz clock off the backplane. I am sure that your rubidium source would be much more stable than the backplane clock.

If you had a PXIe-5122 and you set the "External Sample Clock Timebase" property, you would not get the error because an external sample clock is supported on that device. Of course, whatever you connected into the board would be used as your sample clock and not simply just something to PLL the sample clock to, which is what you are doing with the 5922.

Regards,