Fluctuating temp readings

[greencardigan]

I'm using an 18X to read the temp of a K type thermoucouple via a MAX6675.

http://datasheets.maxim-ic.com/en/ds/MAX6675.pdf

The resulting reading are in the right ballpark but are fluctuating a bit. Consecutive readings 1 second apart might be something like this.

16.75
17.00
16.25
16.25
17.25
16.50
17.00

Is this to be expected?? It may not be a problem with my intended use but I'd like to sort it out if possible.

 

[premelec]

could be noise or not - do you have the TC clamped in an aluminum block for instance? 1/4 C degree variations could happen if just in air or liquid and also depends on the thickness of the TC wires - thermal mass... Or could be other problem - perhaps isolate with short jumper in place before TC installed and see what that does... these things get a bit picky at fine resolution... I think Maxim may have an app note if you look... good luck.

 

[leftyretro]

Well variations can come from several sources:

Process noise (air movement/etc)

sensor noise (TC are just millivolt generators)

MAX6675/PIXAXE (A/D sample processing noise)

I worked at a oil refinery for 30 years on process control and monitoring systems. They were million dollar systems but we would never dream of displaying or process tenths of a degree resolution, just units. Also the history/archiving system would average 60 one second scanned readings into one min values for storing in history. That acts like a filter to keep the meaningless noise out of otherwise useful data for trending and calculation purposes.

Lefty

 

[Dippy]

I've never used the device, but Data Sheet says it's very sensitive to supply noise and ic temp.
Have you taken advice on Data Sheet re: noise and other things?
(Page5).

Have you checked your code?

Is it possible to connect chip so that it sees something absolutley stable, so that you can 'nail' whether its a sensor thing or a chip thing? i.e. so you can separate the variables?

 

[greencardigan]

Thanks for the suggestions.

I don't think fluctuations in air temps are the problem. The same thermocouple connected to my DMM gives steady readings.

I have read through the datasheet and have a 0.1μF ceramic capacitor near the supply pin.

I'll keep investigating. Thanks.

 

[manuka]

The MAX6675 data sheet mentions (bottom P.5) that noise may arise from both a rough power supply & adjacent wiring. Have you attended to these possible culprits? If you are working with modest ambient temps (where TC of course are rather wasted),then perhaps instead try an industry standard DS18B20, which is of course directly PICAXE readable via READTEMP. It's good for temps between -55 °C & +125 °C, with ±½ °C accuracy between -10 °C and +85 °C. 12 bit resolution can be given with READTEMP12.

 

[greencardigan]

I'll be measuring up to 250 deg C so ds18b20 is out.

I'm running the picaxe off 3 x AAA batteries so I don't think power supply should be a problem.

I have been testing it close to my laptop and associated wiring. Is that likely to be an issue?

 

[boriz]

I would just average the current reading with the previous reading. current+previous/2

 

[demonicpicaxeguy]

I'll be measuring up to 250 deg C so ds18b20 is out.

I'm running the picaxe off 3 x AAA batteries so I don't think power supply should be a problem.

I have been testing it close to my laptop and associated wiring. Is that likely to be an issue?

i've found that some of the wireless network cards especially in laptops can bring in considerable interference, even a 240v lead can cause some too, it's best to have a seperate spot on the table where there is nothing but your picaxe project
some applications with datalogging i've found where the interference can't be helped i normally just take 10 readings and average it out

 

[Dippy]

"I have been testing it close to my laptop and associated wiring. Is that likely to be an issue?"

- maybe.

So why not try it in different positions and do a semi-scientific experiment?
Why not try a bit of home-made screening?
Can you 'scope it? (the 'signal' and the chip supply).
Does putting your hand near the wiring/chip make a difference?
Is it all on a hairy bread-board or a nice neat pcb with plenty of ground plane?

Averaging is a good idea. Try averaging several quick readings 1 second apart for comparison. Personally, I'd be very disappointed with the figures you posted.

 

[Dippy]

PS. Second thoughts. Did you manage to isolate absolutely whether it is the chip or the KTC causing the fluctuations?

Not sure how your multimeter works but maybe its averaging a few samples and smoothing things? Therefore giving you an artificially 'good' result. I'm sure someone here knows exactly how every multimeter works. Got a 'scope? No? Get one.

Can you supply a stable input to chip to check data o/p?

 

[greencardigan]

I tried putting a short wire link across the TC inputs and still get the following

