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.

Need clarification on ADS1258 documentation; possible timing issue

Other Parts Discussed in Thread: ADS1258

Greetings,

I am developing on a conversion system that shares two ADS1258 converters on the same SPI bus. I have a few questions regarding the converter operation that isn't completely clear from the documentation (revised Oct 2007), and also a question about our setup.

First of all, our conversion mode is fixed channel. Originally our general method of reading data was to start a conversion, then read the data using the Channel Data Register format read command until the NEW bit was set. This seems to be indicated to be the ideal method of refreshing data, but another point of the documentation says that the status byte of the data is undefined in fixed channel mode. Which is correct? Is the only way to monitor for new data in fixed channel mode to monitor DRDY?

Another clarification of the documentation: are the DLY bits only relevant to auto scan mode, or are they relevant to fixed-channel mode as well?

Also, we are having some difficulties in trying to run the converter with different data rates. We use a general "sample and read" function that looks like this (in pseudocode):

sample_and_read(channel) {

toggle CS;

write channel to MUXSCH;

start conversion;

loop until DRDY;

read data using direct register format

stop conversion;

}

Based on my understanding of the converter, the only thing that should be different in the previous function for different sample rates is the length of time for loop until DRDY. The previous function works fine for most data rates, but occasionally for one data rate, the converter will somehow have a CONFIG register written to that sets the converter in auto-scan mode, thus corrupting further reads. It appears to be a timing issue. Could a command be misinterpreted if the SPI interface was borderline on the reset interval when the chip writes another command? We suspected this was the problem, so we modified the function to the following:

 

sample_and_read() {

toggle CS;

write selected channel to MUXSCH;

start conversion;

loop until DRDY;

toggle CS;

read data using direct register format

stop conversion;

}

However, this introduces a new problem. For a different data rate, this ends up giving less accurate measurements, but only for a certain channel selection. It is not unit specific, as we have demonstrated this on several units with the converters. Any ideas what our problem might be, or is there a much bigger issue with our sample and read function?

Thanks,

 

Corey

  • Hi Corey,  

    The ADS1258 has two modes that it can be operated in; Auto-scan mode and Fixed-channel mode. Auto-scan mode increments through the channels that are preset by the user in the registers before the convert is initiated. Fixed-channel mode is used when the user wants to convert a single channel over and over again. It does not increment through the channels forcing the user to manually go into the register settings to change the channel that is converted. 

    Since Fixed-channel mode is used when you want to convert a single channel, the channel ID bits and new bit in the STATUS byte are not available in the mode. The customer should be monitoring the /DRDY signal to trigger when they send SCLKs to read back the data. Otherwise, they may read back the data as the output register is being updated (reading data as /DRDY pulses). This would cause all the data word to be corrupt and incorrect. 

    The DLY bits are used to add additional delay to the mux cycling time used in Auto-scan mode. They are ignored in Fixed-channel mode.

    Reading through your psuedocode, there is one thing you need to note. You will notice in the datasheet that in Auto-scan mode the max data rate is 23.7kSPS and in Fixed-channel mode, the max data rate is 125kSPS. The settling time of the internal digital filter is the reason for the decrease in data rate in Auto-scan mode. As the converter changes from channel to channel the converter will need about 5 cycles for the digital filter to settle, this is why there is roughly a 5X difference between the auto scan mode and fixed channel mode. Therefore, if you are going through and changing the mux manually, you will need to give it roughly 5 cycles for the digital filter to settle before you can read out accurate and stable measurements. This may be why your readings are not as accurate under certain data rates vs. others. 

    Regards,

    Tony Calabria 

  • Hi Tony,

    Thanks for your quick response. In regards to the point about settled data: the documentation indicates that the initial conversion after a start condition will be delayed an additional number of clock cycles to allow for the data to settle. So, is it true to say that the first DRDY pulse after a start condition will have fully settled data, or does the user software need to wait for several DRDY cycles before the data is settled?

    Also, in regards to the point about reading data and possible data corruption: the documentation states this can happen with a data direct read, but is it possible with a data register format read? If it is possible with a register format read, then it seems to me that it would be necessary to stop the current conversion before issuing a data read to avoid data corruption, given the absence of precise timing control. Is this true?

    Thanks again,

    Corey

  • Hi Corey, 

    Thank you for your clarification of what you are doing. You are correct, there is a delay after the START condition is initiated that lasts multiple cycles. Your data rate will determine how long this initial delay is. I will have to look into your issue a little more next week and get back to you. Have you read back more than one conversion to see if you inaccuracy is in your first reading or all the readings? 

    As for your second question: Using the "Channel Data Read Command" described on page 30 of the data sheet is what you want to use. This method will allow you to read back the data without having to monitor the /DRDY signal. You will not need to stop the current conversion before reading back. See the excerpt from page 30 (show below): 

    "Unlike the direct read mode, channel data can be read during a DRDY transition without data corruption. This mode is recommended when DRDY is not used and the data is polled to detect for the occurrence of new data or when CS is tied low to avoid the necessity for an SPI timeout that otherwise occurs when reading data directly."

    I will get back to you next week on your first question. 

    Regards,

    Tony Calabria