Pax Instruments T400 thermocouple temperature datalogger

[charlespax]

Update: Right now you can purchase the T400 on Kickstarter

I'm super excited to share my project with you: the Pax Instruments T400 temperature datalogger. The Kickstarter campaign is launching in September.

The T400 simultaneously displays all four thermocouple temperatures, the ambient temperature, and a graph of the last 100 readings. It also saves the readings to a MicroSD card and prints the readings to the USB serial port.

  I would be absolutely thrilled to get some feedback on the attached schematic. I feel pretty confident with the design and I'm ready to have it scrutinized to bring it to the next level.

The main processor is the ATmega32U4 running at 8 MHz and 3.3V. The processor was chosen to give Arduino compatibility. Since it runs at 8 MHz and 3.3V it would be programmed as an Arduino Lilypad USB through the Arduino IDE.

The MCP3424 analog-to-digital converter measures the voltage produced by each thermocouple.

The MCP9800 temperature sensor is used for cold junction compensation.

The DS3231 real time clock is used to trigger readings. Between readings the device goes into low power sleep mode. The RTC wakes up the unit to take a reading, giving a longer battery life.

The T400 uses a standard BL-5C battery, great for battery replacement in the field.

As you can see in the attached screenshot, the device can display all four thermocouple temperatures while graphing the most recent 100 readings from all four channels. The graph can display each channel individually or all four together. If the ATmega32U4 has enough programming space, the T400 will also be able to display each channel in large numerals for easy viewing.

If you find this project interesting, learn more at Pax Insruments and sign up to be notified when the Kickstarter launches.

[penfold]

I like it.  The concept is good, assuming the price point for an assembled one comes under a reasonable figure, I think I could find a place for one on my bench.

A couple of comments though...

Do you have a reason for pulling one side of the thermocouple high and the other low? if you're just trying to give each input a defined voltage then you'd probably be better off just holding one side between a 1Meg potential divider and not feeding any current (no matter how small) through the thermocouple... if you're using it to detect whether there's a thermocouple present or not, i think i can let you off.

I'm a little apprehensive to see that there isn't any external gain provided for the thermocouple signals.  There's a lot of error thats likely to occur, if your getting descent resolution and accuracy in your tests i'll concede but you could make so much better use of that 18 bit resolution

I like the idea of a graph showing the last 100 or so samples, but it would be nice if to see a longer period down sampled yet having all the data on the sd card

[fcb]

The MCP3424 in 18 bit mode (3.75Hz sample rate!) gives an LSB of 15.625uV (PGA=1), type K thermocouple is approx. 39uV per degree C.

So whilst with PGA=8, you will have approx 0.05C per LSB, which is probably OK (although I think this is to close to a minimum resolution expected of 0.1C to be useful).  Also, you have a range of approx (PGA=8) 13,000C which is around 10 times more than the type K useful range - this seems like a poor match.

I would use the excellent MCP619 as a front end on each channel (perhaps with a gain of 20-40), and then a mux (4051) and then some more gain (jelly bean opamp perhaps) and use the ADC in your micro.  Or if you're not keen on redoing the work with the MCP3424, then at least add some gain from something like the MCP619 on the front of each channel, to give you a better match with the ADC.

Also, with a chunk more gain, you can have the option of using the PGA to set the range (0-1300C might not need better than 0.1C resolution, 0-100C could run at 0.01C resolution), or run at lower sample resolution for faster updates.

Incidentally, i have recently finished a design that uses a couple of MCP609's and a dsPIC for a four channel type K industrial control. The MCP609 as it was cheaper than MCP619 and met the spec I was after.  Each channel used two series gain blocks (g=24, g=10) as per the application example in the datasheet, however I only cared about positive temperatures. I also used the MCP9701A as the isothermal measurement.

[charlespax]

Thank you so much for your feedback, penfold!

Do you have a reason for pulling one side of the thermocouple high and the other low?... if you're using it to detect whether there's a thermocouple present or not, i think i can let you off.

Yes, this is for detecting if a thermocouple is connected. I basically took the whole thermocouple filtration and detection circuit from the Texas Instruments ADS1118 application report.

The two 1-M? resistors (R_PU and R_PD) serve two purposes. First, these components offer a common-mode bias near midsupply. Connecting only one of the inputs to a common point decreases performance by converting common-mode noise into differential signal noise that is not strongly attenuated. The second purpose of these 1-M? resistors is to offer a weak pull-up and pull-down for sensor open detection. If a sensor is disconnected, the inputs to the ADC will extend to supply and ground and yield a full-scale readout that indicates a sensor disconnection.

