ADS1218 Read data

Hi Louis,

Welcome to the forum!  Unfortunately I do not fully understand your question.  There is no status data returned from the ADS1218.  The ADS1218 only has one converter with a muxed input.  The input channels are selected based on the desired settings in the registers.

The output result of the conversion data is in a 24 bit format.  You usually read the data into a signed 32 bit value.  For the values you have given you have a returned number of codes of 0x0156fe.  You can convert this number into decimal codes.  The input value measured is the number of codes times the value of 1 LSB.  1 LSB (or the value of 1 code) is a voltage value.  The value of 1 LSB will be determined by the gain applied (if any) and the reference voltage used.  More information is shown on page 38 of the datasheet.

Let me know if you have further questions.

Best regards,

Bob B 

Hi Bob,

This is the SPI data return with time in column 1; MOSI (MO) in column 2;  and MISO (MI) in column 3.

Time

in Second MO  MI

0.291266   11    0   read MUX regiter
0.291302    0    0    # of reg
0.291435    0    1    Value of the MUX register
0.385241    1    1    DRDY interrupt come in Read data (Sync2, 1st interrupt)
0.385474    0    0   MSB
0.385528    0    0   Middle
0.385583    0    0   LSB
0.434984    1    0   DRDY interrupt trig in read data (SYNC2, 2nd interrupt)
0.435217    0    1   MSB     (should be zero, <- this error, when sample other channel it is same, the channel # in)
0.435272    0    FE middle
0.435327    0    A9 LSB

I hope this you understand.  it is not after get data how to process it,  It is get the sample data.

Hi Louis,

According to your timing I think you are ok.  Just to make sure, what is your SCLK clock speed?  Also, you need to make sure that there is at least 4 tosc periods between the RDATA command last clock edge and the first clock edge of clocks sent to retrieve the data result.

What is connected to the inputs?  Getting exactly 0 code is next to impossible due to noise.  If the inputs are floating you could get almost any value.  I would suggest shorting the inputs together.  You still won't see 0, but the results should be within the level of noise at the data rate selected.

Best regards,

Bob B

Hi Bob,

Measure the 8 bits of SPI SCLK,  The width is 14.572uSec, divide by 8 and 1 over it.  The result  is 548.998Khz.  This is the SPI actual speed. 

Next, short the inputs together, or say positive is channel 5 and negative is channel 5, ADS1218 MUX value is 0x55;  MSP430 starts the ADS1218, the result are as following:

Note the time is in the second, MI and MO defined as same as above

time             MO   MI      my notes

1.166235    11    0       read the MUX register to check the setting
1.166271    0    0         read the  # of regs
1.166425    0    55       the value of MUX reg, it is 0x55, the setting is correct.
1.262624    1    55       wait and get the DRDY for sync2, 1st interrupt, read the convert data
1.262682    0    0         MSB
1.262737    0    0         Middle
1.262792    0    0         LSB
1.312367    1    0         wait and get  the DRDY for sync2, 2nd interrupt, read the convert data
1.312425    0    55     MSB <-  this is wrong, the channel info return back
1.31248    0    0         Middle
1.312535    0    2A    LSB

From above capture, the converter result is 0x55002A, without 0x55, the result is great under the limits, I define the limits is +/-1000 counts for 24 bits ADS, The 1000 counts is small number,  the result is 0x2A or 42 counts (in decimal) , the result is great. 

But with ADS1218 result 0x55002A or 5570602 counts (in decimal), the result is over the limits a lot, which one is real the convert result? or are there wrong use the ADS1218?  this design needs to make the result under the limits in the lab setup so that the design could be used in the real application.  In real application, the input to ADS1218 are unknown.  but the design is good,  the system can only work with one unknown.

Why does the ADS1218 return the channel information with the result (RDATA = 0x01 CMD)?

Hi Louis,

There are a couple of unknowns.  I don't know your register settings, so I don't know when you will have valid output data.  I do not know when you change the mux channels and when the data becomes available.  And I don't know if your communication is correct.  You are reading back what you wrote, but that doesn't necessarily mean you are writing correctly.  The best way to verify the communication is to use an oscilloscope or logic analyzer to verify data transition and clock edges.  It would appear that the output register is not getting flushed out and keeps repeating the last set of data in the register.  You must make sure that the adequate setup time has completed following the read data command.  I apologize that I earlier stated 4 tosc periods.  That is from one command to the next command.  You must wait 50 tosc periods between the last clock edge of the RDATA command before the next clock edge of the data byte read.  This is the t6 period in the timing specifications (page 9 of the datasheet).

So you are probably not reading the channel data, just the last data that was in the output buffer because you have not waited long enough for the conversion data to be retrieved and placed into the output buffer.

One other thing to consider.  In auto filter mode (default setting) you must always discard the first conversion (see Figure 27 of the datasheet) as it will be invalid. 

Best regards,

Bob B

Hi Bob,

This is interesting "the output register is not getting flushed out and keeps repeating the last set of data in the register."  how many out put register? MUX and RData are different CMDs.  I do use oscilloscope to look the SCLK with MO and MI.  They are looks right.

4.91Mhz cystal connectes tp ADS1218.  The one fosc is 0.203 uSec. is that right?  50 of those is about 10uSec.  From the data I send to you, the time between any two data are over that time.  If the output register is not flusted, why the sync2 1st interrup,  the 55 is with the CMD. and the sync2 2nd interrupt, the 55 moves to MSB, if it keepin CMD position, it will be good. 

Would you able to simulate the result in your lab?  you must has something setup in your lab to test ADS1218.  it is very easy for you to verify and send the source code or setup out for my reference. Could you do that?

 Louis

Hi Luis,

If you send me scope shots of the communication I will attempt to duplicate.  Here is an example of reading from the ADS1218 (same as the ADS1216) using a bit-bang method.  CS must remain low throughout the entire transaction.

/*
******************************************************************************
*/
long ADS1216ReadData(int fWaitForDataReady)
{
   long Data;
   // if requested, synchronize to /DRDY
   if (fWaitForDataReady)
      ADS1216WaitForDataReady(0);

   // assert CS to start transfer
   ADS1216AssertCS(1);

   // send the command byte
   ADS1216SendByte(ADS1216_CMD_RDATA);

   // delay according to the data sheet
   Pause(50 * tosc);
  
   // get the conversion result
   Data = ADS1216ReceiveByte();
   Data = (Data << 8) | ADS1216ReceiveByte();
   Data = (Data << 8) | ADS1216ReceiveByte();

   // sign extend data
   if (Data & 0x800000)
      Data |= 0xff000000;
  
   // de-assert CS
   ADS1216AssertCS(0);
   return Data;
}

Best regards,

Bob B

Hi Bob,

The other interesting statement, it is "CS must remain low throughout the entire transaction"  how important the CS?  If leave it low all the time from setup register to SYNC2 interrupt 1st time to SYNC2 interrupt 2nd time, the set up other channel.  all the way through.  not toggle it at all. Is it good for the ADS1218?  May that be the problem?  maybe the ADS1218 need to toggle the CS from time to time?  this way will let ADS1218 know the data transaction is done. to do the process.

Louis

Hi Louis,

Even though you can leave ADS1218 CS low throughout several communication transactions (or CS can be tied low), it is possible that the communication can be corrupted.  Toggling CS will reset the SPI bus to a known good starting condition.  This is the process I use as I find it much more reliable.

Best regards,

Bob B