06-10-2022 05:01 AM - edited 06-10-2022 05:03 AM
Hardware: PXIe-1082 chassis, PXIe-8861 controller, PXIe-4492 Dynamic Signal Acquisition (DSA) analog input device.
Software: LabVIEW 2019 (19.0.1f5 32-bit)
The title explains well my problem. The analog signal comes from a single pre-polarized condenser microphone.
As you can see, the dt between two consequent samples has a "sawtooth" behavior for nominal sampling rates of 30 kHz, 50 kHz, 70 kHz and 150 kHz. The horizontal lines in each subplot represents the nominal expected time interval (dt = 1/fs).
Here you have a screenshot of the Block Diagram and the Front Panel, the .vi file is attached:
I could not avoid noticing that the problematic frequencies are not an exact divisor of the Sample Clock Timebase, but I still miss the solution to this problem. Any idea on the nature of the issue would be very welcome. Thank you in advance!
Solved! Go to Solution.
06-10-2022 06:05 AM - edited 06-10-2022 06:43 AM
How do you measure dt?
Could it be, that the the numerical resolution of your txt file is the reason ?
EDIT: And always read the actual SR after configuration. Not every SR is possible and rounded to the next higher possible SR.
Measuring the actual ADC sample clock jitter is another task 😉
06-10-2022 07:36 AM
Henrik's right to zero in on the question of how you measure dt.
Those plots have have all the hallmarks of a *quantization* problem in your measurement of dt. Notice the regular pattern of how it toggles between only 2 discrete values. That's exactly what you can expect from a quantized measurement.
The *actual* sample rate is not fluctuating that way, only your quantized *estimate* of it is.
-Kevin P
06-10-2022 10:15 AM
@Henrik_Volkers wrote:
How do you measure dt?
Could it be, that the the numerical resolution of your txt file is the reason ?
EDIT: And always read the actual SR after configuration. Not every SR is possible and rounded to the next higher possible SR.
Measuring the actual ADC sample clock jitter is another task 😉
See this link for allowed sample rates; as Henrik said, you are probably not sampling at the rate you think you are. Some allowed sampling rates for 4492 are 204.8kSa/s, 163.84kSa/s, 102.4kSa/s, 81.92kSa/s, 51.2kSa/s, 40.96kSa/s, 25.6kSa/s, 20.48kSa/s, 12.8kSa/s, 10.24kSa/s, and 6.4kSa/s.
06-14-2022 02:30 AM
Hi Henrik,
indeed the issues seems to lie in the precision with which the time column is stored. The Write to Measurement File Express VI (advised against by many) has an option to write a "X column" obtained as t = index of the sample * (1/fs). These values are truncated by default to 10e-4, and that's how the bias is introduced for those fs whose inverse (dt) has many decimals, like 70 kHz. Now I have replaced the Express VI with a Write Delimited Spreadsheet VI, which allows to specify the format (.n%f). However, I still don't know how to write a time array with the actual sampling instants, and not an array created with the nominal dt. All I found is how to time some parts of the VI itself, like the while loop. But that has to do with computing time, not with hardware sampling.
Thank you for pointing me in the right direction.
06-14-2022 02:32 AM
Hi Henrik,
indeed the issues seems to lie in the precision with which the time column is stored. The Write to Measurement File Express VI (advised against by many) has an option to write a "X column" obtained as t = index of the sample * (1/fs). These values are truncated by default to 10e-4, and that's how the bias is introduced for those fs whose inverse (dt) has many decimals, like 70 kHz. Now I have replaced the Express VI with a Write Delimited Spreadsheet VI, which allows to specify the format (.n%f). However, I still don't know how to write a time array with the actual sampling instants, and not an array created with the nominal dt. All I found is how to time some parts of the VI itself, like the while loop. But that has to do with computing time, not with hardware sampling.
Thank you for pointing me in the right direction.