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.

ADS1241: Self Calibration

Part Number: ADS1241

Hi Experts,

We need your assistance for our customer and I am posting their inquiry below.

Each self-calibration (SELFCAL command) gives quite different values (even the Most Significant Byte) in offset calibration coefficient and full-scale register.

FYI:

  • The ADC is powered up by a linear 3.3V regulator.
  • A raspberry pi controls the ADC via SPI at 1MHz.
  • A 4.9152MHz crystal and a 1V reference are connected,
  • The POL, !DSYNC, !PDWN, BUFEN and !RESET signals are pulled-up (each).
  • The ADC is setup as ACR.Unipolar, ACR.SPEED=1, ACR.BUFEN=1 and ACR.DR=2, all other default (including SETUP).

The communication is stable, the uncalibrated values read are close to the expected (within a range of +/-1%) - trying calibration for better results.

Best regards,

Jonathan

  • Hi Jonathan Navor,

    Can you clarify what you mean by the SELFCAL command gives quite different values? Are you saying that you run the SELFCAL, then read the values from the offset and gain calibration registers, then run SELFCAL again, at which point the offset and gain values are very different compared to the first SELFCAL command?

    What hex values are you reading from the ADC after the SELFCAL command? Can you provide examples of the data you are receiving after multiple efforts to calibrate

    -Bryan

  • Hi Jonathan Navor,

    We saw a post come through where some of the OCR / FSR data was provided. However, now it appears to have been deleted.

    Just so it's clear, if you read the offset and gain calibration registers in order e.g. OCR0 (reg 7) --> OCR1 (reg 8) --> OCR2 (reg 9), the actual calibration coefficient is in the reverse order (LSB to MSB). So if the OCR value that is received is 0x0B0000, this is actually an offset value of 0x00 00 0B. This is a very small number in decimal, and is what you would expect for the ADC offset.

    Similarly, if the FSR value that is received is 0xEC6555, this is actually an FSR value of 0x55 65 EC, which is pretty similar to the default value (0x55 55 59)

    Also note that the values in the OCR and FSR registers are stored in bipolar two's complement coding format, even if the unipolar bit is selected. The ADC performs the conversion internally

    -Bryan

  • Hi Bryan,

    Let me post/reply in behalf of the customer. Here it is below.

    Thank you Bryan. I interpreted the registers MSByte first, tricked by the SPI data (used the same function). Correcting the mistake, the FSR gets a value of roughly 0x555555 after calibration (close to the default value), almost a third of the expected value (0xFFFFFF), while the ADC gives data close to 0xFFFFFF indeed when input=Vref. Still have no clue how to get the advantage of the calibration process...
    Best regards,
    Jonathan
  • Hi Jonathan Navor,

    Why would the FSR give a value of 0xFFFFFF? This is -1 in bipolar mode and max code in unipolar mode (16777216). The expectation is that the FSR value is similar to the default value (0x555559). Then, you take the ratio of the actual code and divide it by the default value (both in decimal), which should give a value close to 1. The ADC then scales the ADC code by this ratio to account for the ADC gain error.

    For example, the default of the FSC register is 0x555559, while one of the values received by the customer was 0x5565FA . These values are 5592409 and 5599148 in decimal, respectively.

    If you divide these numbers you get 5599148 / 5592409 = 1.00121. This is your gain scaling factor. In other words, the ADC converts an uncalibrated ADC code, subtracts the value in the OCR register, then multiplies this value by the gain scaling factor e.g. 1.00121. Then the output data is the calibrated result.

    Finally, the full-scale range extends from +VREF to -VREF. If you apply an input signal equal to VREF, the output code should be 0xFFFFFF if you are in unipolar mode. So the received results make sense

    -Bryan