PCIe-6374 - Python PyDAQmx library - sample rate dependence of DAC output?

[MatzeXYZ]

Hello Community,

i want to write amplitude-modulated sinus signal form to analog output channel of NI PCIe-6374 card. I want to have the same signal at the
output of DAC as I have sended digitally to it (within the accuracy limits).

My actual problem: Dependend on sample rate of the DAC, the residual error between target signal and measured signal changed in a strange way (I measure the DAC output signal directly with one of the ADCs of the same card in differential mode (only possible mode)). Detailed description of the problem (included code examples and graphs) you find in the attachment.

Could you explain me, why the difference between target signal (DAC) and measured signal (ADC) is
increasingly different, when I increase sample rates? Maybe this behavior is within the specifications, but at
the moment I have trouble to understand it.

Link to the Specifications of PCIe-6374 card: https://www.ni.com/pdf/manuals/377388c.pdf

Many thanks!

MB

[Kevin_Price]

I'd advise that you start by putting some *extra* attention to the details of timing and sync between the tasks.

What you've done so far is definitely not *bad* and it'll surely behave *consistently*, but it's possible to take a little more control over the timing to see how much (if any) of the residual you observe can be reduced.

Your scheme triggers your AI task to start when the AO task's internal "StartTrigger" signal asserts.  Both tasks are configured to sample at the same *nominal* rate, but sample timing is otherwise independent.  It's also at least conceivable that the actually-available legal sample rates for AI and AO don't fully coincide -- any such discrepancies will tend to be more pronounced at higher rates.  (This detailed timing info will be findable somewhere, but I'm not certain exactly where to point you.)

My recommendation: don't bother with triggering, rather establish AO / AI sync purely via offset sampling.  I don't know the Python syntax for these things, but here's the idea of what to do:

1. Create a counter pulse train task with >= 50% duty cycle and frequency=desired sample rate.  Don't start it yet.

2. Configure AO to use the counter output as its sample clock signal, sensitive to the *leading* edge (probably rising).

3. Configure AI to use the counter output as its sample clock signal, sensitive to the *trailing* edge (probably falling).

4. Start both AO and AI tasks.

5. THEN start the counter pulse train task.

This "offset sampling" gives the AO output a fraction of the sampling interval to slew and settle before AI captures it.  And the AI has the remaining fraction available to capture it before the AO tries to change again.

I don't know if or how much this detailed timing change will help matters, but it's one of the suspects to try to eliminate.   

-Kevin P