## MAX6675 (thermocouple chip) how to elegantly handle values

32 posts / 0 new
Author
Message

hi folks,

Have a set of MAX6675's connected to a MEGA32, successfully reading temperatures. I'm using C with AVR Studio/WinAVR toolchain.

I'm now at the point where I want to make an "elegant" solution to the conversion of the 12-bit data value that the MAX produces into ASCII for output on both an LCD and UART. Simplistically, the MAX produces a value that is .25 degree C per increment, meaning a value from 0 to 4095 equates to temperatures from 0.0 to 1023.75.

At the moment I do my conversion in two parts. First I take the 12-bit number shifted right twice, and use ITOA - this gives me the whole number component (since right shift by 2 is divide by 4), and then I have a set if IF... ELSE IF statements for the two LSBs that maps 0 = ".00", 1=".25" etc to get the fractional part. In this case I actually do two outputs, which in itself isn't a big deal but I am likely to want to do the conversion and the output as two separate functions in my final code.

At this stage I am not speed constrained, I don't think, so I would probably get by fine with the approach I've taken if I clean up my code and use a single string buffer to maintain the text, but thought if anyone had a neat way to deal with this they were happy to share, I'd appreciate it!

I can't think of a better way (I don't consider involving floats to be a better way). Keep the 0-4095 value for any calculations, and have a single function ("tempval_to_a(uint16_t val, char * p_buf)") that converts the value to a string in the way you describe. If you consider it more elegant you can use the 2 lsbs as an index into a table of 4 strings holding ".00", ".25", ".50" and ".75" and get the digits to the right of the DP that way.

oh yes, I won't be dropping the raw data values as I do need to average samples out over time to make sure I'm not using spurious readings (in my testing around my workbench, I've seen TC readings 300+ degrees over actual because of stray voltage differential on PC equipment, even though that's not my target environment I need to be wary of that)

I have boards with a MAX6675 (several hundred) and the main problem is that the chip 'self heats' and it reads boiling water 10 deg F too hot. So its not as accurate as a \$2 meat thermometer, which goes right to 212 deg and sits there. I guess 10 deg isnt a lot of error at 1300 deg, but its pretty gross at 212. If you can think of a trick to tweak that up (other than just an open loop subtract 10 deg from the reading, which is sort of a kludge) I'd LOVE to hear it. If the guy from MAX-IC is reading this, call your 6675 guru and ask him if he has a workaround.

Imagecraft compiler user

Is the point at which the thermocouple wire connects to the board at the same temperature as the chip? The CJC compensation has to compensate for the temperature at which the TC wire connects to any non-TC wire (connection junctions), but the temperature sensing is inside the chip, so it only works right if the two temperatures (connection junctions and chip) are the same.

I've worked on TC systems where a temp-sensing chip was mounted remotely at the connection junctions to deal with this issue.

The temp of the chip must have something to do with the temp error. My hypothesis is the on chip temp comp (a diode?) only compensates over a certain range. When you put the max6675 on a pc board in a can on a dashboard in the sun, it gets about 150 deg in the can and the temp comp doesnt. Yo to Poundy: I like your hybrid integer and fraction scheme. If I need fp in 2 places, I use it. If I only need it in 1 place, I try to do some heroic special integer solution.

Imagecraft compiler user

Thanks Bob. And there I was thinking it was a kludge, turns out not so....

MAX6675 is great because it has the inbuilt CJC, MAX6675 is bad because of the inbuilt CJC...

