Possible to convert MUT2 to OBD2?

[kc427]

Any idea or is it possible? I just have something in mind. MUT2 protocol is known, OBD2 protocol is also known. So, I am thinking that, the ECU sends out MUT2 protocol data, then use a device, eg, Arduino, to fetch the data, then converts the data to OBD2 protocol and sends out the data. Then can use normal ELM327 bluetooth, and then use Torque Android apps. Is my idea possible?

 

[BCX]

I've been playing around with something like this for a while.

There's quite a lot of hurdles to overcome to do this.

Will elaborate a bit more when I'm not on posting on my phone

 

[kc427]

Glad to hear someone is doing this too.

 

[Mattalot]

Following this, also keen for something like this!

 

[kc427]

Updates:

Finally, google this information, most important thing, https://www.instructables.com/id/Arduino-OBD2-Simulator/ This guy uses Arduino to simulate OBD2 signal by using Uno and CAN-BUS Shield. In other words, it can generate OBD2 signals, so in theory, plug in the ELM327 bluetooth, and then use Torque Android apps, and then can show the data. I think this is one big step forward.

 

[mezje]

Updates:

Finally, google this information, most important thing, https://www.instructables.com/id/Arduino-OBD2-Simulator/ This guy uses Arduino to simulate OBD2 signal by using Uno and CAN-BUS Shield. In other words, it can generate OBD2 signals, so in theory, plug in the ELM327 bluetooth, and then use Torque Android apps, and then can show the data. I think this is one big step forward.

I like this a lot but am not particularly confident, how does this work? It gets OBD2 signals, which are their own protocol, feeds in to the arduino and then what happens? What exactly is converting the MUT2 protocol, if that is even happening.

 

[kc427]

I like this a lot but am not particularly confident, how does this work? It gets OBD2 signals, which are their own protocol, feeds in to the arduino and then what happens? What exactly is converting the MUT2 protocol, if that is even happening.

Should be the other way around. Feeds MUT-II into the Arduino, then convert the data and output the OBD2 signals. This diagram would be more clear.

 

[mezje]

Thanks! I figured the arduino would handle the change but got confused reading the github

 

[BCX]

doh forgot about this.

My conversion between MUT <--> OBD still uses the ISO9141-2 method of communication on the OBD side. We could use CAN instead.
In my proof of concept, the issue I ran into originally was the Arduino I was using used an ATmega328 which only had 1 uart.
I wasn't interested in using another processor with more than one uart, basically cos I didn't want to/had time to learn another toolset. The limitation of 1 uart meant serial had to be implemented in software, and cause problems with buffer and performance.

