Post Go back to editing

AD7949 occasional invalid samples


I am working on a system that uses 5 AD7949s connected to a single SPI bus, clock running at 16MHz. When reading the ADCs, we are using the RAC (read after conversion) method to return samples.

Our sample rate is very low; only 50Hz. The clock was set at 16MHz from the equation on page 22 of the datasheet, which results in a clock of greater than 12MHz (we might not have to follow this requirement? This might only be for RDC conversions)

We noticed that very occasionally, about once every 5 minutes, we read nearly full-scale readings from only the last 7/8 channels from only one of the ADCs, which happens to be the last out of the 5 to be read in the reading loop.

We adjusted the high/low timings of the CNV lines for the system to well exceed the requirements in the datasheet but we still see errors. We noticed that if we enable the readback function, the errors stop.

However, when testing at cold temperatures below -10C, the errors show up again, and only on that single ADC, only for the last 7 out of 8 channels.

Our firmware reads all channels + the temperature channel by performing 2 dummy reads, then the 9 sample reads with readback, for each ADC at 50Hz.

Our ADC settings are:

 * CFG = 1 (overwrite)
 * INCC = 111 (Unipolar, INx ref to GND)
 * INx = 111 (IN7 is highest channel to read)
 * BW = 1 (Full Bandwidth)
 * REF = 001 (Internal reference and temperature sensor enabled. REF = 4.096 V buffered output)
 * SEQ = 10 (Scan IN0 to IN[7:0] (set in CFG[9:7]), then temperature)
 * RB = 0 (read back current configuration at end of data)

This is what the signals look like. Blue is the clock, Green is the CNV line.

  • Greg,

    The fact that the errors occur only on that last ADC instance out of 5 is suspicious.   I have the following questions which will help me understand what should be recommended as the next steps.

    1) During testing what are the inputs connected to?  If any are left floating what happens if you tie those to a known potential?

    2) Does the RDB trick work equally as well at cold as well as at room temperature?

    3) What happens if you slow the I/F clock down to 8 MHz?

    4) Would you be willing to swap the ADC in the troubled area with one that does not fail?



  • Hi,

    1: They are connected to the outputs of current sense amplifiers, with a LP filter (22ohm, 33nF).

    2: Readback does not work equally well. However, it reduces the number of errors when cold, and 0 errors when ambient and hot.

    3: That was one question I had; Can I slow the clock to any rate we want? Lets say I set the clock to 1MHz; will we violate any timing or quiet times when using RAC?

    4: Unsure of this, will need to see if this would be feasible.



  • Greg,

    1) What amplifier are you using and is there any potential the output of one of those channels is saturating?  If so this could cause corruption of all subsequent channels until the fault is cleared.

    2) With regards to read after conversion there is no explicit limitation on the clock throughput other than the conversion period you desire.  It is recommended that you do allow 20ns from the last edge of SCK to the CNV rising edge but other than that there is no restriction.  Of course be sure to allow at least 2.2us from the previous CNV rising edge before you start your data transfer to ensure it truly is RAC.   I think when I recommended 8 MHZ I was trying to fit the transfer (16 clocks) inside the 6us (or thereabouts) you had for the available CNV Low time to make sure the clocks would fit.  My thinking was if you had a marginal interface timing issue slowing the clock down by 2x should fix the problem.


  • Sean,

    1: We're using the automotive INA240 for this. We have done tests where we probe the voltage output/input to the ADC and set a trigger for a voltage over a certain threshold, and we never saw a trigger but we did see false data from the ADCs.

    What do you mean by "fault is cleared"? This would be an internal mechanism right; we can't control this ourselves?

    2: I think we'll try slowing the clock and see what our results are.


  • Hi Sean, we tried turning down the clock to 4MHz because we were seeing rise times that were too long for 16MHz. this has reduced our "full scale" blips down to 0.

    However, we now get fewer, smaller blips, about 16x smaller than before. The 16x looks suspicious (a power of 2).

    This suggests that whatever problem there is is affecting the lower-valued bits in the data transmission?

    Do you have any explanations for this behavior?


  • Greg,

    Can you send me an updated screen capture of your new timing?  

    Also could you please explain what you mean by the following statement?

    Hi Sean, we tried turning down the clock to 4MHz because we were seeing rise times that were too long for 16MHz. this has reduced our "full scale" blips down to 0.

    Are you talking about rise times on the serial data output?  The data clock?   Some other signal?   

    If it is the serial data output line is there anything unique about the routing from that 5th device back to the host processor?

    Then with regards to the failure your are seeing, sounds like you are still seeing code jumps about 1/16th of fullscale every 5 minutes or so.   Is this still on the same affected device?   Did you ever try swapping devices to see if the failure would move.  Or conversely could you change the order that you read back the devices to see if it moves?

    However, we now get fewer, smaller blips, about 16x smaller than before. The 16x looks suspicious (a power of 2).

    Quick EDIT: - SKOWALIK 19:57 26-APR_21

    One thing I've looked at is that the INA240 has a very long settling time (~10us) so if there was any disturbance due to switching transients from a previous channel it is possible it could take some time to settle out.   What I don't understand is why that would effect multiple channels in a sequence and then not happen again for 5 minutes.  I need to think about this some more but if at some stage you'd feel comfortable sharing your layout of the affected device versus one that is working that might help shed some light on things.