Academic Hardware Products (myDAQ, myRIO)

cancel
Showing results for 
Search instead for 
Did you mean: 

NI Mydaq gain loss at Higher frequencies

Hi There,

                  I am using a MYdaq for my student project, I am using this is an audio sine wave generator and analysis tool as part of the project.

 

I am sampling well above nyquist of my highest frequency (20K) at 100K sample rate both on my OP DAC and IP ADC and I have a buffer size of the same size on the I/P and output.

 

I am using the audio L/R inputs and outputs (AC coupled) - This is looped fro the purpose of this excercise.

 

When I generate frequencies (via the Sinewave Vi in labview - "NI_MABase.lvlib: sine waveform.vi"  and my FS and #s is both set to 10000.) i get a drop in level above approx 10K starting at about -1dB up to -3dB at 20K

 

Can anyone help me in tracking down the cause of this?

 

Regards

 

 

 

 

0 Kudos
Message 1 of 8
(7,801 Views)

Hi,

 

Just to for my own sanity, have I got these values right? 

- Sampling at a frequency of 100kHz. (Analogue Input and Output)

- Intending of sampling a 20kHz signal.

 

The specifications of the NI myDAQ can be found here. These specify that the device can sample up to 200kS/s for both Analogue Input and Analogue Output, meaning that the maximum clean sinusoid we can both generate and acquire should be 20kHz, with 10S to represent the wave. Higher frequencies will require lower samples and the signals will look more chopped and aliasing will occur (20kHz*10S = 200kS/s). In order to appropriately measure the 20kHz wave, we need to choose a maximum sample frequency of 200kHz for clean waves. With this in mind 100kHz sample rate should be okay.

 

Is it possible for me to check the code that you have written so far? What I imagine could be happening is that we're seeing these issues due to the slowness of software. If you look at your code and the DAQ VIs are continuously having to check what values to write, rather than having these values delegated down to the hardware layer prior to running the task, this could be the source of the issue. This is because in software, there is a maximum update rate of 1kHz; this is why all of the base clocks in LabVIEW software are 1kHz clocks. If we're constantly having to poll what kind of digital output values we want to write, this will affect the consistency of the generated signals.

 

Kind Regards,


Alex Thomas, University of Manchester School of EEE LabVIEW Ambassador (CLAD)

0 Kudos
Message 2 of 8
(7,789 Views)

Hi Alex - Many thanks for helping with this.

 

The values you have quoted are 100% correct.

 

Yes I would be more than happy to share my code with you, What is the best way for me to send it you?

 

Please let me know and I will get it posted A.S.A.P

 

Kind Regards

0 Kudos
Message 3 of 8
(7,783 Views)

No problem! (I'll try my best!)

 

Please just attach the code to a forum response in the Attachments section of the Post Message screen. If you're unhappy with doing this, I would suggest that instead we could take a look at some of the example NI-DAQmx Examples from the NI Example Finder to see if you achieve this same behaviour.

 

Access the NI Example Finder by navigating through:

<LabVIEW> » Help » Find Examples... » Hardware Input and Output » 

 

We're interested in some VIs in both the Analog Generation and Analog Measurements section of the Example Finder. What we can try from these examples is generating these high frequency sinusoids by buffering their representation down to the on board buffers of the MyDAQ hardware so that they can run continuously without having to constantly query LabVIEW for its next set of data. This will allow us to ensure we're measuring the signals we have in mind. 

 

Analog Generation: <Voltage> » Cont Gen Voltage Wfm-Int Clk.vi

Analog Measurements: <Voltage> » Cont Acq&Graph Voltage-Int Clk.vi

 

Don't worry about running these simulatenously. Althoug we're accessing the same hardware, the NI-DAQmx drivers are clever enough to notice that we're not trying to write to or read from the same channels. 

 

Try generating the waveforms we've discussed and seeing whether you acquire an appropriate result.

 

Best Regards,


Alex Thomas, University of Manchester School of EEE LabVIEW Ambassador (CLAD)

0 Kudos
Message 4 of 8
(7,779 Views)

Thanks Alex Here is the code (Attached)

 

I appreciate your assistance

 

Kind regards

0 Kudos
Message 5 of 8
(7,777 Views)

Alex this is the main example - please igore the other!

 

Regards

0 Kudos
Message 6 of 8
(7,776 Views)

Hi midasRitch,

 

Attached to this post is some example code which shows how we can buffer waveform data down to the hardware layer via signal regeneration. What you will see is that as we approach higher frequencies, the hardware circuitry will begin to behave like a filter on the signal we're generating; this is a phenomenon known as a Slew Rate - the maximum voltage variance we can have over a particular frequency of generation. This means that we can still generate a 20kHz frequency, but the overall full scale voltage range we can change these frequencies over is reduced.

 

Sorry in the delay getting back to you; I hope that this helps.


Alex Thomas, University of Manchester School of EEE LabVIEW Ambassador (CLAD)

0 Kudos
Message 7 of 8
(7,759 Views)

Thanks Alex - In the back of my mind I was thinking about the H/Ware slew rate.

 

I shall investigate this compared to what you have sent me.

0 Kudos
Message 8 of 8
(7,749 Views)