ADS1256

Hi Thomas,

Welcome to the TI E2E Forums!

There is some ADS1256 Example Code with the corresponding logic analyzer data posted on this related E2E thread: http://e2e.ti.com/support/data_converters/precision_data_converters/f/73/p/338399/1182307.aspx#1182307. The logic analyzer data can be opened in the Saleae software (available here: https://www.saleae.com/downloads).

The most common mistake with programming the ADS1256 is not sending SDATAC before reading and writing to the device registers. If you do not use the "Read Data Continuously" mode, then you never need to send the SDATAC command again.

Check out the example and let me know if you have any additional questions!

Regards,
Chris

Hi Chris,

can you please tell what the commands 0x23 and 0x28 do. Cause I did not found them on the datasheet.

Thanks, 

Thomas

Hi Chris,

I figured it out, the ADS is working now:) The problem was that I am using an evalution board that also includes a temp sensor as another slave on the spi bus and I forgot to set the CS for this slave to high... so my bad.

So Thanks your sample has been very helpful!!!

Anyway some things are not a 100% clear to me. So when I write the MUX register with the following commands 0x51, 0x00, 0x28, which analog input is selected and why do I need to select an AINp and AINn? Maybe thats a stupid question but I still dont get this even after reading the datasheet several times. 

And another thing. When I read the data the DRDY went high (red circle), is this ok or not? Cause I expected the DRDY to be low while the CS is low. 

Time during 0x01 and 0x00 is 20µs.

Thanks in advance!!!

Thomas

Hi Thomas,

It's good to hear that your SPI communication is working! I'll try to help clarify your questions:

Thomas Holler said:

when I write the MUX register with the following commands 0x51, 0x00, 0x28, which analog input is selected and why do I need to select an AINp and AINn?

0x51 - WREG command staring at register address 01h

0x00 - write to 1 register

0x28 - Register data; for MUX register 0x28 corresponds to the fields: PSELn = 2 & NSELn = 8, or in other words, AIN2 is selected for the positive input (AINp) and AINCOM selected as the negative input (AINn).

Inside the ADC, your input signal is being sampled by a capacitor. AINp and AINn connect to opposite ends of that capacitor to charge it.

The reason you need to select both the positive and negative input is simply because you are measuring voltage. Recall that voltage is a relative measurement - you are always measuring the difference in voltage between two voltage potentials.You may only need to measure a "single-ended" signal, or a voltage with respect to AINCOM or ground; however, may other signals use "differential signaling" which removes common-mode potentials or noise from the real signal that you care about. Either way, every voltage measurement is always differential in some respect so you need to select both signals to measure.

Thomas Holler said:

When I read the data the DRDY went high (red circle), is this ok or not? Cause I expected the DRDY to be low while the CS is low.

/DRDY can toggle while /CS is low (see top of pg 27 in the ADS1256 datasheet).

It is okay if you see /DRDY go high (and stay high) after clocking out all 24 bits of data, or after you start a RREG or WREG command.