18.50
19.00
18.75
18.75
18.75
18.75
18.75
18.75
19.00
18.50
18.50
19.00
18.75
18.75
18.75
19.00
19.00

Looks like it's not the TC.

No, I don't have a scope.

Someone mentioned haveing good ground planes. I don't really understand this too much. But, i have pics of my stripboard and circuits. They might help.

 

[greencardigan]

And please excuse the dodgey stripboard. It's only the second time I've tried using them.

 

[premelec]

I'd put in some larger low ESR capacitors across the chips and possibly a power supply regulator just for the TC chip... you're getting there... persist!

 

[greencardigan]

I bought some low esr caps yesterday. I got 22U, 47U, 100U, 220U, 470U and 1000U.

Which do you suggest would be best? Or maybe I will just try them all.

 

[greencardigan]

I tried the low esr caps above and also a 2200uF and a 4700uF. They dont seem to make much (if any) difference.

 

[inglewoodpete]

Next step, if you haven't done it already, is to put 100n capacitors across the power pins of both chips on the board. By that, I mean on the copper side of the board directly across the 0v and Vss pins of the chips, with leads as short as possible. I suspect that there is HF switching noise getting into the power due the nature of digital chips.

 

[Dippy]

If I were doing this my next steps would be:-

1. Powering it from an expensive bench power supply. Or more batteries + 5V regulator/caps.
Probably not needed but would be a good comparison vs batteries.

2. Putting it in a metal box (grounded).
Using vero/stripboard you can end up with long track lengths which make good aerials.
There is obviously something casuing instability and you've got to nail it.
(And you have treble-checked your stripboard and quadruple-checked that your chopped tracks are perfectly chopped)

3. Posting the raw data just in case the rounding software is a bit excitable.
A typo may have slipped through. Maybe it was cut'n'paste but you never know....

4. Try another 6675.
Unlikely to be a fault, but, again, you never know and if you spent 3 weeks banging your head (and ours) and found it was the compensation diode or something annoying then you'd go mad.

5. Have you looked around on the net to see if anyone has had similar problems using other processors? Maybe not or maybe so. If so, and solution not easy then look into a different chip.

 

[moxhamj]

I'd definitely second Dippy's suggestions, especially #1. Three batteries are fine for flashing leds and the like, but not so good for reading any analog voltage. As soon as there is any readadc command in a program it is time to go for regulated 5V. Use a low quiescent 5V reg eg LM2936 and a supply with at least 7V.

 

[eclectic]

Would the "enhanced" serial circuit
(Manual 1. page 32)
be of any value?

It would be fairly straightforward to add a BAT85 and a 180 ohm resistor.
e

 

[Dippy]

Actually, as an aside. I wonder if the cable is affecting things?

 

[eclectic]

And another aside.

The circuit in post #12 shows IN6 on the 18X

From Hippy'y thread
http://www.picaxeforum.co.uk/showthread.php?t=8609

PICAXE-18X ( 16F88 )
Serial In ST
In 0 TTL
In 1 TTL
In 2 TTL
In 6 ST
In 7 ST


TTL ( Vsupply <= 4.5V )

Vih : >= 0.25 * Vsupply + 0.8V
Vil : <= 0.15 * Vsupply

Schmitt Trigger (ST)

Vih : >= 0.8 * Vsupply ( >= 4V @ 5V )
Vil : <= 0.2 * Vsupply ( <= 1V @ 5V )

Would using inputs 0 or 1 make a difference?

I'd like to know the answer purely for my own education.

e

 

[Dippy]

Eclectic, check out the Maxim Data Sheet.

Output High Voltage = VCC - 0.4 V
Output Low Voltage = 0.4 V

So @ 4.5V (approx 3AAs)

Maxim:-
High out 4.1V (minimum)
Low out 0.4V (maximum)
@1.6mA load

So, in theory, shouldn't be a problem assuming chip is to spec. and assuming my calculator+finger works and that my Ebay glasses haven't steamed up.

I think Maxim would have had a few letters of complaint if it was a problem

 

[greencardigan]

OK, I'll see if I can try another power supply. I don't have an 'expensive bench power supply' though.

Yes, the data was a cut and paste.

I do have a few more 6675s from another source. So I will try them.

Actually, as an aside. I wonder if the cable is affecting things?

Which cable? The TC cable??

 

[Dippy]

No, I meant the download cable (acting as an aerial).

You've covered all the basic stuff short of a good power supply.

