Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

How to communicate with ECUs? #4

Open
michalmikolajczyk opened this issue Oct 4, 2017 · 46 comments
Open

How to communicate with ECUs? #4

michalmikolajczyk opened this issue Oct 4, 2017 · 46 comments
Labels
help wanted team discussion
Milestone
Alpha

Comments

@michalmikolajczyk
Copy link
Member

The purpose of this discussion is to find the optimal, generic interface to ECUs.

Reading into ECU tuning, I could not find any generic ECU open-source hardware or software, until I stumbled on this awesome piece of software http://www.tuneecu.com/ (don’t be tricked by the funny looking website, the community states it's legit.)

That software is not compatible with KTM dirtbikes though. A user on another forum noted, that official KTM software for ECU tuning, can be downloaded for free, but they charge $500 for the cable. The OBD connector is CAN-bus, while the tuneECU supports the KTM Duke 690 and 990 motorcycles, which use K-Line OBD. Here is the link to the forum: http://ecuhacking.activeboard.com/t49773328/interfacing-to-ktm-keihin-ecu-canbus/

Obviously, it would be terrific for us to be able to connect an IoT device directly to the ECU. There are cables for that, e.g. https://www.powercellperformance.com/shop/tuneecu-programing-cables/
IMHO if we could skip the piggyback hardware in favor of software, it will get us much closer to our goal. One way to do this, would be to install tuneECU on a Raspberry Pi, solutions for that were found after a quick google.

Questions:

  1. any chance of creating a DIY CAN-bus connector?
  2. how do we interact with tuneECU running on the Raspberry Pi, connected to the motorcycle?
  3. any other thoughts?
@decaun
Copy link

decaun commented Oct 5, 2017

You can order Can2Usb cable for 25$: https://m.aliexpress.com/s/item/32611523816.html?spm=a2g0n.search-cache.0.0.34656344ZS6HyG#autostay

With raspberry we need to use a module costs 1.51$ over SPI: https://m.aliexpress.com/s/item/32647462532.html?spm=a2g0n.search-cache.0.0.4b2e10c7PxJioy#autostay

Also some cables :)

Raspberry SPI, I2C tutorial: https://learn.sparkfun.com/tutorials/raspberry-pi-spi-and-i2c-tutorial

@michalmikolajczyk
Copy link
Member Author

@decaun that is quite cool.

If I understand correctly, we can basically connect to the dirtbikes via a Raspberry Pi.
And to connect to a whole other set of machines, we could just use tuneECU.

So what remains is the software to actually communicate with the ECU.

Here is an interesting discussion on the subject:
https://thumpertalk.com/forums/topic/1126740-ktms-ust-or-user-tool-must-read/
They mention the map files, which are *.ksd

And here is the Windows program to use with the UST – User Setting Tool (which costs like $500):
http://www.ktm.com/us/service/maintenance/ So the purpose of those devices (hardware+software) is to read data from the ECU, and overwrite the fuel and ignition maps. Just what we need.

I wonder if the CAN2USB cable will allow us to connect? :) I guess if we get any communication from the ECU, we could try to reverse engineer the protocol, similar to what Sergey Pisarenko did here http://pisarenko.net/blog/2017/04/16/internet-connected-motorcycle-project/ with the Power Commander software.

Does that make sense to you?

My main concern is that, I would rather have the project focused on common solutions, rather then interfaces for particular machines. We need the prototypes, but how can we generalize the solution, and have as little hardware dependencies as possible?

@decaun
Copy link

decaun commented Oct 5, 2017 •
edited
Loading

@michalmikolajczyk well it depends on module we use, it can be receiver, transmitter or both depending on a chip it use. Tune ECU uses both rx/tx at can bus.

As far as i read Sergey Pisarenko already had usb connection at his bike via fuel injection module. If you have such device already it is pretty smart to use MQTT as him.

Can bus is asynchronius protocol without any clock. There is sync period between machines to decide baud rate. Maximum transmission speed is 1Mbps(16MHz).

As in http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ we can use pwm to replicate can bus at GPIO ports but with lower speeds. Speed definitely depends on language we use as you can see( only Native C is at required MHz levels).

It also makes interacting with ECU a bit dangerous on the go. If you change fuel amount on the go that might cause engine to stop instantly and someone can crash.

It is possible to replicate can bus protocol with lower speeds. We just need to implement existing protocol.

Still my concern is having less data speed and energy efficiency since we will use cpu power on raspberry by increasing development time. I dont think it just worths to code it than using a cheap dedicated solution.

