J2534 adapters are far more powerfull and more flexible, but also more expensive than ELM327 adapters.
J2534 (PassThru) is an international standard for reprogramming the calibration tables in the ECU.
Although HUD ECU Hacker does not support flashing functionality, it allows to use a J2534 adapter to communicate with the ECU.
There are also chinese clones ($40 USD) but I did not test them yet.
When you plug in the adapter for the first time Windows installs a default driver and assigns a COM port.
After installing the correct driver from the vendor the COM port will disappear and a J2534 device will show up in Control Panel.
The adapters differ in quality and in price.
Additionally when polling the parameters of the ECU they differ in speed.
When you enable the checkbox 'Sniff Mode' you can capture the traffic between a scantool (or another OBD software) and the ECU.
HUD ECU Hacker implements sniffing the K-Line with all 3 types of adapters: K-Line/VAG, ELM327 and J2534.
However, the only bullet-proof way is shown in the diagram above.
If you try to connect a complete adapter instead of the transistor it will probably not work.
Each adapter / scantool has it's pull up resistor of 510 Ω between K-Line and +12V.
Two resistors switched parallel (scantool + additional adapter) result in 255 Ω and a current of 50 mA to pull the K-Line to ground.
Adapters, scantools and the ECUs have a current limitation and are mostly not able to provide that much current.
You may not capture any data or only the sent data without responses. Verify this with an oscilloscope.
Please see the next picture (oscilloscope) below which illustrates the problem already with 510 Ω.
If you want to save the sniffed data to disk use the button Start Logging in the Trace pane.
ATTENTION:
The chinese ELM327 clones do not implement sniffing functionality. The command 'ATMA' does not capture any data.
KWP Protocol
The
Keyword 2000 protocol (KWP) is defined in
ISO 14230.
ISO 14230 describes 2 ways to start the communication with the ECU: fast init and slow init.
With slow init the computer must wake up the ECU by sending a byte 0x33 with 5 baud. This is extremely slow.
With fast init the computer must send a byte 0xF0 with 200 baud.
The MT05 uses fast init.
This means that the K-Line goes low for exactly 25 ms and then high for 25 ms. After that the communication starts with 10400 baud.
The first command which is sent to the ECU is Start Communication which is the byte 0x81.
This byte is embedded into a packet which starts with a header and ends with a checksum.
Here you see the fast init, followed by the command 'Start Communication' and the response from the ECU.
This screenshot has been made with a ELM327 adapter which has a pull up resistor of 510 Ω from K-Line to +12V.
As you see the MT05 (Response) does not deliver enough current to pull the K-Line completely to ground. The lowest voltage is 1V.
 |
| Show Full Size |
There are long pauses between the bytes:
 |
