CAN-EGT 8 channel thermocouple interface

[AndreyB]

http://www.diyautotune.com/catalog/canegt-channel-thermocouple-interface-p-542.html $299.00



8 inputs for K-type thermocouples
8 analog 0-5 volt outputs
CANbus connection

Mostly posting to show the picture of the inside from http://forum.jbperf.com/viewtopic.php?f=9&t=1416

[puff]

fck! 18,000RUB!
what is so interesting about it? I hardly imagine exhaust with eight sensors… How fast should it read the temperature? all in all, seems pretty much overpriced…

[kb1gtt]

Might be lower cost to buy two frank boards and use their CAN interface. As well you'd get a thermcouple connector or a screw terminal, not just a screw terminal. I can comment about why a screw terminal is wrong, however with EGT's you really don't care if you are off by 10C after being installed for a couple years. So screw terminals for a DIY hobby thing isn't so bad, but for the price I would tend to expect it would come with a proper connector.

Reaction time is typically on the order of a second to a couple seconds. However this is mostly determined by the size of the probe.
http://www.omega.com/temperature/Z/ThermocoupleResponseTime.html

[AndreyB]

Might be lower cost to buy two frank boards and use their CAN interface.

Exactly. For a split second I was thinking that it would be really cool to make and market our own can2egt board, but then I was told that the market for these is really, really small. I know it could be the chicken and the egg situation that the market is so small because these are so expensive, but changing the way people tune is probably not that easy.

[puff]

so, polling each sensor once a second would be okay? they are using their very own CAN message ids? their own protocol? why do they need usb - seems like overkill. bells & whistles to boost sales?
just wondering, what are the benefits of being able to sense temperature of each cylinder? individual ignition/fuelling timing per each cylinder? will it be supported by the firmware?

[kb1gtt]

For theirs you should be able to get each sensor once per second, or faster, but it will only be valid once ever second or so. For our's it would be the same, once per second or so for each sensor. I believe the interface chip will provide data faster than that, but the mass of the sensor limits you to once per second.

Per cyl is mostly to know if one cyl is running hot. It allows you to make adjustments to each cyl fuel to compensate for longer manifolds that run to farther cyls or for cyl's that have some carbon build up or what ever variation on a per cyl basis. Basically your MAP or MAF tells you an average air going into the cyl, while the EGT can let you know if each cyl is taking the same amount of air as the cyl next to it.

Frankenso only has 4 EGT's which is because I ran out of room as I choose to have an option for a proper connector.

I do not know about the CAN ID's and such. I would guess they are using the proprietary and semi protected MS protocol, which I understand uses it's own ID's, and packet formation. However that's just a guess.

[puff]

Yep, and I don't remember any thermocouple inputs on frankenstein.

probably, that's not for civil vehicles? racing sport-cars? I hardly imagine manifolds with all those sensors installed (mine is cast iron - how do I drill it and weld on those 'bungs'?)
speaking of the rest - sensors themselves aren't that expensive, as far as I remember. the cold-junction compensation chips cost more. there are some more expensive chips with digital output (SPI?i2c?- whatever) or afaik one can use much cheaper devices with analogue output? but in that case one would need a micro controller with 8 spare adc inputs. For me it seems reasonable to build a simple device that would convert 8 ADC to 1 spi. i think it's not difficult task and it is doable even for a newbie like me BTW, probably, in this case CAN would be a better choice - it allows you to put this box separately from the ECU.

if you guys decide to build such a device using the extra discovery board, I wish you would document all the protocols so that the others would be able to develop and implement their own solutions.

but first things first. this all makes sense only after the firmware (rusefi) makes it possible to control all of its digital outputs (ignition/fueling) separately. are there any plans to introduce individual trimming for each inj/ign output?

besides, as far as I know, some models of engines had certain cylinders hotter than the others, and their water jacket's designs compensated for such temperature difference. I mean, sometimes it might not be necessary to make all the cylinders work at the same temperature...

[kb1gtt]

If someone wanted, they could re-spin Frankenso, as russian has gotten the SPI working and has taken measurements. The MAX31855KASA SPI chip was $4.50 in qty 1 and the wire was like a buck. The real connector PCC-SMP is about $2. So I would consider this to cost less than $8 per channel. Which would mean 8 channels should cost less then $64 in materials.