I'm a little apprehensive to see that there isn't any external gain provided for the thermocouple signals.  There's a lot of error thats likely to occur, if your getting descent resolution and accuracy in your tests i'll concede but you could make so much better use of that 18 bit resolution

The MCP3424 has an internal PGA. I can boost the input up to eight times without any extra external components. Pretty sweet for minimizing the part count and keeping the board small.    Do you think there would be any noise issues? From what I gather in the datasheet there shouldn't be any problems.

I like the idea of a graph showing the last 100 or so samples, but it would be nice if to see a longer period down sampled yet having all the data on the sd card

I totally agree and have added this to the list of possible features. Things are pretty tight with the ATmega32U4 programming space, so I hope we can squeeze it in. I've added your suggestions to the github repo: down-sample, plot from SD.

Did I cover everything?

[charlespax]

Thank you, fcb. You've given me a few things to consider for the T400 and whatever the next device may be.

The MCP3424 in 18 bit mode (3.75Hz sample rate!) gives an LSB of 15.625uV (PGA=1), type K thermocouple is approx. 39uV per degree C.

So whilst with PGA=8, you will have approx 0.05C per LSB, which is probably OK (although I think this is to close to a minimum resolution expected of 0.1C to be useful).  Also, you have a range of approx (PGA=8) 13,000C which is around 10 times more than the type K useful range - this seems like a poor match.

I plan to have the T400 operate in 16-bit mode to get a 15 Hz sample rate. Loss in resolution, but an acceptable tradeoff to have the readings more quickly. The MCP3424 isn't necessarily the best system to use, but I started the design by leveraging other open source designs. I'm neither a programmer nor an electrical engineer, so there was some necessity to do this.

The full scale output range of the Type K thermocouple is about 62 mV. This provides 38 ?V/°C (= 62 mV/(1370 - -260)°C) of measurement resolution. In 16-bit mode the detectable signal level is 62.5 uV/PGA = 7.8125 mV (for PGA = 8 ). For the input signal level after a gain of eight, (38 ?V/°C) * 8 = 304 ?V/°C. The number of LSB/°C = (304 ?V/°C)/(62.5 uV) = 4.864 divisions per °C. This is mostly taken from the thermocouple example on  page thirty-four of the MCP3424 datasheet.

I can live with a 0.2 °C resolution for the ADC. I'm trying to get this out there for $150 or less.

I would use the excellent MCP619 as a front end on each channel (perhaps with a gain of 20-40), and then a mux (4051) and then some more gain (jelly bean opamp perhaps) and use the ADC in your micro.  Or if you're not keen on redoing the work with the MCP3424, then at least add some gain from something like the MCP619 on the front of each channel, to give you a better match with the ADC.

Also, with a chunk more gain, you can have the option of using the PGA to set the range (0-1300C might not need better than 0.1C resolution, 0-100C could run at 0.01C resolution), or run at lower sample resolution for faster updates.

I don't know if there's a right way to do it, but if there is, it probably sounds like that   At this point in the design I won't be moving to using the microcontroller's ADC. However, I will consider adding some amplification to each channel if I can keep the added cost low enough. If the next device for Pax Instruments is a higher-end T400 type device, I'll definitely take the time and redesign like this.

Incidentally, i have recently finished a design that uses a couple of MCP609's and a dsPIC for a four channel type K industrial control. The MCP609 as it was cheaper than MCP619 and met the spec I was after.  Each channel used two series gain blocks (g=24, g=10) as per the application example in the datasheet, however I only cared about positive temperatures. I also used the MCP9701A as the isothermal measurement.

Sweet! Is that a design you can share? I'd love to see how the experts do it    I'm using the MCP9800, which has an accurace of +/- 0.5 °C around room temperature.

[fcb]

It was a design for a client - so I can't publish schematics etc.

You definitely want to be better than 0.2C, even if the accuracy isn't that good, it just feels better to have closer datapoints - and in this world of specmanship, why wouldn't you?  I would target 0.01C resolution to say 250C and 0.1C above that.

I don't think this will have a significant material implication to your price.  One other thing, I'd probably measure the isothermal block with a PT100/PT1000 RTD, as the MCP9700 series is not that accurate (although more than good enough for my application) - the least amount of calibration in production the better...

[charlespax]

You definitely want to be better than 0.2C, even if the accuracy isn't that good, it just feels better to have closer datapoints - and in this world of specmanship, why wouldn't you?  I would target 0.01C resolution to say 250C and 0.1C above that.

