ADS131E08: Readings multiples of ten

Hi Alberto S. G.

Is it possible you are reading the data incorrectly, or converting incorrectly?

Can you post the actual raw hex data from the ADC instead of the converted values?

Would the data be correct on a per channel basis if you scaled each value by 10? For example, does -10309 correspond to the correct voltage you expect to read on that channel?

-Bryan

We have reviewed the ADC_OUT with an oscilloscpote and the frame sent by the ADCs looks multiple of ten too.

This screenshot show the treated frame we share 

It´s backwards: 

0x00c00001 (header ADC1)

0x00c00800 (header ADC2)

0x00c00000 (header ADC3)

0x00000578 (ch1)

0xfffffb6e(ch2)

0xfffffc4a(ch3)

....

We convert the 24bits complement´s two to 32 bits before of sending.

We have an external CLK of 1.88MHz instead of 2.048 in order to get 14.4ksps instead of 16ksps (DR CONFIG1=010).

Vsupply + - 2V5

Vref 4V

Hi Alberto S. G.

Alberto S. G. said:

0x00c00001 (header ADC1)

0x00c00800 (header ADC2)

0x00c00000 (header ADC3)

I don't understand what "(header ADC1)" means, can you explain?

I asked some questions in my previous post, can you help answer them:

Bryan Lizon86 said:

Can you post the actual raw hex data from the ADC instead of the converted values?

I'm looking for just the raw data, not anything you have sign extended or manipulated in any way. You can use a logic analyzer to pull the data directly from the ADC DOUT pin.

Bryan Lizon86 said:

Would the data be correct on a per channel basis if you scaled each value by 10? For example, does -10309 correspond to the correct voltage you expect to read on that channel?

It is helpful to know what you expect to read versus what you are actually reading. Or, if you apply a 1V signal to the ADC and take 1000 samples, what values do you get?

-Bryan

Sorry Brian,

Yes, I think the value is the expected, but we are losing accuracy.

by example:

-3V (Vref 4)->  (-6291456 expected) --> 6291450 (read value ignoring the noise)

1V (Vref 4)->  (2097152 expected) --> 2097150 (read value ignoring the noise)

I have a testing SW that gets a 1sec capture and the noise surround 0.1 mV but it could be due to my circuit. No worried for now :)

The point that I can´t understand and I would like to discover is why the value always is finishing in 0.  

I ask my partners about the raw data, but the couldn´t provide me it. They just read de ADC_OUT pin with an ocilloscope and confirm me that the read values finished with 0. I will use a logic analyzer and try to read DOUT.

 The header that I meant is the first register we ask to the ADC_DOUT with the status registers.

HI Brian!

We just realized that if we choose a 8ksps data rate instead of our 16ksps that we need. The issue is solved.

 COuld it be a ENOB problem? Does the ADC replace noise with zeros?

Hi Alberto S. G.

Thanks for answering my questions, and clarifying your results.

The ADC should not artificially change the output data depending on the data rate, unless you are operating at 32kSPS or greater where the ADC only outputs 16 bits of data. In fact, it really should be the opposite, where the lower bits are toggling at higher data rates because there is noise, whereas at lower data rates that have less noise those last bits could be stable

I should also point out that being off by a few codes is actually really good. You can see from Table 2 that the ADS131E08 is not a 24-bit noise-free ADC, in fact the best effective resolution (ENOB) you should expect is around 20 bits at the lowest data rate. At 16 kSPS you should expect around 17 bits of resolution, so only being off by a few codes is way better than expected. I still am not sure why that last bit was not toggling at 16 kSPS, but is toggling at 8kSPS. You are definitely operating at 16 kSPS, not 32 kSPS? And you have all channels enabled?

-Bryan

Yes, we have DR 16ksps, this screenshot show the DRDY edge every 62us.

According with our ENOB, 17.33bits (Vref=4 DR=16ksps) we should have 24.27uVnoise and the info I´m losing corresponds to 47.6nV.

The point we wanted was understand it, in order to avoid strange behaviours and improve the functionality...

Hi Alberto S. G.

I don't think anything is wrong here, as you don't appear to have a stuck bit since it is toggling when the data rate = 8 kSPS. But I agree it does seem like non-random behavior for the last bit to always be a 0

Can you read back the data multiple times between DRDY periods to see if it is the same every time? Note the requirements stated in the datasheet for multiple read back, which I copied below

Can you also take 1000 samples of data at 16 kSPS and 8 kSPS with the same input voltage applied (or shorted inputs), and send that data to me so I can review. Again, it would be helpful to see the raw ADC data, not data you have manipulated in code. You can also provide the data for all 8 channels

-Bryan

Hello Brian,

I am attaching both captures, with 8ksps and 16ksps. We have 12 channels, and in this case we configured the channel 4 (fourth column) with MVDD as datashhet said, in ch4 MUX[2:0] = 011 means MVDD/4 in our case, 3.3/4.

The data is signed decimal with 4Vref.

analog_info_8KHz.txtanalog_info_16KHz.txt

We need modify our code to get more than one capture in the same DRDY. I am sharing with you the captures when we get it.

THank you a lot !!

Hi Alberto S. G.

I'm having a hard time believing that the ADC is doing this. This is not just LSB = 0, which could be possible, but it is the entire 24 bit frame always adding up to a multiple of 10 in decimal.

Is it possible that there is a timing issue as you increase the clock rate, which is why it works at 8kSPS and not at 16kSPS? Does it work at the lower data rates? Again, seeing the actual data on a logic analyzer is the only way to tell what's going on. The data you sent it not very valuable because there's always a chance that the conversion process messed something up

-Bryan

Hi Brian, We got a few frames of the 16ksps raw data of DOUT. We have no analyzer so it was a bit hard. But I hope it's worth it

As you can see, every channel measure ends in zero. it seems that is not a conversion issue. He have no faults in the status word and the GPIO bit up is an active low reset...

Let us know if these few plots can help you to understand what is happening...

Thank you!!

Hi Alberto S. G.,

Let me look into this more and get back to you tomorrow

-Bryan

Hi Alberto S. G.,

Apologies, I could not look into this today, I will try to have something for you by the end of the day on Monday

Thanks for your patience

-Bryan