Post Go back to editing

Thermocouple measurement using LTC2368-24 Noise

Category: Hardware

Hello everyone,

i started a little project using LTC2368-24  ( LTC2368CMS24 )  and  the reference voltage source is using a 3.3volt from  LTC6655BHMS8-3.3.

Using 3.3v for vref, i expect to have aprox 0.196 uV/ LSB.

All voltages for the adc chip are buffered with 100n & 47 uf capacitors.

The design is on a 2 layer pcb.

I am stil in the debug phase with this project, so i wanted to see how low can it measure.

So i have shorted to ground both IN+ and IN- and see how low it measures., and i cannot read bellow 97-200 uV.

Tried also with shorting only IN+ & IN-, and the read voltage is a little lower... near 100uV

Tryied even with multiple filtering samples ( 1,32,64... even with 8192 samples), the results are mostly the same.

Most of the read values are in the 0x002XXX .. 0x001FXX hex range.

I also measured the voltage ac ripple on the vref line & the 2v5 line, 1-2mV ripple, didn't saw something noticable.

So at this point i am considering to move everything to a 4 layer pcb, but before i said to ask.

I know in the datasheet there is specified a noise for specific sampling rates, for example at 1 sample is specified 68LSBs, but at 3.3V ref, this would yeld arround 13 uV noise.

But 100-200uV is quite far away, so i am wondering what  i measure is it normal?

Thank you

  • Hi  

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


  • 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,

    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.


    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  

    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.


  • 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.


  • 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.


  • 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.


  • 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  

    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?


  • Hi  

    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?


  • 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.


  • 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!


  • 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.


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

  • Hi,

    i have played with diferent N values and i found something intresting,

    For N=256 i read C15..C0   0x1FE,  this is giving me 510dec,    but if i divide by 2 this number, it gives me 255, which is  N256-1 like expected.

    I noticed the same for other values like...

    N=10000 gives 19998dec /2 = 9999 samples.

    In my case for N=4, gives me 6 which divided by 2 gives me 3 which is N-1.

    The same as for N=16384

    I am missing something here ?!?

  • Hi,

    It seems that it turned out that your data is shifted by one bit, so the SPI settings can be incomptible. Try to find the proper setting.

    Anyway, now you should get the right ADC data if you divide it by 2, so you can test the 33mV reading.


  • Which data is shifted? The adc 24 bit data or the  16bit Nsample data?

    I am a bit confused.

  • Hi,

    Which data is shifted? The adc 24 bit data or the  16bit Nsample data?

    Both, since the 5 bytes form a single bit stream, you have seen the time diagram above. Find the proper SPI setting (read the article I've shown to learn more about SPI modes) to get the bits in the right place.

    Optionally, before doing that, you can divide the data by 2 (you know it is equvivalent to shifting all bits to the right by one) and experiment with different analog input voltages. So use 10k and 100Ohm to get about 33mV, then exchange the resistors to get 3.3V-33mV. Try to get proper readings for these voltages for various averages.
    I think now you will be able to get this ADC work properly.