(never thought I'd say something like this to a 12,000+ post person) The data sheet says the compensation is driven by a diode, and "The cold end (ambient temperature of the board on which the MAX6675 is mounted) can only range from -20Â°C to +85Â°C" so your dashboard stress might expose the board to greater than +85Â°C..... They also talk about getting benefits by using large ground plane....

Bob, what's your application? Sounds like something interesting.... Me, I've just resurrected my coffee roaster project..... Really need to figure out next how to deal with periodic samples, LCD/serial output, and button press/debounce integration since I have most of that working ok in individual modules.

Oh, and another question. In my "read" process, I have a loop cycling 16 times to read each bit that the MAX outputs, and retain bits 14 to 3 for the data (which reminds me I must remember to go back and retain bit 2 for the T/C connection status too). Anyone with other suggestions? Take the whole 16 bits in, and use mask/bit-shift to separate the vaules? Actually just thinking about it, that may well use less cycles - probably go with that....

I read the 6675 on the spi like this.... It takes 220ms to convert so I call this routine every 250ms.

```#define CSLO() PORTC &= ~0x40
#define CSHI() PORTC |=  0x40
unsigned int raw; //raw bits from 6675 (1/4 degrees)
float fqdeg,fqdegsm;
//---------------------
//read max6675 thermocouple preamp     takes 220ms!  called every 250ms
//bit d2 lo means tc open
unsigned char dh,dl;
unsigned int qdeg; //quarter degrees

INTR_OFF();
SPCR=0x5c;    //0x58 -> 0x08 ->clk pol flipped + 0x04 data polarity
CSLO();       //conv halt, output bit 0
asm("nop");
asm("nop");
spiout8(0);   //send dummy byte, generates 8 clks
spiout8(0);   //send dummy byte, generates 8 clks
CSHI();       //conv resume
SPCR=0x50;    //fastest spi back on for needle
INTR_ON();

raw=((unsigned int)dh << 8) + dl; //raw thermocouple reading 1/4 deg C x4? x8?
tcopenerr=(raw & 0x0004) != 0; //check tc open err bit d2
qdeg=raw >> 3;   //12 bit unsigned integer number (4096 quarter degC->1024 degC)
fqdeg=qdeg;
fqdegsm += 0.125*(fqdeg-fqdegsm); //was .1 9/9/08 takes 4x250ms=1sec too slow
degC=fqdegsm*0.25;    //cvt qdeg to degC
degF=degC*1.8 + 32.0; //cvt degC to degF
}

//----------------
void tcloop(void){
char c;

cprintf("thermocouple   q=quit\n");
cprintf("raw err degf   degC \n");
while(c != 'q'){
if(kbhit()){
c=getchar();
}
tcopenerr=0;
cprintf("%03x %3d %#6.1f %#6.1f \r",raw,tcopenerr,degF,degC);
delnms(500);
}
}

```

Imagecraft compiler user

Bob chose to use floating-point as well as (s)printf(). The program as shown will be quite large in AVR terms--probably about 4kB. And won't be particularly fast; the output could approach a millisecond depending on AVR speed.

If this is the "whole app", then so what? Go for it in whatever manner is most straightforward. the float/printf approach, or piecemeal as you have been doing. Multiple character output primitives are no big deal--in general, at a low level there is a call to the putchar or equivalent primitive anyway for each character.

There have been prior discussions on this, e.g.
https://www.avrfreaks.net/index.p...
https://www.avrfreaks.net/index.p...
where different approaches are discussed. Note what the div() function might give you if you haven't already. But in your case the bit extraction is simple enough.

For me, you are starting with a small integer number with modest precision. I'd do what you are doing or use my utoa() family as discussed in the links I gave.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Bob
if the 6675 and the cold junction have no temp difference, there should be minimal error up to about 185 F. Show us a pic of that part of the board. If to far away, thermal epoxy might help in minimizing the difference as will enclosing the board (or at least the front and back of the critical area) in insulating foam. That's to many boards to waste.

bobgardner wrote:
The temp of the chip must have something to do with the temp error. My hypothesis is the on chip temp comp (a diode?) only compensates over a certain range. When you put the max6675 on a pc board in a can on a dashboard in the sun, it gets about 150 deg in the can and the temp comp doesnt.

The datasheet says the CJC works to 85C, and compensates to within 3C. The key is to keep the connection junctions and the chip at the same temperature. I bet if you use a temp gun on the two points you'll find they are at different temps.

The cold junction is right at the tc+ and tc- on the max6675 right? The leads on the max chip are what... tin? That chip is right next (1/8th") to a samtec connector with tin pins. My type K thermocouple has a gold plated pin crimped on the alumel and chromel wires. If I'm seeing 10 deg F error, thats 5 deg C or about 200uV error at 41 uV per deg C. How do you measure galvanic/dissimilar metal errors on the tc leads? I appreciate the brainstorming on this problem. We'll all help poundy with his prob too I hope.

Imagecraft compiler user

Bob:
The connector is the problem. There are to many dissimilar junctions. The chip can't compensate for that. Any connector has to be a thermocouple type of connector. I don't know if chromel/alumel can be soldered. Maybe tin it with acid flux first, then solder next to 6675 where the connector is now. Try it on one.

TC wires can be soldered.... i've just done so :) the real question is whether they *should* have been done 8-O

For me I'm ignoring the issue until it becomes a bigger issue. I'm using banana plug with the TC soldered into, on a short jumper to the MAX6675. In the final board, that distance may actually be much more than it is now, depending on the case/mounting I work out. I will however be trying to make the general temperatures around the MAX and the connectors be similar somehow (TBA ;-)) All this discussion definetely DOES assist me !!

The only junctions that matter besides the TC junction itself are the two formed where the two different TC wires connect to "normal" wires. Any further junctions between those junctions and the internal circuitry conveniently cancel (assuming the same kind of wiring for both leads). So the temperature that the CJC is concerned with is the temperature where the two TC wires connect to whatever they connect to.

isn't the bigger issue the fact that the dissimilar metal wire junction is in my case on a banana plug 75mm+ away from my MAX, therefore possibly exposed to different environmental heating and therefore not properly accounted for in the CJC inside MAX?

poundy wrote:
isn't the bigger issue the fact that the dissimilar metal wire junction is in my case on a banana plug 75mm+ away from my MAX, therefore possibly exposed to different environmental heating and therefore not properly accounted for in the CJC inside MAX?

Yep. If the temperatures of the two (three actually, since you've got two banana plugs) are not all the same, the CJC won't compensate correctly.

Stick your tc in a pot of boiling water and if it reads 212 deg F you're golden. If it reads 222 deg F you're AFU like me.

Imagecraft compiler user

i'll check it reads 100 deg C, I'm pretty close to sea level, and in Australia ;)

Quote:

reads 100 deg C, I'm pretty close to sea level, and in Australia

Wouldn't it then read -100? :twisted:

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

happy new year to you too ;-) We had it first ! (anyone from NZ don't read this :))

Hey BobGardner, by any chance do you have any "thermocouple disconnected" logic checking bit3? I've been looking at my logic, and I see about 50% with that flag set, even though the temperature part reads roughly the same (ie within a degree in stable conditions). I can't see any reason why it would alternate, except if i'm mis-reading the serial data. Perhaps what it's showing is that the conversion isn't really finished (i am doing them based on serial data - a keypress - so i don't think i'm doing them under 250ms)

mmm. Logic error. Think I'm not bringing in enough bits! Yup, confirmed, not enough bits..... darn FOR loops. :s

I do have a check for that bit and I set 'tcopenerr'. Check that listing I posted.

Imagecraft compiler user

Bob:
Are you going to solder the tc directly to one of the boards in place of the connector to see how much of the error goes away?

I went to Skycraft Saturday and bought a type K thermocouple connector with chromel and alumel wires and Monday I'll bypass my kludgy open loop subtract-10-deg-F-from-the-tc reading compensation and solder this connector right to the max6675 pins and see if it reads closer to a sane reading. If I do have an error because of the dissimilar metals in the connections I'm goin to try an multiplicative correction factor rather than a subtractive correction factor. I'm willing to try anything once. If I have to reprogram 500 board sets from angry customers, plus shipping to the seven continents, will that be penance enough? (OK, we dont have any in Antarctica yet, but I'm hopeful)