Plus i was doing this for my own benefit (didn't think there was interest for it), I've overcame my original interest by getting any of my projects to directly understand the MUT protocol to read values such as trip computer/lcd (another unfinished project), wireless Bluetooth connectivity for an android app to clear DTCs/read values (another unfinished project, see the trend? lol)

Since looking at this a few years ago, appears Microchip/Atmel have a revised atmega328pb which has two hardware uarts.

My software architecture for this was the following:

• Arduino received OBD PID
• performs lookup in table to find what MUT location is the equivelant PID
• requests MUT location from ECU
• receives reply
• Performs lookup to see what maths operations are required to normalise/format the MUT value to what the PID is expecting
• sends reply on OBD bus

Things that I never overcame/didn't investigate (though probably easy to fix)

• timeouts for obd where MUT side needed to send five baud init (usually this is around 2 seconds)
• implementing fifo buffers as two protocols are different bauds
• keeping MUT alive to avoid five baud init
• optimize code to allow for greater sample rate
• needed to compile a complete list of PID vs MUT, i only had the obvious ones for testing

Hope this helps.

Cheers,
Bill

 

[Lasiorhinus]

I'd be very interested in a system that could do things like this.

 

[kc427]

doh forgot about this.

My conversion between MUT <--> OBD still uses the ISO9141-2 method of communication on the OBD side. We could use CAN instead.
In my proof of concept, the issue I ran into originally was the Arduino I was using used an ATmega328 which only had 1 uart.
I wasn't interested in using another processor with more than one uart, basically cos I didn't want to/had time to learn another toolset. The limitation of 1 uart meant serial had to be implemented in software, and cause problems with buffer and performance.

Plus i was doing this for my own benefit (didn't think there was interest for it), I've overcame my original interest by getting any of my projects to directly understand the MUT protocol to read values such as trip computer/lcd (another unfinished project), wireless Bluetooth connectivity for an android app to clear DTCs/read values (another unfinished project, see the trend? lol)

Since looking at this a few years ago, appears Microchip/Atmel have a revised atmega328pb which has two hardware uarts.

My software architecture for this was the following:

• Arduino received OBD PID
• performs lookup in table to find what MUT location is the equivelant PID
• requests MUT location from ECU
• receives reply
• Performs lookup to see what maths operations are required to normalise/format the MUT value to what the PID is expecting
• sends reply on OBD bus

Things that I never overcame/didn't investigate (though probably easy to fix)

• timeouts for obd where MUT side needed to send five baud init (usually this is around 2 seconds)
• implementing fifo buffers as two protocols are different bauds
• keeping MUT alive to avoid five baud init
• optimize code to allow for greater sample rate
• needed to compile a complete list of PID vs MUT, i only had the obvious ones for testing

Hope this helps.

Cheers,
Bill

Thanks for your information, and I will get more information later when I have time, because I am still playing with my Arduino with Defi gauges.

 

[kc427]

Just got the CAN_BUS_Shield and UNO yesterday, and will test the basic ODB2+ELM327 with app later when have spare time.

 

[kc427]

doh forgot about this.

My conversion between MUT <--> OBD still uses the ISO9141-2 method of communication on the OBD side. We could use CAN instead.
In my proof of concept, the issue I ran into originally was the Arduino I was using used an ATmega328 which only had 1 uart.
I wasn't interested in using another processor with more than one uart, basically cos I didn't want to/had time to learn another toolset. The limitation of 1 uart meant serial had to be implemented in software, and cause problems with buffer and performance.

Plus i was doing this for my own benefit (didn't think there was interest for it), I've overcame my original interest by getting any of my projects to directly understand the MUT protocol to read values such as trip computer/lcd (another unfinished project), wireless Bluetooth connectivity for an android app to clear DTCs/read values (another unfinished project, see the trend? lol)

Since looking at this a few years ago, appears Microchip/Atmel have a revised atmega328pb which has two hardware uarts.

My software architecture for this was the following:

• Arduino received OBD PID
• performs lookup in table to find what MUT location is the equivelant PID
• requests MUT location from ECU
• receives reply
• Performs lookup to see what maths operations are required to normalise/format the MUT value to what the PID is expecting
• sends reply on OBD bus

Things that I never overcame/didn't investigate (though probably easy to fix)

• timeouts for obd where MUT side needed to send five baud init (usually this is around 2 seconds)
• implementing fifo buffers as two protocols are different bauds
• keeping MUT alive to avoid five baud init
• optimize code to allow for greater sample rate
• needed to compile a complete list of PID vs MUT, i only had the obvious ones for testing

Hope this helps.

Cheers,
Bill

I checked the CAN-Bus Shield schematic, and actually, the Arduino uses SPI to communicate with the CAN-Bus shield, and inside that CAN-Bus shield, it has CAN controller MCP2515 and CAN transceiver MCP2551, so therefore, there is no UART needed for the CAN-Bus shield, and ATmega328P with 1 UART for MUT-II is enough. My only concern is the speed.

Anyway, I just used Arduino UNO with CAN-Bus Shield, plus a bluetooth ELM327 dongle, and successfully simulated few ECU data eg, SPEED, RPM, coolant temp, throttle position. Then I used Torque app to display the data on my phone:

My 1st task has been done, the OBD2 simulation is working by Arduino.

And now, I need to start digging information about hardware connection on MUT-II port and software protocol to talk to our ECU

 

[mezje]

Keep it up mate, awesome stuff!

 

[BCX]

MUT is based off ISO9141-2 standard, except the l-line is not used, only k-line. Baud is 15625, provided your Arduino is using an external crystal at 16mhz, you should have any framing errors.

hardware wise, you'll need an input/output driver that can deal with rs232 logical level. MAX232 works well for this. as the communications is half duplex down the same line, you'll need to account for this in your software. whatever you transmit, you will also receive.

To communicate, the communicate channel needs to be initialised. This is done using the 5 buad init. This not only initalises the communication channel, but allows you to specify which system you'd like to communicate to. As such, you can only communicate with one system at any given time. To communicate with the Transmission, AYC, or SRS, etc. communication needs to time out and then re-initallised with a different system address.

Addresses are below, used my oscilloscope to snif my MUT3 tool. Below is the enum I usually use in my code. You can see an address of 0x0 will initalise the ECU, TCU = 0x1. Some systems our vr4 doesn't have such as immobiliser, camera, etc

public enum ECUAddress
{
ECU = 0x0,
TCU = 0x1,
IMMOBILISER = 0x89,
SS4II = 0x92,
TCL = 0x85,
ECS = 0x2,
ABS = 0x4,
STEERING = 0x83,
HBB = 0x91,
AYC = 0xB,
SRS = 0x8,
SWS = 0x8A,
TPMS = 0x19,
CAMERA = 0x1A
}

5 bit baud is hard to achieve with the arduino uart, so i bit-bang this. Fast initialsation is not supported. So to keep the path up, you need to keep talking. I usually just randomly request something and discard the response.

squence is:
startbit (hold for 200ms)
8 bits representing the address
stopbit

Before sending the 5-bit baud init sequence, you'll need to earth pin 1 on the OBD plug. All other systems that you aren't communicating to will flash their error codes with their respective warning lights. I've hacked the ECU rom to communicate out-of-band, so pin1 does not need to be earthed. but it's not stable, needs some more work.

once 5 bit baud is complete, the respective control unit will reply with 2 bytes. after this, the comms path is open.

Send a byte, and you will receive a byte back.


will add more to this soon...

 

[kc427]

Currently, I use arduino Tx/Rx to connect to the Freescale MC33290, which converts 5v Tx/Rx directly to K Line, so I think it makes life easier without MAX232.

There is a guy who used this MC33290 with Arduino code for ISO-9141. It's worth to take a look if you wish, https://github.com/rvmiller89/arduino_obd, and also https://rvmiller.com/present/CS497_presentation_miller.pdf to see the HW connection.

I took all these as reference for HW connection, and also pin1 to ground, and modified his Arduino code for ISO-9141 to MUT-2 by information I found from the web site MUT-2, https://evoecu.logic.net/wiki/MUT_Protocol and I followed the steps to do the i5 baud init. After switch to 15625 baud, I didn't receive the "C0 55 EF 85"

Do you know any other sites have information about the MUT protocol?

MUT is based off ISO9141-2 standard, except the l-line is not used, only k-line. Baud is 15625, provided your Arduino is using an external crystal at 16mhz, you should have any framing errors.

hardware wise, you'll need an input/output driver that can deal with rs232 logical level. MAX232 works well for this. as the communications is half duplex down the same line, you'll need to account for this in your software. whatever you transmit, you will also receive.

To communicate, the communicate channel needs to be initialised. This is done using the 5 buad init. This not only initalises the communication channel, but allows you to specify which system you'd like to communicate to. As such, you can only communicate with one system at any given time. To communicate with the Transmission, AYC, or SRS, etc. communication needs to time out and then re-initallised with a different system address.

Addresses are below, used my oscilloscope to snif my MUT3 tool. Below is the enum I usually use in my code. You can see an address of 0x0 will initalise the ECU, TCU = 0x1. Some systems our vr4 doesn't have such as immobiliser, camera, etc

public enum ECUAddress
{
ECU = 0x0,
TCU = 0x1,
IMMOBILISER = 0x89,
SS4II = 0x92,
TCL = 0x85,
ECS = 0x2,
ABS = 0x4,
STEERING = 0x83,
HBB = 0x91,
AYC = 0xB,
SRS = 0x8,
SWS = 0x8A,
TPMS = 0x19,
CAMERA = 0x1A
}

5 bit baud is hard to achieve with the arduino uart, so i bit-bang this. Fast initialsation is not supported. So to keep the path up, you need to keep talking. I usually just randomly request something and discard the response.

squence is:
startbit (hold for 200ms)
8 bits representing the address
stopbit

Before sending the 5-bit baud init sequence, you'll need to earth pin 1 on the OBD plug. All other systems that you aren't communicating to will flash their error codes with their respective warning lights. I've hacked the ECU rom to communicate out-of-band, so pin1 does not need to be earthed. but it's not stable, needs some more work.

once 5 bit baud is complete, the respective control unit will reply with 2 bytes. after this, the comms path is open.

Send a byte, and you will receive a byte back.


will add more to this soon...

 

[BCX]

Currently, I use arduino Tx/Rx to connect to the Freescale MC33290, which converts 5v Tx/Rx directly to K Line, so I think it makes life easier without MAX232.

There is a guy who used this MC33290 with Arduino code for ISO-9141. It's worth to take a look if you wish, https://github.com/rvmiller89/arduino_obd, and also https://rvmiller.com/present/CS497_presentation_miller.pdf to see the HW connection.

I took all these as reference for HW connection, and also pin1 to ground, and modified his Arduino code for ISO-9141 to MUT-2 by information I found from the web site MUT-2, https://evoecu.logic.net/wiki/MUT_Protocol and I followed the steps to do the i5 baud init. After switch to 15625 baud, I didn't receive the "C0 55 EF 85"

Do you know any other sites have information about the MUT protocol?

Everything I've posted is from my own experience playing with a MUT and oscilloscope.

I'll have a look at the arduino stuff you posted, looks interesting. I'll have to dig up an arduino and my old code to see where I got to.

 

[kc427]

That guy did the code for ISO-9141 and claimed it's working. So, ISO-9141 and MUT-2 are similar, I expect changing the init code/steps should work on MUT-2.

Everything I've posted is from my own experience playing with a MUT and oscilloscope.

I'll have a look at the arduino stuff you posted, looks interesting. I'll have to dig up an arduino and my old code to see where I got to.

 

[BCX]

After switch to 15625 baud, I didn't receive the "C0 55 EF 85"

I ignore the response after 5 baud init. its not important.
You should be able to request a PID shortly after 5 baud init.

From memory my Arduino code checked that it was receiving a valid response for a PID. MUT tool usually uses 0xFE and 0xFF. Sending 0xFE and 0xFF will reply back with the 2 byte rom/ecu ID which MUT tool uses to identify the ecu.

My C# code using FTDI cable definitely does this, pretty sure my Arduino code replicated the same behaviour.

Code logically is something like:
earth pin 1
5-baud init
So switch to 15625
send 0xFE, wait response
send 0xFF, wait response
Comms should be open.

If either PID didnt get a response, then 5-baud init failed, pin 1 disconnect, wait ~500ms, go back to start.

Timeout to keep comms alive is usually 10-15 seconds otherwise you'll need to 5-baud init again. (back to start)

 

[kc427]

Let me try again when I have time again. I think maybe there is problem with my 5 baud init.

I ignore the response after 5 baud init. its not important.
You should be able to request a PID shortly after 5 baud init.

From memory my Arduino code checked that it was receiving a valid response for a PID. MUT tool usually uses 0xFE and 0xFF. Sending 0xFE and 0xFF will reply back with the 2 byte rom/ecu ID which MUT tool uses to identify the ecu.

My C# code using FTDI cable definitely does this, pretty sure my Arduino code replicated the same behaviour.

Code logically is something like:
earth pin 1
5-baud init
So switch to 15625
send 0xFE, wait response
send 0xFF, wait response
Comms should be open.

If either PID didnt get a response, then 5-baud init failed, pin 1 disconnect, wait ~500ms, go back to start.

Timeout to keep comms alive is usually 10-15 seconds otherwise you'll need to 5-baud init again. (back to start)