I used can2usb for a car to increase fuel efficiency before, its not that easy to tune it even you have expensive hw+sw. Especially on the go it is pretty dangerous. For me safest use case is to just monitor.

@michalmikolajczyk michalmikolajczyk added this to the Alpha milestone Oct 5, 2017
@michalmikolajczyk
Copy link
Member Author

@decaun that is great insight!

communication with ECU
I am not sure if I understand this correctly though. I was most worried about 1. establishing communication with the ECU and 2. understanding the protocol and messages.

CAN-bus interface
Using GPIO ports to replicate can bus sounds awesome. Do you think we need the full app to use C, or just the GPIO CAN-bus replica driver?

safety
we definitely need to restrict tx access, while the machine is operating.

dedicated solutions
I did not quite understand that part. I am all in for quality. Our aim is to build a performant platform. I don't mind deciding to develop less, but I would rather not compromise on the performance of our product. We can rely on other solutions, as long as the license allows us to. We should make them options, if our end users would need to pay for that.
Please let me know what you had in mind.

RX / TX safety
I hear you. Let's keep in mind, that we are not making an end product, but a toolset / framework / platform. We can let our user – the engineer – take care of the particular safety and security precautions, specific to their application. What do you think?

question
are you sure that tuneECU uses CAN-bus? I thought they only used K-line, and I did not understand why open-source CAN-bus solutions were not available

@decaun
Copy link

decaun commented Oct 6, 2017 •
edited
Loading

@michalmikolajczyk

I suppose TuneECU uses more than one protocol regards to bike ECU. Please check: https://en.wikipedia.org/wiki/On-board_diagnostics#OBD-II

It goes like;
SAE J1850 PWM
SAE J1850 VPW
ISO 9141-2
ISO 14230-4
ISO 15765-4 CAN
SAE J1939

For raspberry it is pretty easy to handle ISO 15765-4 CAN at first glance.
Because GPIO pins are digital and at 3.3V with max preferred 16mA ratings, specialized hw could be necessary for each other protocol(since they are rated at 5-12V at unknown currents depends on bikes battery internal resistance etc.).

Challange is not hard if you consider to apply it to support only single bus interface. But if you are willing to support all those protocols above, it is rather complex.

After some research i found an open source hw+sw designed exactly for it already: https://hackaday.com/tag/iso-9141-2/
Instead of arm we can rewrite source code and run it on raspberry.
We can use multiple GPIO pins to drain less current from each and use minimum hardware implementation.

There is also pyobd http://www.instructables.com/id/OBD-Pi/
Im not sure if you can send data to ECU with pyobd since its meant to monitor it.

I think its not really necessary to have high data speed to communicate with ecu but drivers are written already at C++ why not take advantage of it.

Depending on your bike, you already have we can pick one of those protocols and start to develop hw+driver. Than we can add support to other protocols exists.

Last but not least it is going to be even simpler to just monitor ECU at hw side(possible without any special IC). So we can start from monitoring of a selected protocol.
With only voltage regulator, simple transistor and few passive elements we can do it as done in here: http://www.instructables.com/id/Low-Cost-OBD2-Communications-on-K-line-ISO-9141-2-/

@michalmikolajczyk
Copy link
Member Author

@decaun thank you for this. I believe that our Alpha, which is the first prototype, is actually read only in terms of the ECU. So let's just do this, then.

I think it would be great if we would provide at least one end-to-end path, basically supporting at least one bus interface. We would need to make that driver modular, so that it could be replaced by another one, when it is prepared. I understand that because of the voltage differences, other devices would be needed.

The bike that I have, which has the most sophisticated ECU, is KTM SX-F 250 Factory Edition, Model Year 2017. I can't seem to find which protocol that one uses, but I'll drop by the garage and check on the device, perhaps there is some more info. The other bikes have carburetors, and not EFIs. We also have access to the same bike as Sergey Pisarenko, though he used the piggyback Power Commander hardware.

@awareentity awareentity mentioned this issue Oct 17, 2017
Closed
@michalmikolajczyk
Copy link
Member Author

@serega-174
Copy link

Hello, are there any advances on this project, this topic is also of interest.

@michalmikolajczyk
Copy link
Member Author

@serega-174 not really, but it would be nice to take up development on this again, if there's an actual need for it. Would you like to share what you are working on? Perhaps we can help.

@serega-174
Copy link

serega-174 commented Jan 7, 2019 •
edited
Loading