The 2 main areas of concentration revolve around that chip being very sensitive. But is it sensitive to 'airborne' interference or from the power supply?
Doing things on stripboard means you have long unscreened wires.
Doing things from battery mean you have (potentially) an unstable (albeit slightly) power supply.

You haven't posted examples of the raw data. So, is there an error in the rounding in the code?

Is the chip duff? Is it overcompensating the cold junction and giving silly numbers? Can you specifically heat up/cool down the chip to see if it goes mad.

Have you tried putting the complete board in a grounded metal box with the chip signal inputs shorted? (Don't forget to electrically insulate your board).

Have you emailed the manufcaturers Tech department to get a 'real world' opinion on stability? (Don't tell them you've done it on stripboard or they'll laugh). Don't be scared to ask them. As an aside, I've found Tech Depts from Microchip to be quite helpful sometimes.

Maybe it'll only work well on pcb with short track lengths and ground plane. I really don't know.

Bottom line: I'm clutching at straws... and I've run out of ideas.

[ Maybe not applicable here, but for serious people generally:-
I know I've said it dozen times, but serious prototypers/designers canNOT do proper and safe designing/testing without a good quality (and I mean GOOD with a capital F) bench power supply with variable V and I. Example: http://cpc.farnell.com/IN01596/test-equipment/product.us0?sku=tti-thurlby-thandar-instruments-el183
Yes, it costs a lot. But you can be totally confident in the product.
This is just an example and there are other brands of similar quality, but anything cheap should be avoided if the wallet can stand it. It just depends how seriously you take your design work. Pros use this type stuff. Amateurs use Beijing Bangers. ]

 

[greencardigan]

OK, I tried another 6675 and no change.

and here's the code and raw data I'm getting

symbol cs = output4
symbol sck = output5
symbol miso = input6
symbol val = w0
symbol n = b6

do
high cs
low sck

low cs

val = 0
for n = 1 to 16
high sck
val = val * 2 + miso
low sck
next n

high cs

sertxd (#val)
sertxd (13,10)

pause 1000
loop


And the raw data.

536
544
536
536
560
552
552
536
536
552
536
552
552
552
560
552
544
536
560
552
552
552
544
536
544
552
552
552
536
552
544
536
552
560

 

[Dippy]

Now, I have never used this chip so this is merely a suggestion to try and it pobably won't won't work.

1. Try storing the individual bits . Poking 16 locations shouldn't be a problem to store and review. Then check the bits to see if there is some predicatable error.

2. Try (straw cluching on full power) replacing your:
high sck
val = val * 2 + miso
low sck

with
high sck
low sck
val = val * 2 + miso

or
pulsout sck,1
val = val * 2 + miso

It probably won't work but it sounds like 'desparation time' to me.
I take you haven't tried a pukka stabilised power supply and that you haven't contacted Maxims tech department??

Alterntively, that's the best res you're going to get. Have you tried it in boiling water or a known higher temp? Is it an offset error or a multiplicative one? Is +/-0.5oC OK over whole range?

 

[Rstevenson]

High CS ' idle
Low SCK

Low CS ' start transmission sequence

let w0 = 0
let MISO = 0
For N = 1 to 16
High SCK
let w0 = w0 * 2 + MISO
Low SCK
Next

High CS ' terminate the transmission

w0 = w0 / 8 ' use only the 13 most sig bits
Return

try that. i got that directly from someones (cant remember at the moment) site.

 

[hippy]

I think that the whole concern of noise on the digital lines is completely mis-placed. Far more likely that the error is in the KTC analogue input, noise, supply regulation issues or something analogue related.

Before even looking at the datasheet it was interesting to see that the output is only ever a particular set of values ...

536 536 536 536 536 536 536 536 536 536
544 544 544 544 544
552 552 552 552 552 552 552 552 552 552 552 552 552 552 552
560 560 560 560

Those values ( $218, $21D, $228, $230 ) in binary are ...

%0010 0001 1000
%0010 0001 1101
%0010 0010 1000
%0010 0011 0000

Looking at the datasheet ( figure 2, page 6 ) and it's clear the three LSB's are irrelevant to the temperature reading. Why they change we will come back to later, but take them out of the equation for now and we're left with ...

%0100 0011
%0100 0011
%0100 0101
%0100 0110

That's now a range of 35 to 38, 36.5 +/-1.5

The data sheet claims sensitivity is 10.25uV per LSB so that would equate to noise of just under +/-16uV. That seems entirely reasonable to me ( even if this were a wire link ) and almost impossible to remove without some very good design work, and, no offence, vero-board isn't up to the task, nor probably is the power supply. In fact to get rid of noise at that level entirely is probably beyond the realms of all but a highly skilled electronics engineer. The chip itself has a margin of error of between +/-61uV and +/-92uV.

Additionally, on Page 5, "Read the 16 output bits on the falling edge of the clock"; so use Dippy's suggested change to the reading of 'miso' and building up of data reading of 'val' - Forget that, see later edit

Now back to those three changing lowest lsb's. From Page 5, "Bit D2 is normally low and goes high when the thermocouple input is open. D1 is low to provide a device ID for the MAX6675 and bit D0 is three-state".

Not sure what D1 means ( didn't read all the datasheet ), but D0 would be expected to vary occasionally 0 or 1, D1 might as well. D2 is the interesting one, it should never go high, so not sure why it is doing that for the "544" readings. Try the following code and see what that does ...

High cs
Low sck
Do
  Low cs
  For n = 1 to 16
    High sck
    val = val * 2 + miso
    Low sck 
  Next
  High cs
  SerTxd( #bit2," ",#bit1," ",#bit0," : ")
  val = val / 8
  SerTxd( #val, CR, LF )
  Pause 1000
Loop

Seems to be that this entire thread has come down to no one having read the datasheet. Often understandable for those answering questions posed who don't have the time to spare, but as Dippy has said before, anyone using a component should understand what they are doing and how it works before attempting that and that means reading the datasheet, more importantly understanding that.

Going right back to the original post; if these three lsb's were not removed from the raw data and they were changing, this would lead to errors in any calculation and misreporting of temperature. Whenever there is discrepancy with expected or changes in values, go back to checking the raw data first, if that's not right nothing else will be.

Added : I guess the time of Rstevenson's post shows how much time and effort has go into solving and explaining problems ( I was typing and reading datasheets while that post was made ).

Given that that example reads while SCLK is high made me question what "Read the 16 output bits on the falling edge of the clock" means when the data isn't being latched at exactly that time.

The answer comes in Figure 2, "tDo", which elsewhere is said to be 100nS max. A PICAXE cannot read the MISO line that quickly after lowering SCK, so it has to read the MISO line before doing so.

 

[greencardigan]

Thanks again for your efforts. I'll try to digest the last few posts and get back.

The code i'm using is from phandersons website.

 

[greencardigan]

I've tried a few variation of the code with output show below each.

I also tried recording and storing 20 consecutive readings without the serial cable connected. no change.

and the pulsout idea didn't help either.

do
	high cs
	low sck
	low cs
	
	val = 0
	for n = 1 to 16
		high sck
		val = val * 2 + miso
		sertxd (#miso," ")
		low sck
	next n
	
	high cs
	
	sertxd (#val,13,10)
	pause 1000
loop

0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 400
0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 400
0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 392
0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 400
0 0 0 0 0 0 0 1 1 0 0 1 1 0 0 0 408
0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 392
0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 400
0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 400
0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 392
0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 392
0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 400
0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 400
0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 400
0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 392
0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 392
0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 400
0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 384
0 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0 336
0 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 32764
0 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 32764
0 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 32764
0 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 32764
0 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0 336
0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 392
0 0 0 0 0 0 0 1 1 0 0 1 1 0 0 0 408
0 0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 400


#########################

do
	high cs
	low sck
	low cs
	
	val = 0
	for n = 1 to 16
		high sck
		low sck
		val = val * 2 + miso
		sertxd (#miso," ")
	next n
	
	high cs
	
	sertxd (#val,13,10)
	pause 1000
loop

0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 800
0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 768
0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 768
0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 800
0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 768
0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 800
0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 800
0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 800
0 0 0 0 0 0 1 1 0 0 1 1 0 0 0 0 816
0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 784
0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 784
0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 800
0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 800
0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 768
0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 784
0 0 0 0 0 0 1 0 1 1 1 1 0 0 0 0 752
0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 800
0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 784
0 0 0 0 0 0 1 1 0 0 1 1 0 0 0 0 816
0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 768
0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 768
0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 768
0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 768
0 0 0 0 0 0 1 1 0 0 1 0 0 0 0 0 800
0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 0 768
0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 0 784
0 0 0 0 0 0 1 1 0 0 1 1 0 0 0 0 816

 

[boriz]

Data sheet says -20Deg to +85Deg 12 bits, accurate to 0.25Deg.

That&#8217;s a temperature range of 105Deg. At 12 bits, (4096), that&#8217;s about 0.025Deg per bit. One tenth of the quoted accuracy. Or to put it another way, all the lower bit&#8217;s below bit 5 have less than 0.25Deg effect on the reading, so they can be ignored. Chances are they are just going to be noise anyway.

Try masking off the bottom 5 bits. Something like TEMP=TEMP and %1111111111100000

Then avarage the last two or three readings.

 

[hippy]

The data looks reasonable to me, 48 +/-2, around +/-5%, which isn't bad for a sensor which works at the 10uV sensitivity level and a layout not brilliantly suited to low noise. Normalise the second set of readings and the results are about the same.

What were the temperatures at the time ? These may as boriz suggests be of such small scale that they are actual temperature fluctuations.

The anomalous readings are intriguing ...

0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 384
0 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0 336
0 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 32764
0 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 32764
0 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 32764
0 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 32764
0 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0 336
0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 392

There's something going on there when bit 2 is set which the datasheet says means the temperature probe is not connected. The values immediately either side of those are probably a result of entering and leaving the failure state as the readings are otherwise consistent further outwards.

You need to investigate why this is occurring. If there's a problem with the sensor, its connection or board / circuit design that could also be affecting the other readings.

I don't think you are going to get rid of 10uV sensitive noise with your current design so it seems likely that you will have to use some averaging method to remove that noise.

 

[evanh]

Data sheet says -20Deg to +85Deg 12 bits, accurate to 0.25Deg.

That doesn't mean the sampling resolution is pointless though. You can still have a precise repeatable line using all 12 bits but still be over by say 50oC. That's grossly inaccurate and by subtracting 50oC from the raw data one can compensate for this inaccuracy. The stable repeatable readings is what makes this possible.

Try masking off the bottom 5 bits. Something like TEMP=TEMP and %1111111111100000

Now you've just made it a 7 bit sampler! Not a good idea.

I think hippy has probably nailed it. The PCB and wiring is broken or too noisy.


Evan

 

[greencardigan]

What were the temperatures at the time ? These may as boriz suggests be of such small scale that they are actual temperature fluctuations.

As far as I know, the temps should be val / 32.
eg
384 / 32 = 12 deg
408 /32 = 12.75 deg

0.75 degree air temp fluctuations within a few seconds in a breezeless room. Probably not.

The anomalous readings are intriguing ...

0 0 0 0 0 0 0 1 1 0 0 0 0 0 0 0 384
0 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0 336
0 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 32764
0 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 32764
0 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 32764
0 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 32764
0 0 0 0 0 0 0 1 0 1 0 1 0 0 0 0 336
0 0 0 0 0 0 0 1 1 0 0 0 1 0 0 0 392


There's something going on there when bit 2 is set which the datasheet says means the temperature probe is not connected.

Whoops, I meant to say this was with the TC disconnected for a short time. Just to see what each bit was doing. It only occurs when I physically disconnect the TC.

 

[Dippy]

Do you get any changes/improvements if you electrically shield the chip?
What happens if you (slightly) warm-up / cool-down the chip?

Have you emailed MAXIM techies for advice? (Don't be scared).

 

[greencardigan]

Maxim's reply to my support request.

I suspect your circuit may be picking up some noise or the temperature is actually varying.

 

[greencardigan]

Do you get any changes/improvements if you electrically shield the chip?
What happens if you (slightly) warm-up / cool-down the chip?

I think I tried heating/cooling the chip. If I remember correctly this causes the measured temp to change due to the cold junction temp compensation?

Can I shield the chip by putting the whole setup (current plastic box included) into a metal box?

 

[premelec]

That's certainly worth a try! I had a situation once where noise was appearing from the _light_ of a lamp over work bench - with no known photo sensitive devices in play!

Anyhow you have to try everything you can think of and finally there it is -- or isn't

 

[evanh]

Here's some more work for you:

- Dippy mentioned the programming cable as a possible noise source. That is very true. I'd try running experiments with it disconnected. Or redesign with isolation included.

- Looking over the board layout: You should put a 100nF ceramic cap right beside each chip. It needs a small distance from the power pins. Forget the larger caps that were mentioned, you aren't drawing large currents.

- The thermocouple wires should run right up to the MAX6675. This is important because the cold junction sensor is inside the chip.

- Looking over your schematic, I note that you have the thermocouple connected to gnd. Disconnect it and add two 100nF caps down to gnd, again right next to the chip, one for each input pin. This allows the signal to equalise with the reference giving more leaway from the built-in clamping diodes.


Evan