I don't think this will have a significant material implication to your price.  One other thing, I'd probably measure the isothermal block with a PT100/PT1000 RTD, as the MCP9700 series is not that accurate (although more than good enough for my application) - the least amount of calibration in production the better...

I'm pretty strapped for pins, so I'll look into a solution that uses an RTD with an i2c interface. This might even be a good opportunity to find a better ADC with an extra input I can use with the RTD.

Maybe switch from a single MCP3424 to two MCP3423 chips. Then I could run each in 18-bit mode and get 0.05 °C resolution. Not quote there, but it would keep software compatibility.

I'm going to dig around for some chip options. You're making some good points. Thank you 

[mzzj]

I was projecting temperature logger around ltc2498 24bit 8/16 channel adc, arduino with sd card and some cheapo lcd display. Most of the code would be ready for arduino so even a programming noob like me should be able to get some results pretty fast.

[charlespax]

I was projecting temperature logger around ltc2498 24bit 8/16 channel adc, arduino with sd card and some cheapo lcd display. Most of the code would be ready for arduino so even a programming noob like me should be able to get some results pretty fast.

The LTC2499 is basically the same, but with an i2c interface. Do you know if the 2°C absolute accuracy can be calibrated for to give better accuracy?

[mzzj]

I was projecting temperature logger around ltc2498 24bit 8/16 channel adc, arduino with sd card and some cheapo lcd display. Most of the code would be ready for arduino so even a programming noob like me should be able to get some results pretty fast.

The LTC2499 is basically the same, but with an i2c interface. Do you know if the 2°C absolute accuracy can be calibrated for to give better accuracy?

you can probably improve it by calibration. I was planning to use separate cold junction temperature sensor so haven't really paid attention For that.
I was thinking of pt1000 sensor or thermistor, probably bit easier to measure than pt100.
I think calibrated or binned thermistors were available with quite reasonable price.

[charlespax]

you can probably improve it by calibration. I was planning to use separate cold junction temperature sensor so haven't really paid attention For that.
I was thinking of pt1000 sensor or thermistor, probably bit easier to measure than pt100.
I think calibrated or binned thermistors were available with quite reasonable price.

I only need four differential inputs for the thermocouples. And with eight differential inputs on the LTC2499 I can use another one for measuring the RTD circuit. Hmm, this is looking very appealing. I'd also get another three differential channels to play with.

Do you have a sense of the sample rate for the LTC2499/LTC2498? I'm looking through the datasheet and I can't find a specific answer.

[mzzj]

7 hz sample rate or with some trade-offs in accuracy you can get up to 15 sps.

ltc2498 offers pretty outstanding performance for thermocouple measurements:
I have the 1101A demo board for the 2498 and I can just throw 2 meter twisted pair cable (without any sort of input filtering components) to the connectors and LTC2498 will measure happily with less than 0.2 ppm or 1 uV rms noise! I see typically 1-2uV offset, ie practically nothing for thermocouples.


Input protection is one thing that you should think about. ESD protection would be the minimum and since thermocouples are often uninsulated from the tip its not that hard to stick one thermocouple to wrong place  with different voltage level than other channels.

[janekm]

I've also sometimes looked at the kind of under-specced devices sold as these kinds of data loggers and thought someone should do better, so good job

I like your power management circuitry, but I noticed that you currently use a 10k/30k resistor divider for measuring the battery voltage, which would drop >100uA with the device turned off... maybe either increase the resistances or stick a mosfet on the low side.

[mikeselectricstuff]

I've also sometimes looked at the kind of under-specced devices sold as these kinds of data loggers and thought someone should do better, so good job

I like your power management circuitry, but I noticed that you currently use a 10k/30k resistor divider for measuring the battery voltage, which would drop >100uA with the device turned off... maybe either increase the resistances or stick a mosfet on the low side.

This is a better way to do it. (This is for 9/5V but the principle is the same)

[charlespax]

I like your power management circuitry, but I noticed that you currently use a 10k/30k resistor divider for measuring the battery voltage, which would drop >100uA with the device turned off... maybe either increase the resistances or stick a mosfet on the low side.

This is a better way to do it. (This is for 9/5V but the principle is the same)

Thank you mikeselectricstuff and janekm. I've opened this an an issue on github

I'm getting a total power draw in the off state of 0.16 mA, see github issue. I definitely want to reduce that and get rid of the ugly voltage divider hack.

I should be able to take this basic circuit and have the output of the 3.3V regulator enable the transistor. This way I can save a pin. The down side is when the device is in sleep mode; the transistor would still be passing current. I'll have to think about this a bit.

[zapta]

