• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 829 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Polling #DRDY via SPI on ADS1241 and output register update

none53113
Prodigy 90 points
Other Parts Discussed in Thread: ADS1241

Regarding the ADS1241, I would like to know if you can recommend a sequence for reading 4 channels by means of polling DRDY via SPI. I am not sure how to avoid reading corrupt data from the output register. Currently I do the following:

  1. read #DRDY bit, if 0:
    1. read result
    2. set gain for next conversion
    3. set mux
    4. sync
    5. dummy read to start modulator and reset DRDY

Possibly because of a problem in our application, the polling frequency may decrease in regular intervals, so periodically I get erroneous data.

At first I though this may relate to the possible situation where just after verifying DRDY==0, a conversion is finished and the output register updated, consequently corrupting the data read in the next step.

But now it almost seems that despite synching the modulator, the filter is actually causing the error (datasheet p. 10, fig. 2).

We're using a 4,915 MHz xtal, SPEED = 1, DR = 0.

Although the application does not use the DRDY pin, I measured the low pulse-width and it increases in a linear fashion up to 20 ms (caused by polling too slowly). The data shows the same tendency, looks like the 10 percent error specified.

I may misunderstand the datasheet, but I was expecting no such error as I thought modulator, mux change and new conversion to be synchronized.

Swapping step 3 and 4, eliminating step 5, does not improve things.

