FPGA NI USB 7856R: Glitches during analog output / "single point excursion"

[CTA_TUW]

Hi all!

The following problem during analog output generation on NI-USB 7856R is encountered:

When trying to generate a voltage ramp, one datapoint seems to be significantly lower than the previously generated or the next datapoint. (see attached figures). The generation itself is done via DDS from an example found on this forum (http://www.ni.com/example/31066/en/).

I think it’s a glitch or “single point excursion" ?

I tried to narrow down the problem and supplied a minimalistic VI. Here, a sawtooth ramp is generated via a NI example for DDS. Additionally, also a sine via expresss vi with 10Hz is included for comparison. Both signal exhibit this glitches…

What is your impression of this problem? How can it be avoided?

Best regards,

HM

[Maciej_B]

Hi  CTA_TUW,

did you manage to find out solution to this problem or at least explanation?

I am really curious why it is happening.

[CTA_TUW]

Hi Maciej_B!

Sorry for the late reply...Well, it seems there's no quick solution for this glitch problem:

I may quote from Texas Instruments (http://www.ti.com/tool/TIPD142😞

"DAC R-2R architectures display great performance in regards to noise and accuracy, but at a cost of large glitch area".

The only possible solutions for reducing the glitches when more than 3 significant bits change from 0 to 1 (or vice versa), is to use a track and hold (T/H) circuit as proposed by the TI source.

The only thing bothering me is that NI doesn't implement a built-in glitch reduction circuit in the first case...regarding the feasibility of a simple T/H circuit...

Best Regards!

[Intaris]

Isn't track & Hold for the input side, not the output side?

These glitches are occurring at your Output stage, you will see them on an scope attached to your device.

There are ways of compensating but they require active calibration and are temperature-dependent.  i.e. there's no easy way to have a one-off fix for this behaviour.  I know this because we do exactly that with our hardware and it's not a trivial thing at all.

Shane.

[CTA_TUW]

Hello Shane!

Yes you're right, basically T/H is mostly known for the input side - but if you happen to reproduce the switching conditions for the "hold" state you should be able to buffer the glitches before reaching the AO stage. At least that's the possible remedy as proposed by TI (http://www.ti.com/lit/ug/tidu022/tidu022.pdf).

"The glitch reduction technique employed in this design is based on an external Sample and Hold (S&H) circuit following the DAC output. In its simplest form the sample and hold circuit can be constructed from the following components: a capacitive element, output buffer, and switch."

I'm very curious about your method for the glitch reduction of R2R DACs. Maybe you are willing to share some insights?

Best regards!

[Intaris]

Can't share, sorry. Proprietary.

The design you linked to (via PDF) does have other effects on the output, bandwidth, slew rate and so on. It's not a magic bullet.

[CTA_TUW]

Hello Shane!

Unfortunately there's never a magic bullet...

So I'm patiently waiting for the first Gray code DAC from NI (or some other market player) to appear...

[Intaris]

Does grey encoding even work with DACs?

Hmm, quick google search, apparently it does.  Interesting.