I guess the box and small market means increased price. I wonder what or who can interface to the CAN messages.

[Tomin]

CAN protocol could be very simple. Just one ID for broadcasts of temperatures
and one ID for broadcast of "I am a live" packet.
Rusefi then can receives broadcasts and monitor if there is a "live" packet. If not, set a DTC and do some "error cleanup" (set default temps., ...)
STM32 is waste of money and mostly of space for this job. Simple 8bit PIC or 16bit PIC24 can do it for 3$.
I have plan for it. I would like one EGT for every valve.

There could be extra bus for DS18B2x temps too (?onewire?). But did not have tested onewire short bus in automotive environ. yet.

[AndreyB]

Looks like this guy has integrated his own EGT device with MS so I assume the protocol is known:
http://grassrootsmotorsports.com/forum/build-projects-and-project-cars/arduino-based-egt-sensing-for-megasquirt-via-can-bus/88593/page1/

[AndreyB]

Another cool thing - on eBay they have a lot of MAX31855 thermocouple breakout boards, including dual and quad channels:

http://www.ebay.com/itm/301371833877
http://www.ebay.com/itm/301200852126

[puff]

have you seen that sketch that guy shared?

there's the protocol. actually, you don't need arduino for that - bare mega328 will do the same task. with the sketch it's probably easy to replicate however, not sure if the arduino code is efficient.
eight MAX31855 cost a lot)
the can bus is working at 500k.
here's what it does:

Code: Select all

    
byte stmp[8] = {};
for (int i=0; i<4; i++) {    
    double temperature = (*temp[i]).readThermocouple(CELSIUS);
    stmp[i *2] = temperature /255;
    stmp[i *2 +1] = fmod(temperature, 255);
  }
  CAN.sendMsgBuf(0x00, 0, 8, stmp);   // send data:  id = 0x00, standrad flame, data len = 8, stmp: data buf

probably, it's the easiest option to add thermocouple support (at least graphing part)

[puff]

have you seen the pictures of 4ch and 8ch breakout board? 52$ per octo and 40 per quad? seems strange, right? they use just one max31855 and probably a switch? btw, 40$ - this price looks reasonable to me...

[abecedarian]

ADS1118 can sample two differential thermocouples (or 4 single ended) at 860 samples per second (faster than thermocouples tend to react) at 16 bit depth (MAX31855 is 14 bit), do open/short sensor detection, provides cold-junction compensation, and are ~$2 USD.

Just saying.

[puff]

nice! but locally they sell it at the same price as max31855 (i.e. ~$9 per piece). I sent a letter to those who sell 8channel boards on ebay asking what are those two chips on board - just curious.

[puff]

do you think this one is good?
http://www.ebay.com/itm/1M-0-800-Screw-Thread-Thermocouple-K-Type-For-Exhaust-Gas-Temperature-Probe/251735387847?_trksid=p2047675.c100011.m1850&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D1%26asc%3D27538%26meid%3Da845a46fac014973a1687fedeedbe9d6%26pid%3D100011%26prg%3D11353%26rk%3D3%26rkt%3D10%26sd%3D311217955709
just $1? the temperature range of 0-800C is suspicious…

[abecedarian]

do you think this one is good?
http://www.ebay.com/itm/1M-0-800-Screw-Thread-Thermocouple-K-Type-For-Exhaust-Gas-Temperature-Probe/251735387847?_trksid=p2047675.c100011.m1850&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D1%26asc%3D27538%26meid%3Da845a46fac014973a1687fedeedbe9d6%26pid%3D100011%26prg%3D11353%26rk%3D3%26rkt%3D10%26sd%3D311217955709
just $1? the temperature range of 0-800C is suspicious…

No idea- that's a thermocouple, not the chip handling it. But I think one can get K-type thermocouples rated up to around 1400F, so 800 isn't really useful to anyone running a turbo.

One ADS1118 = 2xMAX31855, so if you're doing a V8, you'd need 4 ADS1118 or 8 31855... halve that if you can use single ended sensors.
Considering that, 9*8=$72... 9*4=$36. Do the math.


But I can't say I'm surprised. Everything I see here is oriented at 'discrete' components instead of utilizing 'integrated' when appropriate. That's fine, but doesn't lend itself well to 'modularity', which if I remember correctly was something Jared was pushing for a few years' ago.