There are no specific developments. but it is possible to read the fully binary firmware file. On the thematic forums there is an assumption that a simple OBD2 cable will not be able to connect. It seems like the UST cable sends a request to the ECU, and he sends him a response with a certain signal. But if you know what this request is, I think that you can reprogram the OBD2 chip or something like that

@michalmikolajczyk
Copy link
Member Author

michalmikolajczyk commented Jan 7, 2019 •
edited
Loading

In the machines, that we worked with (enduro bikes, e.g. KTM 250 SX-F 2018), there was no OBD2 output :/

One of the assumptions we took, was that we would not be able to develop a standard interface solution, that would work across all motorcycles, because the motorbikes bring different hardware.

@serega-174 have you seen http://www.tuneecu.com/ ?

@serega-174
Copy link

the usual OBD2 representation is missing, but the motorcycle has its own 6-pin diagnostic connector. And the computer has a CAN Bus output, since the UST is able to read sensors in real time

@michalmikolajczyk
Copy link
Member Author

Agreed, that’s the path we aimed at

Sent with GitHawk

@dyno-dave
Copy link

I did a little work on communicating with KTM dirt bike ecu's. A challenge code is sent to the ecu and and it responds with a hex value. You must do a calculation on the hex value and send it to the ecu within a certain time limit. If correct, the communication line will open. I have some of the specifics if anyone is interested.

@michalmikolajczyk
Copy link
Member Author

@dyno-dave thanks for letting us know! It sounds interesting. Did you communicate with the ECU, while it was actively connected to a running engine?

Essentially, we would like to get live data from the engine.

@dyno-dave
Copy link

There is an android phone app "Ecu Sensors" that works on KTM's. A bluetooth OBDII "Vgate" module that works to collect data with a custom wiring connector.

@MkLHX
Copy link

MkLHX commented Jul 3, 2019 •
edited
Loading

@dyno-dave
Could you please give me the wiring of you diy adaptor cable between 6pin diag ktm connector and the odb interface you use.
I try to make my own but no connection success between my elm327 wifi adaptor and my ktm 350 exc-f ECU.

EDIT:
i answer to myself.

Ktm 6pins => odb 16pins
1 => 16
2 => 6
3 => 14
4 => 7
5 => NC
6 => 4

@MkLHX
Copy link

MkLHX commented Jul 17, 2019 •
edited
Loading

There is an android phone app "Ecu Sensors" that works on KTM's. A bluetooth OBDII "Vgate" module that works to collect data with a custom wiring connector.

Hi there, there is an equivalent of this app on iso?

I'm looking for diag my ktm 350 exc-f with diy wire with a ELM327 interface, connections are good but nothing appends when smartapp try to connect through elm327 on the ECU.

i'm try this with 5 apps but no result. But i'm sure it's possible as you can see here

@canbusobd2
Copy link

hi, sorry my english! I am from Brazil. (help google translate). - I want to develop connection to ktm exc 350 in OBD2. @dyno-dave A challenge code is sent to the ecu and and it responds with a hex value. You must do a calculation on the hex value and send it to the ecu within a certain time limit. (yes, ktm super adventure CAN BUS identical ktm offroad, for connect uses BUS CONTROLLER CAN) The CAN bus system is an intelligent data-bus and doesn't have fuses. If the system detects a higher level of current being drawn on a circuit due to an accessory connected to it, it will simply switch that circuit off. It puts an error message on your dash. That error message is basically telling you to go and make the local dealer a bit richer. Plus, your accessory still won't work!

I am sure you will be able to access...

@canbusobd2
Copy link

controlador de interface can bus

controller can bus. Can we help each other [email protected]

@maiverik
Copy link

I did a little work on communicating with KTM dirt bike ecu's. A challenge code is sent to the ecu and and it responds with a hex value. You must do a calculation on the hex value and send it to the ecu within a certain time limit. If correct, the communication line will open. I have some of the specifics if anyone is interested.

@dyno-dave Can you share specifics pls, i try to make AIM work with MX KTMs

@ptechaus
Copy link

@dyno-dave looking into this as well.
i have an ecu on the way but any information you have to help with this project, i will be more then happy to share my solution once finished.

@andrea282
Copy link

ok I'm testing with kessv2 but for now nothing to do

@Jacques-BAHADORI
Copy link

Hi everybody,

I raise the subject because I have just recovered a KTM Freeride 350 from 2015 with a power failure ... And with an ELM327 Bluetooth adapter, and an ODB2 cable to the KTM 6-pin connector (I checked the wiring), I can't connect to the ECU. However, I tried, by energizing the circuit (by forcing the main relay with a shunt) several times with Torque, Car scanner, and TuneECU, without success.