Imagecraft compiler user

No, tell them all *improved accuracy* and *all new version 2*. Then let them decide if they want the firmware revision. Better still, make them pay return freight if they want it, but of course give them the firmware update free..... :)

Just back from my maiden voyage with my two TC unit reading data and pushing it to a PC while I was roasting coffee. Worked AWESOME. Gave me great visibility of the temperature as the roast progressed, made it very helpful to keep an eye on things. Output of the sample # plus two TC readings every 250ms at 38400 baud worked without missing a beat, only had a couple of LCD glitches (i was using a breadboard so didn't expect rock solid with the temperature and the other electricals around the roaster). The second part of my project is an intelligent application for the PC reading the serial data and graphing it on the fly, plus alerting me to "issues". Had one of those, where the gas ran out and needed to swap bottles, i didn't notice at the time but the temp profile shows it nicely and i reckon the program could have saved me some time and removed the risk of destroying a batch of beans

Hi. Bob did you do the test with the K type connector? I would be interested to know the results of this.

Thanks

Trev

Hi Trevor. Its an auto gauge. You can see a picture at Mcnallyelectronics.com. When used as an EGT sensor, a 10 deg F error at 1300 deg F is within a percent. I got egg on my face when I sold a bunch of them to a guy that was monitoring a water bath and a 10 deg error at 212 deg F is a mess. So I figured since all the boards have the same chromel to gold to tin on the tc+ pin and alumel to gold to tin on the tc- pin, the errors are the same on all boards. These junctions are like little temperature sensitive batteries that spit out more microvolts as they get hotter, so I apply a correction factor that makes it read right at room temp, and I assume its still pretty close at 1300 deg F. Its all glowing red at that temp.

Imagecraft compiler user

Hi Bob. I was messing aroung with these ICs before. i had a thermocouple just wired ended into a screw terminal connection and i was seeing some error. Was curious to see what you did. Thanks for the reply.

Trev