Firmware Update and Emulator for OBD2-Analyser NG / Wireless OBD2
Firmware update for OBD2-Analyser NG. OBD2 software for OBD2-Analyser NG with Bluetooth module running on PC and Raspberry Pi with Bluetooth adapter.
This project improves the firmware of the OBD2-Analyser NG project published in the September 2009 issue of the Elektor magazine. If your OBD2-Analyser NG is equipped with the optional Bluetooth module published in the April 2010 issue of the Elektor magazine, you even do not need to flash the new firmware to try it out! Just use the OBD2-Analyser NG test software that has the new firmware built-in as OBD2 software. In that case you can view more data items or menu items at once, since the test software's display height is 64 simulated pixels (instead of the 32 pixels of the original LCD). The OBD2 software might work with other DXM based OBD2 testers, like the Wireless OBD2 project published in the April 2011 issue of the Elektor magazine, too.
Additionally, the test software can be used as OBD2-Analyser NG emulator. By using the emulator you can enter all menus and view all OBD2 services and all OBD2 data items that the OBD2-Analyser NG firmware has implemented. That is much more than you would see in a real vehicle.
Furthermore, the test software contains a DXM-simulator that provides changeable OBD2 data for the emulator or third party OBD2 software.
Currently, the software runs on PC and Raspberry Pi. To use the OBD2 software with your OBD2-Analyser NG, you need a PC or Raspberry Pi with Bluetooth adapter.
1. Firmware
Compared to the original firmware v1.2.1 the following main features have been implemented:
Check the updates for details and more features.
2. HHEmu - The OBD2-Analyser NG Test Software
HHEmu stands for Handheld Open Emulator, since the primary objective was to develop a PC test environment (emulator, sandbox) for the firmware. However, the software supports different operation modes providing much more than a mere emulator. It can be used as emulator containing a built-in DXM-simulator as OBD2 data source. It can be used as stand-alone DXM-simulator. It can be used as OBD2 software using the GUI of the firmware. And finally, two HHEmus, one runnning as DXM-simulator and one running as OBD2 software, can be connected via a (virtual) serial connection.
HHEmu is a multi-threaded application with 5-7 threads. It executes the firmware in a separate thread and simulates all inputs (key presses, timer interrupt, data from DXM module, data from optional Bluetooth module) and outputs (LCD, data to DXM module, data to optional Bluetooth module) to make the firmware believe it would run on the AT90CAN128.
Since HHEmu version 2.50 you can view more data items or menu items than in a real OBD2-Analyser NG. Now, HHEmu's display height is 64 simulated pixels (instead of the 32 pixels of the original LCD). That allows to display 8 menu lines at once.
The HHEmu program contains DXM OpenHandheld source code v1.2.1, (c) 2009 DIAMEX, written by Erwin Reuss, ER-Tronik. DIAMEX restricts the usage of the source code to non-commercial use. Therefore, HHEmu is subject to the same restrictions.
2.1 OBD2-Analyser NG Emulator
HHEmu in emulator mode enables you to enter all menus and to test all OBD2 features of the OBD2-Analyser NG with the latest firmware update on a PC or Raspberry Pi. That is much more than you would see in a real vehicle that just supports a subset of all OBD2 features. HHEmu comes with a built-in DXM-simulator that provides changeable OBD2 data for the emulator. See the command summary in chapter 2.5.4 for a list of commands accepted by the DXM-simulator.
2.2 OBD2 Software
In OBD2 software mode HHEmu connects either to a real OBD2-Analyser NG equipped with the Bluetooth module (normal user mode) or to a second HHEmu running in DXM-simulator mode (developer mode (a virtual serial port software like com0com can be used for that)).
So, that mode provides an interesting feature for users who have an OBD2-Analyser NG with the optional Bluetooth module: new firmware can be tested in the car with no need for flashing the firmware! Run HHEmu with the built-in new firmware and via Bluetooth connect to a real OBD2-Analyser NG with at least firmware v1.2.1. Then you see on the PC, how the new firmware would run on the OBD2-Analyser NG.
The OBD2 software might work with other DXM based OBD2 testers, too. That depends on the availability of some DXM commands that are undocumented in the official DXM documentation, but are used by the latest official firmware v1.2.1 and therefore, are used by the latest firmware update, too.
2.3 DXM-Simulator
The DXM-simulator can be used to develop your own OBD2 software.
Warning
Do not run HHEmu in DXM-simulator mode unattended if you run it on an overclocked PC or notebook!
If the Bluetooth Menu is entered in the DXM-simulator mode, HHEmu enters a busy-wait-loop. That is running at full speed on a PC consuming all CPU cycles of a single core, so the CPU will become hot.
In the DXM-simulator mode HHEmu connects either to a second HHEmu running in OBD2 software mode or a third party OBD PC software (a virtual serial port software like com0com can be used for that).
tested with:
See the command summary in chapter 2.5.4 for a list of commands accepted by the DXM-simulator.
2.4 HHEmu Installation
Unpack the hhemu_usr_xxx.zip archive of the latest project update to whatever path you want.
2.4.1 HHEmu Installation on PC
Unpack the gtk_xxx_runtime_libs.zip archive(s) of the latest project update to \hhemu_usr\gtk or install mingw32 GTK3+ V3.6.4 or higher.
2.4.2 HHEmu Installation on Raspberry Pi
Install GTK3+.
That is enough for the emulator mode.
The Raspberry Pi OBD2 software mode additionally needs the following steps. Of which some steps can be omitted if a Raspberry Pi 3 with built-in Bluetooth is used. I have tested HHEmu on a Raspberry Pi 2.
Plug in a Bluetooth/USB adapter.
Install Bluetooth.
Set the Bluetooth adapter to always visible.
Pair the adapter with the Bluetooth module of the OBD2-Analyser NG and trust it.
Configure a free rfcomm device like /dev/rfcomm0.
Bind the address of the OBD2-Analyser NG's Bluetooth module to the rfcomm device.
2.5 Usage
Change to the path where you have installed hhemu.exe (e.g. D:\hhemu_usr\gtk) and in the console type:
hhemu --help
HHEmu can be controlled via the mouse by clicking the OBD2-Analyser NG buttons if the background picture HHOpenBackgroundPic.png that shows the 4 OBD2-Analyser NG buttons is found on program startup. Additionally, HHEmu can be controlled via the cursor keys or the h,j,k,l-keys that are mapped to the Up/Down/Ok/ESC-buttons. See the command summary in chapter 2.5.4 for a list of additional keys and their meaning.
2.5.1 Emulator Usage
Change to the path where you have installed hhemu.exe (e.g. D:\hhemu_usr\gtk) and in the console type:
hhemu
Or double click hhemu.exe.
2.5.2 OBD2 Software Usage
Change to the path where you have installed hhemu.exe (e.g. D:\hhemu_usr\gtk) and in the console type:
PC: hhemu COMx
x is the number of the COM-port used by the Bluetooth adapter on your PC to communicate with the OBD2-Analyser NG. In the current implementation x must be less than 10.
Pi: ./hhemu /dev/rfcommx
x is the number you configured for the rfcomm device.
2.5.3 DXM-Simulator Usage
Change to the path where you have installed hhemu.exe (e.g. D:\hhemu_usr\gtk) and in the console type:
hhemu COMx sim
Replace x with the actual (virtual) serial port of your installation. However, port number must be less than 10.
Then enter the Bluetooth menu.
The DXM-simulator is ready now to accept AT commands or OBD requests from a HHEmu running in OBD2 software mode, third party OBD2 software or a terminal program.
2.5.4 HHEmu Command Summary
In OBD2-Analyser NG emulator mode or DXM-simulator mode keys 0-9 can be used to store an up to 2-digit number in the number memory. The number from the number memory will be used for subsequent commands that need a number as parameter.
Possible commands are:
a - set number of permanent DTCs (CAN-protocols only) for the active ECU, 0-16
b - set number of cylinder banks for PID 0x13, 1-2 (***)
c - set number of cylinder banks for PID 0x1D, 1-4 (***)
d - set number of confirmed DTCs for the active ECU, 0-16
e - set number of responding ECUs, 1-8
m - enable MIL in DXM simulation (also sets one confirmed DTC for the active ECU, if none is active, yet)
n - toggle visibility of number memory
p - set number of pending DTCs for the active ECU, 0-16
t - set responding protocol in DXM-simulator or emulator: PWM (1), VPWM (2), ISO 9141-2 (3), KWP2000 5 Baud Init (4), KWP2000 Fast Init (5), CAN 11/500 (6), CAN 29/500 (7), CAN 11/250 (8) and CAN 29/250 (9)
u - set diagnostic interface controller: DXM (0), ELM (1) or STN (2)
v - toggle between fixed current data and IPT data (default) or variable current data and IPT data
x - set negative response code for SID 0x04 (clear DTCs) or SID 0x09, InfoType 0x06 (CVN) either for the active ECU or, if no ECU filter in the current menu is active, for all ECUs.
Possible codes are 10, 11, 12, 21, 22, 78 (value is interpreted as hex). Same code given twice toggles negative response code on/off. If 00 is given, negative response codes are switched off.
y - set No DATA response for next response from DXM
z - set CAN ERROR response for next response from DXM (CAN-protocols only)
q - quit HHEmu
(***) - The standard ISO 15031-5 requires that all ECUs in a vehicle that support the location of oxygen sensors support either PID 0x13 or PID 0x1D, but not both. If you select setting the number of cylinder banks for PID 0x13, the supported PID 0x1D will be cleared automatically for you for all ECUs and vice versa.
Note that for some of the commands to take effect, the Reload OBD2 Data menu item must be executed in the emulator. Further note that some commands only affect the currently active ECU. So, they might have to be entered several times with a change of ECU in between.
2.6 Supported HHEmu Versions
cygwin ncurses
cygwin/X11 ncurses
cygwin/X11 GTK3+ (tested with GTK+ V3.6.4)
mingw32 PDcurses
mingw32 GTK3+ (tested with GTK+ V3.6.1 and V3.6.4)
Raspbian ncurses
Raspbian GTK3+ (tested with GTK+ V3.14.5)
2.7 Released HHEmu Versions
mingw32 GTK3+
Raspbian GTK3+
Other versions are available on request.
Notes:
GTK3+ for Windows is now available with MSYS2. Since that does no longer support XP and Vista and I do not want to drop support of XP, yet, I will not do an update of GTK3+ soon. However, since I also release the object files and the makefile with every release, you should be able to link the object files with newer GTK3+ libraries for yourself.
Using GTK3+ V3.7.x or higher brings support for Broadway. Broadway enables a GTK+ application, like HHEmu, to be run in the Firefox browser. Since the browser can be run on a different machine than the application, you can remotely control the OBD2 Analyser NG via the internet, then. So, a remote mechanic could take a look on live-data of your car. I have tried that with the experimental GTK+3.8.2 package from here http://www.tarnyko.net/en/?q=node/34 and it worked fine.
3. Description of (old) Files in the Attachments Section
Check the latest project update to download the latest version of the firmware and the latest version of HHEmu. The project main page just contains the old files for HHEmu V2.10 and firmware V1.3.0 (containing also the mingw PDcurses version). I keep them here as long as I do not make a new release with full source code.
HandheldOpen_130.zip contains the firmware update v1.3.0 including the new hex file needed for flashing the AT90CAN128. Directory structure and files are almost identical to the old firmware release v1.2.1. File ChangeLog.txt contains a list of changes (despite the filename German only).
The firmware update to version 1.3.0 contains one new feature, several bug fixes and a few changes mainly needed for the emulator. The new feature is support for OBD2 service 0x07 ("Pending Diagnostic Trouble Codes"). Pending trouble codes are failures detected in the current or last completed driving cycle that have not been confirmed in a second driving cycle, yet. Therefore, OBD2 service 0x03 ("Confirmed Diagnostic Trouble Codes") would still be showing an error free car. Service 0x07 helps you to see coming problems earlier. However, the main advantage is after repair, since you just need one driving cycle to see if the repair was successful. The base for the firmware update is the original version 1.2.1. That is the one with Bluetooth support, but you do not need to have the Bluetooth extension installed to use it in your OBD2-Analyser NG.
hhemu_usr.zip contains the HHEmu mingw32/PDcurses executable and the mingw32/GTK3+ executable. Both need additional shared libraries to run. File HHEmu_.txt contains a list of these libraries and the links where to download them (later updates have the runtime libs included in separate archive(s)).
hhemu_dev.zip contains the HHEmu source code with documentation in the code (English only).
hhemu_doc_preview.zip contains a preview of the full HHemu/OBD2-Analyser NG documentation covering installation aspects, emulator usage and emulator internals (German only). Most notably, it contains 2 block diagrammes showing the interaction between the different threads in the GTK+ and curses versions of HHEmu. Furthermore, the preview contains a description of all OBD2-Analyser NG menus/displays that have been changed due to the new feature OBD2 service 0x07 (Pending Diagnostic Trouble Codes).
Warning for HHEmu prior V2.32
Do not run HHEmu unattended if you run it on an overclocked PC or notebook! The emulation is an application that steals many CPU cycles, so the CPU will become hot. The main reason for that is the main-loop of the firmware that is a busy-wait-loop running at full speed on a PC consuming all CPU cycles of a single core. The hhemu_usr.zip archive contains a curses/patched folder and a gtk/patched folder with special versions of HHEmu. In these versions a short pause has been inserted into the busy-wait-loop of the firmware that reduces the strain inflicted on the CPU core significantly.
Warning for HHEmu V2.32 and beyond
See description under chapter 2.3 DXM-Simulator above.
Additionally, the test software can be used as OBD2-Analyser NG emulator. By using the emulator you can enter all menus and view all OBD2 services and all OBD2 data items that the OBD2-Analyser NG firmware has implemented. That is much more than you would see in a real vehicle.
Furthermore, the test software contains a DXM-simulator that provides changeable OBD2 data for the emulator or third party OBD2 software.
Currently, the software runs on PC and Raspberry Pi. To use the OBD2 software with your OBD2-Analyser NG, you need a PC or Raspberry Pi with Bluetooth adapter.
1. Firmware
Compared to the original firmware v1.2.1 the following main features have been implemented:
- support for 8 OBD2 capable ECUs
- pending DTCs, OBD2 service 0x07
- permanent DTCs, OBD2 service 0x0A
- support for numerous additional PIDs of OBD2 services 0x01 and 0x02 (these are displayed in current data menu and freeze frame data menu, if a vehicle supports them)
- evaluation and display of location of oxygen sensors, OBD2 service 0x01 and 0x02, PID 0x13 or 0x1D (this affects displayed bank/oxygen sensor indices of some PIDs)
- evaluation of tester configuration bytes, OBD2 service 0x01 and 0x02, PID 0x4F and PID 0x50 (this affects displayed maximum values and resolution of some PIDs)
- Inspection/Maintenance Readiness Code / OBD2 monitor status since DTCs cleared, OBD2 service 0x01, PID 0x01
- OBD2 monitor status of the current driving cycle, OBD2 service 0x01, PID 0x41
- ECU name, OBD2 service 0x09, infotype 0x0A
- in-use performance tracking counters for spark ignition engines and compression ignition engines prior MY2010, OBD2 service 0x09, infotype 0x08
- in-use performance tracking counters for compression ignition engines for MY2010 and beyond, OBD2 service 0x09, infotype 0x0B
- dynamic supported PIDs for OBD2 service 0x02 (each DTC that caused freeze frame storage can have its own supported PIDs)
- CAN error retry handling (I highly recommend updating if you have troubles with vehicles that use CAN busses. Frequent or even permanent 'no data' messages will no longer occur.)
Check the updates for details and more features.
2. HHEmu - The OBD2-Analyser NG Test Software
HHEmu stands for Handheld Open Emulator, since the primary objective was to develop a PC test environment (emulator, sandbox) for the firmware. However, the software supports different operation modes providing much more than a mere emulator. It can be used as emulator containing a built-in DXM-simulator as OBD2 data source. It can be used as stand-alone DXM-simulator. It can be used as OBD2 software using the GUI of the firmware. And finally, two HHEmus, one runnning as DXM-simulator and one running as OBD2 software, can be connected via a (virtual) serial connection.
HHEmu is a multi-threaded application with 5-7 threads. It executes the firmware in a separate thread and simulates all inputs (key presses, timer interrupt, data from DXM module, data from optional Bluetooth module) and outputs (LCD, data to DXM module, data to optional Bluetooth module) to make the firmware believe it would run on the AT90CAN128.
Since HHEmu version 2.50 you can view more data items or menu items than in a real OBD2-Analyser NG. Now, HHEmu's display height is 64 simulated pixels (instead of the 32 pixels of the original LCD). That allows to display 8 menu lines at once.
The HHEmu program contains DXM OpenHandheld source code v1.2.1, (c) 2009 DIAMEX, written by Erwin Reuss, ER-Tronik. DIAMEX restricts the usage of the source code to non-commercial use. Therefore, HHEmu is subject to the same restrictions.
2.1 OBD2-Analyser NG Emulator
HHEmu in emulator mode enables you to enter all menus and to test all OBD2 features of the OBD2-Analyser NG with the latest firmware update on a PC or Raspberry Pi. That is much more than you would see in a real vehicle that just supports a subset of all OBD2 features. HHEmu comes with a built-in DXM-simulator that provides changeable OBD2 data for the emulator. See the command summary in chapter 2.5.4 for a list of commands accepted by the DXM-simulator.
2.2 OBD2 Software
In OBD2 software mode HHEmu connects either to a real OBD2-Analyser NG equipped with the Bluetooth module (normal user mode) or to a second HHEmu running in DXM-simulator mode (developer mode (a virtual serial port software like com0com can be used for that)).
So, that mode provides an interesting feature for users who have an OBD2-Analyser NG with the optional Bluetooth module: new firmware can be tested in the car with no need for flashing the firmware! Run HHEmu with the built-in new firmware and via Bluetooth connect to a real OBD2-Analyser NG with at least firmware v1.2.1. Then you see on the PC, how the new firmware would run on the OBD2-Analyser NG.
The OBD2 software might work with other DXM based OBD2 testers, too. That depends on the availability of some DXM commands that are undocumented in the official DXM documentation, but are used by the latest official firmware v1.2.1 and therefore, are used by the latest firmware update, too.
2.3 DXM-Simulator
The DXM-simulator can be used to develop your own OBD2 software.
Warning
Do not run HHEmu in DXM-simulator mode unattended if you run it on an overclocked PC or notebook!
If the Bluetooth Menu is entered in the DXM-simulator mode, HHEmu enters a busy-wait-loop. That is running at full speed on a PC consuming all CPU cycles of a single core, so the CPU will become hot.
In the DXM-simulator mode HHEmu connects either to a second HHEmu running in OBD2 software mode or a third party OBD PC software (a virtual serial port software like com0com can be used for that).
tested with:
- moDiag 2.8.601 (DXM)
- moDiagUltimate 4.0.1.0 (DXM)
- CarPort 2.2.15 (DXM)
- ScanTool.net v1.2.1 (ELM/STN, 1 ECU only, non-CAN protocols only) Since PWM is the default responding protocol, nothing needs to be configured for the responding protocol, but one ECU and responding controller ELM or STN must be set. To do that, type "1e1u" or "1e2u" while the HHEmu window is active.
See the command summary in chapter 2.5.4 for a list of commands accepted by the DXM-simulator.
2.4 HHEmu Installation
Unpack the hhemu_usr_xxx.zip archive of the latest project update to whatever path you want.
2.4.1 HHEmu Installation on PC
Unpack the gtk_xxx_runtime_libs.zip archive(s) of the latest project update to \hhemu_usr\gtk or install mingw32 GTK3+ V3.6.4 or higher.
2.4.2 HHEmu Installation on Raspberry Pi
Install GTK3+.
That is enough for the emulator mode.
The Raspberry Pi OBD2 software mode additionally needs the following steps. Of which some steps can be omitted if a Raspberry Pi 3 with built-in Bluetooth is used. I have tested HHEmu on a Raspberry Pi 2.
Plug in a Bluetooth/USB adapter.
Install Bluetooth.
Set the Bluetooth adapter to always visible.
Pair the adapter with the Bluetooth module of the OBD2-Analyser NG and trust it.
Configure a free rfcomm device like /dev/rfcomm0.
Bind the address of the OBD2-Analyser NG's Bluetooth module to the rfcomm device.
2.5 Usage
Change to the path where you have installed hhemu.exe (e.g. D:\hhemu_usr\gtk) and in the console type:
hhemu --help
HHEmu can be controlled via the mouse by clicking the OBD2-Analyser NG buttons if the background picture HHOpenBackgroundPic.png that shows the 4 OBD2-Analyser NG buttons is found on program startup. Additionally, HHEmu can be controlled via the cursor keys or the h,j,k,l-keys that are mapped to the Up/Down/Ok/ESC-buttons. See the command summary in chapter 2.5.4 for a list of additional keys and their meaning.
2.5.1 Emulator Usage
Change to the path where you have installed hhemu.exe (e.g. D:\hhemu_usr\gtk) and in the console type:
hhemu
Or double click hhemu.exe.
2.5.2 OBD2 Software Usage
Change to the path where you have installed hhemu.exe (e.g. D:\hhemu_usr\gtk) and in the console type:
PC: hhemu COMx
x is the number of the COM-port used by the Bluetooth adapter on your PC to communicate with the OBD2-Analyser NG. In the current implementation x must be less than 10.
Pi: ./hhemu /dev/rfcommx
x is the number you configured for the rfcomm device.
2.5.3 DXM-Simulator Usage
Change to the path where you have installed hhemu.exe (e.g. D:\hhemu_usr\gtk) and in the console type:
hhemu COMx sim
Replace x with the actual (virtual) serial port of your installation. However, port number must be less than 10.
Then enter the Bluetooth menu.
The DXM-simulator is ready now to accept AT commands or OBD requests from a HHEmu running in OBD2 software mode, third party OBD2 software or a terminal program.
2.5.4 HHEmu Command Summary
In OBD2-Analyser NG emulator mode or DXM-simulator mode keys 0-9 can be used to store an up to 2-digit number in the number memory. The number from the number memory will be used for subsequent commands that need a number as parameter.
Possible commands are:
a - set number of permanent DTCs (CAN-protocols only) for the active ECU, 0-16
b - set number of cylinder banks for PID 0x13, 1-2 (***)
c - set number of cylinder banks for PID 0x1D, 1-4 (***)
d - set number of confirmed DTCs for the active ECU, 0-16
e - set number of responding ECUs, 1-8
m - enable MIL in DXM simulation (also sets one confirmed DTC for the active ECU, if none is active, yet)
n - toggle visibility of number memory
p - set number of pending DTCs for the active ECU, 0-16
t - set responding protocol in DXM-simulator or emulator: PWM (1), VPWM (2), ISO 9141-2 (3), KWP2000 5 Baud Init (4), KWP2000 Fast Init (5), CAN 11/500 (6), CAN 29/500 (7), CAN 11/250 (8) and CAN 29/250 (9)
u - set diagnostic interface controller: DXM (0), ELM (1) or STN (2)
v - toggle between fixed current data and IPT data (default) or variable current data and IPT data
x - set negative response code for SID 0x04 (clear DTCs) or SID 0x09, InfoType 0x06 (CVN) either for the active ECU or, if no ECU filter in the current menu is active, for all ECUs.
Possible codes are 10, 11, 12, 21, 22, 78 (value is interpreted as hex). Same code given twice toggles negative response code on/off. If 00 is given, negative response codes are switched off.
y - set No DATA response for next response from DXM
z - set CAN ERROR response for next response from DXM (CAN-protocols only)
q - quit HHEmu
(***) - The standard ISO 15031-5 requires that all ECUs in a vehicle that support the location of oxygen sensors support either PID 0x13 or PID 0x1D, but not both. If you select setting the number of cylinder banks for PID 0x13, the supported PID 0x1D will be cleared automatically for you for all ECUs and vice versa.
Note that for some of the commands to take effect, the Reload OBD2 Data menu item must be executed in the emulator. Further note that some commands only affect the currently active ECU. So, they might have to be entered several times with a change of ECU in between.
2.6 Supported HHEmu Versions
cygwin ncurses
cygwin/X11 ncurses
cygwin/X11 GTK3+ (tested with GTK+ V3.6.4)
mingw32 PDcurses
mingw32 GTK3+ (tested with GTK+ V3.6.1 and V3.6.4)
Raspbian ncurses
Raspbian GTK3+ (tested with GTK+ V3.14.5)
2.7 Released HHEmu Versions
mingw32 GTK3+
Raspbian GTK3+
Other versions are available on request.
Notes:
GTK3+ for Windows is now available with MSYS2. Since that does no longer support XP and Vista and I do not want to drop support of XP, yet, I will not do an update of GTK3+ soon. However, since I also release the object files and the makefile with every release, you should be able to link the object files with newer GTK3+ libraries for yourself.
Using GTK3+ V3.7.x or higher brings support for Broadway. Broadway enables a GTK+ application, like HHEmu, to be run in the Firefox browser. Since the browser can be run on a different machine than the application, you can remotely control the OBD2 Analyser NG via the internet, then. So, a remote mechanic could take a look on live-data of your car. I have tried that with the experimental GTK+3.8.2 package from here http://www.tarnyko.net/en/?q=node/34 and it worked fine.
3. Description of (old) Files in the Attachments Section
Check the latest project update to download the latest version of the firmware and the latest version of HHEmu. The project main page just contains the old files for HHEmu V2.10 and firmware V1.3.0 (containing also the mingw PDcurses version). I keep them here as long as I do not make a new release with full source code.
HandheldOpen_130.zip contains the firmware update v1.3.0 including the new hex file needed for flashing the AT90CAN128. Directory structure and files are almost identical to the old firmware release v1.2.1. File ChangeLog.txt contains a list of changes (despite the filename German only).
The firmware update to version 1.3.0 contains one new feature, several bug fixes and a few changes mainly needed for the emulator. The new feature is support for OBD2 service 0x07 ("Pending Diagnostic Trouble Codes"). Pending trouble codes are failures detected in the current or last completed driving cycle that have not been confirmed in a second driving cycle, yet. Therefore, OBD2 service 0x03 ("Confirmed Diagnostic Trouble Codes") would still be showing an error free car. Service 0x07 helps you to see coming problems earlier. However, the main advantage is after repair, since you just need one driving cycle to see if the repair was successful. The base for the firmware update is the original version 1.2.1. That is the one with Bluetooth support, but you do not need to have the Bluetooth extension installed to use it in your OBD2-Analyser NG.
hhemu_usr.zip contains the HHEmu mingw32/PDcurses executable and the mingw32/GTK3+ executable. Both need additional shared libraries to run. File HHEmu_.txt contains a list of these libraries and the links where to download them (later updates have the runtime libs included in separate archive(s)).
hhemu_dev.zip contains the HHEmu source code with documentation in the code (English only).
hhemu_doc_preview.zip contains a preview of the full HHemu/OBD2-Analyser NG documentation covering installation aspects, emulator usage and emulator internals (German only). Most notably, it contains 2 block diagrammes showing the interaction between the different threads in the GTK+ and curses versions of HHEmu. Furthermore, the preview contains a description of all OBD2-Analyser NG menus/displays that have been changed due to the new feature OBD2 service 0x07 (Pending Diagnostic Trouble Codes).
Warning for HHEmu prior V2.32
Do not run HHEmu unattended if you run it on an overclocked PC or notebook! The emulation is an application that steals many CPU cycles, so the CPU will become hot. The main reason for that is the main-loop of the firmware that is a busy-wait-loop running at full speed on a PC consuming all CPU cycles of a single core. The hhemu_usr.zip archive contains a curses/patched folder and a gtk/patched folder with special versions of HHEmu. In these versions a short pause has been inserted into the busy-wait-loop of the firmware that reduces the strain inflicted on the CPU core significantly.
Warning for HHEmu V2.32 and beyond
See description under chapter 2.3 DXM-Simulator above.
Updates from the author
Thomas Beck 3 years ago
Highlights:
Added support for another 19 PIDs and 3 InfoTypes with more than 100 additional OBD2 data items (sensor data, counters, ...).
Imported 9341 diagnostic trouble codes (DTCs) and text descriptions of SAE J2012-DA:2018.
This is a major update. Finally, the OBD2-Analyser NG firmware supports all PIDs (excluding World-Wide Harmonized OBD PIDs (WWH-OBD), heavy duty vehicle OBD PIDs (HD OBD) and PIDs for MY2022 and beyond) defined in the SAE J1979-DA:2019 standard and all 9341 ISO/SAE defined 2-byte DTCs specified in the SAE J2012-DA:2018 standard. I managed to squeeze 478 kB of DTC texts plus the rest of all other data and code into the 128 kB of the AT90CAN128. One array of generated compressed text data exceeded the maximum of 32767 bytes which is possible for avr-gcc. This array had to be split into two arrays. Both of them were put into two Flash sections at the end of the Flash beyond the 64 kB border. According to the map file, the gap between end of program data and start of these sections is around 13 kB. So, there is not much Flash space left to further improve the firmware. Of course, I will continue updating HHGui. The successor standard of classic OBD2 has been released as SAE J1979-2 (OBDonUDS) a few weeks ago. This came along with a new release of SAE J1979-DA, April 2021. With new vehicles supporting only OBDonUDS in the near future, I plan to support OBDonUDS in HHGui, too. This might require new hardware as well.
Since the list of supported PIDs and InfoTypes on the main project page is outdated, here is the current state:
Supported PIDs (OBD2 Service 1 and 2):
0x00 - 0x8F, 0x98 - 0xA9, 0xC0, 0xE0
Supported InfoTypes (OBD2 Service 0x09):
0x00, 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0B, 0x16 - 0x1C, 0x20, 0x40, 0x60, 0x80, 0xA0, 0xC0, 0xE0
If you do not have access to the latest SAE J1979-DA standard, check https://en.wikipedia.org/wiki/OBD-II_PIDs to see the meaning of most of the PIDs and InfoTypes listed above.
Changes:
- added new PIDs
0x72 Wastegate Control, wastegate A,B (commanded/actual)
0x73 Exhaust Pressure, bank 1-2, sensor 1
0x74 Turbocharger RPM, turbocharger A,B
0x75 Turbocharger A Temperature (compressor/turbine inlet/outlet temperature)
0x76 Turbocharger B Temperature
0x7D NOx NTE Control Area Status (HD OBD PID)
NTE = Not-to-exceed,
See Wikipedia https://en.wikipedia.org/wiki/Not-To-Exceed for a description of control areas and carve-out areas.
0x7E PM NTE Control Area Status (HD OBD PID)
0x81 Engine Run Time for AECD 1-5, 1-2 timers per EI-AECD
EI-AECD = emission increasing Auxiliary Emission Control Device
Although the timers count seconds, the firmware only displays full hours. No rounding takes place, 3599 secs are displayed as 0 hrs.
0x82 Engine Run Time for AECD 6-10
0x86 Particulate Matter Sensor (mass concentration bank 1-2, sensor 1)
0x89 Engine Run Time for AECD 11-15
0x8A Engine Run Time for AECD 16-20
0x9A Hybrid/EV Vehicle System Data
Charging state: charge sustaining mode, charge depleting mode, charge increasing mode, battery voltage, battery current.
0x9C O2 Sensor (Wide Range) for Diesel bank 1-2, sensors 3-4
0x9F Fuel System A,B Percentage Use, bank 1-4
0xA3 EVAP System Vapor Pressure A,B
Standard range sensors are displayed as xxxx.xx kPa, wide range sensors are displayed as xxxxx kPa.
0xA7 NOx Sensor bank 1-2, sensor 3-4
0xA8 NOx Sensor Corrected bank 1-2, sensor 3-4
0xA9 Motorcycle Input/Output Status (ABS disable switch status)
The mapping of device/sensor number to an actual device/sensor is manufacturer specific.
- changed display format for EVAP PID 0x32 xxxx.x Pa to xxxx.xx Pa to comply with recent versions of the SAE J1979-DA specification
- added new InfoTypes
0x1A Plug-in Hybrid Vehicle Distance Data
Total distance traveled in charge depleting mode with engine off/running or charge increasing mode.
0x1B Plug-in Hybrid Vehicle Fuel Data
Total fuel consumed in charge depleting mode or charge increasing mode.
0x1C Plug-in Hybrid Vehicle Grid Data
Total grid energy consumed in charge depleting mode with engine off/running, total grid energy into the battery.
All vehicle tracking data items are displayed with two values, a recent value and a lifetime value. Recent values are accumulated over the last 50 hours before Vehicle Operation Data InfoType 0x19 Total Propulsion System Active Time Recent reaches 50 hours and resets to zero. If OBD2 service 0x04 (erase DTCs) is executed, the recent values are cleared as well.
- replaced 4277 DTCs and text descriptions of SAE J2012-DA, revision December 2007, with the 9341 DTCs and text descriptions of the most recent December 2018 revision.
- further improved text compression
The two dictionary compression methods which have been used for the PID descriptions and DTC texts have been merged so that only one decompressor function is required. Furthermore, the entropy encoding previously used for the DTC texts has been improved so that more words in the dictionary could be encoded with shorter indices.
The texts for InfoTypes and readiness monitors have been compressed as well.
For the firmware, the result is that 9869 texts which in uncompressed form would need 506099 bytes in Flash could be compressed to 69691 bytes.
For HHGui, the result is that 9869 texts which in uncompressed form would need 511401 bytes could be compressed to 68832 bytes.
The texts of HHGui and firmware differ, due to LC display size constraints for the firmware.
Due to the increased number of texts, the linear search method previously used to find the start of a compressed text was replaced by a combination of interpolation search and linear search. The result is that the start of all texts can be found in less or equal than 5 steps. The linear search method would have needed 152 steps in the worst case and 152/2 steps on average.
- rewrote LCD and GUI drawing functions to use avr-gcc __memx qualifier for a given text buffer parameter instead of an additional function parameter to distinguish between text in RAM or Flash.
For accessing variables with a __memx qualifier, it makes no difference whether they are in RAM or Flash. Since the decision is made during runtime, this method is slower and needs more Flash, though. A __memx pointer has 24bit instead of the 16bit of a usual pointer. If bit23 is set, the pointer points to SRAM else to Flash. The __builtin_avr_flash_segment(ptr) avr-gcc function can be used to determine where the ptr points to.
Bugfix:
- fixed wrong text in InfoType 0x16 "fuel engine operation" -> "fueled engine operation"
HHGui installation and usage:
HHGui installation and usage instructions are given in files Readme_windows.txt, Readme_ubuntu.txt or Readme_raspberry.txt. These files are in the hhgui350_usr.zip file.
The Windows executable of HHGui needs the runtime libraries that have been released with the HHEmu v2.80 release. The runtime libraries must be copied to a directory that is in the PATH environment variable or they simply must be put into the same directory than the hhgui.exe file.
Developer notes:
A makefile makefile_dev_hhgui, full sources of the emulator/simulator environment, some parts of the firmware (main/USART/LCD/SPI/GUI) and target dependent HHGui libraries (libhhgui_mingw32.a, libhhgui_msys2.a, libhhgui_ubuntu.a, libhhgui_pi.a) are supplied in hhgui350_dev.zip that lets you create your own version of HHGui.
HHGui compile instructions are given in files Readme_windows.txt, Readme_ubuntu.txt or Readme_raspberry.txt.
hhgui350_usr.zip (2790kb)
hhgui350_dev.zip (2836kb)
Thomas Beck 4 years ago
Highlights: Added support for another 11 PIDs and 4 InfoTypes with almost 50 additional data items (sensor data, counters, ...)
Since the list of supported PIDs and InfoTypes on the main project page is outdated, here is the current state:
Supported PIDs (OBD2 Service 1 and 2):
0x00 – 0x71, 0x77 – 0x7C, 0x7F, 0x80, 0x83 – 0x85, 0x87, 0x88, 0x8C – 0x8F, 0x98, 0x99, 0x9B, 0x9D, 0x9E, 0xA0 – 0xA3, 0xA5, 0xA6, 0xC0, 0xE0
Supported InfoTypes (OBD2 Service 0x09):
0x00, 0x02, 0x04, 0x06, 0x08, 0x0A, 0x0B, 0x16 – 0x19, 0x20, 0x40, 0x60, 0x80, 0xA0, 0xC0, 0xE0
If you do not have access to the latest SAE J1979-DA standard, check https://en.wikipedia.org/wiki/OBD-II_PIDs to see the meaning of most of the PIDs and InfoTypes listed above.
Changes:
- added new PIDs
0x6B Exhaust Gas Recirculation Temperature, sensor A-D (wide range or normal)
0x6E Injection Pressure Control System A,B
0x6F Turbocharger Compressor Inlet Pressure, sensor A,B (wide range or normal)
0x9B Diesel Exhaust Fluid (DEF) Sensor Output (of a DEF quality sensor)
DEF Type (e.g. urea concentration too high/low, wrong fluid, proper mixture, ...)
DEF Concentration (32.5% is ideal mixture of urea in water)
DEF Tank Temperature
DEF Tank Level
0x9D Engine Fuel Rate (and vehicle fuel rate which additionally contains fuel injected for aftertreatment)
0x9E Engine Exhaust Flow Rate
0xA1 NOx Sensor Corrected Data (bank 1-2, sensor 1-2)
PID 0x83 NOx Sensor contains raw sensor data. PID 0xA1 NOx Sensor Corrected Data contains the raw data manipulated by learned values and/or offsets.
0xA2 Cylinder Fuel Rate (of the most recent input stroke)
0xA3 Transmission Actual Gear (0-15, 0 = neutral, 1 = 1st gear or reverse) and gear ratio
0xA5 Diesel Exhaust Fluid Dosing
0xA6 Vehicle Odometer
- changed some PID acronyms and PID data to reflect changes in J1979-DA specification:
-- implemented new masks/texts for former FuelSys1/2 which now is FuelSysA,B to support two independent fuel systems which both can be two bank systems
If two bits are set in the received Fuel System A,B data, which is allowed now, the data is printed as is. So, an ECU could send two states for one bank, e.g. OL B1 OL-Drive B1, which makes no sense at all.
Valid combinations would be:
CL OL-Drive B1 or CL OL-Drive B2: system is closed-loop but one bank is open-loop, e.g. due to cylinder deactivation
OL-Fault B1 CL-Fault or CL-Fault OL-Fault B2: one bank is closed-loop but oxygen sensor fault on the other bank
-- With spark ignition engines also becoming equipped with particulate filters, the following PIDs are no longer Diesel only PIDs. Therefore, PID acronyms and PID descriptions have been renamed:
PID 0x8B: renamed Diesel Aftertreatment Status to Aftertreatment Status
PIDs 0x7A, 0x7B, 0x7C, 0x8B: renamed DPF to PF
-- added new data item Recommended Transmission Gear to PID 0x65 (0-15, 0 = neutral, 1 = 1st gear or reverse)
-- PID 0x1C OBD Requirements for Vehicle or Engine: added new OBD requirements for countries like Brasil, China, India, Korea and for heavy duty vehicles and for motor cycles
-- PID 0x51 Fuel Type: added new fuel types like, e.g. FC H2 (fuel cell utilizing hydrogen)
-- PID 0x83 NOx Sensor: added case No Results Available
- added new InfoTypes for MY2019+ vehicles
0x16 Vehicle Operation Data - Ignition Counters/Engine Run Time/Idle Time
0x17 Vehicle Operation Data Distance (traveled)/Fuel (consumed)
0x18 Vehicle Operation Data PKE/EOE - Positive Kinetic Energy/Engine Output Energy
0x19 Vehicle Operation Data PSA - Propulsion System Active Time (Total/City/Idle)
All VOD items are displayed with two values, a recent value and a lifetime value. Recent values are accumulated over the last 50 hours before VOD 0x19 Total Propulsion System Active Time Recent reaches 50 hours and resets to zero. If OBD2 service 0x04 (erase DTCs) is executed, the recent values are cleared as well.
- changed InfoType 0x08 (IPT for spark ignition engines) to reflect changes in J1979-DA specification:
added 4 additional counters for air fuel ratio imbalance monitor and (gasoline) particulate filter monitor
- added support for Supported InfoTypes masks 0x00 - 0xE0 (previously 0x00 only)
- added cnts as unit (for IPT menu and some items in the new VOD menus)
- increased the size of serial Rx buffer and DXM buffers to be able to receive and handle more data
8 ECU names of infoType 0x0A can be received at once from 8 ECUs
15 CALIDs of infoType 0x04 can be received from an ECU (CAN protocol), 9 CALIDs for non-CAN protocols
15 CVNs of infoType 0x06 can be received from an ECU
As a side-effect, DTC texts can be decompressed into an existing buffer and no longer need a temporary buffer on the stack.
- made CALID and CVN menu scrollable lists (page scroll with Up/Down, menu change between the two menus now with Ok (previous versions used Up/Down for this))
- implemented length checks for received PID data
"n/a" might be displayed for a data item in the Current Data menu and Freeze Frame Data menu if received data length is not great enough for the current data item of a PID.
- implemented support for longer CAN ISO-TP segmented messages (15 CALIDs result in 243 bytes to be transmitted over CAN)
Sequence number in the PCI is allowed to wrap to 0 now if it reaches 15 (1 .. 15, 0 .. 15, 0 .. 15).
- gui.c code cleanup to further reduce Flash memory usage
changed display layout and drawing of IPT/VOD/Readiness data to use the same function
changed display layout and drawing of Supported PIDs and Supported InfoTypes screens to use the same function
Bugfixes:
- Tester configuration bytes in PID 0x4F und PID 0x50 had no effect. So, if an ECU actually used this feature to change maximum value and resolution of Lambda, sensor voltage, sensor current, MAF or MAP, the displayed values for these data items were wrong since the configured scaling was not applied.
This was broken in the firmware since v1.11.0 / HHGui v3.20.
- PID 0x8C fixed 32bit overflow in O2 sensor concentration calculation (value after the floating point was totally wrong in most cases)
This bug was in the firmware since PID 0x8C was supported in v1.13.0 / HHGui v3.30.
This fix needs a lot of Flash memory since the firmware uses the uint64_t data type and 64bit math functions of libgcc on an 8bit AVR microcontroller now. I will have to check if not using float and double still makes sense in respect of Flash usage.
- PID 0x8F normalized PM Sensor is a signed value and not a value with negative offset (definition was missing in old version of J1979-DA specification)
This bug was in the firmware since PID 0x8F was supported in v1.13.0 / HHGui v3.30.
- memory areas must not overlap when using memcpy() (happened for VIN, CALIDs and CVNs)
replaced memcpy() by memmove() as suggested in avr-gcc's string.h header file
- long centered texts in single current data and single freeze frame data screens were not displayed
Now they are output left-justified and cut off on the right. This can happen for text only data items like PID 0x03 Fuel System Status (only with the longer texts available since this release) and PID 0x1C Supported Emission Requirements (only text for 0x0F = "OBD OBD II EOBD KOBD" that comes with this release does not fit)
- min/max/avg/current data screen: if an error occurred during initial decoding of a data item, current value showed "n/a" but min/max/avg values showed values of previously displayed data item (the item before or after the current item). Now, the initial "..." is kept for min/max/avg values of the current data item.
additional changes for HHGUI:
- improved display of ECU info in diagnostics info area if DISPLAY_HEIGHT >= 40 (5 lines):
ECU info is presented on two lines now instead of the crowded E1*2:E8 in the OBD2 Analyser NG's small 132x32 LCD.
ECU: EcuAddr
selected ECU index / total number of OBD2 ECUs
e.g.:
ECU: E8
1/2
- improved display for long texts in min/max/avg current data screen
Very long texts use the complete display width now and are cut off on the right. This can happen for text only data items like PID 0x03 Fuel System Status and PID 0x1C Supported Emission Requirements.
HHGui OBD2 simulator mode changes:
There have been significant changes (changed commands, new command to enter user defined OBD2 response data, new hexadecimal input mode) to improve testability of HHGui. If you are interested in the current command list, type hhgui -help and scroll to the section "OBD2 Simulator Command Overview" at the end.
- added o-command to switch between decimal 0-99 and hexadecimal 0x00000000-0xffffffff input
- changed s-command to g-command expecting the configuration byte A of bit-mapped PIDs as hexadecimal input
- new s-command expecting 8/16/32bit data for OBD2 responses as hexadecimal input
Currently, this affects most classic PIDs which use response data A-D.
- changed w-command expecting tester configuration bytes A-D for PID 0x4F and byte A for PID 0x50 as hexadecimal input
HHGui OBD2 simulator mode bugfix:
- calculation of number of CAN frames did not work for great OBD2 response message lengths, e.g. 35 or 41
Last simulated CAN frame was not sent.
HHGui installation and usage:
HHGui installation and usage instructions are given in files Readme_windows.txt, Readme_ubuntu.txt or Readme_raspberry.txt. These files are in the hhgui340_usr.zip file.
The Windows executable of HHGui needs the runtime libraries that have been released with the HHEmu v2.80 release. The runtime libraries must be copied to a directory that is in the PATH environment variable or they simply must be put into the same directory than the hhgui.exe file.
Developer notes:
A makefile makefile_dev_hhgui, full sources of the emulator/simulator environment, some parts of the firmware (main/USART/LCD/SPI/GUI) and target dependent HHGui libraries (libhhgui_mingw32.a, libhhgui_msys2.a, libhhgui_ubuntu.a, libhhgui_pi.a) are supplied in hhgui340_dev.zip that lets you create your own version of HHGui.
HHGui compile instructions are given in files Readme_windows.txt, Readme_ubuntu.txt or Readme_raspberry.txt.
HHGui v3.40 Windows/Ubuntu/Raspberry Pi Binaries (2678kb)
HHGui v3.40 Windows/Ubuntu/Raspberry Pi Source Code (2713kb)
pascalou95 4 years ago
je possède toujours cet analyser et je trouve dommage que la revue Elektor n'a pas donné de suite en français.
merci
pascal
Thomas Beck 5 years ago
Highlight: Added support for another 9 PIDs with more than 50 data items (sensor data, counters, ...)
Changes:
- added support for the following PIDs:
0x69 Commanded EGR Duty Cycle/Position and EGR Error
0x6A Commanded Diesel Intake Air Flow (IAF) Control and Relative IAF Position
0x71 Variable Geometry Turbo (VGT) Control (commanded/actual position and status)
0x7F Engine Run Time, Engine Idle Time, PTO (Power Take Off) Time
0x83 NOx Sensor (NOx concentration for up to 4 sensors)
0x85 NOx Control System
average reagent consumption
average demanded reagent consumption
reagent tank level
engine run time while NOx warning indicator is activated
0x88 SCR Inducement System Actual State/History States of last four 10000km blocks
reagent level too low
incorrect reagent
deviation of reagent consumption
NOx emissions too high
system active state (current 0-10000km block only)
distance traveled in 10000km block while inducement system active compared with total distance traveled in 10000km block
0x8C Oxygen Sensor (Wide Range) for Diesel (oxygen concentration and lambda for up to 4 sensors)
0x8F Particulate Matter (PM) Sensor Output for up to 2 sensors
sensor actively measuring
sensor regenerating
normalized output value: 0% (fully cleaned/regenerated sensor) - 100% (sensor soot load level when sensor regeneration is needed)
Bugfix:
- fixed detection of second data byte B (corresponds with bank 3,4) in PIDs 0x06-0x09 and 0x55-0x58
This was broken in the firmware since v1.11.0 and in HHGUI since v3.20.
Notes:
Since some of these PIDs contain very long text acronyms, I decided to change the display layout in the Current Data and Freeze Frame Data menus. Apart from some rare cases, all acronyms and their related data fit into a single line now. So, I might switch to the new acronym names (see remark in previous update) in a later release.
With the new PIDs, the Current Data and Freeze Frame Data menus support 266 data items now which no longer fits into 8bit. Therefore, the list handling for lists with up to 65536 list items had to be activated. This slightly increases Flash and SRAM usage for all lists.
The text compressor for compressing the PID text descriptions got an update which will be released in the comments section of the OBD2 for Arduino project.
HHGui installation and usage:
HHGui installation and usage instructions are given in files Readme_windows.txt, Readme_ubuntu.txt or Readme_raspberry.txt. These files are in the hhgui330_usr.zip file.
The Windows executable of HHGui needs the runtime libraries that have been released with the HHEmu v2.80 release. The runtime libraries must be copied to a directory that is in the PATH environment variable or they simply must be put into the same directory than the hhgui.exe file.
Developer notes:
A makefile makefile_dev_hhgui, full sources of the emulator/simulator environment, some parts of the firmware (main/USART/LCD/SPI/GUI) and target dependent HHGui libraries (libhhgui_mingw32.a, libhhgui_msys2.a, libhhgui_ubuntu.a, libhhgui_pi.a) are supplied in hhgui330_dev.zip that lets you create your own version of HHGui.
HHGui compile instructions are given in files Readme_windows.txt, Readme_ubuntu.txt or Readme_raspberry.txt.
HHGui v3.30 Windows/Ubuntu/Raspberry Pi Binaries (2629kb)
HHGui v3.30 Windows/Ubuntu/Raspberry Pi Source Code (2665kb)
Thomas Beck 5 years ago
Changes:
- added support for bit-mapped PID 0x8B Diesel Aftertreatment Status
Internally, this PID provides the following data items:
Diesel Particulate Filter (DPF) regeneration status: yes/no
DPF regen type: active/passive
NOx Adsorber regen status: yes/no
NOx Adsorber desulfurization status: yes/no
Normalized trigger for DPF regen: 0 - 100.0 %
Average time between DPF regens: 0 - 65535 minutes
Average distance between DPF regens: 0 - 65535 km
- minor changes of title font and menu fonts: shorter underscore to reduce the space needed by PID acronyms
- fixed missing character 'S' in PID acronym names of long term secondary oxygen sensor fuel trim PIDs LTO2FTx -> LTSO2FTx
By the way, PID acronyms have been changed in more recent versions of the SAE J1979-DA specification. The firmware still uses the old PID acronyms since these are generally shorter. Most of them are only 8 characters long which better fits with the small LC display.
The compressed PID text descriptions are generated with the text compressor which I have published in the comments section here:
OBD2 for Arduino
If you run out of Flash memory in your own microcontroller project which uses texts, you might want to try this. Details are published here:
German: https://www.elektormagazine.de/articles/kurzgefasst-texte-fur-mikrocontroller-speicher-sparen-durch-kompression
French: https://www.elektormagazine.fr/articles/condense-de-textes-pour-microcontroleurs
Additional Changes for HHGui:
- added support for MSYS2/PDCurses since after the latest MSYS2 update MSYS2/ncurses is broken on my machine
- if the terminal window size is too small for the curses screen, the HHGui curses variants try to resize the window now
- 3 minor changes (DEAD_STORE) to satisfy the Infer static analyzer for Linux
- 2 minor changes (value stored is never read) to satisfy the clang scan-build analyzer for Windows/MSYS2
By the way, if the project is compiled with the clang compiler instead of gcc, the executable is smaller.
HHGui installation and usage:
HHGui installation and usage instructions are given in files Readme_windows.txt, Readme_ubuntu.txt or Readme_raspberry.txt. These files are in the hhgui321_usr.zip file.
The Windows executable of HHGui needs the runtime libraries that have been released with the HHEmu v2.80 release. The runtime libraries must be copied to a directory that is in the PATH environment variable or they simply must be put into the same directory than the hhgui.exe file.
Developer notes:
A makefile makefile_dev_hhgui, full sources of the emulator/simulator environment, some parts of the firmware (main/USART/LCD/SPI/GUI) and target dependent HHGui libraries (libhhgui_mingw32.a, libhhgui_msys2.a, libhhgui_ubuntu.a, libhhgui_pi.a) are supplied in hhgui321_dev.zip that lets you create your own version of HHGui.
HHGui compile instructions are given in files Readme_windows.txt, Readme_ubuntu.txt or Readme_raspberry.txt.
HHGui v3.21 Windows/Ubuntu/Raspberry Pi Binaries (2505kb)
HHGui v3.21 Windows/Ubuntu/Raspberry Pi Source Code (2565kb)
Thomas Beck 6 years ago
A few days ago I could test IPT counters (OBD2 service 0x09, InfoType 0x08 and 0x0B) in a real vehicle. Unfortunately, this feature was broken due to a false __flash qualifier in the new OBD_Int2Str() function that came with the v1.11.0 release. So, the problem was not visible in the PC simulation and in the PC HHGui software. The problem also affects other AVR microcontrollers in the OBD2 for Arduino project. A bugfix will be released there for the Arduino MEGA/MEGA2560, too. Arduino Uno R3 and Elektor Uno R4 are not effected since these do not support InfoTypes due to memory reasons.
Thomas Beck 6 years ago
Highlights:
Added new submenu which displays minimum/maximum/average/current sensor data.
Added support for even more OBD2 parameter IDs (PIDs) whose sensor data is displayed in the Current Data and Freeze Frame Data menus.
Changes:
OBD2-Analyser NG firmware changes:
- implemented new submenu for the Current Data menu which displays minimum/maximum/average and current value of a data item
This helps to find defective sensors or can be used as trip computer.
The average data calculation uses the same scaling to get the display value as is used for the current data value. I.e., that the average value changes with the step size that is specified in SAE J1979/ISO 15031-5 for this data item. The average value is calculated by the formula "sum of all received current data values/number of current data values". Then, scaling is applied to get the display value. Since the project does not use float or double data types to save Flash, the scaled display value, which might be a floating point value but internally is represented by two decimal values (value before and after the floating point), is not used for calculation. Average calculation stops if the sum of all received current data values or the number of samples reaches max uint32_t.
To activate the Min/Max/Avg Current Data menu, press the OK-key in the Current Data Large Single Data screen. Then, pressing the Up/Down-key scolls to the previous/next data item in the Min/Max/Avg Current Data menu. To go back to the Single Data screen, press the OK-key or ESC-key. If the menu is entered or if the data item is changed, calculation starts again. This is indicated by three dots "..." being shortly displayed before the first calculation has finished.
If the current data item is a text-only data item, a dash "-" is displayed for min/max/avg and a text is displayed for the current value. If the text does not fit into the display, it is cut off.
For simplicity, min/max/avg is even calculated for data items for which it makes no sense at all, e.g. "time since engine start" or "distance traveled while MIL is activated" or constant values like "engine reference torque".
During implementation of the new submenu, scaling of received values to display values has been optimized in code size. Therefore, the new menu will be part of the next update of the OBD2 for Arduino project even for UNO R3 and Elektor UNO R4.
- added support for further bit-mapped PIDs (first data byte is configuration bit mask that tells the diagnostic tester which sensors are actually available)
0x65 - Auxiliary Inputs/Outputs:
power take off status
automatic transmission neutral/drive status
manual transmission neutral/gear status
glow plug lamp status
0x66 - Mass Air Flow sensor data: 2 sensors A,B
0x67 - Engine Coolant Temperature: 2 sensors 1,2
0x6C - Commanded Throttle Actuator Control and Relative Throttle Position: actuator A,B and position A,B
0x6D - Fuel Pressure Control System: commanded/actual fuel rail pressure A,B and fuel rail temperature A,B
0x77 - Charge Air Cooler Temperature: supports 2 banks each with up to 2 sensors
0x87 - Intake Manifold Absolute Pressure: 2 sensors A,B
- fonts got some kind of proportional spacing for about 25 combinations of two characters
To be honest, the reason for this is more a problem of small display size. Sometimes more text had to be sqeezed in a line.
For the OBD2-Analyser NG, every pixel of the display width is needed for the new min/max/avg menu. So, reducing the space between e.g. "Pa" helps to reduce the space needed to display units like kPa and Pa. Furthermore, for HHGui, "Charge Air Cooler Temperature" did not fit in a line without reducing the space between "Te".
HHGui:
- better display layout in Min/Max/Avg Current Data menu than in OBD2-Analyser NG
Each of the 4 values is displayed on its own line.
min/max/avg/current icons are replaced with text.
- added new command 's' for the OBD2 simulator
This command changes the configuration byte of bit-mapped PIDs.
- added new command 'w' for the OBD2 simulator
This command changes the minimum/maximum value of some PIDs according to the tester configuration PIDs 0x4F and 0x50.
Commands 's' and 'w' are developer commands. Further details are given if is entered in a command shell.
HHGui installation and usage:
HHGui installation and usage instructions are given in files Readme_windows.txt, Readme_ubuntu.txt or Readme_raspberry.txt. These files are in the hhgui320_usr.zip file.
The Windows executable of HHGui needs the runtime libraries that have been released with the HHEmu v2.80 release. The runtime libraries must be copied to a directory that is in the PATH environment variable or they simply must be put into the same directory than the hhgui.exe file.
Developer notes:
A makefile makefile_dev_hhgui, full sources of the emulator/simulator environment, some parts of the firmware (main/USART/LCD/SPI/GUI) and target dependent HHGui libraries (libhhgui_mingw32.a, libhhgui_msys2.a, libhhgui_ubuntu.a, libhhgui_pi.a) are supplied in hhgui320_dev.zip that lets you create your own version of HHGui.
HHGui compile instructions are given in files Readme_windows.txt, Readme_ubuntu.txt or Readme_raspberry.txt.
HHGui v3.20 Windows/Ubuntu/Raspberry Pi Binaries (2503kb)
HHGui v3.20 Windows/Ubuntu/Raspberry Pi Source Code (2561kb)
Thomas Beck 6 years ago
Highlights: Added support for even more OBD2 parameter IDs (PIDs) whose sensor data is displayed in the Current Data and Freeze Frame Data menus.
Changes:
OBD-Analyser NG firmware changes:
- added support for new bit-mapped PIDs (first data byte is configuration bit mask that tells the diagnostic tester which sensors are actually available)
0x68 - Intake Air Temperature: supports 2 banks each with up to 3 sensors
0x78 - Exhaust Gas Temperature (EGT) bank 1: up to 4 sensors, 1 - 4
0x79 - Exhaust Gas Temperature bank 2: up to 4 sensors, 1 - 4
0x7A - Diesel Particulate Filter (DPF) bank 1: delta/inlet/outlet pressure
0x7B - Diesel Particulate Filter bank 2: delta/inlet/outlet pressure
0x7C - Diesel Particulate Filer bank 1/2: inlet/outlet temperature
0x98 - Exhaust Gas Temperature bank 1: up to 4 sensors, 5 - 8
0x99 - Exhaust Gas Temperature bank 2: up to 4 sensors, 5 - 8
PIDs 0x68, 0x78 and 0x7A are supported by Ford EcoSport. I have tested the firmware with a gasoline engine. Nevertheless, Diesel PID 0x7A is reported as supported by the EcoSport's engine control module (ECM). Of course, inside the PID the configuration byte reports all sensors as unsupported. So, in the Current Data menu the firmware correctly displays all 3 pressure sensors as not available.
- error handling has been improved in the Reading Data screen when reading supported PIDs 0x20, 0x40, 0x60, ...
Error handling for the first supported PID 0x00 was already implemented.
If PIDs 0x20, 0x40, 0x60, ... are read (due to the previous supported PID mask reporting this PID as supported) and the OBD2 module answers with "NO DATA", an error message is displayed and reading of further data is stopped. Otherwise, with incorrect supported PIDs mask set, the Current Data menu might display dupplicate/wrong data items. There is no automatic retry. The user must press the ESC-key to return to the Main menu and then, the protocol can be selected again.
- text compression for DTC texts and PID long texts has been significantly improved
So, program data still fits into the lower 64K Bytes of the AT90CAN128's Flash.
Furthermore, a better PID long text compression was needed to still get the new PIDs into an Arduino UNO or Elektor UNO R4 for the next update of the OBD2 for Arduino Labs project.
Bugfix:
- incorrect data was displayed for EVAP system vapor pressure of PID 0x32 and PID 0x54 (a vehicle/ECU supports none or just one of these)
While implementing the signed DPF delta pressure of PIDs 0x7A and 0x7B, I noticed that the signed EVAP system vapor pressures of PID 0x32 and PID 0x54 were not correctly implemented. These PIDs mistakenly got a negative offset (as is correct for most other PIDs that use negative values) instead of the signed implementation requested in the SAE J1979/ISO 15031-5 specification.
HHGui:
In addition to the above changes incorporated from the firmware, the following has been changed:
- the OBD2 simulator finally got a major code cleanup while adding sensor data generators for the new bit-mapped PIDs
Actually, many parts of it were completely rewritten. This allows me to support even more bit-mapped PIDs faster in the future.
Note: The HHEmu DXM Simulator has not been checked to work together with third party OBD2 software anymore. If you need this feature, use the latest release of HHEmu V2.90.
Known problems with new bit-mapped PIDs:
The PID acronym sometimes is too long to fit into the Current Data/Freeze Frame Data list view.
Most classic PIDs use only 8 characters for the acronym. Surplus characters are not printed to the display. Up to now this has not been a problem since the truncated acronym still differed for all data items. Unfortunately, this is no longer the case for data items of DPF PIDs. For example, DPF1_OUTP (DPF bank 1 outlet pressure) and DPF1_OUTT (DPF bank 1 outlet temperature) are both displayed as DPF1_OUT in the list view if the last character is cut off. However, in the title line of the Current Data single data screen, there is more space. So, the full acronym is displayed there.
HHGui installation and usage:
HHGui installation and usage instructions are given in files Readme_windows.txt, Readme_ubuntu.txt or Readme_raspberry.txt. These files are in the hhgui310_usr.zip file.
The Windows executable of HHGui needs the runtime libraries that have been released with the HHEmu v2.80 release. The runtime libraries must be copied to a directory that is in the PATH environment variable or they simply must be put into the same directory than the hhgui.exe file.
Developer notes:
A makefile makefile_dev_hhgui, full sources of the emulator/simulator environment, some parts of the firmware (main/USART/LCD/SPI/GUI) and target dependent HHGui libraries (libhhgui_mingw32.a, libhhgui_msys2.a, libhhgui_ubuntu.a, libhhgui_pi.a) are supplied in hhgui310_dev.zip that lets you create your own version of HHGui.
HHGui compile instructions are given in files Readme_windows.txt, Readme_ubuntu.txt or Readme_raspberry.txt.
HHGui v3.10 Windows/Ubuntu/Raspberry Pi Binaries (2502kb)
HHGui v3.10 Windows/Ubuntu/Raspberry Pi Source Code (2556kb)
Thomas Beck 6 years ago
Highlights: Added support for the DXM OBD2 module in the HHGui OBD2 Software of the OBD2 for Raspberry Pi project. HHGui has been ported to Windows and Linux.
Added vehicle's "inspection/maintenance readiness status since DTCs cleared" to the diagnostics info area.
You do not have an OBD2-Analyser NG or a bare DXM OBD2 module? Nevermind, HHGui supports the Pi-OBD module of the OBD2 for Raspberry Pi project. In order to connect that to a PC, just a serial-to-USB adapter is needed. I use the Elektor FT232R USB/serial bridge BOB for this purpose. That needs the 3.3V jumper setting on the BOB and just 3 lines (Rx, Tx and GND) connected to the Pi-OBD module which is powered from the OBD2 connector.
This update is driven by the OBD2 for Arduino project. To build a 'light' version for the Arduino UNO and Elektor UNO R4 (ATmega328P/PB with just 2KByte SRAM/32KByte Flash), the SRAM/Flash memory usage has to be reduced. So, most changes save SRAM and/or Flash memory. Since the current OBD2 for Arduino versions for the Arduino M0/M0 Pro/Zero, Due and MEGA/MEGA2560 support the DXM and the Pi-OBD module, it was easy to add support for the DXM in the Raspberry Pi OBD2 software HHGui of the OBD2 for Raspberry Pi project, too. Creating a Windows and a Linux version of HHGui was the next step that saves me from having to support two different OBD2 softwares HHGui and HHEmu. Therefore, from this update, only HHGui will be released in the future.
Changes:
OBD2-Analyser NG firmware changes:
Most changes only save SRAM and/or Flash memory. If these changes do not affect HHGui's appearance or behaviour, they are not noted below.
- upgraded build environment to avr-gcc 4.9.2 and avr-libc 2.0.0 of Arduino IDE 1.8.5
- added vehicle's "inspection/maintenance readiness status since DTCs cleared" to the diagnostics info area and made the info area available in the I/M Readiness menu, too
The info area was changed as follows:
line 1 is a combined MIL/DTC status line, now
line 2 shows "RDY: Y" (I/M readiness status: Ready = Yes) or "RDY: N" (I/M readiness status: Ready = No)
line 3 shows "E ECU x of y ECUs: ECU addr", this line is unchanged
If the MIL is commanded on by any ECU, line 1 shows "MIL on icon: number of DTCS"
If the MIL is not commanded on by any ECU, line 1 shows "DTC: number of DTCS".
number of DTCs = number of confirmed DTCs + number of pending DTCs + number of permanent DTCs (CAN protocols only)
notes:
When the diagnostics info area is in display (Diagnostics menu, Trouble Codes menu or I/M Readiness menu), it displays a static status.
When the I/M Readiness menu or one of its submenus is in display, PID 0x01 alternating with PID 0x41 is polled every second. This might lead to a change of MIL icon or readiness state in the diagnostics info area as soon as the menu is changed. However, the Rescan OBD2 Data menu item must be selected to get a new consistent status.
- changed saving of DTCs in memory to significantly reduce SRAM consumption
All DTCs share a common buffer now. The number of DTCs is no longer limited to 16 DTCs per SID and ECU. Instead the number of DTCs is limited to 48 DTCs for all ECUs.
Due to this change, the sequence of DTCs shown in the DTC Summary menu has changed, too.
The old sequence was confirmed/pending/permanent DTCs of ECU1, confirmed/pending/permanent DTCs of ECU2, ..., confirmed/pending/permanent DTCs of last ECU.
The new sequence is confirmed DTCs of all ECUs, pending DTCs of all ECUS, permanent DTCs of all ECUs. The sequence of ECUs depends on the sequence in which the ECUs have responded to the initial "Get supported PIDs" OBD2 request (OBD2 service 0x01, supported PIDs 0x00).
- changed behaviour if more ECUs than OBD_MAX_ECU responded to the initial "Get supported PIDs" OBD2 request
In previous releases, the error message "Too many ECUs" was displayed and the program simply stopped. This was a problem for the original firmware v1.2.x, which only supported 2 ECUs. For the enhanced firmware, that supports the maximum of 8 ECUs, this should never have been a problem.
In the error case, the new firmware v1.9.1 displays this message for 4 seconds and continues. This allows displaying data of those OBD_MAX_ECU ECUs that have responded fastest to the initial OBD2 request.
- moved some flags and variables to GPIOR0-2 registers (especially 10ms timer interrupt related variables)
GPIOR0 is a bit-accessible I/O register for AT90CAN128, ATmega328P/PB and ATmega1280/2560.
It can be used to store up to 8 flags that can be set/cleared/changed atomically.
GPIOR1 and GPIOR2 are byte-accessible I/O registers for AT90CAN128, ATmega328P/PB and ATmega1280/2560.
They can be used to store 8bit values that can be accessed atomically.
- the long PID text descriptions which are displayed in the single data screens of the Current Data and Freeze Frame Data menus have been compressed
Bugfixes:
- fixed buffer overflow in Calibration IDs submenu in Vehicle/ECU Info menu
Using a wrong numer (12 bytes) for the size of a DXM/AGV frame buffer (16 bytes) led to a miscalculated buffer size of 4 * 12 = 48 bytes.
If 3 CALIDs are received in the related Vehicle/Ecu Info submenu a buffer size of 51 bytes is needed for the internally used CAN protocol format (3 byte header (SID InfoType nodi) + 3 * 16 bytes). So, the 3 bytes after the buffer become overwritten. In firmware v1.9.0 that affects the protocol number and and key bytes in case of a keyword protocol. The protocol number is a crucial value for decoding received data. Since the protocol number is determined only once during protocol scan, the error does not heal itself when rescanning OBD2 data.
- USB with AT90USB162 did not work because in the USB menu wrong PORTF/PINF was used instead of PORTD/PIND (copy paste error from Serial Interface menu code)
This feature is still untested because I do not have an AT90USB162 mounted in my OBD2-Analyser NG.
HHEmu changes:
HHEmu is no longer released. This is a mere developer tool for the OBD2-Analyser NG firmware with 4 KByte SRAM / 128 KByte Flash restriction, Diamex DXM OBD2 module simulation, 132 x 32 LCD simulation and therefore, for displaying 1-4 menu/list lines and short text descriptions.
HHGui changes:
The HHGui OBD software of the OBD2 for Raspberry Pi project with configurable display size allows displaying more menu/list lines and longer text descriptions. HHGui has been ported to Windows (Windows XP to Windows 10, 32bit and 64bit) and Ubuntu (64bit).
- HHGui inherits most of the firmware v1.9.1 changes
- the long PID text descriptions in the large single data screens of the Current Data and Freeze Frame Data menus have been capitalized to improve text compression
- if DISPLAY_HEIGHT >= 40, the diagnostics info area gets an additional line (compared to the firmware), so that MIL and number of DTCs are shown on separate lines
- HHGui supports DXM and AGV OBD2 modules
The selection has to be done via command line options if the desired option is not the default setting. There are default settings that depend on the HHGui variant.
Windows and Ubuntu variants:
The default OBD2 module is the DXM module.
The default baud rate for DXM is 19200 Bd (to work with an OBD2-Analyser NG with Bluetooth module or serial-to-USB interface).
The default baud rate for AGV is 115200 Bd (to work with the fixed factory setting of a Pi-OBD module connected to a PC via serial-to-USB interface).
Raspberry Pi variant:
The default OBD2 module is the Pi-OBD module (AGV).
The default baud rate for AGV is 115200 Bd (to work with the fixed factory setting of a Pi-OBD module).
The default baud rate for DXM is 9600 Bd (to work with the factory setting of a bare DXM module).
- added description for the new command line options and HHGui variant-specific usage examples to the built-in manual
- added 'r'-command to the OBD2 simulator
Pressing the 'r'-key while running HHGui as an OBD2 simulator toggles the "inspection/maintenance readiness status since DTCs cleared".
The diagnostics info area will show the new state "RDY: Y" or "RDY: N" if PID 0x01 is read. So, either select the Rescan OBD2 Data item in the Diagnostics menu or change to the I/M Readiness menu (this requests PID 0x01 alternating with PID 0x41 every second).
- added an OBD2 Simulator Command Overview to the built-in manual
HHGui installation and usage:
HHGui installation and usage instructions are given in files Readme_windows.txt, Readme_ubuntu.txt or Readme_raspberry.txt. These files are in the hhgui300_usr.zip file.
The Windows executable of HHGui needs the runtime libraries that have been released with the HHEmu v2.80 release. The runtime libraries must be copied to a directory that is in the PATH environment variable or they simply must be put into the same directory than the hhgui.exe file.
Developer notes:
A makefile makefile_dev_hhgui, full sources of the emulator/simulator environment, some parts of the firmware (main/USART/LCD/SPI/GUI) and target dependent HHGui libraries (libhhgui_mingw32.a, libhhgui_msys2.a, libhhgui_ubuntu.a, libhhgui_pi.a) are supplied in hhgui300_dev.zip that lets you create your own version of HHGui.
HHGui compile instructions are given in files Readme_windows.txt, Readme_ubuntu.txt or Readme_raspberry.txt.
HHGui v3.00 Windows/Ubuntu/Raspberry Pi Binaries (2538kb)
HHGui v3.00 Windows/Ubuntu/Raspberry Pi Source Code (2588kb)
Thomas Beck 7 years ago
Highlights: This update enables the OBD2-Analyser NG to display the DTC text for 4277 DTCs.
This update adds support for several new PIDs (mainly engine torque related).
HHEmu is available for Linux now (tested with Ubuntu 16.04 LTS).
Changes:
- compressed the 4277 DTC texts (uncompressed ~220KB) of the standard SAE J2012:2007
So, all DTC texts plus all other constant firmware data (e.g. menu texts and all tables) fit into the lower 64KB Flash of the AT90CAN128, now.
- added support for the following PIDs:
0x61 - engine torque requested by the driver, displayed in percent of reference torque PID 0x63
0x62 - actual engine torque, displayed in percent of reference torque PID 0x63
0x63 - engine reference torque
0x64 - engine torque map data (maximum 5 points, point 1 = torque at idle), displayed in percent of reference torque PID 0x63
0x84 - manifold surface temperature
0x8E - engine friction torque, displayed in percent of reference torque PID 0x63
HHEmu Changes:
- added longer PID descriptions in the single data screen of the current data menu/freeze frame data menu
In the OBD2-Analyser NG the PID description is restricted to a single line due to the small LCD. For the bigger simulated LCD several text lines can be displayed.
- Bugfix: the DTC texts of the DTC blocks for hybrid vehicles P0Axx (256 texts), P0Bxx (256 texts) and P0Cxx (136 texts) were wrong. The text for DTC number 0x00 was actually the text from the maximum number (256, 256 or 136). For all other DTC numbers n (n = 0x01 .. maximum number of DTC block), the text for number n-1 was shown.
- Bugfix: corrected misspellings in about 30 DTC texts
Simulator Changes:
- added support for PID 0x8D - absolute throttle position G
This was just missing in the simulator. The emulator and the firmware were supporting PID 0x8D since firmware version 1.4.0.
Installation/usage for Ubuntu:
Read the file Readme_ubuntu.txt in the archive hhemu290_ubuntu_usr.zip.
HHEmu V2.90 MinGW32 Software (needs runtime libs from v2.80 update) (1991kb)
HHEmu V2.90 MinGW32 Source Code (844kb)
HHEmu V2.90 Ubuntu 16.04 LTS Software (1964kb)
HHEmu V2.90 Ubuntu 16.04 LTS Source Code (853kb)
Thomas Beck 8 years ago
Highlights: This update enables HHEmu to display the DTC text for 4277 DTCs (including 3526 Powertrain DTCs) of the standard SAE J2012:2007.
This update enables the OBD2-Analyser NG to display the DTC text for about 700 Powertrain DTCs.
The SAE J2012 / ISO 15031-6 standards specify diagnostic trouble codes that should be used for vehicle diagnostics by all manufacturers. However, many DTCs listed there are not emissions-relevant. So, do not expect them to be available via OBD2.
Due to my new project OBD2 for Raspberry Pi, HHEmu Raspberry Pi versions are no longer released here, but in the new project. An update will be there soon. For German speaking users: Das neue Projekt enthält eine deutsche Anleitung für die dort veröffentlichte OBD2 Software HHGui. Diese Anleitung kann in großen Teilen auch für HHEmu und den OBD2-Analyser NG verwendet werden.
Firmware:
Since the DTC texts in their uncompressed form need a lot of space, firmware v1.8.0 for the OBD2-Analyser NG differs from v1.8.0 in HHEmu.
Firmware v1.8.0 for the OBD2-Analyser NG just contains about 700 DTC texts of the following powertrain code ranges:
P0000-P02FF fuel and air metering
P0300-P03FF ignition system and misfire
P2300-P23FF ignition system and misfire
However, I might develop a software to compress the DTC texts, so that more texts fit into the FLASH of the AT90CAN128.
Another problem is the limited number of 3 menu lines in the OBD2-Analyser NG. Therefore, some very long DTC texts are cut off at the end of the third menu line. The new HHEmu command line option 'dtc=Xxxxx' described further down is a workaround for that.
Changes:
- changed display update in standard lists, so that only list/menu lines that actually are affected by a cursor move/key press are redrawn
Standard lists are lists with a full line cursor like in the main menu. Standard lists just contain list elements that change their state when pressing a key.
- changed display layout in the DTC Summary menu
- changed EEPROM default of I/M readiness setting "show unsupported monitors" checkbox to unchecked, so that only supported monitors are displayed.
- changed port reconfiguration when leaving bluetooth mode, serial interface mode or USB mode menus.
That should reduce the occurrence of the error "No response from DXM" when leaving these menus.
- Bugfix/Improvement: non-CAN protocols send 3 DTCs per frame. Unused DTCs are set to 0x0000. The old firmware (at least since v1.7.0) stopped evaluation of DTCs in a frame as soon as the first DTC=0 was detected. Now evaluation continuous to handle the following rare cases: 0 0 DTC, 0 DTC DTC, 0 DTC 0, DTC 0 DTC
HHEmu Changes:
- added command line option "dtc=Xxxxx". This option can be given up to 16 times to specifiy 16 DTCS for the emulator or DXM simulator mode.
If e.g. option dtc=P0120 is given on the command line, a confirmed DTC P0120 will be set for the first simulated ECU.
If a DTC is supported by HHEmu, the full text of that DTC is available if the configured DTC is selected in the DTC Summary menu.
So, this is a simple method to get a description for DTCs not supported by the OBD2-Analyser NG due to memory reasons.
Developer Section:
Due to my new project OBD2 for Raspberry Pi, I created a special source/library package for HHEmu/Mingw32/GTK3.6.4/pthreads2.9.1.
That package enables you to compile your own version of HHEmu with a configurable number of visible menu/list lines.
The supplied libraries are created with Mingw32 (old version from 2013, not MSYS2) and gcc 4.8.1.
The source files contain the firmware fonts and menu texts, so you could change them to your language. OBD2 texts still will be in English, though.
The required font generator that came with the original firmware is located in the HandheldOpen_130.zip file on the main project page.
The source files contain the complete emulator environment. Together with the released firmware main.c, SPI and USART source code, you can fully understand the interaction between the emulator environment and the firmware. A still valid HHEmu/GTK block diagram can be found in the partially outdated hhemu_doc_preview.zip on the main project page.
The source files contain the firmware LCD source code. This can be used for other projects with DOGM132-5 LC displays with ST7565R display controller.
MingW32: You need the base installation with w32api, gcc, binutils and pthreads2.9.1 from https://sourceforge.net/projects/mingw/files/
Start with https://sourceforge.net/projects/mingw/files/Installer/
GTK3.6.4: http://win32builder.gnome.org/gtk+-bundle_3.6.4-20130921_win32.zip
And follow the instructions in the README file in the zip-archive.
This bundle also contains pkg-config that is used by the makefile_dev_hhemu.
HHemu compile instructions:
Unpack the hhemu281_dev.zip archive to a directory of your choice. A directory HHOPEN_BIOS containing several subdirectories will be created there.
Open the Mingw32 command shell, change to the directory HHOPEN_BIOS and type
make -f makefile_dev_hhemu DISPLAY_HEIGHT=x (*)
Wait for the compilation process to finish and cross your fingers that that all goes well ;-)
(*) Replace the x with a valid number of your choice:
32 (= 4 menu lines like in the original OBD2-Analyser NG), 40, 48, 56, 64, 72, 80, 88, 96, 104, 112, 120, 128 (= 16 menu lines)
If DISPLAY_HEIGHT=x neither is given on the command line nor is set as environment variable, DISPLAY_HEIGHT=64 is the default set in the makefile.
I recommend using values between 40 and 120. Some DTC texts are cut off, when using 32. When using 128 the text of the first and last line is partially overwritten by the simulated LCD frame. You could remove the LCD frame drawn in file emu_gtk3.c to avoid that.
Of course if you use values greater than 64, the OBD2-Analyser NG background image does not fit anymore. Remove it and use HHEmu without it.
If you later decide to change the x, you have to delete the old object files first. This can be done with:
make clean -f makefile_dev_hhemu
===============================================================================
2016-08-22
Handheld Open firmware V1.7.2
This update was released as part of Raspbian HHGui/HHEmu only. Firmware V1.8.0 for the OBD2-Analyser NG contains these bugfixes, too.
Firmware Changes:
- Bugfix: If the freeze frame list menu was entered and the number of supported freeze frame data items was smaller than the number of maximum visible list items and smaller than the maximum number of visible current data items, the current data items were drawn but updated only up to the maximum number of freeze frame data items, when entering the current data list menu later.
Current data single data menu was not affected and the error healed itself when changing the ECU.
- Bugfix: If the freeze frame list menu contained just one data item, the sandglass (wait indicator) was not cleared.
- Bugfix: Supported data items arrays for OBD2 service 0x01 and 0x02 were 1 byte too small. So, data could get corrupted, if there was no padding byte(s) between the arrays and the next data following them in memory.
HHEmu V2.81 Mingw32 software (needs runtime libs of previous update) (2016kb)
HHEmu V2.81 Mingw32 source code (876kb)
Thomas Beck 8 years ago
Yet another update: OBD-Analyser NG / Handheld Open firmware V1.7.1 and Handheld Open Emulator (and OBD software for OBD-Analyser NGs with Bluetooth or USB) HHEmu V2.80.
Highlights:
Two variants of adding USB to your OBD2-Analyser NG: Mounting the AT90USB162 or using the Elektor FT232R USB/serial bridge BOB.
Improved HHEmu support for Raspberry Pi. Supports Pi 3 now.
Firmware Changes:
- made Bluetooth menu item in main menu dynamic
- added dynamic USB menu item in main menu
- added dynamic serial interface menu item in main menu
- added 3 check boxes to the Settings menu: enable Bluetooth menu, enable USB menu and enable serial interface menu
If you tick or untick a box, the related menu in the main menu will show up or disappear. So, you can configure the main menu to your needs. Since the menu configuration is stored in the EEPROM, you have to do that once only. The default is: Bluetooth menu available, USB menu disabled, serial interface menu disabled.
- added jump to Check ECU Error Responses screen in Clear Trouble Codes screen if no ECU responded to the clear diagnostic fault/monitor data request.
Furthermore, enabled OK button to quit Check ECU Error Responses screen. In previous releases only ESC button was allowed.
- implemented new LCD text drawing functions and font functions and changed GUI functions to use the new LCD functions
- changed Protocol Info menu to display the full protocol name using a new LCD_DrawTextBox() function that supports multi-line text from SRAM and FLASH.
In previous releases the protocol name for the KWP2000 protocols was cut off at the right, due to limited display width.
- Bugfix/Improvement: Before sending a request, the Rx/Tx buffers and the Rx state machine is reset. So, leaving a menu (where AT commands or OBD2 requests are sent) and re-entering it can repair a failure on the serial connection. Actually, this was needed during development for Rasperry Pi serial interface only, but is kept as a safety measure in the firmware.
- Bugfix: If DXM response CAN ERROR during protocol scan ocurred, the protocl scan continued with ATP4 (KWP2000 5 Baud wakeup) and some protocols were not scanned.
- Bugfix: If DXM response CAN ERROR occurred during erasing of fault codes, the OBD request was not retried.
DXM-Simulator Changes:
- Bugfix: Length information in the header byte of KWP2000 protocols was not correct for OBD messages longer than 7 bytes.
HHEmu Changes:
- reduced minimum window size to 320x165 for the Pi version.
- added mouse/touchscreen support even if no background picture could be read on program startup.
To achieve that, the visible window area is divided into 4 rectangular regions.
Clicking or touching the top left area is like pressing the Up button.
Clicking or touching the bottom left area is like pressing the Down button.
Clicking or touching the top right area is like pressing the ESC button. (*)
Clicking or touching the bottom right area is like pressing the OK button.
That allows to use even small touchscreens with 320 x 240 pixels for the Pi version. I have tested it with the 3.2" touchscreen from Waveshare/Joy-it (if you buy that, use the installation instructions from the Waveshare website).
(*) The top right area additionally contains a hidden top right area with 30 x 30 pixels in size. Clicking or touching that toggles between fullscreen mode and standard window size. This is needed to be able to close HHEmu on a touchscreen even in fullscreen mode that does not have a close button.
- changed emulation to work with higher baud rates/cpu speeds.
Real UDR0 register of AT90CAN128 is used for Tx and Rx. Changed emulation to use UDR0 just for Tx and added a UDR0_RX register just for Rx. So, Tx and Rx operate on different memory locations and Rx data cannot overwrite Tx data and vice versa.
Synchronized access to USART registers UDR0/UDR0_RX in DxmThread and HhopenThread with a mutex.
Synchronized access to SPI registers in LcdThread and HhopenThread with a mutex and a condition variable (see bugfix further down).
With these changes, HHEmu runs stable on the Raspberry Pi 2 and 3.
- changed mingw32 serial port configuration to work with COM port numbers greater than 9 (untested feature).
- added baud rate command line option for OBD2 software mode and DXM-simulator mode.
Valid baud rate options are 9600, 19200, 38400, 57600, 115200 Bd. Default is 9600 Bd.
- added nosync command line option for OBD2 software mode.
The nosync option disables waiting for a prompt sign (">") from the other side (DXM or DXM-simulator) and is intended for use with the new serial interface menu in the firmware.
- added init=DXM command line option for OBD2 software mode.
The init=DXM option sends an ATZ command, waits for any response (besides an error response) closed with a prompt sign from the other side and then sends an initialization sequence ATE0, ATL0 and ATOF1 to the DXM. After every command an OK response is expected. This mode is intended for future use.
The nosync and init options are mutual exclusive.
For usage of new command line options baud rate and nosync, see below.
- added maximize command line option
The maximize option maximizes the window with title if the window manager supports that option. Usually, that brings the window width to display width and increases window height keeping aspect ratio in mind.
- added fullscreen command line option
The fullscreen option gives you a window without title that occupies the whole display if the window manager supports that option. However, aspect ratio is lost if you use that option with a background image. If that option is used without background image, the HHEmu display is centered in the display and aspect ratio of the HHEmu display is kept.
- added nocursor command line option
The nocursor option disables the cursor inside the HHEmu window if the window manager supports that option.
- Bugfix: Simulated SPI between HhOpenThread and LcdThread could get out of sync. So that command bytes for the LCD were misinterpreted as data bytes, causing pixel errors or jumping text lines in the simulated LCD (sporadically happened on Pi 2 and frequently on Pi 3).
- Bugfix: Display updates could get lost, if the underlying GUI was not fast enough. Since LcdThread just sends the differences between the active frame buffer and the background frame buffer to the underlying GUI, differences get lost if an update was not done. Changed implementation so that the LcdThread retries the update later if the underlying GUI signals that it is busy.
- Bugfix/Improvement: Before sending AT commands or OBD2 requests via a serial interface (OBD2 software mode and DXM-simulator mode), the Rx/Tx buffers are flushed.
Hardware Options for USB:
- USB via USB menu
This is intended for users who already have the AT90USB162 mounted, programmed and running or are able to do that. This is untested, since I do not have an AT90USB162 installed and I do not have the needed firmware for the AT90USB162. For that purpose, the new USB menu must be entered in the OBD2-Analyser NG. That enables forwarding of 19200 Bd data from the DXM to the AT90USB162 (not interrupt driven, simple bit-bang, from the AT90CAN128's point of view Tx (output) is port D, pin 3, Rx (input) is port D, pin 2). The source code used for the USB menu is derived from the firmware v1.20 that was released by DIAMEX in their forum.
To make the USB menu available in the main menu, enter the settings menu, tick the USB menu checkbox and return to the main menu.
- USB via serial interface menu (see attached images)
For test purposes I connected the Elektor FT232R USB/serial bridge BOB described in the September 2011 issue of the Elektor magazine.
https://www.elektor.de/ft232r-usb-serial-bridge-bob-110553-91
Attention: If you use that BOB, you must solder the jumper on the BOB to the 3,3V option, before using it. So that the serial line drivers work with 3,3V.
Connect BOB Rx to OBD2-Analyser NG expansion port J2 Pin 2 (Port F Pin 1) Tx.
Connect BOB Tx to OBD2-Analyser NG expansion port J2 Pin 3 (Port F Pin 2) Rx.
I urge you to put resistors in the Tx/Rx lines to limit the current, so that a wiring mistake will not fry any ports. In the OBD2-Analyser NG schematics you can see that a 330 Ohm resistor is in the Tx line from DXM to AT90CAN128 to limit the current to 10mA. For lack of 330 Ohm resistors, I use 200 Ohm resistors (I = U/R = 3,3V/200 Ohm = 16,5mA). The AT90CAN128 spec allows 40mA per I/O Pin. According to the FT232R spec, the maximum current for outputs is 24mA.
Connect BOB Ground to OBD2-Analyser NG expansion port J1 Pin 1 Ground (attention: this is expansion port J1 and not J2)
Connect BOB USB to your PC or Raspberry Pi. The driver for the Pi is already installed. If the driver for the PC is not automatically installed you have to download and install one from the FTDI website.
Then start the OBD2-Analyser NG and enter the serial interface menu.
To make the serial interface menu available in the main menu, enter the settings menu, tick the serial interface menu checkbox and return to the main menu.
Then start the HHEmu OBD2-Software with:
PC: hhemu COMx 19200 nosync
Replace x with the correct COM port number on you system.
Raspberry Pi: ./hhemu /dev/ttyUSB0 19200 nosync
If you have several USB devices attached to the Pi, replace 0 with the correct device number on your system.
How to firmly install the BOB in your OBD2-Analyser NG case, so that it actually can be used, is up to you. Hot glueing it to the case cover might work. Do not forget to insulate it, so that nothing is destroyed in case it falls off. I just used a breadboard for proof of concept.
Of course you can connect other communication devices that have serial devices, too. I even wired it to the Pi's serial device (tested with Pi 2 and 3).
Overview BOB, resistors, Analyser and all RX/TX/GND connections (608kb)
RX/TX/GND connections at the Analyser's expansion ports (520kb)
Main menu with new Serial Interface Mode menu item (510kb)
Serial Interface Mode activated (524kb)
HHEmu running on Pi 3 with 3.2" touchscreen (133kb)
HHEmu Mingw32 software (needs runtime libs) (1948kb)
HHEmu Mingw32 GTK3.6.4 runtime libs, part 1 (2424kb)
HHEmu Mingw32 GTK3.6.4 runtime libs, part 2 (4410kb)
HHEmu Raspberry Pi/Raspbian software (1987kb)
OBD2-Analyser NG firmware v1.7.1 (1007kb)
Thomas Beck 8 years ago
Highlights: Ported HHEmu to Raspberry Pi, implemented PID 0x70 (turbo charger boost pressure) for OBD2 service 0x01 and 0x02
Warning:
For this release a lot of crucial internal things have been changed and I could not test the new firmware in a car with more than one OBD2 capable ECU, yet.
In the emulator up to 8 ECUs work without problems, because the simulated DXM data is sent in the order data of ECU 1, then data of ECU 2 and so on.
Real data of several ECUs however might get mixed up in any order. So, there is a slight chance that something goes wrong here. You have been warned ;-)
Changes:
- added support for PID 0x70 (turbo charger boost pressure) in current data and freeze frame data menus (MY2016 Skoda Octavia supports that, but I could not test it, yet)
notes: PID 0x70 is a new PID with 10 bytes of data, that do not fit into a single diagnostic frame. It is probably meant for use with CAN protocols only.
If PID 0x70 works correctly with non-CAN protocols or in the freeze frame menu could not be tested.
The new PIDs incorporate a configuration byte controling the availability of each data item in the PID. If a data item of PID 0x70 is displayed with n/a, the configuration byte indicates, that this data item is not available.
- changed receive buffer management and decoding of DXM frames
The result is, that HHOpen needs several hundred bytes less RAM. Now, messages can be received, that are up to 384 bytes in size, although the size of the first circular rx buffer filled by the rx interrupt is 256 characters only. So, it should be possible to receive 3 CALIDs (service 0x09, infoType 0x04) per ECU and more than 2 ECU names (service 0x09, infoType 0x0A). Well, at least for the firmware. For HHEmu that depends on cpu, cpu load and OS, if reading from the circular rx buffer is fast enough.
- changed OBD2 library to decode only OBD2 CAN protocol format (old lib decoded DXM frames (CAN Frames and non-CAN protocol frames))
For OBD2 non-CAN protocol format a converter is needed.
- implemented CAN frame reassembler, that copies the raw OBD2 data from all DXM frames containing CAN frames to a buffer that directly can be passed to the OBD2 library
- implemented non-CAN frame reassembler/OBD2 non-CAN protocol format to OBD2 CAN protocol format converter, that takes the raw OBD2 data from all DXM frames containing non-CAN protocol frames and converts the data to the OBD2 CAN protocol format that can be passed to the OBD2 library
- changed floating point operations in OBD2 library to not use floating point multiplication and division anymore. dtostrf() function of AVR libc is avoided, also. That saves about 2 kB FlashROM.
- Bugfix: if in total more than 24 DTCs (non-CAN protocols) or more than 26 DTCs (CAN protocols) of a single OBD2 service SID 0x03, 0x07 or 0x0A were active for alle ECUs (HHEmu supports only 16 DTCs of a single OBD2 service SID 0x03, 0x07 or 0x0A per ECU), some frames were discarded, resulting in incorrect display of DTCs.
- Bugfix: if PID 0x10 MAF scaling has been changed by tester configuration PID 0x50, the displayed value for MAF was wrong (655,35 times too big).
- upgraded mingw32 build environment: upgraded pthreads library from version 2.8.0 to 2.9.1
The pthreads library is contained in the gtk364_pthreads_291_runtime_libs_part2.zip archive.
The hhemu_dev.zip archive contains the source code of the emulator and the mingw32 object files of emulator and firmware, in case someone wants to link against newer GTK3+ libraries, when they are available.
DXM-emulator/simulator only changes:
- improved emulator/simulator internal 'v'-command for variable data displayed in current data menu or in any other third party OBD2 software.
If the single current data menu is in display, pressing the 'v'-key starts a sweep over the value range of the currently displayed data item.
Note however, that in some cases it takes very long until the value changes. E.g., if the data item belongs to a PID with 2 data items data A,B and data C,D, in the worst case D changes 65536 times faster than B. This is because the underlying 32 bit value is just incremented +1 every OBD2 request.
DXM-simulator only changes:
- added support for further AT commands and OBD2 data formats, so that the DXM-simulator can be used with the following third party OBD2 software:
moDiag 2.8.601 (DXM)
moDiagUltimate 4.0.1.0 (DXM)
CarPort 2.2.15 (DXM)
ScanTool.net v1.2.1 (ELM/STN and 1 ECU only)
Before any of the above third party OBD2 software tools can be used, HHemu must be started with "HHemu COM2 sim" and the bluetooth menu must be entered.
Replace COM2 with the (virtual) serial port of your choice. However, port number must be less than 10.
In case of ScanTool, one ECU and responding controller ELM or STN must be set. To do that, type "1e1u" or "1e2u" while the HHEmu window is active.
Additionally, a non-CAN protocol must be set as responding protocol. Since PWM is the default, nothing has to be done here.
- set CAN 11-bit CanId/500kbps as default responding protocol for DXM ATP0 command (auto search) and no responding protocol set via HHEmu t-key command.
- Bugfix: the DXM-simulator sent too great (+1) length information in the CAN first frame for some SIDs.
Changes for Raspberry Pi:
- added support for Raspberry Pi/Raspbian OS (Linux)
HHEmu can be run on the Pi now. Beeps are not supported.
For the emulator mode, you just need a Pi with GTK3+ installed.
For the OBD2-Software mode, you additionally need a bluetooth adapter for the Pi, bluetooth software installed on the Pi and an OBD2-Analyser NG with the bluetooth module.
Of course for use in a vehicle, the official 7" touchscreen display for the Pi and a 12V vehicle socket to USB adapter that can power the Pi and the display come in handy.
The software for the Pi, with a brief description how to install it, is in the hhemu_usr_raspberry.zip archive.
The hhemu_dev_raspberry.zip archive contains the Raspberry Pi object files of emulator and firmware, in case someone wants to link against newer GTK3+ libraries, when they are available.
HHEmu Mingw32 user archive, emulator/simulator/OBD2 software (1940kb)
HHEmu developer archive, emulator/simulator source + object files (1040kb)
HHEmu Mingw32 library archive part 1, GTK3+ runtime libraries (2424kb)
HHEmu Mingw32 library archive part 2, GTK3+ runtime libraries (4410kb)
HHEmu Raspbian user archive, emulator/simulator/OBD2 software (1978kb)
HHEmu Raspbian developer archive, emulator/simulator object files (634kb)
HHEmu current data menu displaying new PID 0x70 (507kb)
HHEmu running on Raspberry Pi (143kb)
Thomas Beck 9 years ago
Changes:
- implemented In-use Performance Tracking (IPT) Menu as submenu of the Vehicle/ECU Information Menu (*)
The IPT submenu can be switched between IPT counter list menu and single IPT counter display that includes full IPT counter description.
While the IPT menu is active, IPT counter data is requested every 5s. Since IPT counter data usually changes less than once per ignition cycle, that is more than enough.
- implemented ECU Name screen as submenu of the Vehicle/ECU Information Menu (**)
- changed Vehicle/ECU Information Menu to have several submenus instead of screens that can be switched
The submenus are:
if infoType 0x02 is supported: VIN
if infoType 0x04 is supported: CALIDs
if infoType 0x06 is supported: CVNs
if infoType 0x08 is supported: IPT (*)
if infoType 0x0A is supported: ECU Name (**)
if infoType 0x0B is supported: IPT (*)
if PID 0x13 or 0x1D supported: O2 sensor locations
(*) In theory there are 2 IPT menus: infoType 0x08 for spark ignition and compression ignition engines prior MY2010 and
infoType 0x0B for compression ignition engines for MY2010 and beyond.
InfoTypes 0x08 and 0x0B should be mutual exclusive in a real vehicle, but for HHOpen its nice to have them both for testing.
(**) As written in the description of the firmware update v1.4.0, due to lack of RAM, it is not possible to read the ECU name for more than 2 ECUs in the Read Data Screen.
However, here in the ECU Name submenu just one ECU name is read, since an ECU filter for the currently selected ECU is active.
So, if you have entered that submenu for an ECU and later go to the Change/Select ECU Menu, the ECU name is displayed there, too, even if there are more than 2 OBD2 supporting ECUs in the vehicle.
Note that HHOpen just supports ECUs that support the supported infoTypes mechanism via SID 0x09, infoType 0x00.
For ECUs that do not support that, no submenus that depend on infoTypes will be shown in the Vehicle/ECU Information Menu.
If also PID 0x13 or 0x1D are not supported by an ECU, the Vehicle/ECU Information Menu will not be available for selection in the Diagnostics Menu.
There is a special shortcut to switch between the CALID and CVN submenus, since these numbers usually build pairs like CALID1/CVN1.
In the CALID submenu pressing the down-key switches directly to the CVN submenu.
In the CVN submenu pressing the up-key switches directly to the CALID submenu.
- implemented support for dynamic supported PIDs in Freeze Frame Menu
A vehicle/ECU that supports dynamic supported PIDs can report different supported PIDs for different DTCs/frame numbers.
As a result, the Protocol Info submenu showing the supported PIDs for SID 0x02, will show the supported PIDs that have been read last in the Freeze Frame List Menu.
For frame number 0, the supported PIDs will already be available in the freeze frame select menu. So that static supported PIDs still can be displayed in the Protocol Info submenu for SID 0x02, although no DTC that caused freeze frame storage is active.
Note that a vehicle/ECU supporting dynamic supported PIDs might report just PID 0x02 (DTC that caused freeze frame storage) supported, as long as no DTC that has stored freeze frames is active.
- reworked Current Data Menu and Freeze Frame Menu: if a cursor movement takes place that needs no list scroll, the PID list is no longer affected.
I.e., the OBD scan does not restart with the topmost visible PID, but continues with the current PID.
Of course the benefit for the real LCD that allows a visible list of 3 items only is small, but for HHEmu with a visible list of 7 items that is a nice feature.
- reworked Scan Protocol Screen to free some RAM (in trade for Flash). Furthermore, added missing code to react to some error conditions.
- reworked Read Data Screen to free some Flash
- if no PIDs are supported, a message is displayed in Current Data and Freeze Frame Menus, instead of an empty screen
- reworked list module to support more than 256 list items and more than 8 visible list items (this is for future enhancements, e.g.: bigger LCD or more PIDs with more data items than 256)
- reworked key press handling and implemented standard process key functions to ease implementation of new menus and save some bytes in Flash
As a result many screens can be quit now by pressing the OK-key, at no additional expense of Flash (of course, the ESC-key still works, too).
- Protocol Info submenus can be changed with OK-key (next menu) and ESC-key (previous menu)
- changed I/M Readiness submenu Supported Monitors to display the supported monitor acronym in the header of the single supported monitor screen.
- changed I/M Readiness submenu Monitor Status to display the monitor status acronym in the header of the single monitor status screen.
So, now that is consistent with all other menus that can be switched between list and single data screens.
- reworked menu configuration and handling to ease implementation of new menus. In fact, the menu configuration could be generated by a tool now.
- implemented DXM request handler/request timer shared by all menus for sending AT commands and OBD2 requests to the DXM to ease implementation of new menus and save some bytes in Flash and RAM
- fixed/improved CVN request/response handling in Vehicle ECU/Info Menu for all protocols. It is still not correct for VPWM/PWM and KWP2000 protocols, since the big 30s/60s timers sometimes needed here are very inaccurate, especially in HHEmu (here timers are machine dependent). Since that are outdated protocols, I will not fix that.
If you see the 'Waiting for CVN response...' message, wait until the display either changes to display the received CVN or to the 'no data' message. In case of PWM/VPWM and KWP2000 protocols waiting for a positive response can take up to 1min!
- fixed a bug in the request timer handling.
If the software 100ms timer is set to the minimum of 100ms (like it is done for scanning data in the Current Data Menu), in some cases it expires at once or
much earlier than 100ms. That depends on the 10ms counter being not at 0ms, but at 10ms to 90ms at the time the software 100ms timer is started.
HHEmu only change:
- implemented v-command to toggle between static or dynamic data (variable data) displayed in Current Data menu and IPT menu
Here is an overview of all commands supported by HHEmu:
In HHEmu emulator mode or HHEmu DXM simulator mode keys 0-9 can be used to store an up to 2-digit number in the number memory. The number from the number memory will be used for subsequent commands that need a number as parameter.
Possible commands are:
a - set number of permanent DTCs (CAN-protocols only) for the active ECU, 0-16
b - set number of cylinder banks for PID 0x13, 1-2 (***)
c - set number of cylinder banks for PID 0x1D, 1-4 (***)
d - set number of confirmed DTCs for the active ECU, 0-16
e - set number of responding ECUs, 1-8
m - enable MIL in DXM simulation
n - toggle visibility of number memory
p - set number of pending DTCs for the active ECU, 0-16
t - set responding protocol in DXM simulator or emulator: PWM (1), VPWM (2), ISO 9141-2 (3), KWP2000 5 Baud Init (4), KWP2000 Fast Init (5), CAN 11/500 (6), CAN 29/500 (7), CAN 11/250 (8) and CAN 29/250 (9)
u - set diagnostic interface controller: DXM (0), ELM (1) or STN (2)
v - toggle between fixed current data and IPT data (default) or variable current data and IPT data
x - set negative response code for SID 0x04 (clear DTCs) or SID 0x09, InfoType 0x06 (CVN) either for the active ECU or, if no ECU filter in the current menu is active, for all ECUs.
Possible codes are 10, 11, 12, 21, 22, 78 (value is interpreted as hex). Same code given twice toggles negative response code on/off. If 00 is given, negative response codes are switched off.
y - set No DATA response for next response from DXM
z - set CAN ERROR response for next response from DXM (CAN-protocols only)
q - quit HHEmu
(***) - The standard ISO 15031-5 requires that all ECUs in a vehicle that support the location of oxygen sensors either support PID 0x13 or PID 0x1D, but not both. If you select setting the number of cylinder banks for PID 0x13, the supported PID 0x1D will be cleared automatically for you for all ECUs and vice versa.
Note that for some of the commands to take effect Reload Data must be executed. Further note that some commands only affect the currently active ECU. So, they might have to be issued several times with a change of ECU in between.
GTK+ V3.6.4 runtime libraries (6669kb)
OBD2-Analyser NG firmware V1.6.0 (963kb)
HHEmu V2.60 developer package (2020kb)
HHEmu V2.60 object files (627kb)
Thomas Beck 9 years ago
This is mainly an update for HHEmu. All GUI elements of the firmware have been made dependent on display width and height. So, transition to a new bigger display is fairly easy now.
To show the results, HHEmu V2.50 has been changed to a display heigth of 64 pixels. That allows to display 1 list or menu title and 7 list or menu items at once without scrolling. That is especially useful in the Current Data menu.
Apart from that a minor bug has been fixed in the firmware. If the beep was enabled, it did not stop, when entering the bluetooth menu. There was a race condition between the timer interrupt stopping the beep and the bluetooth menu that disables all interrupts.
Notes:
I decided against the ability to change the HHEmu window size and the simulated LCD would change its display geometry accordingly. I kept the rescaling of the simulated LCD, if the HHEmu window size is changed.
The reason is that I wanted to keep the source code of the firmware and emulator identical and I did not want to slow down the firmware (realtime display geometry calculations make no sense for a fixed size real LCD). It was not my intention to write an OBD software in the first place. I just wanted a good emulator to be able to test the firmware.
Therefore, LCD geometry can be changed in the makefile (DISPLAY_WIDTH and DISPLAY_HEIGHT defines), but not while HHEmu is running.
HHEmu V2.50, firmware V1.5.1, GTK+ user package (1929kb)
GTK+ V3.6.4 runtime libraries (6669kb)
OBD2-Analyser NG firmware V1.5.1 (998kb)
HHEmu V2.50 developer package (2015kb)
HHEmu V2.50 object files (617kb)
Thomas Beck 10 years ago
This update makes an inspection/maintenance readiness menu available in the diagnostics menu.
Changes:
- new dynamic menu item 'I/M Readiness' in the Diagnostics Menu
The menu item is available, if the current ECU supports PID 0x01 (MIL, number of DTCs and monitor status since DTCs cleared).
The I/M Readiness Menu consists of three menu items:
Supported Monitors
Monitor Status
Monitor Settings
The Supported Monitors Menu contains a list of supported OBD monitors reported via PID 0x01. Depending on the type of ignition (spark or compression ignition), the list contains different supported monitors (e.g. MIS_SUP) followed by the support state (yes, no) of the current ECU.
If a monitor is selected, the full description of the monitor is shown (e.g. Misfire monitoring supported: yes/no).
If the 'Show unsupported Monitors' checkbox is not ticked in the Monitor Selection Menu, the list contains only monitors that are actually supported by the current ECU.
The Monitor Status Menu contains a list of monitor statuses reported via PID 0x01 (monitor status since DTCs cleared) and if supported via PID 0x41 (monitor status this driving cycle). The list depends on the settings made in the Monitor Settings Menu and the type of ignition. The list contains monitor statuses (e.g. MIS_RDY/MIS_ENA/MIS_CMPL) followed by the actual state (yes, no, n/a (not applicable)) of the current ECU.
If a status is selected, the full description of the status is shown (e.g. Misfire monitoring ready/enabled/completed: yes/no/ n/a).
If the status filter in the Monitor Settings Menu is set to 'since DTCs cleared' or 'this cycle', the Monitor Status menu item in the I/M Readiness Menu changes to 'Monitor Status (DTC)' or 'Monitor Status (Cycle). Furthermore, the title in the Monitor Status Menu changes to 'MONITOR STATUS (DTC)' or 'MONITOR STATUS (CYC)'. So, the user is made aware of an active filter in every affected menu.
The Monitor Settings Menu contains two or three menu items that enable/disable filters for the supported monitors list and monitor status list:
Show Status [all/since DTCs cleared/this cycle] (dynamic menu item, available only if the current ECU supports PID 0x41 (monitor status this cycle))
Show unsupported Monitors checkbox
Show A/C System Monitor checkbox
With the Show Status menu item it is possible to filter the Monitor Status list, if both PID 0x01 (monitor status since DCTS cleared) and PID0x41 (monitor status this cycle) are supported by an ECU.
If the filter is set to [all] or [since DTCs cleared] the monitor status list also contains the MIL state and the number of DTCs. These might differ from the display in the Diagnostics Menu, that displays the summary state of all ECUs. In the Monitor Status Menu MIL on or off means, that this ECU is commanding the MIL on or off. So, it is possible to see MIL off here, while the Diagnostics Menu says MIL on, if another ECU commands the MIL to be on. The number of DTCs shown in the Monitor Status Menu is the number of confirmed DTCs of the current ECU. If the number is greater than 16, '>16' is displayed, since the analyser does not support more than 16 DTCs per ECU.
If the filter is set to [this cycle] and the ECU is changed to an ECU that does not support PID 0x41, i.e. there is no Show Status [...] menu item in the Monitor Settings Menu, the filter setting is ignored until another or the previous ECU that supports PID 0x41 is selected.
The setting of the Show Status [all/since DTCs cleared/this cycle] is not stored in the EEPROM. If the analyser is powered up, the setting is always [all] = no filtering of the Show Status list is done.
The setting of the Show unsupported Monitors checkbox is stored in the EEPROM. If the box is ticked, all possible monitors relevant for the type of ignition are shown in the Supported Monitors Menu and in the Monitor Status Menu.
The setting of the Show A/C System Monitor checkbox is stored in the EEPROM. If the box is ticked, the A/C system refrigerant monitor (*) is shown in the Supported Monitor Menu and in the Monitor Status Menu. However, if the monitor is unsupported and the Show unsupported Monitors checkbox is not ticked, the monitor is not shown.
(*) The A/C system refrigerant monitor is a special case. In old versions of the specification ISO 15031-5 this was a required monitor to check for leaks in the A/C system, if a vehicle's A/C system was working with the R-12 refrigerant. After the ban of R-12 for new vehicles due to environmental reasons the monitor was no longer needed and was removed from the specification.
Further details regarding OBD monitors can be read in the ISO 15031-5 specification or its SAE counterpart J1979.
For the US further details regarding I/M readiness can be found here http://www.epa.gov/obd/regtech/inspection.htm
notes:
While the I/M Readiness Menu or any of its submenus is active, the analyser permanently requests PID 0x01 and if supported PID 0x41, to be able to provide accurate status data in the Monitor Status Menu.
However, this can lead to inconsistent DTC states displayed in the Diagnostics Menu and the DTC menus, if returning to these menus. These menus need Reload OBD Data be executed to display consistent states.
Example: Diagnostic Menu displays MIL off and no DTCs. While the I/M Readiness Menu is active an error occurs in the active ECU. The Monitor Status Menu shows MIL on and 1 DTC. If you return to the Diagnostics Menu, the state will show MIL on and 0 DTCs. The DTC Summary Menu will show 'no trouble codes'. Only if you select Reload OBD Data the DTC state will be updated here, too.
In a real vehicle clearing diagnostic fault data in the Trouble Codes Menu also clears the readiness/completion status of the OBD monitors in the Monitor Status Menu. This behaviour has not been implemented in HHEmu.
- improved automatic selection of ECU
After trying the analyser in a diesel with two ECUs supporting OBD2, I wondered why the TCM (transmission ECU) was selected first.
So, to determine the first ECU that will be selected the following strategy is applied now:
The ECU table (built according to the responding ECUs) is searched first for ECUs supporting PID 0x13 or 0x1D (location of oxygen sensors (spark ignition engines)).
The first ECU found, is set to be the first active ECU. Usually that is an engine ECU.
If no such ECU is found (compression ignition engine, electric motor), the ECU table is searched for the ECU that supports the most OBD data items (each supported PID contains one or several data items).
The ECU that supports the most data items is set to be the first active ECU. At least for compression ignitions engines that usually is an engine ECU.
- improved processing of OBD responses containing CALIDs and CVNs for Vehicle/Ecu Info Menu
If more than 3 CALIDs or CVNs are reported by an ECU, only the first 3 are processed. However for non-CAN protocols, due to insufficient receive buffer size 3 CALIDs still cannot be received by the analyser, yet.
At the moment the change has no visible effect. Due to insufficient receive buffer size 4 or more CALIDs cannot be received by the analyser, anyway.
For installation and further details see the contribution describing the firmware v1.4.0:
http://www.elektor-labs.com/contribution/hhemu-v230-obd2-analyser-ng-firmware-v140.14016.html
GTK+ V3.6.4 runtime libraries (6669kb)
OBD2-Analyser NG firmware V1.5.0 (997kb)
HHEmu V2.40 developer package (2014kb)
HHEmu V2.40 object files (616kb)
Thomas Beck 10 years ago
This is an update to significantly speed up OBD data display in the Current Data Menu and in the Freeze Frame Menu. Furthermore, for HHEmu users it is an update that significantly reduces CPU load in the emulator and OBD2 software mode (not in the DXM simulator mode, though). So, I highly recommend updating.
Changes:
- fixed a bug in the Read Data Screen. There was a buffer overflow in the text under the progress bar.
- fixed a bug in the Read Data Screen, if coming from the Clear DTC Menu or from Reload OBD Data the ESC button could be pressed (short press) while the Read Data Screen was active. That led to a jump to the Select Protocol Menu.
If in the Diagnostics Menu, there should be no other way to go back to the upper menus than a reset (ESC button long press).
- fixed a bug in the Current Data Menu and Freeze Frame Menu. If at the end of the PID list, and scrolling one position up, the list update did not update the first line at once. However, it was updated in the second and all further loops.
- improved LCD update. Display updates after key press events and OBD data received events are much faster now. Furthermore, if nothing has been drawn into the display buffer since the last update, no update is done at all.
- changed behaviour of the 'Read Indicator' (the little bullet in front of a PID) in the Current Data Menu and in the Freeze Frame Menu. The indicator shows the PID(s) to be read next (before any request is sent).
Doing the update in the 100ms timer event function of the menu, was actually the main reason for the V1.4.0 and V1.4.1 firmware being so slow in these menus. There, the indicator showed the PID(s) that have been requested in the timer event function.
Now the update of the Read Indicator is done when changing the list and in the OBD data received event function.
- reworked TIMER2_COMP interrupt service routine to gain a few clock cycles (details affecting the contact bounce suppression routine are here http://www.mikrocontroller.net/topic/48465#3714661 and here http://www.mikrocontroller.net/topic/48465#3722345 (both in German only). The beep routine was reworked in the same way.)
- added cli()/sei() calls missing in the original firmware, when accessing volatile variables outside of the TIMER2_COMP interrupt service routine non-atomically.
- added a 1ms delay in the main loop if no DXM Rx data transfer is active.
In the real firmware that is not noticeably at all, due to the Rx data transfer being done in an interrupt. However, in the emulator and OBD2 software mode the little pause in the main loop makes a big difference in CPU load.
The DXM simulator mode is unaffected, since in the active Bluetooth Menu another loop is running at full speed to copy single bits between the simulated Bluetooth I/O pins and the simulated DXM I/O pins.
- when running two HHEmus in parallel, one in DXM simulator mode and one in OBD2 software mode, it is not so obvious which one is the simulator for connecting them.
I changed the string 'HHEmu Vx.xx' in the System Information Menu for the simulator mode. In DXM simulator mode it displays 'HHSim Vx.xx'.
So, before entering the Bluetooth Menu to actually start the DXM simulator mode, the System Information Menu can be entered to check that this actually is the HHEmu running as DXM simulator.
The HHEmu running in OBD2 software mode displays an empty System Information Menu before the Bluetooth Menu is entered in the HHEmu running in DXM simulator mode.
- changed the beep sounds.
Actually there was a bug in HHEmu that the OCR3A register value was taken as beep frequency, instead of using the formula from the AT90CAN128 specification for phase and frequency correct PWM.
PWM frequency = f_clk_IO / (2 * prescaler * TOP)
with
f_clk_IO = F_CPU define from makefile (8 MHz)
prescaler = 1
TOP = OCR3A register value
the formula is frequency = 8000000/(2 * OCR3A).
However, since I like the 'false' HHEmu beeps more than the OBD2-Analyser NG beeps, I changed the analyser beeps to sound like the HHEmu beeps ;)
- further optimizations done to reduce code size and improve speed
For installation and further details see the contribution describing the firmware v1.4.0:
http://www.elektor-labs.com/contribution/hhemu-v230-obd2-analyser-ng-firmware-v140.14016.html
GTK+ V3.6.4 runtime libraries (6669kb)
OBD2-Analyser NG firmware V1.4.2 (988kb)
HHEmu V2.32 developer package (2012kb)
HHEmu V2.32 object files (606kb)
Thomas Beck 10 years ago
Yet another update: OBD-Analyser NG / Handheld Open firmware V1.4.1 and Handheld Open Emulator (and OBD software for OBD-Analyser NGs with Bluetooth) HHEmu V2.31.
This fixes a bug with the key bytes of the keyword protocols ISO 14230-4 (KWP2000) and ISO 9141-2. The DXM simulator of HHEmu V2.30 sends the two key bytes in the simulated DXM ATK command response without a space in between. The real DXM sends the key bytes with a space. The simulator has been changed accordingly.
The result was, that firmware V1.4.0 and HHEmu V2.30 in OBD software mode displayed wrong values for the key byte 1 (low byte). Since key byte 1 is crucial for detecting the correct header size, cars designed after the Swedish Implementation Standard SSF 14230-2 (KWP2000 with 4 byte header instead of the 3 byte header defined in ISO 15031-4) did not work with the OBD2-Analyser NG.
Further changes:
- all menus that have not been rewritten so far (see previous contribution), have been changed to use the new menu, list, gui and text modules.
That means, in one of the next releases the display/window size can be changed and the window will not just scale, but more list lines than the current 3 will be displayed at once (HHEmu only). Of course that also greatly helps to use a bigger LC display with the OBD2-Analyser NG or a newly designed analyser in a later step.
Furthermore, since all texts have been moved into separate text modules (one for OBD2 relevant texts, one for all HHOpen relevant texts), it is possible now to provide support for other menu languages than English. Contact me, if you are interested to provide support for your language. Apart from the obvious translation of all texts you might have to change or provide new fonts for your language, also. A font editor/generator can be found in the old firmware release V1.3.0.
- the Change ECU menu item of the Diagnostics Menu has been changed to be a dynamic one
If your car features only 1 OBD2 capable ECU, the menu item Change ECU is not displayed.
- execution of Reload OBD2 Data or Clear DTCs no longer changes the active ECU. The active ECU is kept, if it responds.
Of course that feature is available only in vehicles with 2 or more OBD2 capable ECUs.
- new menu item Save Last Protocol (to EEPROM) in System Settings Menu
- the protocol selected by the user in the Select Protocol Menu is moved to the beginning of the list, if that feature is enabled in the System Settings Menu
- sequence of protocols in Select Protocol Menu has been changed
Since CAN is the only allowed protocol for newly designed cars since 2008 (mere facelifts of pre 2008 cars do not count as newly designed cars), the list starts with the CAN protocols now and antique PWM/VPWM protocols have been moved to the end of the list.
However, if you select automatic protocol scan, the scan still starts with PWM, VPWM, ... since that is the recommended sequence in ISO 15031-4.
The numbering of protocols displayed in the top right corner of the Diagnostics Menu has not been changed, since that is the numbering used by the DXM command ATPx (x = 0..9).
- KWP2000 fast init and 5 Baud init can be selected separately as protocol now
In previous releases just KWP2000 could be selected, that internally tried both protocol variants.
- a few functions have been inlined, replaced by a macro, reduced in number of parameters or rewritten to use precalculated values to slightly increase the scan speed in the Current Data Menu and in the Freeze Frame Menu
If you do not notice any difference, ECU response time might be the limiting factor in your vehicle.
- the 't'-command of HHEmu (set responding protocol) has been improved to not just work in the simulator mode, but also in emulator mode (see previous contribution)
For installation and further details see the previous contribution:
http://www.elektor-labs.com/contribution/hhemu-v230-obd2-analyser-ng-firmware-v140.14016.html
GTK+ V3.6.4 Runtime Libraries (6669kb)
OBD2-Analyser NG Firmware V1.4.1 (989kb)
HHEmu V2.31 developer package (2014kb)
HHEmu V2.31 object files (609kb)
Thomas Beck 10 years ago
HHEmu V2.30 is built against the now officially available GTK+ V3.6.4 libraries (from http://www.gtk.org/download/win32.php) that are included.
I have upgraded my build environment from WinAVR 20100110 to avr-gcc 4.8.0, avr-libc 1.8.0, binutils 2.23.52 to be able to use __flash address space that was introduced in avr-gcc 4.7.0 (to get rid of the pgm_read_byte/word() routines to access FLASH data).
I still have not converted all pgm_ accesses to __flash, but I fixed the texts of the experimental hex-file of the previous contribution, that did not display correctly.
Apart from the usual bugfixes, the following things have been added or have been changed compared to the previous firmware V1.3.0 release:
- CAN error retry handling has been implemented for the OBD requests in the read data screen, current data menu, freeze frame data menu and vehicle/ECU info menu.
I have seen a few vehicles that the analyser has great troubles to display stable data in the current data menu. The reason is the DXM, that sends the CAN ERROR response to the AT90CAN128 where the firmware runs. The firmware V1.3.0 and earlier displays the 'no data' string, then. So, the displayed value changes between a real data value and 'no data'. In some cases that happens so often, that the shortly displayed data value cannot be read. In other cases it is at least annoying.
I have no CAN analyser to analyse the real cause. It is definitly not a problem of the physical connection to the CAN bus as the DXM documentation claims. I suppose a problem with CAN bus congestion. Too many messages on the bus and the DXM cannot send the OBD request. If the DXM would not receive an OBD response in time, the answer to the AT90CAN128 would be NO DATA and not CAN ERROR.
The retry handling ensures that the OBD request is retried as long as CAN ERROR is received. In the current data menu you can see that, if the 'read indicator'-dot/bullet in front of the currently read PID stops at a PID for a longer time than usual.
- Improved vehicle/ECU info menu.
First menu page shows ECU short and long name, if SID 0x09, InfoType 0x0A is supported, followed by the VIN, if SID 0x09, InfoType 0x02 is supported.
There are restrictions due to receive buffer size, that only 2 ECU names can be received completely. So, if more than 2 ECUs support ECU name, no ECU name is displayed in that menu.
Second Menu page shows location of up to 8 oxygen sensors, if SID 0x01, PID 0x13 or PID 0x1D is supported
Third menu page shows up to 3 CALIDs, if SID 0x09, InfoType 0x04 is supported. Note, that in case of non-CAN protocols a third CALID might be cut off at the end or display random data (last char) due to limited receive buffer size.
Fourth menu page shows up to 3 CVNs, if SID 0x09, InfoType 0x06 is supported.
Error handling for InfoType 0x06 (CVN) according to SAE J1979 / ISO 15031-5 has been implemented, in case that negative responses have been received. Possible negative responses might be 'Request correctly received - response pending' or 'Conditions not correct'.
If the negative response / no response handling actually works in a real vehicle could not be tested.
- Changed fonts, so that all ASCII characters required by the standard SAE J1979 / ISO 15031-5 for InfoType 0x06 (CVN) are available.
- Improved select ECU menu.
If SID 0x09, InfoType 0x0A is supported, the ECU long name is displayed in the list of ECUs.
There are restrictions due to receive buffer size, that only 2 ECU names can be received completely. So, if more than 2 ECUs support ECU name, no ECU names are displayed.
- support for 8 OBD2 ECUs added
The receive buffers (DXM receive buffer and DXM frame buffer) have been increased from 128 to 256 bytes. That is enough to store the 16 DXM frames (12 bytes each) the original HHOpen firmware supports.
But beware, in case of many ECUs with many DTCs or many ECUs that support InfoType ECU Name, the receive buffer is still to small. In that case additional bytes/frames are discarded.
In case of ECU name, if more than 2 ECUs support SID 0x09, InfoType 0x0A, no ECU name is read at all.
- support for all supported PID masks PIDs (0x00, 0x20, 0x40, ..., 0xC0, 0xE0) has been added in Reading Data Menu
- support for the following new PIDs has been added in the Current Data Menu:
PID 0x42: Control module voltage
PID 0x43: Absolute load value
PID 0x44: Commanded equivalence ratio
PID 0x45: Relative throttle position
PID 0x46: Ambient air temperature
PID 0x47: Absolute throttle position B
PID 0x48: Absolute throttle position C
PID 0x49: Accelerator pedal position D
PID 0x4A: Accelerator pedal position E
PID 0x4B: Accelerator pedal position F
PID 0x4C: Commanded throttle actuator control
PID 0x4D: Time run by the engine while MIL is activated
PID 0x4E: Engine run time since DTCs cleared
PID 0x51: Fuel type currently used (*)
PID 0x52: Alcohol fuel percentage (*)
PID 0x53: Absolute EVAP system vapor pressure (*)
PID 0x54: EVAP system vapor pressure (*)
PID 0x55: Short term secondary oxygen sensor fuel trim - bank 1/3
PID 0x56: Long term secondary oxygen sensor fuel trim - bank 1/3
PID 0x57: Short term secondary oxygen sensor fuel trim - bank 2/4
PID 0x58: Long term secondary oxygen sensor fuel trim - bank 2/4
PID 0x59: Fuel rail pressure (absolute) (*)
PID 0x5A: Relative accelerator pedal position (*)
PID 0x5B: Hybrid/EV battery pack remaining charge (*)
PID 0x5C: Engine oil temperature (*)
PID 0x5D: Fuel injection timing (*) (**)
PID 0x5E: Engine fuel rate (*) (**)
PID 0x5F: Emission requirements to which vehicle is designed (*)
PID 0x8D: Absolute throttle position G (*)
(*) These PIDs are not supported in HHEmu V2.20, but are supported now in HHEmu V2.30. These PIDs have not been tested in OBD2 software mode in a vehicle, yet.
(**) Short texts of these PIDs are too big and are cut off at the right, so that the display is not corrupted.
- support for PID 0x13 or 0x1D (location of oxygen sensors) added
PID 0x13 or 0x1D are read in Reading Data Menu for all ECUs that support them.
PID 0x13 or 0x1D are displayed in Vehicle/ECU Info Menu and are evaluated in Current Data Menu.
So, data byte B of PIDs 0x06-0x09 and 0x56-0x59 (short fuel trim and long fuel trim for banks 3 and 4) is only evaluated and displayed in the Current Data Menu, if 0x1D indicates the presence of oxygen sensors for that banks. So, PIDs 0x06-0x09 do no longer display non-existent data.
Furthermore, the evaluation of PID 0x13 and 0x1D allows displaying correct indices for bank/sensor of the oxgen sensor PIDs 0x14-0x1B, 0x24-0x2B and 0x34-0x3B. In the old firmware wrong indices were displayed for engines with 3 or 4 banks or for engines with more than 1 bank if PID 0x1D was used by the vehicle to report the location of oxygen sensors.
- support for PID 0x4F (OBD tester configuration #1) added
PID 0x4F is read in Reading Data Menu for all ECUs that support that PID.
PID 0x4F is evaluated in Current Data Menu. If data bytes of PID 0x4F contain values != 0, these values are used as new maximum values for PIDs 0x09, 0x24-0x2B, 0x34-0x3B or 0x44.
- support for PID 0x50 (OBD tester configuration #2) added
PID 0x50 is read in Reading Data Menu for all ECUs that support that PID.
PID 0x50 is evaluated in Current Data Menu. If data byte A of PID 0x50 contains a value != 0, that value is used as new maximum value for PID 0x10.
- SID 0x04 (clear DTCs) responses evaluated for protocols that support negative responses. No response is detected also. The first 3 ECUs with negative/no responses are displayed.
That provides feedback whether clearing diagnostic fault data actually has succeeded completely, partially or not at all.
If the negative response / no response handling actually works in a real vehicle could not be tested.
- support for SID 0x0A (permanent DTCs, CAN-only SID, phased-in on MY2010-12 vehicles) added
Permanent DTCs cannot be cleared by diagnostic testers. These DTCs are automatically cleared by the OBD system if the failure is no longer present.
SID 0x0A is read in Reading Data Menu.
The number behind 'DTC:' in Diagnostics Main Menu and Trouble Codes Menu now shows the number of confirmed DTCs + pending DTCs + permanent DTCs.
In the DTC Summary Menu permanent DTCs are followed by the string 'permanent'.
- Improved reading of current data and freeze frame data.
If several data items in the display are coming from the same PID, that PID is just read once.
That is a must for the current data PIDs, e.g. the oxygen sensor PIDs, those data pairs (voltage/lambda, current/lambda, ...) are correlated then.
The state machine for reading of current data has been improved to avoid unnecessary 'No data' messages. Scrolling the current data list no longer can flood the display with 'No data' messages. However, if the DXM actually reports NO DATA, that still leads to the display of 'No data' of course.
- Improved protocol info menu.
First menu page shows protocol info. In case of the keyword protocols, the meaning of the keyword (P2min time and header size) is displayed.
Second menu page shows supported PID masks of supported PIDs 0x00, 0x20, 0x40, ..., 0x0A for SID 0x01 (Current Data).
Third menu page shows supported PID masks of supported PIDs 0x00, 0x20, 0x40, ..., 0x0A for SID 0x02 (Freeze Frame Data). The Freeze Frame Menu must be entered first for the currently selected ECU to show correct data, otherwise all supported PID masks show 0x00.
Fourth page shows supported infoTypes 0x00 for SID 0x09 (Vehicle/ECU Info).
- Current Data Menu no longer sets all supported PID masks to 0xFF (all PIDs supported), if no PID is supported at all. So, in case your (old) vehicle does not correctly support supported PID masks, the Current Data Menu will stay empty.
This will be fixed in a later release by means of a new menu that allows individual configuration of the PIDs/data items shown in the Current Data Menu.
- HHEmu in DXM-simulator mode now supports the open source OBD2 software ScanTool.net v1.21 (http://www.scantool.net/downloads/diagnostic-software/). So, it actually is working as an ELM-simulator or STN-simulator then.
To use that feature you need the e, t and u command keys described further down (set e=1, t!=0, u!=0 before entering the Bluetooth Menu in HHEmu DXM simulator mode).
- massive internal changes to make the code more maintenance friendly
OBD2 data decoding and OBD2 texts moved into new modules that later will be released as OBD2 library. Current Status: All SIDs/PIDs/InfoTypes used by the firmware V1.4.0 are supported.
Menu texts of rewritten menus moved to a single separate TXT module to be able to support other menu languages later.
MEN module to handle menu enter/cancel events.
GUI module to hide the LCD and Font routines from the menu code to support bigger LC display sizes/window sizes later.
List module to handle lists with more than 3 entries to support bigger LC display sizes/window sizes later. HHOpen menus that already have been rewritten to use the new list module support fast scrolling now. So, long pressing the up/down buttons in these menus leads to a page scroll now.
The following menus have been rewritten so far:
Current Data Menu
DTC Summary Menu
Clear DTC Data Menu
Freeze Frame Menu
Vehicle/ECU Info Menu
Protocol Info Menu
Select ECU Menu
Reading Data Menu
Bluetooth Menu
System Info Menu
Note: All that error/retry handling and the software layering with larger call stack takes its toll in an embedded project. While you will not notice any difference between HHEmu with firmware V1.3.0 or firmware V1.4.0 running on a PC, the firmware V1.4.0 runs noticeably slower in the real OBD2-Analyser NG. You can see that in the current data menu, where the data update rate has decreased, although the desired programmed update rate of function runtime + 100ms has not been changed.
I plan to improve the data update rate in a later release. Either by e.g. function inlining, that will increase memory consumption, or by simply decreasing the programmed data update rate.
Installation:
Firmware V1.4.0:
The _hhopen.hex file from the HandheldOpen_140.zip archive must be flashed into the OBD2-Analyser NG.
The update procedure is shortly described in the article about the bluetooth extension for the OBD2-Analyser NG in the Elektor magazine April 2010.
HHEmu V2.30:
Unpack the hhemu_usr_gtk364_firmware_140.zip archive to whatever path you want.
Unpack the gtk364_runtime_libs.zip to <your selected path>\hhemu_usr\gtk.
The hhemu_dev.zip file containing the HHEmu V2.30 source code is not compatible with the previous HHOpen firmware V1.3.0 source code (HandheldOpen_130.zip). As long as no new firmware source code is released, I have provided object files in objectfiles.zip in case someone wants to link against newer GTK+ libraries when they are available.
Usage:
To use HHEmu with your OBD2-Analyser NG, start a cmd.exe console window, change to the path where you have installed the release and the GTK+ runtime libs (e.g. D:\hhemu_usr\gtk) and in the console type:
hhemu COMx
x is the number of the COM-port used by the Bluetooth adapter on your PC to communicate with the OBD2-Analyser NG. In the current implementation x must be less than 10.
Typing hhemu --help shows additional info.
For using HHEmu in emulator mode, the program can be started by double-clicking the program icon with the mouse.
HHEmu can be controlled by the mouse by clicking the OBD2-Analyser NG buttons, if the background picture HHOpenBackgroundPic.png that shows the 4 OBD2-Analyser NG buttons is found on program startup.
Additionally, HHEmu can be controlled by the cursor keys or the h,j,k,l-keys, that are mapped to the Up/Down/Ok/ESC-buttons.
Furthermore, in HHEmu emulator mode or HHEmu DXM simulator mode keys 0-9 can be used to store an up to 2-digit number in the number memory. The number from the number memory will be used for subsequent commands that need a number as parameter.
Possible commands are:
a - set number of permanent DTCs (CAN-protocols only) for the active ECU, 0-16
b - set number of cylinder banks for PID 0x13, 1-2 (*)
c - set number of cylinder banks for PID 0x1D, 1-4 (*)
d - set number of confirmed DTCs for the active ECU, 0-16
e - set number of responding ECUs, 1-8
m - toggle MIL
n - toggle visibility of number memory
p - set number of pending DTCs for the active ECU, 0-16
t - set responding protocol in DXM simulator mode: PWM (1), VPWM (2), ISO 9141-2 (3), KWP2000 5 Baud Init (4), KWP2000 Fast Init (5), CAN 11/500 (6), CAN 29/500 (7), CAN 11/250 (8) and CAN 29/250 (9)
u - set diagnostic interface controller: DXM (0), ELM (1) or STN (2)
x - set negative response code for SID 0x04 (clear DTCs) or SID 0x09, InfoType 0x06 (CVN) either for the active ECU or, if no ECU filter in the current menu is active, for all ECUs.
Possible codes are 10, 11, 12, 21, 22, 78 (value is interpreted as hex). Same code given twice toggles negative response code on/off. If 00 is given, negative response codes are switched off.
y - set No DATA response for next response from DXM
z - set CAN ERROR response for next response from DXM
q - quit HHEmu
(*) - The standard ISO 15031-5 requires that all ECUs in a vehicle that support the location of oxygen sensors either support PID 0x13 or PID 0x1D, but not both. If you select setting the number of cylinder banks for PID 0x13, the supported PID 0x1D will be cleared automatically for you for all ECUs and vice versa.
Note that for some of the commands to take effect Reload Data must be executed. Further note that some commands only affect the currently active ECU. So, they might have to be issued several times with a change of ECU in between.
HHEmu V2.30, firmware V1.4.0, GTK+ user package (1918kb)
GTK+ V3.6.4 Runtime Libraries (6669kb)
HHEmu V2.30 developer package (2006kb)
HHEmu V2.30 object files (603kb)
Thomas Beck 10 years ago
Here you find an experimental version of the Handheld Open Emulator HHEmu V2.20 that is built against the now officially available GTK+ V3.6.4 libraries (from http://www.gtk.org/download/win32.php) that are included. Furthermore, HHEmu is built against the current version of the upcoming firmware V1.4.0.
This release is intended to be used as OBD2 software. So, it can be used only if your OBD2-Analyser NG is equipped with the optional Bluetooth module.
If your OBD2-Analyser NG is not equipped with the optional Bluetooth module, you either can use it in the emulator mode to see what is coming in the next firmware release, or you can try the experimental firmware hex-file V1.4.0 that is included in the archive HandheldOpen_experimental_140.zip.
I have upgraded my build environment from WinAVR 20100110 to avr-gcc 4.8.0, avr-libc 1.8.0, binutils 2.23.52 to be able to use __flash address space that was introduced in avr-gcc 4.7.0 (to get rid of the pgm_read_byte/word() routines to access FLASH data).
I did not have the time yet to convert all pgm_ accesses to __flash and did not test the hex-output of avr-gcc with my OBD2-Analyser NG, yet. So, I do not know if the experimental firmware hex-file functions correctly. You have been warned :-)
The following things have been added or have been changed compared to the previous HHEmu V2.10 / firmware V1.3.0 release:
- support for 8 OBD2 ECUs added
The receive buffers (DXM receive buffer and DXM frame buffer) have been increased from 128 to 256 bytes. That is enough to store the 16 DXM frames (12 bytes each) the original HHOpen firmware supports.
But beware, if in the unlikely case that all ECUs have many stored DTCs, the receive buffer might still be too small, and as a result the program might crash.
- support for all supported PID masks PIDs (0x00, 0x20, 0x40, ..., 0xC0, 0xE0) has been added in Reading Data Menu
- support for the following new PIDs has been added in the Current Data Menu:
PID 0x42: Control module voltage
PID 0x43: Absolute load value
PID 0x44: Commanded equivalence ratio
PID 0x45: Relative throttle position
PID 0x46: Ambient air temperature
PID 0x47: Absolute throttle position B
PID 0x48: Absolute throttle position C
PID 0x49: Accelerator pedal position D
PID 0x4A: Accelerator pedal position E
PID 0x4B: Accelerator pedal position F
PID 0x4C: Commanded throttle actuator control
PID 0x4D: Time run by the engine while MIL is activated
PID 0x4E: Engine run time since DTCs cleared
PID 0x51: Fuel type currently used (*)
PID 0x52: Alcohol fuel percentage (*)
PID 0x53: Absolute EVAP system vapor pressure (*)
PID 0x54: EVAP system vapor pressure (*)
PID 0x55: Short term secondary oxygen sensor fuel trim - bank 1/3
PID 0x56: Long term secondary oxygen sensor fuel trim - bank 1/3
PID 0x57: Short term secondary oxygen sensor fuel trim - bank 2/4
PID 0x58: Long term secondary oxygen sensor fuel trim - bank 2/4
PID 0x59: Fuel rail pressure (absolute) (*)
PID 0x5A: Relative accelerator pedal position (*)
PID 0x5B: Hybrid/EV battery pack remaining charge (*)
PID 0x5C: Engine oil temperature (*)
PID 0x5D: Fuel injection timing (*) (**)
PID 0x5E: Engine fuel rate (*) (**)
PID 0x5F: Emission requirements to which vehicle is designed (*)
PID 0x8D: Absolute throttle position G (*)
(*) These PIDs are not supported in the emulator and simulator modes, yet. Besides PID 0x56 these PIDs have not been tested in OBD2 software mode in a vehicle, yet.
(**) Short texts of these PIDs are too big and might corrupt the display or are not displayed at all
- support for PID 0x13 or 0x1D (location of oxygen sensors) added
PID 0x13 or 0x1D are read in Reading Data Menu for all ECUs that support them.
PID 0x13 or 0x1D are evaluated in Current Data Menu.
So, data byte B of PIDs 0x06-0x09 and 0x56-0x59 (short fuel trim and long fuel trim for banks 3 and 4) is only evaluated and displayed in the Current Data Menu, if 0x1D indicates the presence of oxygen sensors for that banks. So, PIDs 0x06-0x09 do no longer display non-existent data.
Furthermore, the evaluation of PID 0x13 and 0x1D allows displaying correct indices for bank/sensor of the oxgen sensor PIDs 0x14-0x1B, 0x24-0x2B and 0x34-0x3B. In the old firmware wrong indices were displayed for engines with 3 or 4 banks or for engines with more than 1 bank if PID 0x1D was used by the vehicle to report the location of oxygen sensors.
- support for PID 0x4F (OBD tester configuration #1) added
PID 0x4F is read in Reading Data Menu for all ECUs that support that PID.
PID 0x4F is evaluated in Current Data Menu. If data bytes of PID 0x4F contain values != 0, these values are used as new maximum values for PIDs 0x09, 0x24-0x2B, 0x34-0x3B or 0x44.
- support for PID 0x50 (OBD tester configuration #2) added
PID 0x50 is read in Reading Data Menu for all ECUs that support that PID.
PID 0x50 is evaluated in Current Data Menu. If data byte A of PID 0x50 contains a value != 0, that value is used as new maximum value for PID 0x10.
- SID 0x04 (clear DTCs) responses evaluated for protocols that support negative responses. No response is detected also. The first 3 ECUs with negative/no responses are displayed.
That provides feedback whether clearing diagnostic fault data actually has succeeded completely, partially or not at all.
- support for SID 0x0A (permanent DTCs, CAN-only SID, phased-in on MY2010-12 vehicles) added
Permanent DTCs cannot be cleared by diagnostic testers. These DTCs are automatically cleared by the OBD system if the failure is no longer present.
SID 0x0A is read in Reading Data Menu.
The number behind 'DTC:' in Diagnostics Main Menu and Trouble Codes Menu now shows the number of confirmed DTCs + pending DTCs + permanent DTCs.
In the DTC Summary Menu permanent DTCs are followed by the string 'permanent'.
- Improved reading of current data and freeze frame data.
If several data items in the display are coming from the same PID, that PID is just read once.
That is a must for the current data PIDs, e.g. the oxygen sensor PIDs, those data pairs (voltage/lambda, current/lambda, ...) are correlated then.
The state machine for reading of current data has been improved to avoid unnecessary 'No data' messages (scrolling the current data list no longer can flood the display with 'No data' messages, but corrupt received data still leads to the display of 'No data' of course).
- Improved protocol info menu.
First menu page shows protocol info. In case of the keyword protocols, the meaning of the keyword (P2min time and header size) is displayed.
Second menu page shows supported PID masks of supported PIDs 0x00, 0x20, 0x40, ..., 0x0A for SID 0x01 (Current Data).
Third menu page shows supported PID masks of supported PIDs 0x00, 0x20, 0x40, ..., 0x0A for SID 0x02 (Freeze Frame Data). The Freeze Frame Menu must be entered first to show correct data, otherwise all supported PID masks show 0x00.
Fourth page shows supported infoTypes 0x00 for SID 0x09 (Vehicle/ECU Info).
- Current Data Menu no longer sets all supported PID masks to 0xFF (all PIDs supported), if no PID is supported at all. So, in case your (old) vehicle does not correctly support supported PID masks, the Current Data Menu will stay empty.
This will be fixed in a later release by means of a new menu that allows individual configuration of the PIDs/data items shown in the Current Data Menu.
- HHEmu in DXM-simulator mode now supports the open source OBD2 software ScanTool.net v1.21 (http://www.scantool.net/downloads/diagnostic-software/). So, it actually is working as an ELM-simulator or STN-simulator then.
To use that feature you need the e, t and u command keys described further down (set e=1, t!=0, u!=0 before entering the Bluetooth Menu in HHEmu DXM simulator mode).
- massive internal changes to make the code more maintenance friendly
OBD2 data decoding and OBD2 texts moved into new modules that later will be released as OBD2 library. Current Status: OBD2 lib lacks SID 0x09 support for infoTypes other than 0x00. All other SIDs/PIDs/InfoTypes of the firmware V1.3.0 are supported.
Menu texts moved to a single separate TXT module to be able to support other menu languages later.
MEN module to handle menu enter/cancel events.
GUI module to hide the LCD and Font routines from the menu code to support bigger LC display sizes/window sizes later.
List module to handle lists with more than 3 entries to support bigger LC display sizes/window sizes later. HHOpen menus that already have been rewritten to use the new list module support fast scrolling now. So, long pressing the up/down buttons in these menus leads to a page scroll now.
The following menus have been rewritten so far:
Current Data Menu
DTC Summary Menu
Clear DTC Data Menu
Freeze Frame Menu
Protocol Info Menu
Select ECU Menu
Reading Data Menu
Bluetooth Menu
System Info Menu
Installation:
Unpack the hhemu_usr_gtk364_firmware_140_prerelease.zip archive to whatever path you want.
Unpack the gtk364_runtime_libs.zip to <your selected path>\hhemu_usr\gtk.
The hhemu_dev.zip file containing the HHEmu V2.20 source code is not compatible with the HHOpen firmware V1.3.0 source code (HandheldOpen_130.zip). As long as no new firmware is released, I have provided object files in objectfiles.zip in case someone wants to link against newer GTK+ libraries when they are available.
Usage:
To use HHEmu with your OBD2-Analyser NG, start a cmd.exe console window, change to the path where you have installed the prerelease and the GTK+ runtime libs (e.g. D:\hhemu_usr\gtk) and in the console type:
hhemu COMx
x is the number of the COM-port used by the Bluetooth adapter on your PC to communicate with the OBD2-Analyser NG. In the current implementation x must be less than 10.
Typing hhemu --help shows additional info.
For using HHEmu in emulator mode, the program can be started by double-clicking the program icon with the mouse.
HHEmu can be controlled by the mouse by clicking the OBD2-Analyser NG buttons, if the background picture HHOpenBackgroundPic.png that shows the 4 OBD2-Analyser NG buttons is found on program startup.
Additionally, HHEmu can be controlled by the cursor keys or the h,j,k,l-keys, that are mapped to the Up/Down/Ok/ESC-buttons.
Furthermore, in HHEmu emulator mode or HHEmu DXM simulator mode keys 0-9 can be used to store an up to 2-digit number in the number memory. The number from the number memory will be used for subsequent commands that need a number as parameter.
Possible commands are:
a - set number of permanent DTCs (CAN-protocols only) for the active ECU, 0-16
b - set number of cylinder banks for PID 0x13, 1-2 (*)
c - set number of cylinder banks for PID 0x1D, 1-4 (*)
d - set number of confirmed DTCs for the active ECU, 0-16
e - set number of responding ECUs, 1-8
m - toggle MIL
n - toggle visibility of number memory
p - set number of pending DTCs for the active ECU, 0-16
t - set responding protocol in DXM simulator mode: PWM (1), VPWM (2), ISO 9141-2 (3), KWP2000 5 Baud Init (4), KWP2000 Fast Init (5), CAN 11/500 (6), CAN 29/500 (7), CAN 11/250 (8) and CAN 29/250 (9)
u - set diagnostic interface controller: DXM (0), ELM (1) or STN (2)
x - toggle 'Conditions not correct' negative response code for SID 0x04 (clear DTCs) either for the active ECU or, if no ECU filter in the current menu is active, for all ECUs.
q - quit HHEmu
(*) - The standard ISO 15031-5 requires that all ECUs in a vehicle that support the location of oxygen sensors either support PID 0x13 or PID 0x1D, but not both. If you select setting the number of cylinder banks for PID 0x13, the supported PID 0x1D will be cleared automatically for you for all ECUs and vice versa.
Note that for some of the commands to take effect Reload Data must be executed. Further note that some commands only affect the currently active ECU. So, they might have to be issued several times with a change of ECU in between.
GTK+ V3.6.4 runtime libraries (6669kb)
HHEmu V2.20 developer package (1938kb)
HHEmu V2.20/Firmware V1.4.0 object files for linking with GTK3+ (534kb)
Experimental OBD2-Analyser NG firmware V1.4.0 hex-file (42kb)
Thomas Beck 10 years ago
Update 2014/04/27: With the new HHEmu V2.30 release installation is easy now. So, I have updated this still open question a little bit.
I am curious to get to know, whether HHEmu in HHDiag mode (OBD2 software mode) can be used as OBD2 software for the OBD2 Wireless project in the Elektor magazine April 2011? Although it has never been intended to do so.
The OBD2 Analyser NG and the OBD2 Wireless internally use the DXM module for the low level protocol stuff. Actually you can easily connect a terminal to your OBD2 Analyser NG equipped with the bluetooth module and type DXM AT-commands and OBD2 commands by hand (activate the bluetooth menu in the OBD2 Analyser NG and use 9600 Baud, 8N1 in the terminal program). Therefore, I assume that it works in the same way with the OBD2 Wireless.
So, I am searching for someone, who has the OBD2 Wireless Bluetooth version (the ZigBee version should work as well).
What do you have to do?
1. Download the hhemu_usr_gtk364_firmware_140.zip file and the gtk364_runtime_libs.zip file from the Software section of the contribution http://www.elektor-labs.com/contribution/hhemu-v230-obd2-analyser-ng-firmware-v140.14016.html
2. Unpack the hhemu_usr_gtk364_firmware_140.zip archive to whatever path you want. Unpack the gtk364_runtime_libs.zip to <your selected path>\hhemu_usr\gtk.
3. Search for the COM port that is assigned to the Bluetooth/ZigBee adapter of your PC
Start -> All Programs -> Accessories -> System Tools -> System Information -> Components -> Ports -> Serial might work for your OS.
4. Open a cmd.exe shell window and change to <your selected path>\hhemu_usr\gtk.
5. Enter the following command: hhemu.exe COM3 (replace the '3' with the number you found above)
If it is the correct COM port, the command will block the window and at first nothing will happen.
6. Connect the OBD2 Wireless Bluetooth to you car or a power supply.
Wait a few seconds, if a connection can be established between HHEmu and the Wireless OBD2 via Bluetooth.
The HHEmu screen should appear now. You can control it with the arrow keys. The q-key quits the emulator.
Nothing happens? Well, break hhemu.exe with CTRL-C in the shell and try again steps 5 and 6.
Still nothing happens? Reverse order of steps 5 and 6.
Still nothing happens? I think it just can be a baud rate problem and I will make a special version of HHEmu with configurable baud rate.
If the Wireless OBD2 is connected to a power supply, just the System Information menu will provide data from the DXM.
If the Wireless OBD2 is connected to the car, also the Start Diagnose menu and submenus should work.
Please report back here, if you encounter problems or if you succeed!