An MC33814 could run 1/2/4 cylinders, and handle a VR sensor and O2 heater. Two MCP33810 could run a V8, but toss in that MC33814 and you could run anything from 1 to 10 cylinders, maybe more with appropriate drivers and programming, and do so with O2 and diagnostics on board.


But I look at the big picture, and as of yet, nothing I see will run my motorcycle- all 2 cylinders of it, at least not without a lot of work.

[kb1gtt]

I don't see ICE calibration from that ADS1118 chip. Does it do that kind of compensation? I fear there is significant software that needs to be behind the ADS1118 to get valid readings. Also I don't see a temperature sensor in the chip itself, so you would need a separate temp sensor to measure the thermocouple that is your PCB connector.

The low cost way to do this is to use a PGA to bump up the small signal such that you get something that can be read into normal ADC's. Then you put a LM35 in or really close to the PCB connector, then you do some software to deal with all the calibration stuff. Example found here. http://hfoplant.blogspot.com/2011/10/thermocouple-circuits.html

The software can be a bit of a blah, but once you have it written or found on the internet, it's really not that hard of a task to do. It also typically doesn't take much CPU cycles. The problem is, how does a DIY'er validate that the software is correct? Most OEM's have TCPL simulators that allow them to validate it very quickly. Which is what Cypress has done and released. App note found here http://www.cypress.com/?docID=46585 See below references, which includes the software and has been validated up to 1300 degrees.

PSoC 3 CAN and TCPL references.
http://www.cypress.com/?rID=60544
http://www.cypress.com/?rID=37766

I'm not sure how many TCPL's you can get from one PSoC. I think you can get at around 32 to 64 in one chip. I'm also not quite sure what it's doing for the equiv of the LM35, I think just like the MAX chip it's requiring the PSoC to be near the connector, then it uses the internal PSoC's internal temp sensor.

[puff]

that was the question: usually you expect much wider temperature range for k-type thermocouples… will the 800c model be enough for a usual atmo engine
yes, i did the math.
but check the 8ch board here http://www.ebay.com/itm/301371833877
I don't get what is a single ended sensor and what are the others (is the above mentioned a single ended sensor, or not?)

As for your expectations - I've read some stories by a guy from Belorussia, whose business is car repair. There are plenty of second-hand cars imported from Europe, and at least twice over the course of the last couple of months he had to deal with baked chips, which were basically unobtainable (because of price, or because of delivery time, or both). Purchasing a new ECU was not an option (too expensive). So he just soldered on some discrete transistors on top of those chips to restore the fried channels… Fortunately, they were simple chips (basically, several transistors in one package - a solenoid driver and ignition driver, as far as i remember) without intricate internal controls.

Since we are not targeting at miniaturization, and these chips don't provide any other benefits - the current state of affairs looks pretty much reasonable to me.
As for your complaint - what is the problem about 2 cyl engine? Works too fast?

Jared, ICE? PGA? TCPL? What are these? What do you think of that 8ch board on ebay?

[kb1gtt]

Ah, I see some cypress references use the DS600 for cold junction. That is mostly for getting better accuracy. However other sensors can be used with slightly degraded accuracy. So you could use the internal sensor, but your readings would be more like +/- 2C instead of +/- .5C. Which would be fine for an EGT, as the EGT is typically looking for 50C or more variations.

I'm not sure about the ebay chip, perhaps the single channel is OK, I would need a schematic to learn more. The 8 channel is probably OK for +/- 5C, but I would need a schematic to learn more.

ICE is a bucket of cold water, its used a reference point for thermocouple circuits.
PGA = Programmable Gain Amplifier
TCPL = ThermoCouPLe. Follows Calvin and Hobs comic naming convention http://calvinandhobbes.wikia.com/wiki/G.R.O.S.S.

[puff]

hm. reread that ebay listing:

