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.

ADS124S08: Second channel data acquisition problem

Part Number: ADS124S08
Other Parts Discussed in Thread: ADS1248

Request you to help us in the following queries:

Firstly thank you very much for the support as we could able to program the ic and get data from a single channel(AIN0,AIN1 sensor connected).

question1:I AM PROGRAMMING THE IC from FPGA.

configuration:

1.Continous conversion mode

2.800 sps

3.PGA 32 GAIN

4.LOW LATENCY FILTER

5.Delay ...>11*tmod

For acquiring the single channel data i am using following flow:

case(1):

1.write the data to configuration registers. I am using first five registers. while writing to registers sart/sync is high

2.making start/sync pin low  ,waiting for 24 t clk cycles

3..start/sync high,      waiting for 28 t clk cycles

4.start/sync low,  checking for DRDY to be low

6.data acquisition.

7.going back to 1.

case(2):

Now i am changing the mux register to 23(AIN2,AIN3 sensor connected)only sending this value  i mean reading only 2 channel and following from 1 to7 steps as mentioned above.

but drdy is not becoming low.

in case 1 no problem.but in case 2 i could not able to read the data as drdy not becoming low. request u to help us...

  • I've not used this particular ADC, but most of TI's newish ADC's work very, very similarly.  Have you read back all of the registers and verified that they match what you think they should?  Nearly every time I've had difficult with one of these, it has turned out I was mistakenly writing to the wrong register.

  • Hi Ponraj,

    Let's trace back as to what your sequence is doing.

    1.write the data to configuration registers. I am using first five registers. while writing to registers sart/sync is high

    2.making start/sync pin low  ,waiting for 24 t clk cycles

    3..start/sync high,      waiting for 28 t clk cycles

    4.start/sync low,  checking for DRDY to be low

    6.data acquisition.

    7.going back to 1.

    1. For step one you are writing the configuration.  When START/SYNC is high the conversion will start.  When writing the configuration it is not necessary to set START/SYNC high.  This was required for the ADS1248 but is not required for the ADS124S08.  In this case if an ongoing conversion is taking place and the configuration is changed, the conversion will restart.
    2. Setting the START/SYNC low signals that the ADC to stop converting after the current conversion completes.
    3. Setting the START/SYNC pin high restarts the conversion with the current configuration.
    4. This is similar to (2) where setting the pin low will halt further conversions following the completion of the current conversion.  The end of the conversion is signaled by DRDY going low.
    5. Missing 5.
    6. You need to read back the conversion.
    7. After the result has been read, you go back to 1 and reconfigure the mux channels.

    Once you set the START/SYNC pin high the DRDY will also go high and a new conversion will start using the current configuration.  When you change the mux channels, the conversion will restart if START/SYNC is still high.  Pulsing the START/SYNC pin will also restart the conversion.  So DRDY should go low following the end of the conversion unless there is something that forces DRDY to go high and you miss the DRDY.  As I mentioned, DRDY will go high when the START/SYNC pin goes high, but DRDY will also go high on the first rising edge of SCLK.  So it is possible that if the conversion ends during a communication, the DRDY may be missed as the SCLK can force the DRDY pin high.

    In general it is best to use an interrupt driven system for monitoring DRDY as opposed to polling the pin as it may be possible to miss the DRDY if timing is incorrect.  However polling should work in your case as long as the timing for communication completes prior to the end of a conversion period.

    The best way to verify your communication and timing is to use an oscilloscope or logic analyzer to verify that the state machine is working as expected.  Do you have any scope or logic analyzer shots for me to check?

    Best regards,

    Bob B