| Show Full Size |
In detail the command 'Start Communication' (Service = 81) looks like this:
| Command (from PC): | 81 11 F1 81 04 |
| Response (from ECU): | 83 F1 11 C1 EF 8F C4 |
The MT05 uses the address 11. The application on the PC (the tester) uses the address F1.
The MT05 responds with 2 key bytes EF and 8F which define how the ECU wants the commands to be formatted.
They define how to transmit the packet length and if the source/target addresses are to be sent.
You see the meaning of the key bytes in the Trace pane in magenta when connecting.
| Command 'Start Communication' |
Response Short (1...63 data bytes) |
| Header 1 |
81 |
80 + length of data (1 byte) |
Header 1 |
83 |
80 + length of data (3 bytes) |
| Header 2 |
11 |
Destination address (ECU) |
Header 2 |
F1 |
Destination address (tester) |
| Header 3 |
F1 |
Source address (tester) |
Header 3 |
11 |
Source address (ECU) |
| Data 1 |
81 |
Service 'Start Communication' |
Data 1 |
C1 |
Service confirmation = 81 + 40 |
| Checksum |
04 |
81+11+F1+81 = 04 |
Data 2 |
EF |
Payload byte 1 (bit flags) |
|
Data 3 |
8F |
Payload byte 2 (always 0x8F) |
| Checksum |
C4 |
83+F1+11+C1+EF+8F = C4 |
The first header byte is called format byte. It may contain the length and defines if addresses are sent and the type of addresses.
A physical address (format byte contains 0x80) means that a specific ECU is addressed. There is only one response for each command.
A functional address (format byte contains 0xC0) is like a broadcast address. It means that a group of ECU's is addressed.
It can be used when the physical ECU address is unknown. But there may come multiple responses for one command.
To simplify reading the binary data HUD ECU Hacker displays the data bytes in parenthesis in the Trace pane:
81 11 F1 ( 81 ) 04
83 F1 11 ( C1 EF 8F ) C4
The other bytes are not really interesting as they are generated automatically.
If the ECU does not understand a command it sends 7F (failure) in the byte 'Data 1' of the response.
The following table shows a long response (102 data bytes) which contains an additional length byte (header 4).
| Command 'Read Data' |
Response Long (64...255 data bytes) |
| Header 1 |
82 |
80 + length of data (2 byte) |
Header 1 |
80 |
Extra length byte follows |
| Header 2 |
11 |
Destination address (ECU) |
Header 2 |
F1 |
Destination address (tester) |
| Header 3 |
F1 |
Source address (tester) |
Header 3 |
11 |
Source address (ECU) |
| Data 1 |
21 |
Service 'Read Data' |
Header 4 |
66 |
Length of data (102 byte) |
| Data 2 |
01 |
Subfunction 1 |
Data 1 |
61 |
Service confirmation = 21 + 40 |
| Checksum |
A6 |
82+11+F1+21+01 = A6 |
Data 2 |
01 |
Subfunction confirmation = 01 |
|
Data 3 |
... |
Payload byte 1 |
| Data 102 |
... |
Payload byte 100 |
| Checksum |
... |
80+F1+11+66+61+01+... |
Keep-Alive
If the ECU does not receive commands it switches to sleep mode after 5 seconds.
While HUD ECU Hacker is polling data this will never happen because polling takes place 3 to 5 times per second.
Only if you switch to manually enter commands (in the Trace pane), polling stops and HUD ECU Hacker sends a Keep-Alive every 3 seconds.
| Command (from PC): | 81 11 F1 3E C1 |
| Response (from ECU): | 81 F1 11 7E 01 |
PCHUD
The Delphi manuals for MT05 and for MT20 explain a software 'PCHUD'.
Previously this was the only software that could communicate with these ECU's.
PCHUD (Hands Up Display for PC) is a very old program from Delco Electronics written in 1993 for Windows 3.
 |
| Show Full Size |
Today it is practically impossible to find this software in internet.
I found lots of dead links and a fake PCHUD download on a chinese website which was a trojan.
But in the forum
China Riders I found a thread from the (ex)user
'katflap' talking about PCHUD.
Only thanks to 'katfalp' I could still in the year 2020 download and test this software.
This ancient 16 bit program does not run on 64 bit Windows because Microsoft has removed the support for 16 bit applications on 64 bit platforms.
Running it on a 32 bit Windows in the 16 bit emulator (NTVDM.exe) I notice that it permanently occupies 100% of one CPU core.
While PCHUD is displaying the data from the ECU it sends every 200 ms the same command (21 01) which the ECU responds with a data block of 100 bytes.
This 'parameter polling' looks like this:
 |
| Show Full Size |
It was a lot of work to analyze which meaning has each of the 100 bytes in the response
and to find the formulas which convert the raw values into temperature, voltage and pressure.
PCHUD is superseded by HUD ECU Hacker
The ancient PCHUD from Delco is obsolete because
- it does not run on 64 bit Windows
- it occupies permanently 100% of a CPU core
- it cannot be connected over an ELM327 or J2534 adapter (which did not exist in 1993)
- it cannot clear the DTC fault codes (the menu is permanently grayed out)
- it can only display 36 parameters at the same time
- it shows the gauge for negative values wrongly
- it is clumsy to use and uses undocumented PAR, HUD, SLW, LGC, LGG, SCR, CFG and PLY files
The new HUD ECU Hacker from ElmüSoft
- runs on Windows XP, 7, 8 and 10
- runs on 32 bit and 64 bit Windows
- uses the .NET framework 4.0 or higher and so should also run on Linux (not tested)
- connects to the ECU via K-Line/VAG or ELM327 or J2534 adapter
- shows the entire communication with the adapter in the Trace pane
- shows all 90 parameters at once in a user-configurable dashboard
- shows detailed tooltips for all parameters and their meaning
- can be configured 100% by the user by editing an XML parameter file in a text editor (e.g. Notepad++)
- the user can enter formulas to convert raw data into temperature, voltage or pressure
- shows fault codes (DTC) with a text explanation
- can clear fault codes
- can capture the data from the ECU in a logfile
- can export a logfile to a CSV file
- can ceate graphs from a logfile
- displays ECU data in a dashboard which is 100% configurable by the user
- automatically installs the Windows drivers for the USB to RS232 adapter / ELM 327 adapter
- allows you to manually enter commands and send them to the ECU for testing
- can sniff the data traffic on the bus (for example from a scan tool or from another OBD software)
- is optimized in each line of it's code to consume a minimum of CPU
- can be adapted for other ECU's which use different commands and parameters than the MT05 / MT20
- can be adapted to connect to vehiles with CAN bus or J1850 (only over ELM 327 adapter)
|
In contrast to all other OBD2 software HUD ECU Hacker is not commercial paid software.
This program is sharityware, which means that the author does not earn any money with it.
But if this program helped you saving money by not needing an expensive scan tool
you are asked to give a donation to a non-profit organization of your choice.
Like for example Shanti Bavan, a project which gives education for free to the poorest of the poor in India. There is an excellent documentary about this very special residential school on Netflix: Daugthers of Destiny |
|
 |
