This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADS1271: MSB sent twice

Other Parts Discussed in Thread: ADS1271

Hello,

I'm using ADS1271, data rate 1 KHz, SPI interface. Most of my samples are correct but quite often I read one of these:

- samples with most significant byte sent twice (first and second byte are the same)

- samples with every one of my threee bytes shifted by some bits (for example I read 00000110 instead of 00011000)

I had a look with the oscilloscope and it appears as if the serial interface (CLK, SCLK, ...) is always the same.

Other details: supply and reference are correct, clock frequency 10MHz (crystal clock witha 50ohm series resistor), SCLK frequency is 2.5MHz.

I tested high-resolution, high-speed and low-power modes

Thanks for your help.

  • Alice,

    The second case, (and it may be a similar problem as the first case), can often be caused by a noisy SCLK line. In this problem, the part sees an extra SCLK and shifts the data out.

    In some boards, I've seen that a small amount of capacitance from a clock (such as the master clock) to the SCLK line can corrupt the data.

    To help prevent this, I would perhaps do a small RC filter from the source of the SCLK line to the SCLK pin. You may have to play with this, but as little as 100ohms and 10pF might be enough to prevent this.

    Hopefully this helps.

    Joseph Wu

  • Alice, 

    Also make sure you have the correct clock phasing and polarity. Verify with page 6 of the data sheet that you are reading the data on the right edge of SCLK. The falling edge is the critical SCLK edge.

    -Tony 

  • I solved, it was no noisy line, but DRDY line went low during the acquisition and data was overwritten.

    I didn't wait for the high impulse on DRDY, I only checked that it was low to start the acquisition.

    Now I wait for the high impulse on DRDY line and everything works fine.

    Many thanks however!

  • Alice,

    I'm glad you found the problem.

    That's something that I've seen in the past, but it didn't click with your problem.

    In most applications, I'd say that the readout should be:

     1. Timed to the conversions, or
     2. Triggered on the falling edge of DRDYn.

    If neither is the case, then there's the chance that the readout is mis-timed to the conversion. DOUT could overwritten with new data as the new conversion is completed.

    Let us know if you have any other questions.

    Joseph Wu