Page 1 of 3

CAN support

Posted: Wed Jun 10, 2015 11:21 am
by AndreyB
I was curious how hard would OBDII via CAN be - turned out it's not that hard.

I've implemented https://svn.code.sf.net/p/rusefi/code/trunk/firmware/controllers/obd2.cpp based mostly on random sniffed pieces I was able to google and the Wikipedia article. See also https://sourceforge.net/p/rusefi/tickets/207/

Re: CAN support

Posted: Wed Jun 10, 2015 1:33 pm
by puff
Nice!
Does this mean, we can use CAN chip and ELM327 bluetooth adapter to get info from the rusefi board on a generic software (e.g.Torque for Android)?
Will the error messages be supported?
We have coolant, tacho, speedo. Now we need fuel tank level, so that rusefi is a single souce of data for a vehicle dashboard ! ;-)

Re: CAN support

Posted: Wed Jun 10, 2015 2:11 pm
by AndreyB
puff wrote:Nice!
Does this mean, we can use CAN chip and ELM327 bluetooth adapter to get info from the rusefi board on a generic software (e.g.Torque for Android)?
Yes, I was able to see coolant and MAP in Torque for Android via ELM327 bluetooth adapter. Error codes not implemented yet, not sure why other sensors did not work - so far it's just a proof of concept. I am not sure if I will be looking into this further soon, that's a chance for other people to contribute :)

Re: Firmware developent status

Posted: Mon Oct 19, 2015 7:04 pm
by Rhinoman
I intend to add support for 'OBD2' PIDs for my application. There isn't an OBD2 spec as such, its a piece of legislation that mandates the use of sub-sections of various ISO specifications. The latest ISO specs themselves are copyright but the protocols are unlicensed, the older versions of the specs are freely available from the archives of the US government, I will find the link. My intention is to implement some KWP2000 functions which will allow reprogramming and other functions.
First I need to get Eclipse working.

Re: CAN support

Posted: Mon Oct 19, 2015 7:08 pm
by AndreyB
Rhinoman wrote:My intention is to implement some KWP2000 functions which will allow reprogramming and other functions.
Our CAN support is based on hardware CAN in stm32f4, what are you planning for KWP2000?

I would love to have reprogramming over CAN for TunerStudio - I believe it's possible, just a question of figuring out what TunerStudio would need for that :)

Re: CAN support

Posted: Mon Oct 19, 2015 7:14 pm
by Rhinoman
As far as CAN is concerned I've only done reprogramming via the CAN Calibration Protocol (CCP) and some proprietary manufacturers protocols, there is also a KWP over CAN protocol, I've no idea what Tuner Studio can support. In the past I've used Vector CANape and CANalyzer but its far too expensive for hobby use, something like $7000.
KWP2000 uses a standard UART.

Re: CAN support

Posted: Mon Oct 19, 2015 7:20 pm
by AndreyB
Gotcha! KWP2000 over CAN would be great!

I would not be surprised if TS uses it's own protocol, their serial protocol is pretty straightforward and I have a feeling they have something close to their serial just wrapped into physical CAN.

See https://svn.code.sf.net/p/rusefi/code/trunk/firmware/console/binary/tunerstudio.cpp
See TS default .ini files (once you install TS) for all mentionings of CAN.

Re: Firmware developent status

Posted: Mon Oct 19, 2015 7:32 pm
by Rhinoman
russian wrote:I would not be surprised if TS uses it's own protocol, their serial protocol is pretty straightforward and I have a feeling they have something close to their serial just wrapped into physical CAN.
It seems like it from what I can find, MS uses its own protocol using a 29-bit message format which is normally used on trucks or for proprietary data.

Re: CAN support

Posted: Mon Oct 19, 2015 7:35 pm
by AndreyB
Rhinoman wrote:It seems like it from what I can find, MS uses its own protocol using a 29-bit message format which is normally used on trucks or for proprietary data.
I would love to get a sniff of TS<>some_other_ECU exchange just to have an example.

Re: Firmware developent status

Posted: Mon Oct 19, 2015 8:33 pm
by Rhinoman
The specs that you can get on-line are the SAE specs, these are the specs that were originally called up by the OBD2 legislation, SAE specs generally are the US implementations of the International (ISO) standards. They are available from the internet archive and are usually easier to locate from Google.

i.e. SAE J1962 (connector).
https://archive.org/details/gov.law.sae.j1962.1995

i.e. SAE J1979 (test modes)
https://archive.org/details/gov.law.sae.j1979.2002

I have some ISO specs such as ISO11898 (CANbus)

The original CARB regulations are here:
http://www.anr.state.vt.us/air/docs/CalifCode/1968.1.pdf
You need to trawl through the EPA/CARB website because the regulations changed continuously. Mostly they just added stuff, foe example, KWP2000 and CANbus weren't allowed by the original regulations.

