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.

ADS1256, reading a wrong value

Other Parts Discussed in Thread: ADS1256

I want to build a device based on ads1256. For the experiments, I bought a chinese clone of ads1256evm module and UMFT4222EV module, to communicate it with the computer. I wrote a program that reads the values from the ADC. and writes it to a file.

In the file, I have about 15 incorrect values for every 1024 values.

for example, ADC codes : (if nothing is connected to the analog inputs, I get ...) 

3724   3727  ...  14   ... 3726    3727    3715  ...  919183  ...  3724   3740   3726   ... 14   ...  -8.06091e+006  ... 3717    ... 

I already broke my head.... Wiring diagram of modules as shown in Figure 25 on page 28, datasheet ads1256. Timings, like also took into account.
How can I fight with a wrong value?
  • Hi Andrey,

    Welcome to the E2E Forums!

    I would recommend shorting the inputs to a mid-supply voltage. When the inputs are floating, leakage currents are the only thing forcing the input voltage, which usually results in full-scale readings. Additionally, floating inputs are more sensitive to noise pick-up (for example EMI/RFI).

    The following blog post might give you some additional troubleshooting tips:

     

    Best Regards,
    Chris

  • I hooked AIN0 to VREF test point. Drate set to 3750, nsel to 0x8, acal to 1.
    I get ADC values approximately equal to 2.08563e+006. It is approximately comply with 2.5V.

    But I have in file a wrong values (1-5 values from 1024).
    2.08564e+006 ... -2.94578e+006 ... 2.08565e+006 0 -2.94938e+006 2.08565e+006 ... 2.03976e+006 .... 729043 ... 2.08565e+006

    I do not have the oscilloscope. And I do not understand, how can i catch to wrong diagram among others?

    I have the same problem and same question...
  • Hi Andrey,

    Make sure that the negative input (AINCOM when NSEL = 0x8) is also connected to a valid potential. In the case of the ADS1256, AINCOM can be connected to ground.

    Since you data is flipping signs and going from very large values to very small values, I'd guess that this is an artifact of leaving one of the inputs floating, otherwise something in your system is unstable or the code is not reading the ADC data correctly.

    If the issue is related to the SPI communication, it will be difficult to debug without an oscilloscope... Are you able to correctly read back the device register settings? This will give you some degree of confidence in the SPI communication.

    Best Regards,
    Chris

  • Hi, Christopher!
    I made how You say.
    I wrote program, which read all ADC regs and write them to file (1000 times).
    Result file NOT have a wrong value. I rewritable it file many times, it have same result - no errors!

    In my main program I reading the ADC value with command RADTAC. I change command to RDATA. Result executing program no have errors!!!??? Some values (1-5 values on 1024) may differ from expected value up to four standard deviations. But, in result i not have a wrong value.

    If I return a command RDATAC, i have a wrong value (1-10 value on 1024)...
  • Hi Andrey,

    Okay, I think things are working for you. Let me explain...

    The RDATA and RDATAC commands behave a little bit differently:

    1. RDATAC is a stand-alone command that puts the device in "read data continuously" mode.
      1. In this mode, you are suppose to wait for /DRDY to go low and then retrieve the data from the output shift-register (with 24 SCLKs) BEFORE the next /DRDY falling edge.
      2. You can get corrupted data if you do not retrieve data quickly...If you are in the process of clocking out data when the next /DRDY falling edge occurs, the data will update DURING the read process, giving an invalid result.

    2. RDATA is a multi-byte command. It is required when not operating in "read data continuously" mode.
      1. In this case you would send the RDATA command, followed by 0x00, 0x00, 0x00 (requiring a total of 32 SCLKs to retrieve the data), Make sure you ignore any data on DOUT that is clocked out while the "RDATA" command is clocked in!
      2. This command SAVES the conversion results to a separate output buffer so that the next conversion result does NOT corrupt the data, if you are clocking out data when /DRDY goes low!

     

    If you only see occasional bad data in RDATAC mode, than likely the data is being clocked out during a /DRDY falling edge.


    I would recommend using the RDATA command to avoid corrupted data....Otherwise, you'll need to setup the software to retrieve data right after a /DRDY falling edge. This works best when the /DRDY signal is connected to a GPIO falling-edge triggered input pin, and the interrupt triggers the MCU process to go read ADC data.

     

    Best Regards,
    Chris


  • Hi, Christopher!

    I understand you.
    But, I do not know how i can read values more faster (if i use RDATAC).
    My experimented device is connected to PC (ADS1256->SPI->UMFT4222EV->USB->WINDOWS->MyProgram).

    In description (datasheet ads1256, page 35, command RDATAC ) says: "...After all 24 bits have been read, DRDY goes high. It is not necessary to read back all 24 bits, but DRDY will then _NO_ _RETURN_ _HIGH_ until new data is being updated..."
    ...I do not understand it complitly?

    When DRDY will goes high, if I do not read the value in time?
    How can I understand that the value now read (or was read) at a wrong time?
    Can I skip value if at start reading DRDY is equal LOW?

    Thanks You!!!

    Otherwise, you'll need to setup the software to retrieve data right after a /DRDY falling edge. This works best when the /DRDY signal is connected to a GPIO falling-edge triggered input pin, and the interrupt triggers the MCU process to go read ADC data.

    I'll test it.

  • Hi Andrey,

    What are your SCLK and CLKIN frequencies? SCLK can go up to 1/4th the CLKIN frequency. If you are using a slower SCLK, then it will take longer to clock out the data and increase the likelyhood of corrupted data.

    However, the SCLK frequency might not be the issue. Instead, you might have delay between when /DRDY goes low and when the MCU starts reading the data - especially If the MCU is polling /DRDY. In this case, it might take awhile for the MCU to notice that /DRDY has gone low. It is best if the MCU uses a falling-edge triggered interrupt to quickly respond to /DRDY falling edges!

     

    Regarding /DRDY returning high...

    /DRDY returns high after all 24 bits have been read OR when the ADC begins to update the data. In the later case, /DRDY is only high for a short period before going low again. This is called the "/DRDY Update Time" in the datasheet (see figure 4).

     

    If you don't read the data in time...

    - There is no problem if you're using the RDATA command. You can simply finish reading data. However, you can still lose data if you don't send the RDATA command before the next conversion completes.

    - In "read data continuous" mode, data gets corrupted. The code needs to be written such that this never happens. (If this is not possible to prevent, then you must use the RDATA command to retrieve data.)

    Best Regards,
    Chris