Please let me know if the problem is likely caused by the filter settling and possibly how to avoid it. Thanks!

  • 0
    TI__Guru* 97465 points

    Hi,


    I've read through your post and I don't see any glaring errors. The sequence you describe: RDATA, Set Gain, Set Mux, SYNC, dummy read to set DRDYn high makes sense to me and that's the way I would have done it to read multiple channels.

    Just to be sure however, I'd like some more information.

    1. Can you post the exact sequence of commands? This would include the exact hex codes used for the commands and maybe any kind of timing information. This would also give me the exact setup information (although you already listed some).

    2. I'm glad you posted the case where the conversion finishes during a data read. Many people don't realize this and get corrupted data occasionally.

    3. How often do you poll the DRDYn line when looking for it to go low?

    4. Are you measuring a DC source or an AC source? If the source is AC, then it's subject to the frequency response of the digital filter as shown in Figure 2.

    5. I didn't understand one of the paragraphs of the post: "Although the application does not use the DRDY pin, I measured the low pulse-width and it increases in a linear fashion up to 20 ms (caused by polling too slowly). The data shows the same tendency, looks like the 10 percent error specified." Could you clarify this?

    6. Do you use the DSYNC command or the pin?

    7. This may be linked to 5, but can you please describe the error you get in detail? Does the data vary with the timing of the read? Is the error a portion of the exact value that you'd get? What source are you reading, what value are you expecting to get, and what value do you actually get?

    I realize it's quite a few questions, but I don't see any problems with the way you're trying to read the part.


    Joseph Wu

  • 0 in reply to Joseph Wu
    Prodigy 90 points

    Dear Mr. Wu,

    thanks for your reply.

    3. How often do you poll the DRDYn line when looking for it to go low?

    DRDY is polled via SPI very frequently, but due to a delay in the firmware, the polling and thus the command sequence may be delayed up to about 20 ms after DRDY goes low. This time (DRDY low pulse width) was measured on the DRDY pin. The delay varies in length, the error of the measured DC signal seems to correlate.

    6. Do you use the DSYNC command or the pin?

    The command.

    7. This may be linked to 5, but can you please describe the error you get in detail? Does the data vary with the timing of the read? Is the error a portion of the exact value that you'd get? What source are you reading, what value are you expecting to get, and what value do you actually get?

    Yes, the data varies with the timing of the read. Input is from a transimpedance amp with DC applied.

    See below for sample data (x ms, y ADC values). The input was manually changed at 340. Gain is 128. There are four channels measured, so the rate for this channel is 15 Hz / 4.

    The error looks like this

    If the source is AC, then it's subject to the frequency response of the digital filter as shown in Figure 2.

    Do you mean Figure 6? Regardless, it's a DC source.

    1. Can you post the exact sequence of commands? This would include the exact hex codes used for the commands and maybe any kind of timing information. This would also give me the exact setup information (although you already listed some).

    Here's the command data:

    Read #DRDY bit from ACR: 0x12, 0x00, 0x00

    Read output register: 0x01, 0x00, 0x00, 0x00

    Set gain: 0x50, 0x00, gain

    Mux: 0x51, 0x00, mux

    Dsync: 0xFA

    Dummy read : 0x01, 0x00, 0x00, 0x00

     

    2. I'm glad you posted the case where the conversion finishes during a data read. Many people don't realize this and get corrupted data occasionally.

    Well, I haven't ruled this out yet as I don't see a way to detect this condition using the SPI interface only.

    To sum it up:

    The error is clearly triggered by the delay in polling DRDY. While the delay problem may be fixed in the future, it should not cause a problem reading the ADC. The error increases with the delay. Through DSYNC, it would be expected that there is no filter settling error after a mux change (or any other timing-related error for that matter). I'm not certain that what I see is the filter settling error. Another source of error may be a "race condition" where after polling the #DRDY flag (low) the result register is read, while a new conversion has finished and the register is being updated.

    Another behaviour that I have no explanation for is that every other channel (0-4, 1-5) seems to have a similar error just with a different sign.

    I hope you have a better picture of my problem now. If this points towards corrupt result register data, please let me know how to work around this.

    Thank you for your help!

  • 0 in reply to none53113
    Prodigy 90 points

    Sorry, forgot the initialisation:

    0x50
    0x06
    0x00
    0x68
    0x20
    0x00
    0x00
    0x00
    0x00

  • 0 in reply to none53113
    TI__Guru* 97465 points

    2. I'm glad you posted the case where the conversion finishes during a data read. Many people don't realize this and get corrupted data occasionally.

    Well, I haven't ruled this out yet as I don't see a way to detect this condition using the SPI interface only.

    *****

    I haven't had a chance to read through your entire post, but one other thing that might help is if you had the raw data for the reads that gave you the data plot. When I say the raw data, I'm referring to the hex values coming out of the converter when data is being written.  I'd also like to know the input value (I'm assuming it's pretty close to the y-axis of the plot), the reference value and the gain of the PGA.

    If this is an error in the read associated with missing the DRDY, you might be able to track it down with the data itself (or even capture it with the oscilloscope). In the data, you'll be able to see patterns in which the DRDY is missed and the data output starts again. Just as an example, after the 8 read bit, the following 16 bits look like the start of another good read and the bits look like a run-on in data.

    In the case of negative input (like yours), the data errors would always make the error more positive and with a positive input, the errors would make the error more negative.

    Also, in your case, the errors appear to be localized within certain times in the sequence, which also may be caused by an error in timing. If that were the case, you might be a small amount off in time for the reading but set to a reading every x seconds. Also, the readings would get worse over a set of readings and then correct for itself as the timing error goes through the time when the data is being read with 24 SCLKs. This might be related to the amount of time it takes to read 24 bits of data compared to the data rate. If you continue with the reads, do the errors occur basically periodically?


    Joseph Wu

  • 0 in reply to Joseph Wu
    Prodigy 90 points

    Dear Mr. Wu,

    thanks for your suggestions and sorry to bother you. After more tests it all pointed towards the problem being caused only by muxing, and thus making DSYNC appear to be ineffective in synching the filter to the start of a new conversion. Alas, I have been sending an invalid command for DSYNC (bad bit, bad!). Very embarrassing.

    Thanks again for your support.

     

  • 0 in reply to none53113
    TI__Guru* 97465 points

    No problem - as long as you found your answer.

    If you have any other questions,  feel free to post again.

     

    Joseph Wu