40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log  Not logged in ELOG logo
Entry  Fri May 17 18:58:58 2013, Jamie, Koji, Summary, CDS, Weird DAC bit flipping at half integer output values const.pdfsweep.pdf
    Reply  Fri May 17 19:56:52 2013, Koji, Summary, CDS, Weird DAC bit flipping at half integer output values 
    Reply  Wed May 22 11:09:33 2013, Jamie, Summary, CDS, Weird DAC bit flipping at half integer output values nopad.pdf
       Reply  Wed May 22 11:21:28 2013, Koji, Summary, CDS, Weird DAC bit flipping at half integer output values 
          Reply  Wed May 22 11:35:06 2013, Jamie, Summary, CDS, Weird DAC bit flipping at half integer output values 
             Reply  Wed May 22 15:08:37 2013, Koji, Summary, CDS, Weird DAC bit flipping at half integer output values Screenshot.png
Message ID: 8598     Entry time: Fri May 17 18:58:58 2013     Reply to this: 8599   8613
Author: Jamie, Koji 
Type: Summary 
Category: CDS 
Subject: Weird DAC bit flipping at half integer output values 

While looking at the DAC anti-imaging filters, Koji noticed an odd feature of the DAC output:

sweep.pdf

What you see here is 16kHz double data from a model right before the DAC part ('C1:SUS-PRM_ULCOIL_OUT', blue), and the full 64kHz int data sent to the physical DAC as reported by the IOP ('C1:X02-MDAC0_TP_CH0', green).  The balls are the actual sample values (as expected there are four green balls for every blue).  The output data is being ramped continuously between 0 and 1.

As the output data crosses the half-count level, the integer DAC output oscillates continuously at every 64kHz sample between the bounding integer values (in this case 0 and 1).

Here's the data as we hold the output continuously at the half-count level; the integer DAC output just oscillates continuously:

const.pdf

After some probing I found that the oscillation happens between [-0.003 +0.004] of the half-count level.

The result of this is a fairly strong 32 kHz line in the DAC analog output.

We looked in the controller.c and couldn't identify anything that would be doing this.  This is the output procedure as I can see it (controller.c lines): 

  1. The double from the model is passed to the IOP
  2. The IOP applies a sample-and-hold or zero-pad if the model is running at a slower speed than the IOP (1799)
  3. The data is then anti-image filtered (1801)
  4. A half-integer is added/subtracted before casting such that the cast is a round instead of a floor (1817)
  5. The data double is cast to an int (1819)
  6. The data is written to the DAC (1873)

There's nothing there that would indicate this sort of bit flipping.

ELOG V3.1.3-