Thermocouple measurement using LTC2368-24 Noise

Hi moro 

How have you determined the 100uV value when the inputs are connected? Is it RMS or peak-to-peak value?

Zoltan

Hi Zoltan,

the value was read directly from the adc without any aditional procesing. I was reading every 50ms the adc's register and just show the data on the screen.

I am doing something wrong?  

Hi,

It seems that you've measured the peak-to-peak value, however, in the datasheet the RMS value is given as 68.5 counts. The peak-to-peak value is much higher, as a rule of thumb, it is often given as 6 or 6.6*RMS value. See this short video about this: RMS Noise to Peak-to-Peak Noise on the ADI website.

Here is the historgram from the datasheet:

I've marked the approximate position of the mean and standard deviation (σ), which is the RMS if you subtract the mean. As you can see, there are samples in the range of 100 to 600, so the data are scattered in about a 500 LSB width interval. In you case it means, that you can easily get samples in 500*3.3V/2^24 range, which is about 98uV.

See also this thread about a similar question: 1/f noise corner frequency.

I hope this helps you.

Zoltan

Hello Zoltan,

please corect me if i say something stupid. To be honest this is a bit overwhelming, its the first time i try to go so deep understanding the adc's datasheet.

This σ  68.5 Lsb rms standard deviation for N=1, right?  If i understood corectly, 68.5 lsb yelds about 13.37 uV rms.

And 6.6* 13.37uv would give a peak of 88uV which is ~455 Lsb, right?

One question regarding the graph from bellow,  i see this counts colum,  what is that 4000 represents?  The number of samples taken with N=1 ?

I supose that i need to do some plotting to figure out where i am with my rms noise

Hi,

Yes, your numbers are correct. The histogram consists of columns, the 4000 is only one tick in the vertical axis that helps you to read the magnitude of the columns. The height of any column is an integer that tells you how many samples fall into the interval of the ADC code represented by the width of the bar (here it is very narrow, not easy to read). If you are not familiar with historgrams, check a brief description on wikipedia or similar source, I don't think this forum is the rigth place to learn more about it.

The main conclusion is that the noise in your system (100uV peak-to-peak) is in agreement with the datasheet (88uV peak-to-peak). Don't forget to see the video about RMS and peak-to-peak noise.

Zoltan

Hi Zoltan,

thanks for your patience, definitely i will look in more detail checking the hystograms.

I modified the setup a little bit, and changed the averaging filter to  ( N =16384),  with IN+ & IN- shorted to Ground,

 i read a peak range between 72-73 uV.  This is giving me a RMS of 11 uV.

What do you think about this?

Hi,

As I see, you averaged 16384 samples and the noise remained almost the same - it is not normal at all. It looks like averaging only two samples, since the result is about σ/√2. Are you sure you use the averaging feature properly?

I don't know how your data look like, but is does not seem to be pure noise.

Zoltan

p.s.: I don't think it is a good idea to measure the peak-to-peak value and then divide it to get the RMS, see the video about the reasosn. Calculate the RMS from the datastream directly, otherwise the error can be much larger.

Hi moro 

I recommend to try the following to isolate the problem

Do not connect both inputs to GND to be sure that zero scale error (+/-20ppm) do not affect the results. You can use the following circuit (sets the voltage to about 330uV at IN+) instead:

Set N=1 and N=4 (see Figure 14) and measure a few hundred samples for both settings. Plot the data and calculate the standard deviation for both cases (do not use peak-to-peak value). For N=4 the standard deviation should be halved. You can share the raw data here (preferably in an excel file).

You can also consider the power supply, SPI interface connection, sampling clock, where noise can enter too.

Be sure you set N and read the averaged data properly. What you got can be an indicator of improper setting or reading.

Zoltan

Hi Zoltan,

i will try your setup, but first of all i wanted to share with you this little detail that maybe has some relevance.

The adc chip is comunicating with the microcontroler ( stm32f103) using opto-isolator, namely ISO7221A.