Apart from that HUD ECU Hacker has been designed to be community software.
Every user can adapt the program to his needs.
When you have adapted the XML parameter file for another vehicle, you are asked to send it to me for publishing it.
The time has come to create OBD software which has not to be paid and works without dongle.
I need the help from ECU experts, as I'am software developer (since decades), but I don't have much knowledge about ECU's.
The parameter XML file needs to be reviewed by an expert.
I'am not sure if all parameters are defined correctly.
And I simply copied the parameter descriptions form the user 'katflap', but I don't know if they are all correct.
HUD ECU Hacker - Control
This screenshot shows the playback of the logfile Regal Raptor - Error Clearing.xml
- I disconnected the plug of one oxygen sensor.
The plug has 4 pins: Two for the sensor and two for the heater. (See circuit diagram of MT05 above)
- After turning on the ignition key the ECU immediately alerted error P0037. I did not even start the motor.
HUD ECU Hacker translates the fault codes into human understandable messages.
If the error message is too long to fit you can hold the mouse over it and you see a tooltip.
- The error was first reported as Current.
- Then I turnd off the ignition, reconnected the oxygen sensor and turned on ignition again.
- Now the ECU detected that the error is not present anymore and reported it as Historic.
- Then I recorded the logfile
- At 00:00:10.200 I clicked the button Clear Fault Codes which removed the fault code.
Clearing Fault Codes
The button "Clear Fault Codes" sends a command which instructs the ECU to clear the fault code from the memory.
But this does not always result in removing the error message.
If the ECU detects that the error is still present it will not be cleared: You click the button and nothing happens.
If the ECU detects that the error is not present anymore it clears the current error alone after driving several minutes.
On the other hand the historic error stays until you reset the error with the button "Clear Fault Codes".
But the historic error does not affect the EFI / MIL indicator lamp.
HUD ECU Hacker - Data Grid
This screenshot shows the playback of the logfile Regal Raptor - Starting Motor.xml
At 00:00:16.831 I turned the throttle up to the maximum with the motor not running.
At 00:00:32.712 I started the motor. You see that the ignition voltage drops down to 9.2 Volt.
At 00:01:55.106 I turned the throttle again, now with the motor running.
At 00:02:25.260 I pressed the kill switch (red button). The ignition voltage goes down to 0 Volt.
While recording this logfile the motorbike was standing still (not driving).
For each parameter you see the raw value and it's meaning and the minimum and maximum values.
A gauge displays the value graphically. If the value can also be negative, the gauge starts in the middle.
The description in the last column is from 'katflap'.
Values that have changed since the previous sample have a yellow background. You can turn off this highlighting.
HUD ECU Hacker - Dashboard
 |
| Show Full Size |
This screenshot shows the playback of the logfile Regal Raptor - Driving.xml
At 00:00:35.878 I started the motor. The ignition voltage drops down to 7.7 Volt
At 00:00:39.488 the motor turned off alone because it ran too slow.
At 00:00:42.113 I started the motor again and drove around the block (not fast, ony first and second gear).
At 00:02:57.941 I pressed the kill switch.
On the screenshot above you see a tooltip which appears when you hold the mouse over a parameter.
Some parameters have a
wrench icon.
You can click on it and modify these values in the ECU. See
Data Slewing.
The dashboard can be configured 100% by the user after checking the checkbox Edit Mode below.
You can create, edit and delete groups and assign parameters to them.
You can move around the groups, change the order of parameters and drag and drop them to another group.
In this dialog you can configure a value parameter.
The ignition voltage has a minimum of 0 Volt and a maximum of 32 Volt.
You can restrict the range of the gauge to something more useful like 7 V to 16 V.
When you set an alarm the parameter will be displayed in red if the value exceeds the given limits.
HUD ECU Hacker - Graph
 |
| Show Full Size |
|
|
 |