On this motorcycle, the ECU is new (KTM invoice April 2022) and it has never worked. I think there was never a map loaded inside and there apparently isn't one by default... So I would like to connect to the ECU and try to load a MAP.
Does anyone have any information on this?

In addition, I have an initial formation in electronics and I develop C programs from time to time. So, I can help if necessary...

Thank you and good day.

Best regards.

Jacques

@MotoDan
Copy link

MotoDan commented Jun 15, 2023

@dyno-dave can you contact me?

@dyno-dave
Copy link

dyno-dave commented Jun 15, 2023 via email

@MotoDan
Copy link

MotoDan commented Jun 15, 2023 via email

@dyno-dave
Copy link

dyno-dave commented Jun 16, 2023 via email

@MotoDan
Copy link

MotoDan commented Jun 16, 2023 via email

@maiverik
Copy link

@dyno-dave, @MotoDan
Guys, im also still looking for this protocol. Please share with me when you find it.

@Jacques-BAHADORI
Copy link

Hello, I am also interested in the subject and I can possibly help.
Thanks.
Jacques

@HarleyGAnderson
Copy link

For pre 2017 ktm excf/sxf the ecu has a 128kb file
MCU is similar to M16C
Password for these ecu's i believe is 12 26 56 99 84 F3 F1 (ill have to go back through my files to double check)

alientech kess and piasini tools can read/write these ecu's as well as the 2017+ ecu's which have a 1028kb file

@MotoDan
Copy link

MotoDan commented Jun 19, 2023 via email

@dyno-dave
Copy link

dyno-dave commented Jun 20, 2023 via email

@MotoDan
Copy link

MotoDan commented Jun 20, 2023 via email

@dyno-dave
Copy link

dyno-dave commented Jun 20, 2023 via email

@MotoDan
Copy link

MotoDan commented Jun 20, 2023 via email

@MotoDan
Copy link

MotoDan commented Jul 13, 2023 via email

@dyno-dave
Copy link

dyno-dave commented Jul 13, 2023 via email

@MotoDan
Copy link

MotoDan commented Jul 14, 2023 via email

@OlliKantola
Copy link

@MotoDan Are you still actively working on this topic? I have made / I'm in the process of making my own ESP32 based KLine communicator for KTM 690 Enduro MY 2008 with Keihin ECU + Keihin EPT (throttle body control module). Below you may find step-by-step process on how the communication is initialized.

Communication is started by sending following payload to ECU over KLine: 0x81,0xD5,0xF5,0x81,0xCC
ECU responds with: 0x80,0xF5,0xD5,0x03,0xC1,0xDA,0x8F,0x77

Diag tool continues by transmitting: 0x80,0xD5,0xF5,0x02,0x27,0x03,0x76
ECU responds with: 0x80,0xF5,0xD5,0x04,0x67,XX,YY,CRC

This is ECU message is the critical one. Bytes XX and YY are required when calculating the handshake value for the next diag tool transmit. Handshake value is then masked to fit in 16bit variable.
handShakeVal = XX * 0x4E00 + YY * 0x4D4E

E.g.
handShakeVal = 0xDAEC
0x80,0xD5,0xF5,0x04,0x27,0x04,0xDA,0xEC,CRC
Where CRC:
0x80+0xD5+0xF5+0x04+0x27+0x04+0xDA+0xEC = 1087 = 0x43F
0x43F & 0xFF = 0x3F

Following payload is sent by diag tool that contains the calculated handshake value:
0x80,0xD5,0xF5,0x04,0x27,0x04,0xDA,0xEC,0x3F

If handshake value and checksum were correct, the following is sent by ECU:
0x80,0xF5,0xD5,0x02,0x67,0x04,0xB7

From here on diag tool can start to query data from the ECU and ECU will respond. Connection will timeout if more than 400ms has went since last activity (diag tool has to keep the connection alive by querying information). It will take roughly 50ms for single request + response, so data rate of the KLine can be even as good as 20messages per second.

I did reverse engineer the handshake calculation by writing a program to simulate ECU and then I injected different combinations of handshake bytes to diagnostics tool (TuneECU and KTM Ecusensors) and wrote down the calculated handshake value. It took couple of days to figure out how the handshake value was calculated.

Do you have any recordings from the KLine or CAN bus of the bike? Maybe similar or even the exact same handshake is used on another models...

@dyno-dave
Copy link

