DS2760 (TAI8560) - no cold junction compensation
JavaBen
Posts: 6
This is rather strange.
I have been using the USB adapter, as none of my computers have serial ports.
I have multiple TAI8560 1-Wire devices that I use with thermocouples scattered around the house.
I was able to read the temperature correctly using the 1-Wire OneWireViewer application, as well as other software. The cold junction compensation was always correctly incorporated.
I added a cat5 link to the basement recently to extend the 1-wire network. It tested fine. However, it didn't work - it lacked the offset for cold junction temperature. I only plugged in 1 of my TAI8560 in the basement - I have several but only plugged in this one on the new wiring.
So I brought the sensor (tai8560) back upstairs to plug directly into my computer thinking I either had a wiring problem, or blew the TAI8560 or the USB adapter - same problem - no cold junction compensation.
So I plugged in another TAI8560 at the computer - same result. Plugged in another - same result.
I can see the ambient temperature on the software, and I can see the channel 1 values, which are the raw thermocouple values. So this seems to validate the USB adapter, but I bought another one just in case.
If I hold the thermocouple end, increasing the sensor temperature by body heat, I see the voltages change. It shows up as being about 16 degrees over ambient, so with ambient being 81 or so, that's about 96, and about right.
I've tried this on several computers. All are showing the same problem!
I've double checked the JVM jre, and it's at 1.5. I even removed all other Java installations so it wouldn't get a different one by mistake......still the same problem.
I've stepped through the code, and it appears to be accessing the correct device and channel (btw - this is the only device on the 1-wire net).
Oracle recently pushed down their 1.6 version, and I thought this was probably the problem, but I've removed all of that an re-installed a 1.5 release....same problem.
I thought the most likely suspect was that I miswired something down to the basement and maybe it cause a problem on the USB adapter, so I bought another USB adapter and just tried it out - same problem.
Any suggestions?
I have been using the USB adapter, as none of my computers have serial ports.
I have multiple TAI8560 1-Wire devices that I use with thermocouples scattered around the house.
I was able to read the temperature correctly using the 1-Wire OneWireViewer application, as well as other software. The cold junction compensation was always correctly incorporated.
I added a cat5 link to the basement recently to extend the 1-wire network. It tested fine. However, it didn't work - it lacked the offset for cold junction temperature. I only plugged in 1 of my TAI8560 in the basement - I have several but only plugged in this one on the new wiring.
So I brought the sensor (tai8560) back upstairs to plug directly into my computer thinking I either had a wiring problem, or blew the TAI8560 or the USB adapter - same problem - no cold junction compensation.
So I plugged in another TAI8560 at the computer - same result. Plugged in another - same result.
I can see the ambient temperature on the software, and I can see the channel 1 values, which are the raw thermocouple values. So this seems to validate the USB adapter, but I bought another one just in case.
If I hold the thermocouple end, increasing the sensor temperature by body heat, I see the voltages change. It shows up as being about 16 degrees over ambient, so with ambient being 81 or so, that's about 96, and about right.
I've tried this on several computers. All are showing the same problem!
I've double checked the JVM jre, and it's at 1.5. I even removed all other Java installations so it wouldn't get a different one by mistake......still the same problem.
I've stepped through the code, and it appears to be accessing the correct device and channel (btw - this is the only device on the 1-wire net).
Oracle recently pushed down their 1.6 version, and I thought this was probably the problem, but I've removed all of that an re-installed a 1.5 release....same problem.
I thought the most likely suspect was that I miswired something down to the basement and maybe it cause a problem on the USB adapter, so I bought another USB adapter and just tried it out - same problem.
Any suggestions?
Comments
http://www.roso-control.com/Espanol/DDEVIEW/Esp_DDEVIEW.htm
try it and see if it helps, i know you can go in and see the compensation factor and change it, and im pretty sure you can enable and disable it with this software, either way, this will give you way more info about 1-wire devices than maxim's viewer.
ALSO...
i just remembered that with certain 1-wire devices that when you do a reset on them, they sometimes disable some functions that were otherwise enabled from the factory. i found this out the hard way myself.
I'm also sorry to say I goofed up. In going through the code on the OneWireViewer.java, I finally realized this code doesn't actually handle thermocouples! It's just reads the ambient temperature on the chip (ds2760 I think) and displays this as the temperature. The separate channel for the thermocouple is channel 1.
AAG supplies a thermocouple test software, so I ran this in hopes of getting it to work, but something still isn't right.
I was stepping through the code, and couldn't figure out why the ADC counts were so odd; another goof - I just recall that AVR says this chip does the ADC in 2's complement.
That doesn't explain why the AAG test software isn't working but it's at least moving me forwards towards some new insight.
Heading out on vacation Monday for 2 weeks, so will probably be the end of Sep before I can get back to this, but thanks so much for your input - it's really appreciated!
JavaBen
Anyway, back to the test: I removed the thermocouple and inserted a shorting wire. That should give me 0 byte data on the ADC, since the negative and positive are shorted together. Reading the Current Register directly on the DS2760 still shows a digital ADC value of -110....so something's not right here. I would suspect the DS2760, but I've got about 5 of them and they all tell the same tale, so it can't be that.
I may just have to park this for a while on the PC until I can get a microcrontroller up and running to access it directly.
I'm not sure if the problem is with the Win drivers, the USB adapter, or what. I hooked up a scope and I can see the DS2760 responding to being polled, so things are working somewhat. I wouldn't think the drivers, USB and DS2760 would be bad if the query to the device wasn't showing correct responses, but the ADC values certainly are toast. The internal temperature values are good......bummer; hate to give up.
The for best accuracy, the program will store a look-up table for the thermocouple being used, voltage output at a sequence of temperatures. 1) With ambient temperature from the DS2760 sensor, look up the corresponding EMF that a thermocouple would produce at that temperature. Thermocouple tables are constructed assuming a cold junction at the ice point. 2) Add that to the EMF measured from the thermocouple. 3) Look down in the table to find the temperature that corresponds to the combined EMF. That is the result. It may be necessary to interpolate both the lookup and the lookdown. For low accuracy requirements (for example, a set point system), it is possible to use a linear approximation, the thermocouple's average µV/°C. And as another alternative, you can use the polynomial and inverse polynomials, provided your computer has the horsepower for that.
Thanks for your input.
I am familiar with this product, as I have used it previously to control an inlet-air valve on my BBQ smoker before I moved it all over to AVR chips.
I'm sorry I didn't make it clear earlier in my previous post, but I went directly to the chip's Current Register to get the actual counts of uVolts from the ADC. I did this using the Maxim OneWireContainer30 class, then reading the two bytes at 0x0E and 0x0F, which contains the chips Current Register ADC.
I removed the thermocouple and I then shorted the inputs normally used by the thermocouple, so that I should have been able to obtain a value of 0 uVolts or close to it. Alas, I didn't. I see a value of about -100 counts, which are multiplied by the 15.624 e6 count value on a full range of 64mv.
So going directly to the chip gives invalid counts, as does all of the software I've used so far. I don't think my USB adapter is bad or else I don't think I would get communications from the chip nor the ambient temperature, which I'm getting. I think that also rules out the Win drivers for the same reason. And I have multiple tai8560's that have worked in the past.....and they are all exhibiting this problem, so I'm at a loss.
In reading back over this, I appear to be saying nothing can be wrong because everything is right.....but I can't argue with the facts - it's not functioning! So I'm missing something.
Anyway, thanks for you thoughts, I really appreciate them!
Have you tried heating and cooling the "short circuit" and reading the DS2760 to see if the reading changes? You still have a thermocouple of sorts that is creating a residual offset voltage that must be subtracted from the main thermocouple voltage. It may be that in your previous experience the temperature you were measuring was high enough that it masked the offset voltage. Go back and read Tracys' post again. If your procedure is in fact exactly what you posted, you are leaving out a VERY important step.
Rick
Thanks for your comment, but I respectfully disagree. If I put a short copper wire of about .5 inches in length between the negative and positiver terminals of the chip's Current input, then I have shorted the two inputs, and have no voltage difference across the 2 terminals, since the terminals on the device are copper as well. Thus the offset voltage from a cold-junction doesn't occur, as no thermocouple wires are involved in this connection I have made, since this shorted input is on the chip's 'Current' inputs (so-named because the chip was originally designed to measure current via a voltage drop across an outside resistor).
The cold-junction voltage, which is generated when thermocouple wire is used, and is generated at the point where the thermocouple wire connects to metals other then the same wire used in the thermocouple, is calculated by using the chip's internal temperature value; it is compensated in software later - it is not directly offset inside the chip and does not directly apply to the Current inputs when no thermocouple wire is used.
So when you use this chip to determine temperature via thermocouple wire, there are two (2) voltages generated - one at the end-point of the thermocouple where you are trying to determine the temperature, and the other at the point where the thermocouple wire connects to the device AKA cold-junction temperature offset. When used in this way, the counts in the chip's Current register is obtained, with each count equal to 15.625 uVolts. Then the chip's internal temperature is read, then what-ever software you are using has to use the Current registers counts, adjust with the chip's internal temperature, and then either look up the table value for the type of thermocouple used, or calculate the temperature directly using some of the polynomial formulas published.
So at no point does this chip ever directly adjust the thermocouple voltages for cold junction temperature - instead two distinct values are obtained from the chip: 1) the thermocouple's voltage and any cold-junction offset as it applies directly to the Current inputs, converted by the 12bit ADC and placed into the Current register, and 2) the temperature within the chip. Your software then has to combine the two values per standard thermocouple voltage to temperature conversions, to obtain the correct temperature.
So when I have a shorted copper wire placed across the inputs to the chip's Current 12-bit ADC, there is zero (0) volts difference across the two terminals, and the output of the ADC should be zero (0) counts. And I'm not seeing 0 counts, which is the problem I'm trying to find a solution for.
Thanks for your time and consideration!
JavaBen
Unless, by some coincidence, the current offset bias register (address=$33) got programmed with that value. It's worth checking.
Great idea!
I had missed this info.
Thanks!
It will be next week (I'm still on vacation) before I can test this out.
JavaBen