| Show Full Size |
|
These images are graphs created from the logfile Regal Raptor - Driving.xml
You can chose the parameters that you want to include.
If you want more sophisticated graphics you can export the data to CSV and
load it into the
LiveLink Gen-II software (70 MB).
HUD ECU Hacker - Trace
 |
| Show Full Size |
In this screenshot you see the Trace pane which shows all the communication with the adapter.
Blue are the commands sent and green are the responses received.
The KWP packtes show the data bytes in parenthesis: Header ( Data ) Checksum.
With the checkbox Inject Commands at the bottom you can send your own commands to the ECU for testing.
For the purpose of hacking you can also enter XX, which will be replaced with all values from 00 to FF.
For example if you enter '21 XX' HUD ECU Hacker will send 256 commands from '21 00' to '21 FF' to the ECU.
Data Slewing
The MT05 allows to manually modify some of the parameter values which have been measured or calculated.
You can set absolute (fix) values or you can add a delta (± offset) to the current ECU values.
These changes have immediate effect on the running motor.
The purpose of data slewing is to analyze an engine which is not running correctly.
For example if the engine is off and you set Fuel Pump Duty Cycle to 15% you hear the fuel pump running.
 |
| Show Full Size |
This graph shows the logfile Regal Raptor - Data Slewing.xml where the engine was running idle with 1400 rpm.
At 00:00:29.806 I have set the value Idle RPM Target to 2500 rpm. The ECU slowly adapted the idle speed.
At 00:01:12.480 I switched off the slew value.
|
The modified values are not stored in the non-volatile memory of the ECU.
However this feature is for experts only. Wrong values can produce knocking or stall the motor.
I saw that the ECU does not go to sleep mode after changing some of the values.
Do not forget to click 'Reset all values' when you are finished with your tests.
|
ATTENTION:
Data Slewing does not work with my chinese ELM327 adapters. But J2534 and K-Line adapters do work.
The
ELM327 Datasheet says (page 31) that the ELM327 limits the bytes that can be sent to the maximum for OBD2.
Therefore HUD ECU Hacker sends the command ATAL which allows longer commands.
My chinese adapter answers ATAL with 'OK', but it still refuses to send more than 4 data bytes.
You will see a timeout error in HUD ECU Hacker.
ELM327 Terminal
As there are so many problems with chinese ELM327 clones I implemented the ELM327 Terminal.
Here you can test your adapter by sending commands and studying the responses.
The screenshot shows that my ELM327 clone sends commands only up to 4 data bytes.
If I send 5 data bytes or more (like the Slewing commands) there is no response, no error and no prompt.
I verified on the oscilloscope that the adapter indeed does not send anything.
The command ATAL is simply ignored although it was answered with 'OK'.
It is a fraud to sell this crap.
By the way: It is completely irrelevant if a chinese adapter claims to be version 1.5 or 2.1. They are all crap.
And I saw people complaining in internet about ELM327 adapters which have even less functionality than mine.
Recording on the Road
You can create logfiles after connecting to the ECU. You can easily record a log file while you are driving.
Connect the cables and put a notebook into a saddlebag.
 |
