12-19-2012 08:54 AM - edited 12-19-2012 08:55 AM
Hi,
I have to perform some PXI-5922 calibrations and some (what I think) general questions came up, so I decided to post them here.
We (mostly) use the PXI-5922 in 1042Q chassis with some more cards and during the measurement tasks all are synced to (and use) the PXI-CLK10.
PXI-CLK10 in our case is provided by PXI-6672 cards linked (or calibrated against) to some atomic clocks 😉
(A1) I assume that self calibration (and linearisation!) with niScope_CalSelfCalibrate of the 5922 is always performed against the internal (then free running) oscillator.
(A2) During the (T-CLK synced) measurement tasks the PXI-5922 120MHz sample clock oscillator is linked via PLL to the PXI-CLK10.
(well, before T-CLK we also tell all cards to use the PCI-CLK10 as reference)
(Q1) Since self calibration is essential for best performance and timing for the ADC might be slightly different (up to 50ppm) would the performance of the ADC be affected?
(Q2) Is there a difference in niScope_CalSelfCalibrate if called after niScope_init or niScope_CalStart?
(Q3) The adjustment of the 5922 is performed in the order self calibration, adjusting the timebase and finally adjusting the range. Since the timebase affects the ADC linearity and so the range calibration, would it make sense to do the timebase adjustment before the self calibration?
Since there could be only one TIMING MASTER and that is sitting in the SYSTEM TIMING SLOT of my PXI chassis (Ok, that master might be chained to our national time master, but that is academic 😉 ) I would like to verify and adjust my PXI-5922 against that master. However, it seems wise in terms of system calibration, to do at least all verification with PXI-CLK10 based timing.
(Q4) Can I initiate a self calibration or a adjustment with a PXI-CLK10 linked 120MHz timebase??
(I know about the implication, that this calibration would only be valid as a system calibration including the PXI-CLK10 timebase, but it seems very reasonable from a system calibration view)
(Q5) niScope_CalAdjustVCXO want a 1MHz sine at channel 0 with 1Vpp (according to the cal-manual) and no other way to adjust the VCXO seems possible, so to link the VCXO to my TCXO time master I could easily provide a 1Vpp 1Mhz square wave via the time master DDS to channel 0. Can I use a 1MHz square wave for the niScope_CalAdjustVCXO?
The square wave (with high dV/dt) would be disconnected during niScope_CalAdjustRange. Otherwise I can of course lock a sine generator to PXI-CLK10 and use that signal.
(Q6) In order to do a quick verify of the PXI-5922 VCXO timebase against the PXI-6672 timebase without external cabling (just internal signal routing) what would be the best way (if possible)?
Seems that the PXI-5922 can't route any internal clock referenced signal to the PXI Bus that the 6672 (ni-Sync) measure frequency vi could use 😞
Finally I wish everyone a peaceful Christmas and a happy (and successful ) new year 2013
12-19-2012 09:29 AM - edited 12-19-2012 09:37 AM
While carefully RFTM about 5922 calibration I found a formular typo at page 18
otherwise the error would always fail the cal limit 🙂
12-21-2012 10:11 AM
Hi Henrik,
nice catch about the documentation. I forwarded it to our Documentation team (I am sure they will take it as some sort of a Christmas present 🙂 ).
Merry christmas to you too
12-21-2012 03:07 PM
@Naity wrote:
Hi Henrik,
nice catch about the documentation. I forwarded it to our Documentation team (I am sure they will take it as some sort of a Christmas present 🙂 ).
Merry christmas to you too
Thanks, but hopefully the first message to the experts too 😉
01-03-2013 06:53 PM
Hi Henrik,
(A1) I assume that self calibration (and linearisation!) with niScope_CalSelfCalibrate of the 5922 is always performed against the internal (then free running) oscillator.
For self-calibration, yes, it is mostly performed against internal references only. As per the 5922 calibration procedure (p. 2 states):
"Self-calibration, also known as internal calibration, uses a software
command and requires no external connections."
There is a caveat to this (that is why I said mostly) but I will need to check to verify whether or not it applies to the 5922. This part of the calibration is only pertinent to Phase DAC adjustment (i.e. it is only relevant to applications using TClk synchronization, as you are.)
For linearization, I'm not entirely certain what you mean (see below).
(A2) During the (T-CLK synced) measurement tasks the PXI-5922 120MHz sample clock oscillator is linked via PLL to the PXI-CLK10.
(well, before T-CLK we also tell all cards to use the PCI-CLK10 as reference)
Yes, TClk does automatically PLL the 5922 to the chassis reference clock. As stated here:
"To generate TClk signals, devices must have a common reference
clock (for internal sample clocks)"
If you want to use a better reference clock than what is already built into the chassis, you could choose to override the chassis backplane PXI_Clk10 with your own (e.g. more accurate, lower jitter) reference clock.
As a third option (which requires more programming) NI-TClk also gives the ability for you to specify a reference clock source for each digitizer (which would come into the CLK IN SMB terminal on the 5922, for instance).
(Q1) Since self calibration is essential for best performance and timing for the ADC might be slightly different (up to 50ppm) would the performance of the ADC be affected?
What exactly do you mean by "performance and timing for the ADC"? What kind of ADC performance (DC accuracy, phase noise/jitter, etc.?)
(This is an over-generalization which leaves out details, especially for the 5922, but) an ADC will take a sample when it sees the rising edge of a sample clock. The +/-50ppm accuracy would influence the sample clock rate, and will therefore affect performance derived from the timing information of the waveform.
For example:
Examples of performance NOT determined by the timing information (and therefore not influenced by a provided reference clock) includes:
- offset accuracy
- vertical gain accuracy.
Examples of performance THAT IS determined by timing information (and therefore influenced by a provided reference clock)
- phase noise (which we can integrate to find jitter) - perhaps ENOB
Providing a reference clock can improve certain performance aspects of your digitizer, depending on what performance you're concerned about. (NOTICE - I'm not talking about calibration here - see below).
(Q2) Is there a difference in niScope_CalSelfCalibrate if called after niScope_init or niScope_CalStart?
No, there is no difference between calling Self Calibrate before either of those functions. However, the niScope_init and niScope_CalStart functions are definitely different (not interchangeable).
(Q3) The adjustment of the 5922 is performed in the order self calibration, adjusting the timebase and finally adjusting the range. Since the timebase affects the ADC linearity and so the range calibration, would it make sense to do the timebase adjustment before the self calibration?
Not quite - there is also a self-calibration required after range and timebase adjustment. You call self-calibrate before (step 5) and after (step 12) all of the adjustments take place.
Since there could be only one TIMING MASTER and that is sitting in the SYSTEM TIMING SLOT of my PXI chassis (Ok, that master might be chained to our national time master, but that is academic ) I would like to verify and adjust my PXI-5922 against that master. However, it seems wise in terms of system calibration, to do at least all verification with PXI-CLK10 based timing.
What exactly do you mean by "ADC Linearity"? Are you referring to the INL and DNL influence on the ADC's DC offset or DC gain accuracy performance? INL and DNL are included in the specifications for the digitizer's accuracy (given as a percentage of the input + DC offset). But as I mentioned before, accuracy performance is not influenced by the accuracy of the reference clock.
If your concern is with a specification that is determined with timing information, you verify the timing accuracy by running the timing accuracy calibration verification step in the 5922 Calibration Procedure. As noted (p. 20, Table 7) the test limit is +/- 5.3ppm assuming the internal sample clock is being used. If you have a reference clock which is more accurate than this, and you are PLL'd to it, then the test you are running is no longer the internal timebase accuracy, but the accuracy of your reference clock. This is confirmed by referencing p. 13 of the 5922 specifications.
Also, as noted in the calibration procedure, the same clock is used to digitize both channels, so there is only a need to run this test on one channel. The same is true if you have several digitizers PLL'd to the same reference clock (as in the case of TClk). Just to try it, you could run the same timing accuracy verification test on several channels on several digitizers and confirm the results are similar.
(Q4) Can I initiate a self calibration or a adjustment with a PXI-CLK10 linked 120MHz timebase??
(I know about the implication, that this calibration would only be valid as a system calibration including the PXI-CLK10 timebase, but it seems very reasonable from a system calibration view)
Keep in mind that external sample clocks are not supported on the 5922 (you cannot provide a 120MHz timebase in any form to the 5922 digitizer). You can only provide a reference clock, and that must adhere to the input requirements given (1 MHz to 20 MHz in 1MHz increments, etc.)
That being said, no, there is no option to self-calibrate while maintaining a PLL to a reference clock. It's theoretically possible to achieve some further performance gains by doing this, but your measurement error will probably cover up any such performance gains. Also, any theoretical performance gains achieved could not be reflected in the published specifications - the published specifications would remain the same.
I'd like to take a step back and ask what, exactly, your application requirements are? Are you observing some kind of performance with the 5922 digitizer that you are seeking to improve?
-Andrew
01-08-2013 07:59 AM - edited 01-08-2013 08:04 AM
Hi Andrew,
thank you for your answers 🙂
I will start with your last questions:
>I'd like to take a step back and ask what, exactly, your application requirements are? Are you observing some kind of performance with the 5922 digitizer that you are seeking to improve?
Well, I work for the PTB and hunting for the next digit is our profession 😉
We use these cards to calibrate accelerometers and corresponding amplifiers (up to 100kHz, sometimes higher). One major part of the uncertainty budget is the dynamic voltage measurement. So getting it below 150ppm would be nice.
Currently I rework our internal 5922 calibration procedures, and with the help from my colleagues from the electrical department I hopefully soon get my AC reference source calibrated for the dynamic part and maybe have the chance hook it up to a dynamic josephson reference (See fig.10 a 5922 🙂 ). In short: I want to do better than the claimed spec. (Some hints to papers doing it are linked here, more via PM)
Since we use the PXI 5922 in conjunction with a time reference ( see first post: PXI-CLK10 in our case is provided by PXI-6672 cards linked (or calibrated against) to some atomic clocks )
the verification part of the calibration is done with the sample clock linked to PXI-CLK10.
@TimmTheEnchanter wrote:
Hi Henrik,
(Q4) Can I initiate a self calibration or a adjustment with a PXI-CLK10 linked 120MHz timebase??
(I know about the implication, that this calibration would only be valid as a system calibration including the PXI-CLK10 timebase, but it seems very reasonable from a system calibration view)
Keep in mind that external sample clocks are not supported on the 5922 (you cannot provide a 120MHz timebase in any form to the 5922 digitizer). You can only provide a reference clock, and that must adhere to the input requirements given (1 MHz to 20 MHz in 1MHz increments, etc.)
That being said, no, there is no option to self-calibrate while maintaining a PLL to a reference clock. It's theoretically possible to achieve some further performance gains by doing this, but your measurement error will probably cover up any such performance gains. Also, any theoretical performance gains achieved could not be reflected in the published specifications - the published specifications would remain the same.
Ok, so I have to live with that and monitor the internal clock.
(Q5) niScope_CalAdjustVCXO want a 1MHz sine at channel 0 with 1Vpp (according to the cal-manual), so to link the VCXO to my TCXO time master I could easily provide a 1Vpp 1Mhz square wave via the time master DDS to channel 0. Can I use a 1MHz square wave for the niScope_CalAdjustVCXO?
The square wave (with high dV/dt) would be disconnected during niScope_CalAdjustRange. Otherwise I can of course lock a sine generator to PXI-CLK10 and use that signal.
(Q6) In order to do a quick verify of the PXI-5922 VCXO timebase against the PXI-6672 timebase without external cabling (just internal signal routing) what would be the best way (if possible)?
Seems that the PXI-5922 can't route any internal clock referenced signal to the PXI Bus that the 6672 (ni-Sync) measure frequency vi could use
Just curious: What reference is used in the 5922? LM399, LTZ or ?? (not asking for selection, treatment, aging,,,, etc, at least of same importance 😉 )
01-09-2013 12:05 AM
(Q5) niScope_CalAdjustVCXO want a 1MHz sine at channel 0 with 1Vpp (according to the cal-manual), so to link the VCXO to my TCXO time master I could easily provide a 1Vpp 1Mhz square wave via the time master DDS to channel 0. Can I use a 1MHz square wave for the niScope_CalAdjustVCXO?
I have not personally tried that implementation, but I don't believe it will cause an issue. You could always try it (if you do, let me know what you find). Keep in mind that your 1MHz square wave will not look like a very good square wave due to the analog front-end bandwidth of the 5922 digitizer (which is 0.4*sample rate, or 6MHz at 15MS/s, as per p. 5 of the 5922 specifications). I expect the higher order harmonics which make a square wave look like square will essentially be filtered out.
The square wave (with high dV/dt) would be disconnected during niScope_CalAdjustRange. Otherwise I can of course lock a sine generator to PXI-CLK10 and use that signal.
You're correct in thinking that disconnecting such a signal is a requirement for adjusting the calibration range.
Of course, locking a sine generator (that produces a 1MHz signal) to a stable and accurate PXI_Clk10 signal is most consistent with the calibration procedure requirements.
(Q6) In order to do a quick verify of the PXI-5922 VCXO timebase against the PXI-6672 timebase without external cabling (just internal signal routing) what would be the best way (if possible)?
The best method, of course, is to use the regular timebase accuracy verification step in the calibration procedure. However, as you point out, that requires external cabling in a reference (a sinewave) from the "real world" so that the digitizer's concept of how fast time is moving can be double-checked and verified.
Obviously, you can't check a digitizer's timebase accuracy with itself (i.e. without something else from the "real world" to verify with), since the digitizer's concept of time is based on the free-running internal oscillator.
Seems that the PXI-5922 can't route any internal clock referenced signal to the PXI Bus that the 6672 (ni-Sync) measure frequency vi could use
To ask how to export something from the digitizer is essentially asking the digitizer to act as a function generator (which it's obviously not designed to do). The capabilities of exporting signals from the digitizer are limited to what the PXI-5922 routing matrix identifies as possible (you'll notice that it's slightly different than the PCI-5922 routing matrix, as the PCI version of the digitizer has an exportable onboard 10MHz reference clock - but I'm not sure that's what you'd want to use, anyway).
Unfortunately, I can't think of a good way for you to generate a signal with a digitizer that you will be able to verify frequency accuracy or stability with - the best means is to require some sort of cabling from a "real world" signal you trust.
Do your configurations during acquisition/test time (after you've run your calibration routine) always include a PLL to the super-accurate reference clock source you are using? If so, then why would you want to verify the accuracy/stability of your local oscillator on the digitizer in the free-running (not PLL'd) situation? That data points seems rather irrelevant if you don't have a test case which requires that information.
Just curious: what reference is used in the 5922? LM399, LTZ or ??
Unfortunately, I cannot share that kind of information (e.g. components used on our products) here. I understand you would like to know it because you are trying to exceed the performance specifications published for the 5922. If this information is very important to you, I would recommend asking your local NI sales representatives, and possibly opening a support request in order to address it.
-Andrew
01-09-2013 04:34 AM
>Do your configurations during acquisition/test time (after you've run your calibration routine) always include a PLL to the super-accurate reference clock source you are using?
No, we have a fiber wire link to our national time reference in our lab, providing 10MHz. We use it to calibrate/verify the the PXI-6672 TCXOs that is sitting in every of our PXI systems.
Like that I can be sure to have my 6672 TCXO always in a 1ppm range which is fine for our task.
>If so, then why would you want to verify the accuracy/stability of your local oscillator on the digitizer in the free-running (not PLL'd) situation?
>That data points seems rather irrelevant if you don't have a test case which requires that information.
Since I can't initiate a self-calibration while the internal oscillator is bound to PXI-CLK10 , and nobody can tell me how big that impact might be, I think it makes sense to check the internal oscillator against the PXI-CLK10 time reference (the 6672 in our case) after or before self calibration. Therefore it would be nice for the operator if he doesn't need to change the external cabling.
Idea:
Route a trigger event (ref stop trigger?) to a RTSI line and start a multi record acquisition (set to immediate, one post (dummy) sample, fetch and dump while acquire) . Like that I should get a pulse train that is timed by the internal oscillator.... however high speed digitizer help notes:
Caution The total number of records that you can acquire is limited. Each record requires up to 64 bytes of page-locked memory. Windows 2000 can crash without warning if too much memory is page-locked at any given time. The actual amount of page-locked memory depends on the amount of physical memory and the number of other devices being used in your host computer. You can configure as many records as you need, but save your work first.
... to get 1ppm resolution I need 10e6 records .... well, I have a win7 OS, LV2012 with the recent NI-scope , is that still a concern?