CAN-EGT 8 channel thermocouple interface

User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: CAN-EGT 8 channel thermocouple interface

Post by kb1gtt »

There has been some talk about using CAN as a kind of back haul for other remote devices. Are there any suggested CAN protocols that might allow others to develop modules that can be interfaced. I guess CANopen comes to mind. For example, if someone has PIC experience and motivation to build something, I'm all for supporting them. I'n the early stages of the effort, I'll comment about why I would choose ARM, but if someone chooses something different, I'll probably offer support in what ways I can. If we can choose a published back-haul, this would make it easier for people to interface with rusEFI.

So I wonder what CAN protocols should be considered and why should they be considered? Also is CAN the best back-haul for things like this EGT board?

Other boards I see needing a back-haul mechanism a need for include VR/hall for wheel speed sensing, PWM fuel pump controller, GPS, accelerometer data, transmission controller, ect. So we should consider a back-haul that can support other devices with various levels of packet priority.
Welcome to the friendlier side of internet crazy :)
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: CAN-EGT 8 channel thermocouple interface

Post by puff »

providing apis sounds reasonable. i don't know anything of priorities. in the beginning of this thread there was a link, the guy was setting up a 500kbit communications mediaand then sending out 8 bytes of data with can id 0x00. is it a sender id or a recipient id? . am i right that in CAN everyone can listen to everyone?
it seems, it is essential to provide flexibility in setting up the communications speed (someone wants to use dashboards operating at some speed and using certain can ids, others use can for other purposes, etc).
User avatar
abecedarian
Posts: 386
Joined: Fri Nov 15, 2013 10:49 am

Re: CAN-EGT 8 channel thermocouple interface

Post by abecedarian »

I know this thread is about an 8 channel EGT thing... but think about the direction things may go, particularly if something like this is integrated into RUSEFI hardware.

I wonder about providing 'pre-programmed' chips, as in PSoC3, or even PSoC4. How well would the program survive reflow or mounting if soldered separately? And then, what to do if the program needs updated? If there's something that needs updated because of some bug that might be found, or maybe because there's a tweak that improves that chip's efficacy and requires tweaking some timer or ADC routine or who knows, what then?

Unless the end-user has access to all the programming tools, programming hardware and software specifically, updates are best delivered via ONE channel- the RUSEFI firmware, at least until everything has been worked out... which still means RUSEFI firmware is updated, and that is uploaded to the device, and then the device handles updating ancillaries. I, for one, do not want to have to plug in more than one dongle to update my ECU. You?


People need to consider the ramifications of what decisions they make now, before committing to anything.
You can lead the horticulture but you can't make them think.
Tomin
Posts: 39
Joined: Fri Oct 18, 2013 8:03 pm

Re: CAN-EGT 8 channel thermocouple interface

Post by Tomin »

I thought we are talking about separate ECU for EGT measuring.
Otherwise, in case of hardware of EGT in Rusefi ecu, I am for handling in STM, of course. No risk of more firmwares / version mismatches, ...
puff wrote:i don't know anything of priorities.
Priority is done from CAN ID. Transmitter what currently transmitting ID with more ?logic 0? in series of bits of the ID sequence
will win and continue of transmitting, second transmitter will detect a colision and instantly stops transmitting.
See CAN arbitration: http://en.wikipedia.org/wiki/CAN_bus
puff wrote:in the beginning of this thread there was a link, the guy was setting up a 500kbit communications mediaand then sending out 8 bytes of data with can id 0x00. is it a sender id or a recipient id? . am i right that in CAN everyone can listen to everyone?
CAN ID is only one in every message. It is ID of the message, not transmitter or receiver address. Every unit can choose what ID(s) will be handled/received and what will be ignored.
CAN receivers has FILTERs (filter+mask) for it.
puff wrote:it seems, it is essential to provide flexibility in setting up the communications speed (someone wants to use dashboards operating at some speed and using certain can ids, others use can for other purposes, etc).
Used speed must be only one on the bus, what I know. Otherwise there will be false signals of errors on the bus from receivers.
Of course, firmware needs possibility to choose this speed.

I have some knowledge about CAN busses in Fords/Mazdas/etc.
There is a ISO15765 protocol for diagnostic purposes. I can implement such protocol to RusEfi in the future. Already have some code for it.
(I have implemented it in my home automation system for some type of diagnostic.)
Better/detailed diagnostic possibility with true DTCs should be something fine in RusEfi, I think.

But, such protocol is not needed for comm. between ECUs.
Many manufacturers uses simple schema of broadcasts. Every ECU continuosly sends message(s) with our data.
For example engine ECU (lets talk about PCM = powertrain control module) sends RPM, IAT, LAMBDA, etc..
EGT ECU can sends one message with 8 temps. (one CAN msg. has max. 8 bytes) in one CAN frame. If there is more data bytes, it could use 2 or more IDs. Simple, efective, no more needed.
Of course, ecu can also send packet like "I am ok, live and my status is XY."
If engine PCM can not receive such ID/message for more than X (mili)seconds, it "knows" that there is something bad with EGT ECU
and do some stuff like writing appropriate DTC error code in DTC bank. Also can substitude EGTs values from predefined values, etc.
So, there is no necessity for some type of handshaking, no separate thread for it, no flags, ...
Software implementation of such communication is trivial.
In that way it is handled in all Fords, what I know and I think in many others cars too.
Tomas
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: CAN-EGT 8 channel thermocouple interface