The main advantage of using ISO/SAE standards is that a cheap Bluetooth/ELM tool can be used, the main disadvantage is that, prior to CAN, its a very slow interface. Suzuki models use a combination of a proprietary implementation for live data and an OBD2 compliant implementation for fault codes, live data is also available via OBD2 for the proles.

Re: Firmware developent status

Posted: Mon Nov 02, 2015 12:00 pm
by KaxLon
russian wrote:I would love to get a sniff of TS<>some_other_ECU exchange just to have an example.
You mean like a MS2 <-> TS ? I can make that happen. Do you want the raw USB traffic?

Re: Firmware developent status

Posted: Mon Nov 02, 2015 2:57 pm
by AndreyB
KaxLon wrote:Do you want the raw USB traffic?
that exchange was in light of TunerStudio CAN option. I am not sure how raw USB is applicable here but raw CAN would be great!

Re: CAN support

Posted: Wed Nov 18, 2015 7:18 pm
by Rhinoman
In the past I've used CCP for development and programming over CAN:
http://vector.com/portal/medien/cmc/application_notes/AN-AMC-1-102_Introduction_to_CCP.pdf
I should have some example code on my other laptop that I can send to you.

Re: CAN support

Posted: Tue Nov 24, 2015 2:34 pm
by AndreyB
russian wrote:I would love to get a sniff of TS<>some_other_ECU exchange just to have an example.
Still interested :)

Re: CAN support

Posted: Thu Dec 03, 2015 7:24 pm
by AndreyB
russian wrote:
russian wrote:I would love to get a sniff of TS<>some_other_ECU exchange just to have an example.
Still interested :)
Looks like I was totally confused while assuming that TS supports some CAN protocol.

So far I am still unsure which CAN protocols are worth looking for, I am surprised that j2534 requires a $250 piece of hardware.

Re: CAN support

Posted: Thu Dec 03, 2015 8:03 pm
by Tomin
I don't know what protocol do you think. Prot. for diagnostic or for tuning ?
I don't know anything about TS protocols, only about diagnostics.
j2534 is a standard described protocol between PC application and diagnostic tool. It has nothing with protocol between diag.tool and ECU, what I know about that.
I would prefer UDS (ISO14229) (newer one) or ISO15765.
ELM327 is able to handle ISO15765 prety well. I think it is the cheapest way.

Re: CAN support

Posted: Thu Dec 03, 2015 8:17 pm
by Rhinoman
I'm pretty sure that UDS is simply an extension of ISO 15765. J2534 is the standard for a 'pass through' connection for programming and doesn't replace ISO15765 either. I believe that Russian has already partly implemented 15765.

Re: CAN support

Posted: Thu Dec 03, 2015 8:42 pm
by AndreyB
Tomin wrote:I don't know what protocol do you think. Prot. for diagnostic or for tuning ?
ELM327 is able to handle ISO15765 prety well. I think it is the cheapest way.
rusEfi already has some diagnostics via ELM327 - there are definitely bugs (would be great if anybody has a look by the way) but at least some sensors were displayed in Torque.

I am actually trying to understand if tuning via CAN makes sense or not. Would ELM327 be capable of handling longer ISO15765 packets for tuning?

q1: is there any vehicle-specific free or better open source software which would do tuning via ELM327? That would allow me sniff the exchange and play with all this with some ECU on a bench

q2: same as q1, but configurable software so that I can create a configuration for rusEfi? RomRaider is close to be answer but a) it's pretty much dead and b) I think it uses j2534 and not ELM327.

Bottom line - I still do not understand the whole CAN thing completely.

Re: CAN support

Posted: Thu Dec 03, 2015 9:38 pm
by Tomin
Elm does not supp. long packets nativelly, but they could be sended with some added soft. in a master. So it would have to supp. in TS.

Re: CAN support

Posted: Thu Dec 03, 2015 9:43 pm
by AndreyB
Looks like TunerStudio ("TS") has nothing to do with ELM327. At the moment I do not know any tuning software which would tune anything via ELM327. Do you know any software (open source would be best) which would tune anything via elm327?

Re: CAN support

Posted: Fri Dec 04, 2015 2:04 am
by kb1gtt
Is this of any potential interest? Seems to list AT commands and such for software.

http://www.elmelectronics.com/DSheets/ELM327DS.pdf
Capture.PNG
Capture.PNG (20.39 KiB) Viewed 27377 times

Re: CAN support

Posted: Fri Dec 04, 2015 2:08 am
by AndreyB
Image
that's the scary part - looks like it's the limit of elm327 capacity. There is an opinion that a smarter device is needed for longer packets needed for tuning.

See also http://forscan.org/forum/viewtopic.php?f=4&t=867

Re: CAN support