Note: The Octo (8) board uses multiplexing to read up to 8 thermocouples. It takes 0.125 seconds to measure the temperature on each thermocouple, so all 8 can be read in 1 second. Please take a look at the sample code to see how take readings. Essentially, you set T0, T1 and T2 to the correct thermocouple - wait 0.125 seconds - then take a reading. The single, dual and quad boards do not use multiplexing so they can be read as fast as the MAX31855 allows.
Specifications:
Uses MAX31855KASA+ Thermocouple-to-digital converter (type K)
Measures -270°C to +1800°C in 0.25 degree increments
LED indicator shows when the board has power
Standard 0.1" header for connecting to microcontroller
screw terminals for connecting thermocouples
Screw holes for mounting the board
Compatible with Arduino, PIC and other microcontrollers
Dimensions:
Single: 1.1" x 1.1" (28mm x 28mm)
Dual: 1.5" x 1.1" (38mm x 28mm)
Quad: 1.8" x 1.3" (45mm x 33mm)
Octo: 2.0" x 1.6" (50mm x 40mm)

the suggested code is here https://github.com/engineertype/MAX31855
but I don't see how the 8-ch works… nor I can see the source code for it.
only this picture:

Снимок экрана 2014-12-19 в 15.10.40.png (957.42 KiB) Viewed 20238 times

[abecedarian]

I don't see ICE calibration from that ADS1118 chip. Does it do that kind of compensation? I fear there is significant software that needs to be behind the ADS1118 to get valid readings. Also I don't see a temperature sensor in the chip itself, so you would need a separate temp sensor to measure the thermocouple that is your PCB connector.

I'm guessing you didn't actually look at the datasheet then. The internal temp sensor is right there in the block diagram on page 1.
Also, there's an EVM for this chip. If you seriously consider this, I'll buy the EVM and have it shipped it to you, Jared.

The low cost way to do this is to use a PGA to bump up the small signal such that you get something that can be read into normal ADC's.

The ADS1118 has PGA and 16 bit sigma delta ADC, built in. Can't get much more low-cost than that, can you?

Then you put a LM35 in or really close to the PCB connector, then you do some software to deal with all the calibration stuff. Example found here. http://hfoplant.blogspot.com/2011/10/thermocouple-circuits.html

Or just put the ADS1118 near that connector, and sample the internal temp sensor along with sampling the thermocouple... i.e. read the sensor and internal temp, which is what you'd have to do anyways if you use the LM35: read the TC and the LM35.

And for humor's sake... I don't see ICE calibration for the LM35 you are proposing. This, thus, makes your argument about not having ICE calibration for the ADS1118 a moot point at best, and maybe somewhat laughable, considering you use that data to bring doubt into the chip's efficacy while simultaneously introducing some other solution which doesn't meet your criteria either.

And... the LM35 is $0.50 to $2 USD depending on the source, whereas the ADS1118 is ~$2 no matter where, and you'd need two LM35 and other hardware to do what the ADS1118 does, regardless.

So your idea of 'low cost' just got expensive, when you think about the components and programming investment.

The software can be a bit of a blah, but once you have it written or found on the internet, it's really not that hard of a task to do. It also typically doesn't take much CPU cycles. The problem is, how does a DIY'er validate that the software is correct? Most OEM's have TCPL simulators that allow them to validate it very quickly. Which is what Cypress has done and released. App note found here http://www.cypress.com/?docID=46585 See below references, which includes the software and has been validated up to 1300 degrees.

PSoC 3 CAN and TCPL references.
http://www.cypress.com/?rID=60544
http://www.cypress.com/?rID=37766

I'm not sure how many TCPL's you can get from one PSoC. I think you can get at around 32 to 64 in one chip. I'm also not quite sure what it's doing for the equiv of the LM35, I think just like the MAX chip it's requiring the PSoC to be near the connector, then it uses the internal PSoC's internal temp sensor.

Well, yeah. Can't do CJT compensation if you're not close to the CJ, can you? But that's the whole point of these things needing to be close to the connector, and in a somewhat stable temperature area, is it not?

But I wonder why even consider PSoC or similar when there are chips out there that do the job perfectly fine on their own?

[kb1gtt]

Yup, 10 minutes at a time to look at things, and yes I missed that this has the internal sensor. I agree the AD chip does offer the option for CJT compensation. PSoC and the MAX chip have the same feature. The PSoC allows for an external sensor if so desired, which allows you to get a more accurate CJT compensation. However for EGT, it's not that critical as a couple degrees doesn't mater that much. If you use a PSoC, you get CAN, and up to something like 32 thermocouples for around $6. I think the MAX chip and AD chip are far more expensive, but far easier to use.

