• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 46 subscribers
  • Views 586 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.

ADC1248 dout/drdy vs. rdatac/sdatac and timing

Tommy Nielsen51
Prodigy 20 points

I am using the ADC1248 at SPS 640.

In the specification it says that a conversion will end worst case in less than 1.7 seconds.

I try to run with a delay from SYNC to RDATA in SDATAC mode which is 2 ms. However the ADC data I get is periodical wrong.

If I increase the delay time to 2.5 ms it becomes more stable, and at 2.8 ms it seems totally stable.

Now it would be nice if I could use the dout/drdy to find out when the conversion has ended. However this seems only to be possible in RDATAC mode?

So my question is, if I can not thrust the timing in the specification, how can I determine when the conversion has ended in SDATAC mode.

  • 0
    TI__Guru* 97695 points
    Tommy,


    Unless you are having problems with an external clock, the timing should be spot on. With the internal oscillator, the timing should be within +/-5% of the expected value.

    I would start by running the device as you've mentioned but look at the /DRDY instead of the DOUT/DOUT line. Even if you don't use it in your system, you should be able to see the line go low in response to a completed data. Get a plot with an oscilloscope to make sure of the timing delay. I think you'll want to show the SCLK lines, along with /DRDY, DOUT, and DIN. Once you get the plot, post it back here. You may also want to show the SYNC command in, along with the /CS line to make sure that the command was implemented correctly without any timing violations.

    Out of curiosity, when you say that the ADC data is periodically wrong, how is it wrong? Is the data completely random? Is it higher or lower than expected?


    Joseph Wu
  • 0 in reply to Joseph Wu
    Prodigy 20 points

    Thanks for your answer, good idea to monitor the communication pins, but I have a few questions more regarding timing I hope you can help with.

    The data is completely wrong. I did not look at the raw data only at the scaled data which is temperatures between 20 and 30 degree. When it fails it gives a temperature of -260 degree.

    We have a flow which look like:

    For each channel (we run 6 channels 4 input and 2 internal)

         For each ADC make CS (we have 5 ADC on the same SPI) and:

               Configure ADC/Channel (We make first 6 writes (VBIAS,IDAC0,IDAC1,SYS0,MUX0,MUX1 in this order and then 6 reads (to verify the write))

               Set RDATAC or SDATAC (I think RDATAC should be default, depending on if we run in single or use drdy)

               Send NOP to make sure dout is high (If we run in RDATAC mode).

        Wait some time (Don’t know if it is needed, spec is unclear)

        For all ADC

            Send SYNC command (Done by CS all ADC and send one SYNC command)

        Wait conversion time (for SDATAC) or wait for dout to go low (polling, for RDATAC) 

        For each ADC

             (For RDATAC I again wait for dout to go low for the given ADC (polling right now))

             Send RDATA and read data

    Now the questions:

    1) After each read/write command I have a delay of 5us/15us. I think it is a bit hard to figure out the correct values?

    2) As exception if I use SDATAC, I put a delay of conversion time to make sure the DRDY has appeared before I send the SYNC command. I suppose this is the way to do it?

    3) Should there be a delay after the configure and before the SYNC, when it is done as above?

    4) At the wait conversion time it is specified that for the given SPS that I should wait max 1700us, to make it stable I have to wait 1950us. I Wonder why?

    5) Now if I remove the 6 reads (with a delay of 1950us), then the first channel on the 5.th ADC fails. If then I put an extra delay of 60us (30us is to little) so the delay is 2010us then the result becomes correct again. This I find very strange, as the read is before the SYNC, so I dont see why this should effect the timing to remove the reads. So I believe there is something fundamental I am missing?

    It should be said that the delay above is not including delays in SPI communication, which seems to be approximate equal to the delay I put in.

  • 0 in reply to Tommy Nielsen51
    TI__Guru* 97695 points
    Tommy,


    When you say the data is completely wrong, it really helps to have the raw data. I'd like to know if it's a matter of settling, reading error, or random bits coming out. I'd also like to know what the expected data coming out is and what the voltage input is at the time.

    For the order of the commands, I don't see anything out of the ordinary that would give any specific problems. However, I need to know more about your system and what you are measuring. I may also need to know about how you have the reference set up (is this a ratiometric measurment? Is there an external reference? or is the internal reference being use alone?).

    I'll go through your questions first and then I'll offer a couple of thoughts.

    1. After the read/write commands, I don't think you need to give much time between them. You mention 5/15 us, but really, I think the timing should be the min 7 tosc needed for the tsccs in the timing characteristics. (time from last SCLK fall to rise of /CS).

    2. If you use the SDATAC, it'll take place after the current conversion completes. I'll say more about the SYNC command afterward.

    3. Technically, you may not need the SYNC command at all. If you write to any of the first four registers (MUX0, VBIAS, MUX1, or SYS0) it automatically triggers a SYNC command with the write. The digital filter resets and a new conversion starts. Again, I'll back to this later.

    4. and 5. I'm not sure about either.

    Again, I need to know more about what you are measuring, but it might have to do with some settling in your circuit. If you are writing the registers, then waiting some time, then writing the SYNC, you add some delay to give the circuit to settle.

    The device makes the change in the circuit as you complete the WREG command. However, if you make changes (like changing the IDAC current location and magnitude) you still may need settling time especially if there are larger capacitances on those nodes. The extra delay may be giving extra time to settle. To be honest though, it doesn't seem like a change of an extra 60us would make that much of a difference in the settling time.

    If you can, I always recommend getting scope plots of the communications. Then verify all the timing against the timing diagrams in the datasheet. Since you do get good readings and then one bad reading, I'd also try to capture that read, along with all the SPI lines.

    After that, you might want to look at the analog lines as well to see if there are any problems from the measurement side.

    More detail in your response will be helpful.


    Joseph Wu