Posted: Fri Dec 04, 2015 10:23 am
by Tomin
Don't know about any tuning with ELM.
I think only serial port or usb to serial port is supported in MS, no ? (http://www.tunerstudio.com/index.php/cablesandbluetooth)

You can use ELM like a "retransceiver", but it is not so simple as with other "transparent" devices.
ELM can not handle iso15765 multiframe packets nativelly for you,
but you can, with some code in your software/(client of ELM), send such packets.
Look at command AT CAF 0
Once you turn off CAN autoformating, you can send PCI byte in your data, so you can drive how PCI will count sequence of packets etc.
Also you can turnoff automatic "can flow control" (PCI=30) and send it in your soft too. See command AT CFC 0

There is a better ELM -> STN1100 chip. There should be some beta stage firmware for that with support sending of long packets, but
don't know how far it is from working state. You can try to ask here.

My Fordiag interface (something similar to STN chip) also will have support for long packets in a short future. It is also interface in <100$ range.
It will have even Lawicel compatibility, which has very simple command set and is more "transparent" for data between serial and CAN.

Re: CAN support

Posted: Fri Dec 04, 2015 2:42 pm
by Rhinoman
J2534 is only applicable to North America, elsewhere the laws are based on EOBD which states that manufacturer's must protect the ECU against unauthorised access. I doubt if anyone outside NA would want to buy a J2534 interface.
The STN1110 is ELM compatible and supports raw CAN, that would be worth looking at.

Re: CAN support

Posted: Fri Dec 04, 2015 2:45 pm
by Tomin
Rhinoman wrote:The STN1110 is ELM compatible and supports raw CAN, that would be worth looking at.
Are there any diferencies between raw can in STN and ATCAF0 in ELM ? What do you think exactly with that ?

Re: CAN support

Posted: Mon Dec 07, 2015 3:52 pm
by AndreyB
Tomin wrote:but you can, with some code in your software/(client of ELM), send such packets.
My whole point with CAN is to use some existing tuning software. Originally I was thinking that TunerStudio was the software with CAN support, this turned out not to be true. For rusEfi console I think I will stay with TTL for now since it works OKish for now. Only once somebody comes up with CAN tuning software it would make sense to move forward with more CAN login in rusEfi.

Re: CAN support

Posted: Wed Dec 09, 2015 4:35 am
by blundar
Andrey, you're making this too hard. CAN is just like ethernet or USB (well not JUST like) - it's a transport mechanism. It's almost as inconsequential as TCP/IP is for delivering movies with Netflix. It's a means to an end, that's all. There are some standards and conventions, but no magic. The higher-level protocols like KWP2000 and the many proprietary chats are what are interesting. CAN is like the alphabet where the higher level protocols are the article or book.

AFAIK, there are *NO* applications that use ELM for actual tuning/reprogramming ECUs. The ELM interfaces are incredibly slow compared to most of the quality J2534 interfaces. (And $250 is CHEAP for a J interface! My MyCanic was about $800 when I got it and the CarDAQ plus my buddy has was close to $1600 new) There are a couple of notable applications that make use of the OpenPort (which is a J2534 interface made by tactrix.com ) for reprogramming primarily Subaru and Mitsubishi vehicles. RomRaider, ECUFlash. I'd never want to try any reprogramming with an ELM anyway - programming a 2008 Ford diesel truck with a Siemens ECU takes ~12minutes with the Ford software and a good J2534 interface. Even with a custom rewritten boot loader and all the stops pulled out, it still takes 6-7minutes. It would take hours with an ELM, even if the protocols were supported.

One of my buddies did recommend this for modifying / souping up ELM interfaces. It's an alternative firmware that allows the LAWICEL protocol, which makes it useful to use with several open source packet monitoring softwares:
https://area515.org/elm327-hacking/

Re: CAN support

Posted: Wed Dec 09, 2015 10:52 am
by kb1gtt
I think that russian is mostly looking for an existing software package as it prevents the need of redeveloping bits of the puzzle. It looks like tactrix / openecu uses CAN for programming. That is a very popular Subaru re-flashing device. Perhaps it's worth considering making rusEFI function with one of the protocols supported by openecu.

Re: CAN support

Posted: Wed Dec 09, 2015 1:23 pm
by Rhinoman
kb1gtt wrote:I think that russian is mostly looking for an existing software package as it prevents the need of redeveloping bits of the puzzle. It looks like tactrix / openecu uses CAN for programming. That is a very popular Subaru re-flashing device. Perhaps it's worth considering making rusEFI function with one of the protocols supported by openecu.
Tactrix/OpenECU is not actually an open source project and the Subaru code uses encryption.

Re: CAN support

Posted: Thu Dec 10, 2015 1:42 am
by AndreyB
blundar wrote:And $250 is CHEAP for a J interface! My MyCanic was about $800 when I got it and the CarDAQ plus my buddy has was close to $1600 new)
I guess that's the part which I am failing to comprehend. How comes there is no such thing as a $49 open hardware/open source J2534?