[abecedarian]

Yup, 10 minutes at a time to look at things, and yes I missed that this has the internal sensor. I agree the AD chip does offer the option for CJT compensation. PSoC and the MAX chip have the same feature. The PSoC allows for an external sensor if so desired, which allows you to get a more accurate CJT compensation. However for EGT, it's not that critical as a couple degrees doesn't mater that much. If you use a PSoC, you get CAN, and up to something like 32 thermocouples for around $6. I think the MAX chip and AD chip are far more expensive, but far easier to use.

ADS1118 - $2.58 @ digikey = 2 thermocouples
MAX31855 - $3.25 @ digikey = 1 thermocouples
Cypress PSOC3 (CY8C3****) = $6.00 @ Cypress and requires additional hardware to program it.

Do the math.

One could provide for 8 cylinders using the ADS1118, and come out spending less than what's required to implement the PSoC3.

[kb1gtt]

Price for 8 thermocouples noted below.

$10.32 = 4 * $2.58 ADS1118
$20.00 = 4 sqin * $5/sqin OSH PCB pricing
$30.32 total

$26.00 = 8 * $3.25 MAX31855
$30.00 = 6 sqin * $5/sqin OSH PCB pricing
$56.00 = Total

$6.00 = 1 * $6.00 PSoC3
$15.00 = 3 sqin * $5/sqin OSH PCB pricing
$21.00 Total

For around $11 each, I think I can program it with out much of a problem. Last I recall it was a 10 to 15 second process. I see the PSoC as lower cost if you require 2 or more of the other chips, mostly because PCB materiel is costly. Perhaps with higher QTY the PCB materiel costs are less of a factor. However the PSoC can provide 32 thermocouples for nearly the same price as 8 thermocouples. It would be nice to have feedback on more than just the EGT's, so I could see some people wanting more than 8 thermocouples. As well, the PSoC allows remote locating via CAN, while the others do not. So you can decide if you want to run long mV wires in your engine bay, or low impedance reasonably noise immune CAN in the engine bay.

For me I consider all these prices low-enough, so I consider them to all be valid solutions. The reason why I would go PSoC is because of the additional location via CAN option. I see them as having all the same critical features, but the PSoC has one additional feature.

[puff]

Don't know anything about psoc3 or how hard it is to program it. You mean to say it doesn't require CAN transceiver? CAN controller? Thermocouple interface?
Personally, I'd opt for a cheap mega328+4 ADS1118 + CAN-related stuff - all in all that would be 7 chips on board. or even 8 with a voltage regulator. Or even couple of boards: the one depicted above and 328 + can. This seems the most effective in my country.

P.S. Drilling and tapping cast iron would be difficult...

[kb1gtt]

Correct, PSoC3 would be a 1 chip solution, not 7 chips. This causes the PCB to shrink very much. Power PSoC also includes the Voltage regulator, so you can run it directly off 12V perhaps as high as 32V.

[Tomin]

puff: AVR has almost no support of CAN bus.
Lets take any cheap 8bit PIC18F with CAN and you will have much simpler work and one chip less again.
Every has 10bit ADC and with proper opamp and shifting to smaller scale (from temp. say 300C) in front of them it could be usefull for EGT range, no ?
Or take PIC24FJ64GC with 12bit A/D and you have 4C resolution in scale 0-1000C. (I know it is simplified, but ...)
Free GCC with MPLAB X, then 5(0?) minutes of googling of code + some small coding and voala.. you have almost done.

[kb1gtt]

I would generally suggest using an ARM based chip. ARM's are know for being the lowest cost per CPU cycle, as well they are multi sourced. There are reasons why ARM's are used for around 70% to 80% of all embedded applications. http://en.wikipedia.org/wiki/ARM_Holdings#Sales_and_market_share The options for open or low cost ARM compilers are much more and much more developed for ARM based devices. This means there are typically less compiler bugs, and if you do happen to hit a bug, it's more likely you will find others references and other support about the bug.

If we go MAX chip, STM32, and CAN, russian already has code, he just had to delete the extra stuff, and make it work with a smaller lower cost STM32.

[puff]

for me pic is not an option asit requires a separate programmer. i have the programmer for avr and the code is there. i also have a small stm microcontroller, but i don't if it supports can. however i have a can controller (5v)...