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.

ADS1231: Incorrect output value

Part Number: ADS1231
Other Parts Discussed in Thread: ADS1262, ADS124S06, ADS1248

I am polling an ADS1231 in a load cell application. With my applied load I normally get an ADC value of < 0x200000. Occasionally I get ADC values of 0x??ffff.

My code is

void ReadAdc()

{

    if( GetDataBit() )
    {
        return;
    }

// read in the data
    long newValue = 0;
    for( int nBit = 0; nBit < 24; nBit++)
    {
        Clock(CLOCK_PIN);
        newValue <<= 1;
        newValue  += GetDataBit();
    }
// add another clock to force the data pin high so that the above polling works correctly
    Clock(CLOCK_PIN);
}

    void Delay()            { delayMicroseconds(1); }
    void Clock(int nPin)    { digitalWrite(nPin, 1); Delay(); digitalWrite(nPin, 0); Delay(); }

From a scope trace, I can see that when I get the incorrect reading the dout pin remains high throught the clock pulses.

Although I am checking for DOUT low before starting my reading, I am not synchronised with the ADS1231 sample interval and therefore there is a chance that a new sample is initiated during my poll.

Do I need to wait for DOUT clocking high then low so that I can synchronise to the sample interval?

Is there a better part to use for this application (ideally I would like 20+ bits at about 1ksps)

  • I have partially answered my own question :)

    It looks like the problem is caused by not being synchronised with the ADC sample clock

    When I changed my code to
    while( !GetDataBit() )
    ;
    while( GetDataBit() )
    ;

    // read in the data
    long newValue = 0;
    for( int nBit = 0; nBit < 24; nBit++)
    {
    Clock(CLOCK_PIN);
    newValue <<= 1;
    newValue += GetDataBit();
    }
    // add another clock to force the data pin high so that the above polling works correctly
    Clock(CLOCK_PIN);

    I no longer get the unexpected values.

    This is not ideal, because obviously I am wasting time whilst waiting for a conversion.

    I am going to investigate using an interrupt on the data ready pin, but once again this is not going to be ideal.

    Is there a better ADC for my application (20+ bits, 1ksps) - obvioulsy I also am looking for new devices rather than those nearing end of life
  • Hi Robert,

    Welcome to the E2E forum! It is possible to see an issue with the data read if the conversion update occurs during the data read.  This is mentioned in the datasheet on page 13 under Data Retrieval.  The general problem with polling for new data is you want to collect the result as soon as possible after DOUT/DRDY transitions from high to low, but this may become difficult with many other processes running within the loop.  Apparently this is your difficulty with your first code you sent.

    The second piece of code waits for a complete conversion period to end then looks for the update period then reads the data.  This can work, but wastes a lot of time and also will not capture sequential data.  At best you capture every other conversion result.

    There are a number of ways to check for new data.  When using the polling method, it is always best to call the polling function several time within the conversion period.  This will dramatically decrease the risk of reading the results during the update period.  Another method uses an interrupt to read the data as soon as possible after the DOUT/DRDY makes the transition from high to low.

    Another consideration is to maximize the SCLK frequency to make sure that the communication is as fast as possible to read out the data.  

    As to the use of other devices and faster data rates, most likely you will run into the same types of issues.  Also 20+ bits of resolution at 1kHz with gain will be a challenge.  Some devices you could look at are the ADS124S06 and the ADS1262.

    Best regards,

    Bob B

  • Hi Bob,

    Thank you for you answer.

    I agree that the data sheet does mention a problem reading the data during a conversion but maybe it could be made a bit clearer that even if you start the transfer with data ready low you do have to complete it. (I have seen other similar support questions for other devices that imply that this is not an uncommon misunderstanding of how the device operates). It does make it, and similar devices quite difficult to use for simple polled applications.

    My second code sample was not considered to be a final solution just a quick test to prove that I had identified the problem. Whilst it does waste CPU resource, because I send 25 clock pulses therefore leaving DOUT high, providing I poll before DOUT goes low it should still acquire every sample.

    In my test environment, using interrupts is a challenge, but if I use this or a similar device I would look to use them for my production system

    Thank you for yours suggested alternative devices, I will check them out

    Regards

    Rob

  • Hi Rob,

    Thanks for the comments as we are always interested in trying to make things clearer in the datasheets.  One additional comment I would like to make is with respect to the complexity of the various devices we offer. 

    In the case of the ADS1231, the device is pin controlled and has a very simplistic interface.  For this device, the conversion result has a single output register so when the conversion is complete it is placed in this output register when DOUT/DRDY transitions from a high state to a low state.  There is no way to communicate to the ADS1231 by commands and no ability to repeat or read the data from the device additional times.  It is a less complicated device and less expensive.

    We have other devices that will automatically output data in a similar way (conversion result posted to the output register), but that can also have the automatic posting of the conversion result turned off.  One such set of devices is the ADS1248 family.  This is a more complicated device with many registers and has the ability to read a single conversion result by command.  With this device you can turn off the automatic posting of the result and read the results directly.  So with complexity of the device you get additional features that prevent the type of data interruption result you are seeing.

    With the ADS124S06 you have an additional feature whereby once you start reading from the device the conversion result update will not interfere with the current data read.  This device can also operate in a single conversion mode where you can more efficiently control the timing of conversions by issuing a START command to start a conversion cycle.

    So there are many devices and many features so that the operation of the device and the cost of the device can cover a multitude of differing applications.

    Best regards,

    Bob B