Post by puff »

didn't get it. does this mean that the egt unit might just be sending out, say, each 50ms couple of messages, say with can ids 0x98 and x99 with temperature values for the eight cylinders, and should there be any other device on the bus sending out can messages with same can ids, the ecu would get confused?
all in all i like this simple approach without complex protocols, handshaking, etc.
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: CAN-EGT 8 channel thermocouple interface

Post by kb1gtt »

@puff, As I understand it, yes CAN allows all devices to listen, including the transmitting chip. This is required because if two devices start at the exact same time, eventually one device will command a 1 and hear a 0 or vice versa. When a chip hears a difference from what they are transmitting, from what they are trying to transmit, it means that another device ID of higher priority has the bus, so that lower priority ID has to be quite. The device can trigger to start attempting to send packets every 50mS or so, but will have to wait a bit before it can actually get the bus. I believe you are correct, you simply broadcast it and hopefully the ECU hears it. If not, then ECU triggers DTC.

@tomin, I read an article in Circuit Cellar about a fellow that used CAN for his home automation. Any chance you are that fellow?

About ISO15765, that seems like a good option, as it will probably be desired else where, for interfacing with off the shelf diagnostic equipment. The goal will of course to be only to use the MFG codes, and such to keep things legal friendly. I understand the official rusEFI position is to avoid things like VIN, and controlled emissions reports and such. I see no reason why we can't develop the MFG specific communications.
Welcome to the friendlier side of internet crazy :)
puff
contributor
contributor
Posts: 2961
Joined: Mon Nov 11, 2013 11:28 am
Location: Moskau

Re: CAN-EGT 8 channel thermocouple interface

Post by puff »

couple more questions:
rusefi supposes tranceivers operate at 3.3v. what you usually need to reconcile it with other devices operating at 5v?
you have some better ideas for connecting the thermocouples instead of wago connectors?
spi of that ads1118 means that i would neet clk, miso, mosi and four more pins on the mcu side to choose the needed chip? all of the first three lines connected in parallel? will i still be able to use it for pogramming purposes?
2$ per chip - is that ebay, 5 pcs for 10$, somewhere from china? (here i'll get 1 pieceat that price - suspicious)
User avatar
kb1gtt
contributor
contributor
Posts: 3758
Joined: Tue Sep 10, 2013 1:42 am
Location: ME of USA

Re: CAN-EGT 8 channel thermocouple interface

Post by kb1gtt »

I've had luck with this PCB screw terminal. http://octopart.com/7693-keystone-116638 It's about $.50 each, perhaps that's to high of a price, but they are reasonably rugged. I've never used them in QTY, but they worked well on a prototype.
Welcome to the friendlier side of internet crazy :)
Tomin
Posts: 39
Joined: Fri Oct 18, 2013 8:03 pm

Re: CAN-EGT 8 channel thermocouple interface

Post by Tomin »

puff wrote:didn't get it. does this mean that the egt unit might just be sending out, say, each 50ms couple of messages, say with can ids 0x98 and x99 with temperature values for the eight cylinders, and should there be any other device on the bus sending out can messages with same can ids, the ecu would get confused?
It is of engineer responsibility to assign unique IDs on the bus to approp. ecu. EGT ecu will send 0x98 and 0x99 messages and no one else.
There should not be any other source for such msg.
PCM as receiver of such messages is not able to recognise which ecu is transmitter of such msg. CAN itself does not have system of something like address of transmitter and receiver (like in OBDII (on ISO bus) protocol is, for example).
CAN frame has only ID + 8bytes of data. Nothing more.

kb1gtt: no, I am not the person.
Tomas
Tomin
Posts: 39
Joined: Fri Oct 18, 2013 8:03 pm

Re: CAN-EGT 8 channel thermocouple interface

Post by Tomin »

kb1gtt wrote:About ISO15765, that seems like a good option, as it will probably be desired else where, for interfacing with off the shelf diagnostic equipment. The goal will of course to be only to use the MFG codes, and such to keep things legal friendly. ...
Don't know about legality of using iSO15765. I hope it does not have any royalties or so.
Using ISO15765 would have benefit in every phone/tablet/PC+ELM327 will have possibility to read DTCs from RusEfi
and in addition there would be used applications like Torque for live data monitor, ....
Tomas
User avatar
AndreyB
Site Admin
Posts: 14292
Joined: Wed Aug 28, 2013 1:28 am
Location: Jersey City
Github Username: rusefillc
Slack: Andrey B

Re: CAN-EGT 8 channel thermocouple interface

Post by AndreyB »

Another 8 channel: http://forum.jbperf.com/viewtopic.php?f=14&t=829
Above the CPU and headers is the jack for the CAN bus. This is a 3.5mm jack that is compatible with the USB-CAN adapter plug
Is there a de-facto pinout of using 3.5mm plug for CAN?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions

Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Post Reply