dyno-dave commented Jul 24, 2024 via email

@DirtBiker92
Copy link

Hello, Im sorry for your loss.I have a question.I have started a small garage for fixeing dirtbikes(especially ktm) and i want to be able to access the ecu, but I only know the basics, but im willing to use my own bike(2021 ktm sx350f) to test everything and if we succeed i can pay.I am willing to learn but dont know where to start.If I can help I am all in.

@vwspeedsterke
Copy link

Which software can I use to read the engine hours, it is for a ktm sxf250 2021 with keihin ecu

@pcace
Copy link

pcace commented Oct 28, 2024 •
edited
Loading

@MotoDan Are you still actively working on this topic? I have made / I'm in the process of making my own ESP32 based KLine communicator for KTM 690 Enduro MY 2008 with Keihin ECU + Keihin EPT (throttle body control module). Below you may find step-by-step process on how the communication is initialized.

Communication is started by sending following payload to ECU over KLine: 0x81,0xD5,0xF5,0x81,0xCC ECU responds with: 0x80,0xF5,0xD5,0x03,0xC1,0xDA,0x8F,0x77

Diag tool continues by transmitting: 0x80,0xD5,0xF5,0x02,0x27,0x03,0x76 ECU responds with: 0x80,0xF5,0xD5,0x04,0x67,XX,YY,CRC

This is ECU message is the critical one. Bytes XX and YY are required when calculating the handshake value for the next diag tool transmit. Handshake value is then masked to fit in 16bit variable. handShakeVal = XX * 0x4E00 + YY * 0x4D4E

E.g. handShakeVal = 0xDAEC 0x80,0xD5,0xF5,0x04,0x27,0x04,0xDA,0xEC,CRC Where CRC: 0x80+0xD5+0xF5+0x04+0x27+0x04+0xDA+0xEC = 1087 = 0x43F 0x43F & 0xFF = 0x3F

Following payload is sent by diag tool that contains the calculated handshake value: 0x80,0xD5,0xF5,0x04,0x27,0x04,0xDA,0xEC,0x3F

If handshake value and checksum were correct, the following is sent by ECU: 0x80,0xF5,0xD5,0x02,0x67,0x04,0xB7

From here on diag tool can start to query data from the ECU and ECU will respond. Connection will timeout if more than 400ms has went since last activity (diag tool has to keep the connection alive by querying information). It will take roughly 50ms for single request + response, so data rate of the KLine can be even as good as 20messages per second.

I did reverse engineer the handshake calculation by writing a program to simulate ECU and then I injected different combinations of handshake bytes to diagnostics tool (TuneECU and KTM Ecusensors) and wrote down the calculated handshake value. It took couple of days to figure out how the handshake value was calculated.

Do you have any recordings from the KLine or CAN bus of the bike? Maybe similar or even the exact same handshake is used on another models...

Hi there, it sounds very interesting!!
i have looked into your 690 datalogger project, but were not sure how far you were able to get the project.
Were you able to find a way to log data on your 690? I am trying to get this to work on a 2016 701. which (i heard) is the last model to have the same Keihin ECU as the 690 - and so the last model without a way to connect to the ecu via standard odb protocolls.
What i am reall interested is the process how you did the reverse enginering - because i doubt that here on my 701 its the same handshake values

Cheers

@OlliKantola
Copy link

@pcace I did got it to a point where I was able to view signal values from a small "Nokia LCD" and log to my smart phone over WIFI connection using pydroid and TCP. However I'm more of an embedded guy instead of Android developer so I was struggling in writing my own Android app.

Unfortunately I don't have the bike anymore, so I can't do any testing or development by myself. My new bike is much more basic electronic wise (Beta RR 300 MY20), but some day I might hook up my ESP32 thingy on it to see what can be extracted from it's K-line.

I did reverse engineer the handshake by emulating 690 ECU with ESP32 for the TuneEcu diagnostics tool. I tried sending different handshake values to see how they affect the response payload. After some hours I was able to derive the formula. I think remapping with TuneEcu is not possible on 2013 and newer bikes. Also my bike had two ECU's, one for engine and one for throttle body.

If you have working diagnostics tool for your bike E.g. TuneEcu, it should be possible to reverse engineer the init comms process. Easiest way to determine if the communication is the exact same is to use cheap 8 channel logic analyzer (saelae logic 8 or similar) and sniff the communication between diag tool and bike ECU's.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted team discussion
Projects
None yet
Milestone
Alpha
Development

No branches or pull requests