Very interesting, I am in the market for temperature logger to diagnose our central heating system.

Tree minor suggestions: use micro USB connector (more standard) and display with good contrast (in the pictures it looks like those greenish low contrast displays)

[charlespax]

Very interesting, I am in the market for temperature logger to diagnose our central heating system.

Tree minor suggestions: use micro USB connector (more standard) and display with good contrast (in the pictures it looks like those greenish low contrast displays)

Thanks for your feedback, zapta. When I started this project I wasn't sure what use cases it would have. I've gotten a better picture now that I've put it out there on the internet.

The T400 already uses a MicroUSB connector and has through hole supports to make is strong. Github issue: https://github.com/PaxInstruments/t400-electronics/issues/55

I've switched to an LCD with a different backlight. The green was taken with an LCD while I was waiting for the manufacturer to to make a white version. It's a bit too bluish now, but it looks waaay better than the green backlight. I think it's pretty good contrast too (see attached). I've submitted a Github issue: https://github.com/PaxInstruments/t400-electronics/issues/57

[zapta]

The T400 already uses a MicroUSB connector and has through hole supports to make is strong. Github issue: https://github.com/PaxInstruments/t400-electronics/issues/55

Perfect, many ignore the through hole support and the connectors peel off.

Have you consider having real time clock so the logs correlate with actual time/date?

[charlespax]

Perfect, many ignore the through hole support and the connectors peel off.

Have you consider having real time clock so the logs correlate with actual time/date?

As soon as a connector popped off my prototype I implemented a solution. I just used the same part at the Blinky Tape. That's proven to be quite robust.

The T400 has an RTC. The interrupt mask triggers each reading then the T400 sets the next alarm and the device sleeps in between. The firmware can read the RTC date/time and prints it to the header of each new log file. However, the UI cannot set the date/time.

The ATmeag32U4 memory space is being stretched pretty thin. Programming in the functionality to set the RTC date/time isn't much space. Making the UI for the user to do it *does* take up a lot of space. I'll get the feature in there if I can. Even if I can't, having the RTC trigger readings is a must-have feature.

[charlespax]

Check out the electronics and firmware issues on GitHub. I think you might fine some inspiration for more ideas 

[zapta]

[The ATmeag32U4 memory space is being stretched pretty thin. Programming in the functionality to set the RTC date/time isn't much space. Making the UI for the user to do it *does* take up a lot of space. I'll get the feature in there if I can. Even if I can't, having the RTC trigger readings is a must-have feature.

Between the u8glib, vprintf, sd and usb there is not much left of the 32K flash.  Having an open source project with low memory margin is not great but on the other hand the Arduino compatibility is a big plus IMO.

Some u8glib fonts require more memory than others, and possibly you make the existing fonts sparse, including only characters that you need (yak). There are other memory considerations with u8glib, for example drawing a rounded rectangle pulls the circle logic which adds ~800B IIRC.  If you need to speed up the drawing there are also tricks for that (you don't need to redraw the entire screen on each iteration of the picture loop, just that portion of the screen. BTW, the u8glib developer is very responsive on the Android/Display forum.

[charlespax]

Between the u8glib, vprintf, sd and usb there is not much left of the 32K flash.  Having an open source project with low memory margin is not great but on the other hand the Arduino compatibility is a big plus IMO.

Some u8glib fonts require more memory than others, and possibly you make the existing fonts sparse, including only characters that you need (yak). There are other memory considerations with u8glib, for example drawing a rounded rectangle pulls the circle logic which adds ~800B IIRC.  If you need to speed up the drawing there are also tricks for that (you don't need to redraw the entire screen on each iteration of the picture loop, just that portion of the screen. BTW, the u8glib developer is very responsive on the Android/Display forum.

Excellent points. We'll probably have to optomize the u8glib library or even switch to something else. We'll tackle that later if the space is really needed. Pairing down the font and limiting the device to only one font are musts! are musts!

Last week cibomahto implemented your speedup suggestion

Yes, the u8glib dev is great! I have asked for LCD support twice and both times was helped within an hour.

I've submitted you suggestions at github issues to track them. Thanks! 

[zapta]

... I just used the same part at the Blinky Tape. ...

I like that blinky tape. Just ordered one. Thanks for the pointer.

[charlespax]

... I just used the same part at the Blinky Tape. ...

I like that blinky tape. Just ordered one. Thanks for the pointer.

Sweet! Matt Mets made the Blinky Tape. He's also hacking on the firmware for the T400.

[charlespax]

This week I'm hacking onhardware version 0.8. Please keep the suggestions coming