| Show Full Size |
Adapting HUD ECU Hacker to other ECU's
HUD ECU Hacker can be adapted to other ECU's by simply editing the parameter XML file.
First make a copy of the file
MT05 - Regal Raptor.xml, rename it and open it in
Notepad++.
If your car/motorbike/ATV does not connect via K-Line or uses another ECU address or another initialization, adapt the red attributes below.
| <Config>
<Address ECU="0x11" Tester="0xF1">
....
<Elm327 Protocol="5" BaudSlow="38400" BaudFast="38400">
....
<J2534 Protocol="4" ConnectFlags="0x00" BaudRate="10400" Init="Fast">
....
</Config> |
ECU addresses are normally in the range between 0x10 and 0x17 for engine controllers.
If you don't know the protocol or the ECU address, it is easy to find them if you have an ELM327 adapter.
The ELM327 allows to use protocol 0 for auto-detection. It will try all protocols until it gets a response from the ECU.
Open the Terminal and enter the following commands:
The command 'Start Communication' (81) may take a while. Wait until you get a response. If you get an error see
Trouble Shooting.
The command AT DP shows the name of the protocol and AT DPN shows the protocol number.
STEP 1:
Enter the ECU address and the protocol number into the parameter XML file.
You can convert decimal values to hexadecimal (and vice versa) with the Windows calculator after switching it to programmer mode.
You can enter decimal or hexadecinal values into the XML file as you like. Hexadecimal values must always start with 0x.
If you did it correctly you can now connect to your ECU with the button 'Connect'.
Don't forget to select your new XML file in the combobox 'Parameter File' at the top.
Check in the Trace pane that the command 81 (Start Communication) has executed without error.
STEP 2:
In the next step you have to test the commands which read the parameters:
- If your vehicle is OBD2 compliant you find the most commonly used parameters in Wikipedia.
- You can get them also by reverse engineering a scan tool or another OBD software using Sniff Mode.
After connecting to the ECU switch to the Trace pane and set the checkbox Inject Commands below.
Now you can send any command to the ECU and see the response.
Let's say you want to get the engine speed from an OBD2 compliant vehicle.
Wikipedia tells you that this is the Service 01 and the PID 0C.
In the field below in the Trace pane you type 01 0C and click the button "Send".
The ECU should answer with Header (3 byte) + Confirmation (2) + Engine RPM (2) + Checksum (1) = total 8 bytes.
So the last two bytes before the checksum are the raw engine speed.
The formula in Wikipedia says that the returned raw value (First byte * 256 + Second byte) must be divided by four.
STEP 3:
If this works successfully you can enter the new command into the XML file:
| <Command TxBytes="01 0C" RxPacketSize="2">
<RxParam Offset="0" ByteCount="2" ByteOrder="HL" Type="Unsigned"
Formula="$Val/4" Digits="0" Unit=" rpm"
UID="VRPM"
DispName="Engine Speed"
Description="The current speed of the engine">
</RxParam>
</Command> |
ATTENTION: Please read the description at the top of the file "MT05 - Regal Raptor.xml", which explains all attributes!
Installation
After downloading the ZIP file you unpack the content into a folder on your disk (or a USB stick).
The program will ask you once if you want to create a shortcut on the desktop and/or in the start menu.
It will then check if it has write permission in it's subfolders 'LogFiles' and 'Parameters'.
If not it will restart itself once with administrator privileges and set write permissions for 'Users'.
This happens only if you have copied the content of the ZIP file to 'Program Files'.
If you copy the ZIP file to 'My Documents' you have already write permissions.
In the toolbar at the top you can then install the drivers.
The toolbar also has a button that brings you with one click to the Device Manager, where you see all COM ports.
The toolbar has a tooltip for each button which appears when you hold the mouse over it.
 |
| Show Full Size |
Trouble Shooting
Errors when connecting to the ECU:
- The ignition key must be on.
- The kill switch must be in the position where it allows the motor to run.
- Switch to the neutral gear.
- It is not necessary to start the motor before establishing a connection.
- Check that you have connected the 3 wires correctly as shown in this diagram.
- The voltage of the K-Line wire MUST be +12 Volt while the adapter is connected to the ECU.
- If you use the K-Line or VAG adapter ecxecute the Echo Test to check the adapter.
- There are 2 types of timeout errors which indicate different errors:
- Timeout waiting for echo means always that you have a hardware problem or the wrong COM port.
- Timeout waiting for response (or received garbage characters) with ELM327 adapter may mean that the baudrate is wrong.
You can change the baudrate in the XML parameter file. Normally the ELM327 has a default baudrate of 38400 baud.
- Timeout waiting for response with K-Line / VAG adapter may happen rarely.
The reason is that the ISO 14230 protocol is very time critical. It demands 50 ±1 ms for the fast init.
But Windows as a multitasking OS is not very precise and the interval seen on an oscilloscope may vary from 45 ms up to 70 ms.
If the interval between fast init and the command 'Start Communication' exceeds the limits the ECU does not respond.
In this case you get a timeout error. Simply click 'Connect' again until it works.
If you get the timeout error repeatedly you can enter a K-Line timing correction which is added to the 50 ms interval.
ATTENTION: If you enter a wrong value here you may screw up the fast initialization.
If changing this value did not solve your problem, reset the correction to zero otherwise you may never be able to connect.
- BUSINIT: ERROR from the ELM327 adapter means that the ELM327 did not receive a response from the ECU.
The chinese clones of the ELM327 send the Fast Init and then their own 'Start Communication' command C1 33 F1 81 66.
They always use the hard coded functional ECU address 0x33 for the very first command.
For the Delphi MT05 this is no problem. It answers this request although it has the physical address 0x11.
But 0x33 may be an invalid address for other ECU's. The chinese ELM327 clones do not allow to change the ECU address.
If you have an ECU which does not answer at all use a K-Line or J2534 adapter instead and adapt the ECU address in the XML file.
If you have any problem you can send me a screenshot of the Trace pane with the error message.
But first read this help!
You find my email at the end of the help file.