When you said about the data being incorect, i said myself to check again the timings between the start & ready signals.

I have made some timing captures, with N = 1

Bellow is a logic analyzer capture for the mentioned signals.  The "opto" named ones are directly on the adc pins.

The busy width for both sides is 640 ns.

The start signal width is 1.05 us on both sides.

And there is this propagation delay because of the opto isolator which is around 420ns. 

I am not sure if this can cause some trouble ...

Ok, i noticed that Start convert signal is still high for a period of time while the "Busy" signal already fallen down.

I  rework some software timings for my gpios, and now the signals look corectly like in the datasheet, where start signal goes down before Busy goes down also.

I am not sure if this has any impact in reading the data.

Here is the new logic capture, i will come back latter with the 330uv setup and measurements.

With this ocassion i noticed my opto isolators are the slowest variant...

Hi,

I guess all of the SPI signals go through the isolator, so all of the signals have delay. How high is the SCK frequency? What is the frequency of the ADC START signal? When the SPI read is started relative to these signals?

The delay of the ADC data relative to the SCK edge is the double of the isolator's delay, this should also be considered.

Zoltan

Hi,

Just let me note: this ADC is not the best choice for a thermocouple application. I would choose a precision sigma-delta ADC (e.g. AD7193, AD7793. Much simpler to use, much cheaper, etc. See the Applications/Technology Solutions/Sensor Interfaces/Temperature Sensing/Thermocouple page for more devices, reference designs.

Zoltan

Hi Zoltan,

the adc start frequency is around 21 hz,  i  trigger a conversion every 20 ms.

the spi clock is quite slow,  250 khz, i have roughly 2us on time, and 2us off time.

The time between busy falling edge and the first spi clock rising edge is arround 3.1 us

Hi Zoltan,

the adc start frequency is around 21 hz,  i  trigger a conversion every 20 ms.

the spi clock is quite slow,  250 khz, i have roughly 2us on time, and 2us off time.

The time between busy falling edge and the first spi clock rising edge is arround 3.1 us

I have uploaded here the excel raw data for N=1 and N=4,  400 samples.

One remark,  instead of 100k & 10 ohm,  i used 1Mega & 100 ohm, and 100nf cap.

I agree with you that maybe 24bit is to much for such a aplication.  Of course this adc will not be directly conected to the thermocouple.  I plan to use a instrumentation opamp using max4238 with some gain.

Latter edit: i uploaded the corect data file.

XLSX

This is the start and ready signals for N=4.

I have 1.3 us time between the falling edge of the ready signal and the next rising edge to start a new conversion.

Between the 4 start signals, there is no clocking on the spi.

After the 4th falling edge on the ready signal, i wait arround 3.1us to send 24 spi clocks and readout the value .

Unfortunatly i discovered also the date before and after the opto isolator is diferent because of that delay....

the ADC sends 00 3E AE,  and after the opto, the mcu sees 00 1F 57,    i need to change my setings for the spi. Because of this delay i need to change the data to be validated on the traling edge of the SCK ( CPHA = 1 ).

I will come back in the evening with the corect values, i hope this was my only problem in why the data is strange...

Hi ZoltanDTI 

i removed completely the opto isolators, i noticed that delay from the optical isolators is causing me serious trouble with MOSI and SCK hold/setup times.

Now everything is tied directly to the mcu.

I have attached the correct data now, 400 samples read with N=1 and 400 with N=4.

What do you think?

XLSX

Hi,

I don't see change in the data and the calculated voltage does not seem to match the input voltage. You've used 100 Ohm and 1M for dividing Vref of 3.3V, so the input voltage should be 330uV. The corresponding code is 1678, but even considering the zero scale error (max ±20ppm, ±336 code), your data are far from this.

I do not understand why don't you have the same mean using four averages. Figure 14 shows that you should get the average of four consecutive samples, that should fluctuate around the same mean as the individual samples:

Are the data really the raw values from the ADC?

So until you can't calculate the applied input voltage properly from the ADC output code (at least for N=1), you certainly have somewhere a mistake in reading the data. Maybe in the software.

Zoltan

Hi,

I am wondering, since there is no software power management for supplying the adc,  basically everything is powerd at once ,  and  when the mcu gpio's get initialised  could this trigger these strange values?

Bellow is the 2.5Vdd & 3.3Vref voltage for adc at powerup aswell  the start& busy signals

After the power up at ~560 miliseconds i sent 24 dummy clocks on spi to clear the IO register

for N = 1 ,  SCLK is 250khz,   330uV at input.

This how the raw spi comunication looks like without any software manipulation. The exact same values are read trough software.

Also bellow a picture with the timings between Start-CNV, BUSY and the 1st clock edge

After the busy goes down i clock 24 bits  in frames  of 3 x 8 to readout the data.

And this is how a data frame looks for N = 4 - reading 0x0021CC.

Bellow is how the start-cnv and busy signals look for N=4

After the 4th BUSY falling edge  i send 24 bits to read the averaged by 4 data.

By the way, maybe this sounds stupid.... i presume the adc is already dividing by 4 the data before reading via spi,  I mean i dont need to average this in my sw, right?

At this point i start to go out of ideas.

Hello,

i think i found something strange while checking a data frame.

Here i have ploted also a serial out for debuging the data.

N = 4 and i aparently get a value of hex value of 21BA.

But if i look closely to bits 15-8, judging by the logic voltage levels ( see the zoomed picture bellow) , i actually get 43 in hex

For the rising edge of bit 14 i see the miso goes high delayed by 4 ns from the clock edge, maybe this is why i read this bit as 0 instead of 1.

The same problem for the falling edge of the bit.

The same situation is also for other bits,   the last byte is seen as 0xBA, but based on logic levels seen, i have 0x74.

So my data in reality would be  0x4374 instead of  0x21BA?

Is this 4 ns delay  time normal? 

I am a bit puzzled.

To be honest this is my first time to see a spi device behaving like this.

There are no capacitors or other components on the spi line that can cause such a delay.

Hi,

4ns of delay is absolutely normal, see the datasheet:

If you use the SPI protocol, you may know that if the data is shifted out on the rising edge, then it is sampled on the falling edge (see Introduction to SPI Interface for details), as marked with yellow circles:

So the delay does not mean any problem. Of course, the proper SPI mode should be selected.

I recommend to do the following tests.

1. To be sure that you read the data properly, read 5 bytes of data instead of 3. The last two bytes should represent the number of averages:

Give it a try for different number of averages. Play with this until you read the data correctly.

2. Increase the input voltage to be sure you don't have problems with small errors. So, replace the 1MOhm resistor with 10k, keep the 100 Ohm (do not increase it). Then you have about 33mV at the input. Use N=1 and N=4 as before and see if you can get the correct value.

Good luck!

Zoltan

Hi,

i changed the SPi settings to sample on the falling edge of SCK  ( CPHA  = 1) . This enigma is solved now, at least i have reliable interpretation of the logic data from SPI now....

Before i change the resistors, i  have added the extra 2 bytes to the reading.

With N = 1 for C0..C15 bits i read a value of 0.

But when i change to N = 4  for C0...C15 i get a value of 6 ( see bellow screen shot).

Before i change the resistors, i was wondering why i get a value of 6 samples for average? 

Shouldn't be 4 ?

At least this is my understanding from the picture bellow.

Latter edit ...on i spoted this in the datasheet:

So if N =1 , then i get 0 samples averaged.

But for N=4 shouldnt i get  N-1 averaged samples? 3 ?

Hi,

I interpret the time diagram just as you. So 6 is not OK. But as I said, try this with different number of averages, then you'll get more info about the behavior. Try N=1 too. Are you sure there are no other sampling peaks before this four? Check the signals with an oscilloscope, the logic analyser may have somewhat different levels for the logic values.

Zoltan

p.s.: 3 can be obtained by shifting the bits by one bit to the right. So the SPI settings may be wrong.