It is generally not good to see the /DRDY pulse that you showed. This indicates that the ADC conversion process is occurring faster than you are retrieving the data. This means you are losing data (and if you were using RDATAC mode - you could have corrupted data). You may want to slow down the data rate, by setting the DRATE register to a non-default value (the default value is 0xF0 which corresponds to a 30kSPS data rate - which allows for 33us (1 / 30 kHz) to read the data.

To change DRATE you would send something like 0x53, 0x00, 0x82 (for 100 SPS).

Best Regards,
Chris

Hi Chris,

Thanks again for your support. I was working with ADC the last weeks and trying some new stuff and its working pretty decently. Although I can read the data and applying different filters on it, I still have trouble with the DRDY, as the DRDY signal does not behave the way I expected. I also tried different data rates, without having any effect on the behaviour of the DRDY. 

Attached you can find my record of the SPI communication (logic analyser file), it would be great if you could check it and write me your opinion on this, exspecialy according to the DRDY.

Furhtermore here is picture of the part of the communication which I think is wrong.

4606.14-06-11_Version 1A.zip

Thanks alot for your help, so far it has been a great support!! If you need more detail information please let me know.

Regards

Thomas

Hi Thomas,

Glad I can help!

Your SPI communication looks okay to me...

• /DRDY is pulsing every 33us which corresponds to the default 30kSPS data rate.
• The first two /DRDY pulses indicate that data is updating (Figure 24 in the datasheet).
• The third rising edge occurs because you completed a data read - at which point /DRDY returns high until the next conversion completes.
  • From pg 27...
    "DRDY goes low when new conversion data is available. It is reset high when all 24 bits have been read back using Read Data (RDATA)..."

The only issue I found was the SPI mode setting you were using in Saleae Logic. Make sure you are using CPOL = 0, CPHA = 1, so that you view the data correctly with your logic analyzer. I checked this first because I use the same logic analyzer at times and have made this mistake myself.

My only recommendation is to decrease the data rate... take the same functions you are using to write to the MUX register but change the sent values from 0x51,0x00,0x28 to 0x53,0x00,0x82 (for 100 SPS). You don't need the faster data rate (because you do not capture all of the data points) and you will observe better noise performance using a slower data rate due to additional averaging.

Best Regards,
Chris

Hi Chris,

Thanks! I figured it out, the DRDY now looks pretty decent.

Although I have another issue, so when the sensor is close to the value zero the signal gets very unstable, as I receive some significant jumps, as you can see on the pictures below.

This picture shows a chart of the raw ADC data, when the sensor is close to the value zero.

I attached the sensor to a test bench, so it is not moving at all.

In the following picture you can see numeric values of these jumps.

I am not sure if this issue is related to the sensor itself or the ADC, so my question is if you have seen such an effect earlier? Or is this issue related to the self calibration of ADC? And do I need to change the STATUS register in order to enable the self calibration?

Thanks alot for your time!

Best regards

Thomas

Hi Thomas,

What software program are you using to read the data?

Are the decimal numbers referenced to full-scale (such that +1 is positive full-scale and -1 is negative full-scale)?

Do you have the actual RAW data? (Meaning the codes for the ADC and not the data calculations coming from your software program?

I would want to look into the software to see how it is reading/converting the ADC data. The data coming from the ADS1256 is 24-bits and 2's compliment format. If your software is not expecting 2's compliment data, then that may explain the jumps in the data.

It may also be possible that a data bit is being flipped accidentally. Perhaps the SPI mode is not set correctly, so data is misinterpreted by the MCU. What SPI mode is the Arduino set to use?

I would look for a data processing error first, as this would be the most likely issue. If you can send me the raw data codes that are coming from the ADC, I can help you determine if the ADC data is valid and showing good performance.

Best Regards,
Chris

Hi Chris,

I have the arduino nano connected via SPI to the ADC.

I am using SPI mode 1.

To draw the chart I was first using my own C# application, but I switched now to a software thats called realView.

The decimal numbers are not referenced to ful scale. 

So here is what I am doing on the Arduino:

I read the 3 bytes (_highByte, _middleByte, _lowByte) comming from the ADC and store them into a single variable (result). Here is the source code:

digitalWrite(CS,LOW);

SPI.transfer(0x01);

delayMicroseconds(DELAY_BEFORE_READ);

_highByte = SPI.transfer(0x0);
_middleByte = SPI.transfer(0x0);
_lowByte = SPI.transfer(0x0);

digitalWrite(CS, HIGH);

delayMicroseconds(DELAY_AFTER_READ);

result = _highByte * 65536 + _middleByte * 256 + _lowByte;

Directly after that I convert the unsigned 24 bit data to signed 32 bit data

if (result & 0x00800000)
{
result |= 0xff000000;
}

Then I cast the result into a float variable

result_float = (float)result;

So related to the jumps I noticed that I have these jumps within the raw data that I read from the ADC.

Here is the data that I recorded. 

7370	0,0159065	11:23:15
5196	0,0112149	11:23:15
8731,93	0,0188463	11:23:16
5058	0,0109168	11:23:16
9569	0,0206512	11:23:17
8584	0,0185266	11:23:17
9592	0,020702	11:23:18
6411	0,0138365	11:23:18
6314	0,0136275	11:23:19
4359	0,00940787	11:23:19
6035,65	0,0130266	11:23:20
7628	0,0164633	11:23:20
6172,91	0,0133221	11:23:21
7002	0,0151133	11:23:21
7521,96	0,0162344	11:23:22
8178	0,0176507	11:23:22
8992,37	0,0194093	11:23:23
9524,94	0,0205577	11:23:23
9650,75	0,0208293	11:23:24
8483,34	0,0183096	11:23:24
7702,56	0,0166244	11:23:25
7585,23	0,0163715	11:23:25
6444,29	0,0139087	11:23:26
5149,59	0,0111144	11:23:26
6720,85	0,0145058	11:23:27
6007,44	0,0129662	11:23:27
2133,76	0,00460541	11:23:28
2718,81	0,00586798	11:23:28
1168,11	0,00252101	11:23:29
4328,66	0,00934219	11:23:29
711,262	0,00153507	11:23:30
162,086	0,000349824	11:23:30
103,116	0,00022254	11:23:31
2087,02	0,00450425	11:23:31
622,942	0,00134451	11:23:32
4672,88	0,0100854	11:23:32
1780,81	0,00384362	11:23:33
2157,23	0,00465591	11:23:33
2004,31	0,00432575	11:23:34
534,944	0,00115449	11:23:34
1,66782E7	-0,141326	11:23:35
34552,9	0,00215495	11:23:35
864,536	0,00186594	11:23:36
2427,87	0,00523987	11:23:36
2224,41	0,00480096	11:23:37
1874,7	0,00404614	11:23:37
248,258	0,000535802	11:23:38
2550,38	0,00550449	11:23:38
1178,76	0,00254405	11:23:39
1,66782E7	-0,141362	11:23:39
38145,7	0,00990887	11:23:40
1,66764E7	-0,145194	11:23:40
37581,3	0,00869104	11:23:41
2779,79	0,00599955	11:23:41
2520,51	0,00544005	11:23:42
2314,41	0,00499515	11:23:42
7136,34	0,0154018	11:23:43
4332,64	0,0093512	11:23:43
4978,69	0,0107455	11:23:44
2429,11	0,00524255	11:23:44
236,384	0,000510172	11:23:45
3628,19	0,00783056	11:23:45
3026,22	0,00653129	11:23:46
3559,93	0,00768329	11:23:46
3205,71	0,00691898	11:23:47
2560,29	0,00552603	11:23:47
208,71	0,000450466	11:23:48
1570,26	0,00338908	11:23:48
2936,27	0,0063374	11:23:49
1985,91	0,00428605	11:23:49
1,66775E7	-0,142847	11:23:50
33828	0,000590409	11:23:50
5990,81	0,0129297	11:23:51
5525,95	0,0119268	11:23:51
5585,88	0,0120554	11:23:52
6145,88	0,0132648	11:23:52
6993,3	0,0150931	11:23:53
7220,55	0,0155835	11:23:53
8045,35	0,0173638	11:23:54
4363,38	0,00941686	11:23:54
7084,53	0,0152897	11:23:55
6149,88	0,0132726	11:23:55
7417,46	0,016009	11:23:56
6889,06	0,0148687	11:23:56
9206,35	0,0198711	11:23:57
9212	0,0198815	11:23:57
8097,73	0,017477	11:23:58

The text document is separated into 3 columns -> 1. the variable result (so raw ADC data), 2. value in degree, 3. timestamp

You can see that I have 4 jumps at the time 11:23:35,11:23:39, 11:23:40 and 11:23:50. 

If you want I can send you my complete Arduino projekt and the SPI protocol, but due to our client I can not post all of this within this blog. Let me know if you need more information. 

Furthermore I would like thank for your support and your quick response. 

Best regards

Thomas

Hi Chris,

you got the point!

I was using byte variables to store the ADC data. I cant belive I missed this, Thanks for your help, we get now rid of the jumps.

Thanks, I come back to you if I have further question.

Great support! Thank you!

Hi Chris,

I have another question related to the data rate setting within the DRATE register.

I was testing several settings for the DRATE register and I noticed that I can only set the data rate between 30,000 SPS (default) and 3,750 SPS. If I go any lower, for example 2,000 SPS the data that I receive from ADC is incorrect (means that the data is always the maximum value of the measuring range, in my case about 18 degree).

Do you have any idea why this is happening, maybe some timing issue?

Below you will see the function (registerSetup) that I use within the arduino to initialize the ADC.

void registerSetup(void)
   {
   
    digitalWrite(CS,LOW);
    SPI.transfer(0x52);    //ADCON
    SPI.transfer(0x00);
    SPI.transfer(0x00);
    digitalWrite(CS, HIGH);
  
    digitalWrite(CS,LOW);
    SPI.transfer(0x53);   //DRATE
    SPI.transfer(0x00);
    SPI.transfer(0xC0);  // 3,750 SPS
    digitalWrite(CS, HIGH);
  
    digitalWrite(CS,LOW);
    SPI.transfer(0x54);   //GPIO
    SPI.transfer(0x00);
    SPI.transfer(0xF0);
    digitalWrite(CS, HIGH);
   
    digitalWrite(CS,LOW);
    SPI.transfer(0x51);   //MUX
    SPI.transfer(0x00);
    SPI.transfer(0x01);
    digitalWrite(CS, HIGH);
   
    digitalWrite(CS,LOW);
    SPI.transfer(0xFC);  
    digitalWrite(CS, HIGH);
   
    digitalWrite(CS,LOW);
    SPI.transfer(0x00);  
    digitalWrite(CS, HIGH);
   
    delayMicroseconds(440);
   
    digitalWrite(CS,LOW);
    SPI.transfer(0xF0);  
    digitalWrite(CS, HIGH);
   
    delay(120);
   }

Thanks in advanced and best regards!

Thomas

Hi Thomas,

This datarate issue is odd. I would expect inaccurate results at the faster data rates because of the settling times shown in table 15 of the datasheet.

One ongoing question I have is how do you check for the /DRDY pulse? In your code you are inserting delays. Typically, you should wait for an interrupt or poll the /DRDY signal to know that a conversion has completed.

At the faster data rates, you'll also need to wait for multiple /DRDY pulses (multiple conversions) for data to fully pass through the digital filter and come out settled. One thing you can check, even at the lower data rates, is to take multiple conversions and see if the output codes get closer to your expected value.

If you see this, you have a settling issue. Either, you're

• changing the multiplexer input during a conversion and getting an output which is an average of the two channels,
• or your input filtering circuitry is still charging to the applied input voltage and is not providing a settled input to the ADC.

Try capturing multiple conversions and seeing if your data is consistent.

Also, I might suggest putting the self-calibration command before the SYNC and WAKEUP commands. It is odd to perform calibration after your conversion. Be sure to wait for the calibration to complete. It's length will change based on the data rate. Reading /DRDY is the best way to know when it has completed.

Best Regards,
Chris

Hi Chris,

Thanks for your help!

I am now checking the DRDY and with that it works fine, I can set any DRATE I want, Thanks.

So actually everthing is working fine and we have more or less finished our application with the ADC and we have tested it intensivly, so the results that we get are within the specification of our customer.

As you have been a great support I would like to ask you if you could check the complete scetch and the communication between the arduino and the adc, you might find some things we could improve in order to achieve better results? The source code is keept very simple and straight forward, so it will be easy to understand.

So if you could help us with that one last step we would really appreciate it.

I dont want to post the complete scetch within this blog, so is it possible that you could send me your mail address and I will send the sctech together with a description and the specification to you.

Thanks in advanced!

Best regards

Thomas  

Hi Thomas,

I'd be glad to look at the communication!

You can send files to us at this email address: pa_deltasigma_apps@ti.com

Best Regards,
Chris