OBD2 for Raspberry Pi
OBD2 for Raspberry Pi with Pi-OBD add-on board or DXM OBD2 module and OBD2 software taken from my other labs project Firmware Update for OBD2-Analyser NG.
This project turns the Raspberry Pi into an OBD2 on-board diagnostic tester. So, the Pi can read OBD2 vehicle data and it can read and clear emissions-related diagnostic trouble codes and inspection/maintenance readiness monitor data.
Preface
You might have stumbled across my other OBD2 project here. That project provides firmware and OBD2 software (Mingw32 and Raspbian) for the OBD2-Analyser NG published in the September 2009 issue of the Elektor magazine. However, there is one big drawback with that project: the required hardware is no longer available. Finally, my new OBD2 project will fix that :)
The OBD2-Analyser NG uses a DIAMEX DXM OBD2 module interfacing with a vehicle bus on one side and providing a serial interface on the other side. The Raspberry Pi features a serial interface at its GPIO pins. Both serial interfaces operate with 3.3V line drivers and are easy to connect. So, I came up with the idea to develop a simple add-on board for the Pi using a DXM OBD2 module. However, I did not have a spare DXM OBD2 module available. Therefore, I somehow had to find a way to use the DXM on my OBD2-Analyser NG. Its serial interface is connected to an AVR AT90CAN128 microcontroller. A free port of the AT90CAN128 is available at the OBD2-Analyser NG's expansion pin header. So, I implemented a simple firmware change to route DXM data from the serial interface to port pins accessible at the expansion pin header and vice versa. After that, I wired the pins to the serial interface GPIOs of the Pi and could successfully control the DXM on the OBD2-Analyser NG with my OBD2 software running on the Pi.
After sharing that great news with DIAMEX, my project was sponsored by them with a free DXM OBD2 module that I used to build a prototype on a breadboard. Furthermore, DIAMEX developed a Pi-OBD add-on board based on their modern AGV OBD2 module, a follow-up module to the DXM, and I added support for AGV in my OBD2 software. So, now there are even two variants to add OBD2 to Raspberry Pi:
Variant 1: OBD2 for Raspberry Pi using the DIAMEX Pi-OBD add-on board
(*) Pi and display are powered via the OBD2 cable
(**) displays connected via the HDMI ribbon cable are recommended, other displays need some hardware hacks
Variant 2: OBD2 for Raspberry Pi using the DIAMEX DXM OBD2 module
(*) displays connected via the HDMI ribbon cable are recommended, other displays that occupy (but do not use) the Pi's serial interface require 2-3 mini-clips to get access to the serial interface and GND. Instead of mini-clips, wires soldered to that pins on the bottom side of the Pi are recommended for a reliable connection. If a display uses the first 26 pins only, GND can be connected to pin 30, 34 or 39.
1. The DIAMEX Pi-OBD add-on board
The Pi-OBD add-on board basically is an DIAMEX AGV OBD2 interface combined with an automotive-proven power supply/voltage regulator for the AGV, the Pi and a display. All put on a PCB that fits the Raspberry Pi B+, 2 and 3. The complete system is powered via the OBD2 cable. The Pi-OBD add-on board contains two connectors for an OBD2 cable: a 2x5 box header or a 9x1 male pin header. Of course, connector usage is mutual exclusive. The AGV OBD2 interface on the Pi-OBD add-on board is a follow-up OBD2 interface to the DXM. It is much more configurable than the DXM.
The AGV interface supports the following OBD2 protocols:
(*) The baud rate of the CAN protocols with 11 or 29 bit identifier and default 250 kbit/s baud rate is configurable.
The Pi-OBD uses a few GPIOs and covers some more. So, using a display connected via an HDMI ribbon cable is recommended. However, since the SPI GPIOs are not used by the Pi-OBD it is possible to build an adapter for displays connected via the SPI GPIOs.
Pi Pins and GPIOs connected to an 8x1 female header on the Pi-OBD:
Pin 2: +5V
Pin 4: +5V
Pin 6: GND
Pin 8: GPIO 14 - serial interface Tx
Pin 10: GPIO 15 - serial interface Rx
Pin 12: GPIO 18 - used for Pi-OBD module reset (pin low = reset, pin high = no reset)
Pin 14: GND
Pin 16: GPIO 23 - used for bootloader access (pin high + module reset = bootloader activated for Pi-OBD firmware update)
Pins 1, 3, 5, ..., 15 are covered by the Pi-OBD, but the Pi-OBD contains holes for mounting a connector in case a display or other hardware needs access to these pins.
A 2x1 male pin header for +5V and GND is available on the Pi-OBD to power the display.
The Pi-OBD add-on board contains 4 holes on the PCB matching the 4 holes on the Pi B+, 2 or 3. So, it can be mounted using 4 spacers and 4 screws.
2. The DXM OBD2 Module Add-on Breadboard
The DXM OBD2 module is well known to Elektor readers from the OBD2-Analyser NG project published in the September 2009 issue of the Elektor magazine and the Wireless OBD2 project published in the April 2011 issue. It is still available with updated firmware from www.diamex.de. You can get an OBD2 cable from them, too.
My add-on breadboard consists of a DXM OBD2 module, a 9x1 male pin header for the OBD2 cable, a 3x1 male pin header for the serial interface and a few wires for the connections. Additionally, I mounted a diode in the +12V line for reverse voltage protection, a small blocking capacitor near the power supply pins of the DXM and two resistors in the serial Tx/Rx lines that provide protection against wiring errors. A schematic that shows the wiring between DXM and OBD2 connector can be found in the official documentation of the DXM. Schematics showing the same wiring and a 1N4004 diode, a 10µF/63V capacitor and a 330 Ohm resistor are printed in the article of the OBD2-Analyser NG.
If you use bent pin headers and mount the DXM and the additional parts in a flat way, you should be able to mount the add-on board reversed. So that it fits under a display.
2.1 Wiring
The DXM takes the 12V from the OBD2 connector and has an internal 3.3V voltage regulator onboard. Do not forget to connect the 3.3V voltage regulator output to the 3.3V input. If you have no use for the antique PWM/VPW or K-line protocols, i.e. you use the OBD2 tester just in vehicles that use CAN protocols, you do not have to make these connections.
OBD2 connector DXM module Raspberry Pi
Pin 2 PWM/VPW+ ----------------------------- Pin 2 PWMP
Pin 10 PWM/VPW- ------------------------------ Pin 3 PWMM
Pin 4 Chassis GND --------------------------- Pin 4 GND --------------------- Pin 6 Ground
Pin 5 Signal GND - Pin 4 Chassis GND
Pin 6 CAN-High -------------------------------- Pin 32 CANH
Pin 14 CAN-Low --------------------------------- Pin 31 CANL
Pin 7 K-Line ------------------------------------- Pin 33 KLINE
Pin 15 L-Line ------------------------------------- Pin 34 LLINE
Pin 16 12V -------- >|- diode ---------------- Pin 1 12V - capacitor - Pin 4 GND
Pin 9 3V3OUT - Pin 14 3V3IN
Pin 24 TXD ----- resistor ----- Pin 10 GPIO 15 Rx
Pin 25 RXD ----- resistor ----- Pin 8 GPIO 14 Tx
Note: The DXM and AGV modules feature a command that returns the voltage measured at the module's power supply input. If a diode is used, keep in mind that the returned voltage is not equal to the battery voltage. That is due to the forward voltage drop of the diode. For the used silicon diode the drop is at least 0.7V and increases with current. So, if you later enter the system information menu of the HHEmu OBD2 software, the DXM-Voltage displayed there is less than the battery voltage.
3. Raspberry Pi
So far, I have tested the add-on boards and the OBD2 software using the following setup:
Since I did not build an adapter, the Pi-OBD add-on board does not fit under the display. It can be mounted to the right or top of the Pi using just 2 instead of all 4 spacers. The Pi-OBD add-on board does not power the Pi and the display in my configuration, since I did not connect 5V. I soldered a 2x1 male pin header to Tx/Rx at the bottom side of the Pi 3 and connected Rx/Tx of the Pi-OBD there. GND is taken from pin 39. The Pi-OBD's reset and bootloader pins are connected to pin 32 (GPIO 12) and 36 (GPIO 16). The 3.2" display just covers the pins 1-26, so pins 32, 36 and 39 are accessible.
On both Pis I use the serial device /dev/ttyAMA0. Usually, that device is already used by the Pi and you have to free it.
On the Pi 3 you additionally have to reconfigure or disable Bluetooth to make that device available. Read the serial interface configuration section in the file Readme_raspberry.txt that is part of the attached OBD2 software zip-file.
4. OBD2 Software for the Pi
The OBD2 software uses the OBD2-Analyser NG firmware inside. Since that just speaks DXM, I would waste a significant amount of limited FLASH memory in the real firmware to add support for AGV that never will be used there. Therefore, I decided to make a separate version for AGV using a define HHEMU_OBD_PI set in the makefile. Furthermore, for the AGV version I disabled some OBD2-Analyser NG menus and features that are of no relevance (e.g. Beeps, Bluetooth menu, USB menu, Serial interface menu, DXM simulator mode).
So, depending on the add-on board you need different versions of the OBD2 software. The Pi-OBD add-on board needs the HHGui software, the DXM add-on board needs the HHEmu software.
The OBD2 software needs a minimum window size of 640 x 330 pixels (if a background image can be read during software initialization, see details further down) or 320 x 165 pixels without background image.
4.1 HHGui OBD2 Software
HHGui is short for Pi-OBD2 Handheld GUI. The name implies that the GUI resembles a real OBD2 handheld tester like the OBD2-Analyser NG. In fact, HHGui uses the same background image feature than HHEmu. If the image HHGuiBackgroundPic.png is found on program startup, the simulated LCD screen of HHGui is printed to the LCD area of a scanned image of the real OBD2-Analyser NG. Furthermore, the OBD2-Analyser NG buttons displayed in the background image actually function as buttons when touched on a touchscreen. That makes the illusion of a real handheld even more perfect. By the way, as long as you keep the original size and the position of buttons, you can create your own background image and use that with HHGui.
Start HHGui with
Further self-explanatory command line options like fullscreen or maximize combined with nocursor can be given.
If you start HHGui without background image, touchscreen control differs. Then, 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.
(*) 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 HHGui on a touchscreen even in fullscreen mode that does not have a close button.
In some menus long-pressing/touching the button areas has a special meaning. E.g. long-pressing Up/Down in a list, will make a page scroll.
Long-pressing ESC makes a software reset. Then, HHGui displays the start screen and jumps to the main menu.
If you start HHGui without device and baud rate, e.g. typing just ./hhgui, HHGui is started in OBD2 simulator mode. In that mode, you can view and test all menu items and OBD2 services that are supported by HHGui. Furthermore, a lot of OBD2 parameters like the number of diagnostic trouble codes can be configured in that mode if you have connected a keyboard or if you use a virtual keyboard for input of commands. The commands are described in my other OBD2 project in the HHEmu command summary chapter.
4.2 HHEmu OBD2 Software
The OBD2 software named HHEmu is described in detail in my other Labs project here: http://www.elektormagazine.com/labs/firmware-update-and-emulator-for-obd2-analyser-ng-wireless-obd2
Start HHEmu with
That is identical to
Usually, device is one of /dev/ttyAMA0, /dev/ttyS0 (Pi 3 miniUART) or /dev/serial0. The device must be free and configured (see chapter 3 above).
Other command line options are identical to the HHGui options described above.
4.3 Other Ways to start HHGui/HHEmu
Apart from the start out of the console described above, you should take further variants into account: auto start HHGui/HHEmu in desktop or start HHGui/HHEmu via desktop menu entry or start HHGui/HHEmu via double-clicking a start script.
Create/edit a file
Depending on the start with or without background image it should contain the following lines:
OBD2 software with background image
OBD2 software without background image
If the file is not executable, enter chmod +x ./startobd.sh
If you use a system directory, you need sudo chmod +x ./startobd.sh
4.3.1 Auto start HHGui/HHEmu in Desktop
There are several ways to do that. The one that works for me is:
Start editor with
save and exit.
Reboot to test it.
4.3.2 Start HHGui/HHEmu via Desktop Menu Entry
Copy a xxx.desktop file from /usr/share/applications to another directory.
Change to that directory.
Rename the file to hhgui.desktop or hhemu.desktop and edit the file.
Change the Name line to
Name=HHGui
or
Name=HHEmu
Change the Exec line to
Save the file, copy or move it back to /usr/share/applications (you need sudo to do that).
A new desktop menu entry HHGui or HHEmu will show up.
4.4 OBD2 Diagnostic Services supported by HHGui/HHEmu
The most important part of OBD2 on-board diagnostic is specified in the ISO 15031-5:2015 standard that is based on the SAE J1979 standard. The full name of the standard is 'Road vehicles - Communication between vehicle and external equipment for emissions-related diagnostics - Part 5: Emissions-related diagnostic services.
These diagnostic services request emissions-related data from 1-8 OBD2 electronic control units (ECUs). The main electronic control unit that delivers OBD2 data is the engine control unit (also ECU). To avoid misunderstandings engine control module (ECM) is a better name for it. For vehicles with automatic transmission the transmission control module (TCM) is also a good candidate for delivering emissions-related data.
The standard defines diagnostic services identified by a service ID (SID). Most services support different functionalities addressed by a function identifier. Depending on the SID the function identifier is called parameter ID (PID), test ID (TID), on-board diagnostic monitor ID (OBDMID) or vehicle information type (INFOTYPE).
HHGui and HHEmu support the following diagnostic services:
Service 0x01 - Request current powertrain diagnostic data
This service is used to request current data, like vehicle speed, engine RPM, coolant temperature, oil temperature, boost pressure and so on. Current data also contains inspection/maintenance readiness monitors or static data like the location and number of oxygen sensors.
The nice feature with most of that data is, that it is raw sensor data that is not yet manipulated for a gauge. So in case of vehicle speed, you get the actual speed and not the speed the speedometer is showing you.
Service 0x02 - Request powertrain freeze frame data
This service is used to get a set of saved data related to a diagnostic trouble code (DTC) that caused freeze frame storage. Some DTCs trigger saving of current data at the time the error occurred. The set of saved data is called freeze frame data. This can be inspected later to analyse the cause of the fault.
Service 0x03 - Request emissions-related diagnostic trouble codes
This service is used to read confirmed DTCs. DTCs get the confirmed status in case the DTC is caused by misfire likely damaging the catalyst(s) or if a fault has been detected by the ECU in two consecutive driving cycles under the same conditions. A confirmed DTC is indicated to the driver via the malfunction indicator light (MIL). A steady light indicates a fault that allows driving to the next workshop. A blinking light indicates a fault likely to cause further damage when driving on.
Service 0x04 - Clear/Reset emissions-related diagnostic information
This service resets confirmed and pending DTCs, I/M readiness monitor data, freeze frame data and further data. Furthermore, it disables the MIL. After this service has been executed a vehicle is not ready for inspection. It has to be driven a while until all supported I/M readiness monitors again have successfully been run.
Some vehicles/ECUs require the ignition on and engine off condition before this service succeeds. Of course, using that service without having repaired anything should be avoided. The service 0x01 PID 0x30 returning the number of warm-ups since DTCs cleared and the PID 0x31 returning the distance travelled since DTCs cleared will reveal when data has been cleared.
Service 0x07 - Request emissions-related diagnostic trouble codes detected during current or last completed driving cycle
This service is used to read pending DTCs. It can be used after repair to see if a problem has actually been fixed. It avoids having to drive for two driving cycles until a confirmed DTC would show up again.
Service 0x09 - Request Vehicle Information
This service is used to read the vehicle identification number (VIN), software calibration IDs (CALIDs), software calibration verification numbers (CVNs), in-use performance tracking (IPT) data (this contains statistical data, like the number of ignition-cycles or how often OBD2 monitors have been run) or the ECU name.
Service 0x0A - Request emissions-related diagnostic trouble codes with permanent status (CAN protocols only)
This service is used to read permanent DTCs. Each confirmed DTC triggers setting of a permanent DTC at the end of an ignition-cycle. Permanent DTCs cannot be cleared by executing service 0x04 or by disconnecting the battery. They are automatically cleared by an ECU after repair, when the ECU determins that the error condition for a fault is no longer present for several consecutive driving cycles.
The services 0x05, 0x06 and 0x08 not described here are not supported by HHGui/HHEmu yet.
Please note that OBD2 diagnostic services cannot be used to configure anything in a vehicle. Furthermore, besides the MIL no other fault lights can be reset. For that purpose manufacturer specific diagnostic services have to be used. Therefore, resetting a service interval/service now message or clearing an airbag fault light or the configuration of door locking cannot be done with OBD2.
5. Proof of Concept (The full Story)
I did not have a spare DXM OBD2 module available, but I have built the OBD2-Analyser NG published in the September 2009 issue of the Elektor magazine. That uses a DXM OBD2 module that actually can be used without desoldering it. The DXM is connected via its serial interface to the USART0 of an AVR AT90CAN128. In Bluetooth mode the latest official firmware v1.2.1 acts as a gateway and forwards the USART0 data to its port F, port pin 7 that is connected to the serial interface of a BTM-222 Bluetooth module. In Rx direction the firmware reads data from the BTM at port F, pin 6 and forwards the data to USART0 that sends it to the DXM.
So, for a quick test I used the existing gateway mechanism, but changed it to use the free port F, port pins 1 and 2. These are easily accessible at the J2 extension header pins 2 and 3 of the OBD2-Analyser NG. Ground is available at the J1 extension header pin 1.
The serial interface of the Pi uses GPIO 14 (pin 8) for the Tx line and GPIO 15 (pin 10) for the Rx line. Ground is available at pin 6.
So, for the test I made the following connections:
Raspberry Pi OBD2-Analyser NG AT90CAN128
Ground pin 6 extension header J1 pin 1 Ground
Tx GPIO 14 pin 8 extension header J2 pin 3 Rx port F bit 2
Rx GPIO 15 pin 10 extension header J2 pin 2 Tx port F bit 1
For the connections I used a breadboard and put small 200 Ohm resistors in the Tx and Rx lines to avoid damage, in case I would make a wiring mistake. You can see that in the attached image.
This is the hardware test setup. The software changes are implemented as part of my OBD2-Analyser NG firmware update v1.7.1. The result is a new Serial Interface Mode accessible via the main menu of the firmware. The Serial Interface Mode menu item in the main menu must be enabled beforehand by ticking the related checkbox in the settings menu.
After flashing the new firmware, the OBD2-Analyser NG can be connected to a car or 12V power supply. Then, the Serial Interface Mode menu must be entered to activate the gateway routings described above.
The HHEmu OBD2 software needs a few changes, too. These are implemented in HHEmu v2.80. If HHemu is started with a serial device given on the command line, it is waiting for a prompt from the other side. Since the DXM in my test setup is not directly connected, it does not notice that it is now connected to the Raspberry Pi. It is still conected to USART0 of the AT90CAN128 and will not send a prompt, since it already has sent one that was read by the OBD2-Analyser NG, before the Serial Interface Mode was entered. Therefore, I implemented the nosync command line option. If you connect a DXM module right to the Raspberry Pi, this change is not needed. However, you need another command line option init=DXM to initialize the DXM module. In my test setup the DXM is already initialized by the OBD2-Analyser NG firmware.
For convenience, I implemented another command line option to make the baud rate configurable. Normally, HHEmu tries to connect to a (virtual) serial interface with 9600 Bd 8N1. According to the DXM documentation, the DXM module has a factory setting of 9600 Bd. Therefore, that would match. However, during OBD2-Analyser NG initialisation the DXM baud rate is changed to 19200 Bd by the firmware. So, in my test setup the DXM module runs with 19200 Bd.
Preface
You might have stumbled across my other OBD2 project here. That project provides firmware and OBD2 software (Mingw32 and Raspbian) for the OBD2-Analyser NG published in the September 2009 issue of the Elektor magazine. However, there is one big drawback with that project: the required hardware is no longer available. Finally, my new OBD2 project will fix that :)
The OBD2-Analyser NG uses a DIAMEX DXM OBD2 module interfacing with a vehicle bus on one side and providing a serial interface on the other side. The Raspberry Pi features a serial interface at its GPIO pins. Both serial interfaces operate with 3.3V line drivers and are easy to connect. So, I came up with the idea to develop a simple add-on board for the Pi using a DXM OBD2 module. However, I did not have a spare DXM OBD2 module available. Therefore, I somehow had to find a way to use the DXM on my OBD2-Analyser NG. Its serial interface is connected to an AVR AT90CAN128 microcontroller. A free port of the AT90CAN128 is available at the OBD2-Analyser NG's expansion pin header. So, I implemented a simple firmware change to route DXM data from the serial interface to port pins accessible at the expansion pin header and vice versa. After that, I wired the pins to the serial interface GPIOs of the Pi and could successfully control the DXM on the OBD2-Analyser NG with my OBD2 software running on the Pi.
After sharing that great news with DIAMEX, my project was sponsored by them with a free DXM OBD2 module that I used to build a prototype on a breadboard. Furthermore, DIAMEX developed a Pi-OBD add-on board based on their modern AGV OBD2 module, a follow-up module to the DXM, and I added support for AGV in my OBD2 software. So, now there are even two variants to add OBD2 to Raspberry Pi:
Variant 1: OBD2 for Raspberry Pi using the DIAMEX Pi-OBD add-on board
- Pi-OBD add-on board (*)
- OBD2 cable (*)
- 7" touchscreen (**)
- Raspberry Pi/Raspbian with free serial device, e.g. /dev/ttyAMA0 or /dev/ttyS0
- HHGui OBD2 software for the Pi
(*) Pi and display are powered via the OBD2 cable
(**) displays connected via the HDMI ribbon cable are recommended, other displays need some hardware hacks
Variant 2: OBD2 for Raspberry Pi using the DIAMEX DXM OBD2 module
- DXM OBD2 module
- A few additional parts like PCB (a breadboard will do), wires, connector for GPIOs, connector for OBD2 cable, optional but recommended: 2 resistors, 1 capacitor, 1 diode
- OBD2 cable
- Vehicle 12V socket to USB adapter + USB cable to power the Pi and the display
- Raspberry Pi/Raspbian with free serial device, e.g. /dev/ttyAMA0 or /dev/ttyS0
- Display for the Pi (minimum display size 320 x 165 pixels) (*)
- HHEmu OBD2 software for the Pi
(*) displays connected via the HDMI ribbon cable are recommended, other displays that occupy (but do not use) the Pi's serial interface require 2-3 mini-clips to get access to the serial interface and GND. Instead of mini-clips, wires soldered to that pins on the bottom side of the Pi are recommended for a reliable connection. If a display uses the first 26 pins only, GND can be connected to pin 30, 34 or 39.
1. The DIAMEX Pi-OBD add-on board
The Pi-OBD add-on board basically is an DIAMEX AGV OBD2 interface combined with an automotive-proven power supply/voltage regulator for the AGV, the Pi and a display. All put on a PCB that fits the Raspberry Pi B+, 2 and 3. The complete system is powered via the OBD2 cable. The Pi-OBD add-on board contains two connectors for an OBD2 cable: a 2x5 box header or a 9x1 male pin header. Of course, connector usage is mutual exclusive. The AGV OBD2 interface on the Pi-OBD add-on board is a follow-up OBD2 interface to the DXM. It is much more configurable than the DXM.
The AGV interface supports the following OBD2 protocols:
- SAE J1850 PWM and VPW
- ISO 9141 (keyword protocol with 5-baud wakeup)
- ISO 14230 (KWP2000 with 5-baud wakeup or fast initialisation)
- ISO 15765 (CAN with 11 or 29 bit identifier and 250 kbit/s or 500 kbit/s baud rate)(*)
(*) The baud rate of the CAN protocols with 11 or 29 bit identifier and default 250 kbit/s baud rate is configurable.
The Pi-OBD uses a few GPIOs and covers some more. So, using a display connected via an HDMI ribbon cable is recommended. However, since the SPI GPIOs are not used by the Pi-OBD it is possible to build an adapter for displays connected via the SPI GPIOs.
Pi Pins and GPIOs connected to an 8x1 female header on the Pi-OBD:
Pin 2: +5V
Pin 4: +5V
Pin 6: GND
Pin 8: GPIO 14 - serial interface Tx
Pin 10: GPIO 15 - serial interface Rx
Pin 12: GPIO 18 - used for Pi-OBD module reset (pin low = reset, pin high = no reset)
Pin 14: GND
Pin 16: GPIO 23 - used for bootloader access (pin high + module reset = bootloader activated for Pi-OBD firmware update)
Pins 1, 3, 5, ..., 15 are covered by the Pi-OBD, but the Pi-OBD contains holes for mounting a connector in case a display or other hardware needs access to these pins.
A 2x1 male pin header for +5V and GND is available on the Pi-OBD to power the display.
The Pi-OBD add-on board contains 4 holes on the PCB matching the 4 holes on the Pi B+, 2 or 3. So, it can be mounted using 4 spacers and 4 screws.
2. The DXM OBD2 Module Add-on Breadboard
The DXM OBD2 module is well known to Elektor readers from the OBD2-Analyser NG project published in the September 2009 issue of the Elektor magazine and the Wireless OBD2 project published in the April 2011 issue. It is still available with updated firmware from www.diamex.de. You can get an OBD2 cable from them, too.
My add-on breadboard consists of a DXM OBD2 module, a 9x1 male pin header for the OBD2 cable, a 3x1 male pin header for the serial interface and a few wires for the connections. Additionally, I mounted a diode in the +12V line for reverse voltage protection, a small blocking capacitor near the power supply pins of the DXM and two resistors in the serial Tx/Rx lines that provide protection against wiring errors. A schematic that shows the wiring between DXM and OBD2 connector can be found in the official documentation of the DXM. Schematics showing the same wiring and a 1N4004 diode, a 10µF/63V capacitor and a 330 Ohm resistor are printed in the article of the OBD2-Analyser NG.
If you use bent pin headers and mount the DXM and the additional parts in a flat way, you should be able to mount the add-on board reversed. So that it fits under a display.
2.1 Wiring
The DXM takes the 12V from the OBD2 connector and has an internal 3.3V voltage regulator onboard. Do not forget to connect the 3.3V voltage regulator output to the 3.3V input. If you have no use for the antique PWM/VPW or K-line protocols, i.e. you use the OBD2 tester just in vehicles that use CAN protocols, you do not have to make these connections.
OBD2 connector DXM module Raspberry Pi
Pin 2 PWM/VPW+ ----------------------------- Pin 2 PWMP
Pin 10 PWM/VPW- ------------------------------ Pin 3 PWMM
Pin 4 Chassis GND --------------------------- Pin 4 GND --------------------- Pin 6 Ground
Pin 5 Signal GND - Pin 4 Chassis GND
Pin 6 CAN-High -------------------------------- Pin 32 CANH
Pin 14 CAN-Low --------------------------------- Pin 31 CANL
Pin 7 K-Line ------------------------------------- Pin 33 KLINE
Pin 15 L-Line ------------------------------------- Pin 34 LLINE
Pin 16 12V -------- >|- diode ---------------- Pin 1 12V - capacitor - Pin 4 GND
Pin 9 3V3OUT - Pin 14 3V3IN
Pin 24 TXD ----- resistor ----- Pin 10 GPIO 15 Rx
Pin 25 RXD ----- resistor ----- Pin 8 GPIO 14 Tx
Note: The DXM and AGV modules feature a command that returns the voltage measured at the module's power supply input. If a diode is used, keep in mind that the returned voltage is not equal to the battery voltage. That is due to the forward voltage drop of the diode. For the used silicon diode the drop is at least 0.7V and increases with current. So, if you later enter the system information menu of the HHEmu OBD2 software, the DXM-Voltage displayed there is less than the battery voltage.
3. Raspberry Pi
So far, I have tested the add-on boards and the OBD2 software using the following setup:
- Raspberry Pi 2/Raspbian, official 7" touchscreen, Pi-OBD add-on board or DXM add-on breadboard
- Raspberry Pi 3/Raspbian, Waveshare/Joy-it 3.2" touchscreen, Pi-OBD add-on board or DXM add-on breadboard (*)
Since I did not build an adapter, the Pi-OBD add-on board does not fit under the display. It can be mounted to the right or top of the Pi using just 2 instead of all 4 spacers. The Pi-OBD add-on board does not power the Pi and the display in my configuration, since I did not connect 5V. I soldered a 2x1 male pin header to Tx/Rx at the bottom side of the Pi 3 and connected Rx/Tx of the Pi-OBD there. GND is taken from pin 39. The Pi-OBD's reset and bootloader pins are connected to pin 32 (GPIO 12) and 36 (GPIO 16). The 3.2" display just covers the pins 1-26, so pins 32, 36 and 39 are accessible.
On both Pis I use the serial device /dev/ttyAMA0. Usually, that device is already used by the Pi and you have to free it.
On the Pi 3 you additionally have to reconfigure or disable Bluetooth to make that device available. Read the serial interface configuration section in the file Readme_raspberry.txt that is part of the attached OBD2 software zip-file.
4. OBD2 Software for the Pi
The OBD2 software uses the OBD2-Analyser NG firmware inside. Since that just speaks DXM, I would waste a significant amount of limited FLASH memory in the real firmware to add support for AGV that never will be used there. Therefore, I decided to make a separate version for AGV using a define HHEMU_OBD_PI set in the makefile. Furthermore, for the AGV version I disabled some OBD2-Analyser NG menus and features that are of no relevance (e.g. Beeps, Bluetooth menu, USB menu, Serial interface menu, DXM simulator mode).
So, depending on the add-on board you need different versions of the OBD2 software. The Pi-OBD add-on board needs the HHGui software, the DXM add-on board needs the HHEmu software.
The OBD2 software needs a minimum window size of 640 x 330 pixels (if a background image can be read during software initialization, see details further down) or 320 x 165 pixels without background image.
4.1 HHGui OBD2 Software
HHGui is short for Pi-OBD2 Handheld GUI. The name implies that the GUI resembles a real OBD2 handheld tester like the OBD2-Analyser NG. In fact, HHGui uses the same background image feature than HHEmu. If the image HHGuiBackgroundPic.png is found on program startup, the simulated LCD screen of HHGui is printed to the LCD area of a scanned image of the real OBD2-Analyser NG. Furthermore, the OBD2-Analyser NG buttons displayed in the background image actually function as buttons when touched on a touchscreen. That makes the illusion of a real handheld even more perfect. By the way, as long as you keep the original size and the position of buttons, you can create your own background image and use that with HHGui.
Start HHGui with
./hhgui device 115200 init=AGVFurther self-explanatory command line options like fullscreen or maximize combined with nocursor can be given.
If you start HHGui without background image, touchscreen control differs. Then, 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.
(*) 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 HHGui on a touchscreen even in fullscreen mode that does not have a close button.
In some menus long-pressing/touching the button areas has a special meaning. E.g. long-pressing Up/Down in a list, will make a page scroll.
Long-pressing ESC makes a software reset. Then, HHGui displays the start screen and jumps to the main menu.
If you start HHGui without device and baud rate, e.g. typing just ./hhgui, HHGui is started in OBD2 simulator mode. In that mode, you can view and test all menu items and OBD2 services that are supported by HHGui. Furthermore, a lot of OBD2 parameters like the number of diagnostic trouble codes can be configured in that mode if you have connected a keyboard or if you use a virtual keyboard for input of commands. The commands are described in my other OBD2 project in the HHEmu command summary chapter.
4.2 HHEmu OBD2 Software
The OBD2 software named HHEmu is described in detail in my other Labs project here: http://www.elektormagazine.com/labs/firmware-update-and-emulator-for-obd2-analyser-ng-wireless-obd2
Start HHEmu with
./hhemu device init=DXMThat is identical to
./hhemu device 9600 init=DXMUsually, device is one of /dev/ttyAMA0, /dev/ttyS0 (Pi 3 miniUART) or /dev/serial0. The device must be free and configured (see chapter 3 above).
Other command line options are identical to the HHGui options described above.
4.3 Other Ways to start HHGui/HHEmu
Apart from the start out of the console described above, you should take further variants into account: auto start HHGui/HHEmu in desktop or start HHGui/HHEmu via desktop menu entry or start HHGui/HHEmu via double-clicking a start script.
Create/edit a file
nano /your_path_to_obd2_software/startobd.shDepending on the start with or without background image it should contain the following lines:
OBD2 software with background image
cd /your_path_to_obd2_software
./hhgui /dev/ttyAMA0 115200 init=AGV nocursor maximizecd /your_path_to_obd2_software
./hhemu /dev/ttyAMA0 init=DXM nocursor maximizeOBD2 software without background image
./hhgui /dev/ttyAMA0 115200 init=AGV nocursor fullscreen./hhemu /dev/ttyAMA0 init=DXM nocursor fullscreenIf the file is not executable, enter chmod +x ./startobd.sh
If you use a system directory, you need sudo chmod +x ./startobd.sh
4.3.1 Auto start HHGui/HHEmu in Desktop
There are several ways to do that. The one that works for me is:
Start editor with
sudo nano ~/.config/lxsession/LXDE-pi/autostart@lxterminal -e /your_path_to_obd2_software/startobd.shsave and exit.
Reboot to test it.
4.3.2 Start HHGui/HHEmu via Desktop Menu Entry
Copy a xxx.desktop file from /usr/share/applications to another directory.
Change to that directory.
Rename the file to hhgui.desktop or hhemu.desktop and edit the file.
Change the Name line to
Name=HHGui
or
Name=HHEmu
Change the Exec line to
Exec=lxterminal -e /your_path_to_obd2_software/startobd.shSave the file, copy or move it back to /usr/share/applications (you need sudo to do that).
A new desktop menu entry HHGui or HHEmu will show up.
4.4 OBD2 Diagnostic Services supported by HHGui/HHEmu
The most important part of OBD2 on-board diagnostic is specified in the ISO 15031-5:2015 standard that is based on the SAE J1979 standard. The full name of the standard is 'Road vehicles - Communication between vehicle and external equipment for emissions-related diagnostics - Part 5: Emissions-related diagnostic services.
These diagnostic services request emissions-related data from 1-8 OBD2 electronic control units (ECUs). The main electronic control unit that delivers OBD2 data is the engine control unit (also ECU). To avoid misunderstandings engine control module (ECM) is a better name for it. For vehicles with automatic transmission the transmission control module (TCM) is also a good candidate for delivering emissions-related data.
The standard defines diagnostic services identified by a service ID (SID). Most services support different functionalities addressed by a function identifier. Depending on the SID the function identifier is called parameter ID (PID), test ID (TID), on-board diagnostic monitor ID (OBDMID) or vehicle information type (INFOTYPE).
HHGui and HHEmu support the following diagnostic services:
Service 0x01 - Request current powertrain diagnostic data
This service is used to request current data, like vehicle speed, engine RPM, coolant temperature, oil temperature, boost pressure and so on. Current data also contains inspection/maintenance readiness monitors or static data like the location and number of oxygen sensors.
The nice feature with most of that data is, that it is raw sensor data that is not yet manipulated for a gauge. So in case of vehicle speed, you get the actual speed and not the speed the speedometer is showing you.
Service 0x02 - Request powertrain freeze frame data
This service is used to get a set of saved data related to a diagnostic trouble code (DTC) that caused freeze frame storage. Some DTCs trigger saving of current data at the time the error occurred. The set of saved data is called freeze frame data. This can be inspected later to analyse the cause of the fault.
Service 0x03 - Request emissions-related diagnostic trouble codes
This service is used to read confirmed DTCs. DTCs get the confirmed status in case the DTC is caused by misfire likely damaging the catalyst(s) or if a fault has been detected by the ECU in two consecutive driving cycles under the same conditions. A confirmed DTC is indicated to the driver via the malfunction indicator light (MIL). A steady light indicates a fault that allows driving to the next workshop. A blinking light indicates a fault likely to cause further damage when driving on.
Service 0x04 - Clear/Reset emissions-related diagnostic information
This service resets confirmed and pending DTCs, I/M readiness monitor data, freeze frame data and further data. Furthermore, it disables the MIL. After this service has been executed a vehicle is not ready for inspection. It has to be driven a while until all supported I/M readiness monitors again have successfully been run.
Some vehicles/ECUs require the ignition on and engine off condition before this service succeeds. Of course, using that service without having repaired anything should be avoided. The service 0x01 PID 0x30 returning the number of warm-ups since DTCs cleared and the PID 0x31 returning the distance travelled since DTCs cleared will reveal when data has been cleared.
Service 0x07 - Request emissions-related diagnostic trouble codes detected during current or last completed driving cycle
This service is used to read pending DTCs. It can be used after repair to see if a problem has actually been fixed. It avoids having to drive for two driving cycles until a confirmed DTC would show up again.
Service 0x09 - Request Vehicle Information
This service is used to read the vehicle identification number (VIN), software calibration IDs (CALIDs), software calibration verification numbers (CVNs), in-use performance tracking (IPT) data (this contains statistical data, like the number of ignition-cycles or how often OBD2 monitors have been run) or the ECU name.
Service 0x0A - Request emissions-related diagnostic trouble codes with permanent status (CAN protocols only)
This service is used to read permanent DTCs. Each confirmed DTC triggers setting of a permanent DTC at the end of an ignition-cycle. Permanent DTCs cannot be cleared by executing service 0x04 or by disconnecting the battery. They are automatically cleared by an ECU after repair, when the ECU determins that the error condition for a fault is no longer present for several consecutive driving cycles.
The services 0x05, 0x06 and 0x08 not described here are not supported by HHGui/HHEmu yet.
Please note that OBD2 diagnostic services cannot be used to configure anything in a vehicle. Furthermore, besides the MIL no other fault lights can be reset. For that purpose manufacturer specific diagnostic services have to be used. Therefore, resetting a service interval/service now message or clearing an airbag fault light or the configuration of door locking cannot be done with OBD2.
5. Proof of Concept (The full Story)
I did not have a spare DXM OBD2 module available, but I have built the OBD2-Analyser NG published in the September 2009 issue of the Elektor magazine. That uses a DXM OBD2 module that actually can be used without desoldering it. The DXM is connected via its serial interface to the USART0 of an AVR AT90CAN128. In Bluetooth mode the latest official firmware v1.2.1 acts as a gateway and forwards the USART0 data to its port F, port pin 7 that is connected to the serial interface of a BTM-222 Bluetooth module. In Rx direction the firmware reads data from the BTM at port F, pin 6 and forwards the data to USART0 that sends it to the DXM.
So, for a quick test I used the existing gateway mechanism, but changed it to use the free port F, port pins 1 and 2. These are easily accessible at the J2 extension header pins 2 and 3 of the OBD2-Analyser NG. Ground is available at the J1 extension header pin 1.
The serial interface of the Pi uses GPIO 14 (pin 8) for the Tx line and GPIO 15 (pin 10) for the Rx line. Ground is available at pin 6.
So, for the test I made the following connections:
Raspberry Pi OBD2-Analyser NG AT90CAN128
Ground pin 6 extension header J1 pin 1 Ground
Tx GPIO 14 pin 8 extension header J2 pin 3 Rx port F bit 2
Rx GPIO 15 pin 10 extension header J2 pin 2 Tx port F bit 1
For the connections I used a breadboard and put small 200 Ohm resistors in the Tx and Rx lines to avoid damage, in case I would make a wiring mistake. You can see that in the attached image.
This is the hardware test setup. The software changes are implemented as part of my OBD2-Analyser NG firmware update v1.7.1. The result is a new Serial Interface Mode accessible via the main menu of the firmware. The Serial Interface Mode menu item in the main menu must be enabled beforehand by ticking the related checkbox in the settings menu.
After flashing the new firmware, the OBD2-Analyser NG can be connected to a car or 12V power supply. Then, the Serial Interface Mode menu must be entered to activate the gateway routings described above.
The HHEmu OBD2 software needs a few changes, too. These are implemented in HHEmu v2.80. If HHemu is started with a serial device given on the command line, it is waiting for a prompt from the other side. Since the DXM in my test setup is not directly connected, it does not notice that it is now connected to the Raspberry Pi. It is still conected to USART0 of the AT90CAN128 and will not send a prompt, since it already has sent one that was read by the OBD2-Analyser NG, before the Serial Interface Mode was entered. Therefore, I implemented the nosync command line option. If you connect a DXM module right to the Raspberry Pi, this change is not needed. However, you need another command line option init=DXM to initialize the DXM module. In my test setup the DXM is already initialized by the OBD2-Analyser NG firmware.
For convenience, I implemented another command line option to make the baud rate configurable. Normally, HHEmu tries to connect to a (virtual) serial interface with 9600 Bd 8N1. According to the DXM documentation, the DXM module has a factory setting of 9600 Bd. Therefore, that would match. However, during OBD2-Analyser NG initialisation the DXM baud rate is changed to 19200 Bd by the firmware. So, in my test setup the DXM module runs with 19200 Bd.
Diskussion (1 Kommentar)
andrew barker vor 6 Jahren
Nice project Thomas, It's at limit of my knowledge but I'm considering trying it for fun and having recently discovered my old Audi A3 uses ISO9141. I'm renovating and trying to get her started.
I have a RaspberryPi and OBD cable, so a couple of questions:
1. is you code python and opensource?
2. So if I bought the OBD Pi Hat and DMX OBD module would I be able to re-program to skip the LCD i.e. use wifi to SSH into the pi to get output?
Many thanks for any guidance.
AB
I have a RaspberryPi and OBD cable, so a couple of questions:
1. is you code python and opensource?
2. So if I bought the OBD Pi Hat and DMX OBD module would I be able to re-program to skip the LCD i.e. use wifi to SSH into the pi to get output?
Many thanks for any guidance.
AB
Antworten
Thomas Beck vor 6 Jahren
Hello Andrew, the source code is written in C. The original author of the OBD2 Analyser NG released the AT90CAN128 firmware C source code with the restriction 'for non-commercial private use only'. Since HHGui uses parts of this firmware inside, HHGui is released with the same restriction. Due to missing demand and because Diamex has removed the firmware source code from the companies homepage long ago, the v1.3.0 firmware release was the last release for which I have provided full source code. To ease development for the many systems (Arduino, Pi, Windows, Ubuntu) that are supported in the meantime, AGV/DXM/OBD2 stuff and all menus are provided in a C-library in hhgui320_dev.zip (for the Pi, this is libhhgui_pi.a) which is not documented for the user.
To use the Pi-OBD module (at least at the moment, the DXM module is not available), the HHGui software is not necessarily needed. The module can be controlled via any terminal software. The text commands it understands are given in its documentation.
Of course, an experienced developer could replace the HHGui GUI/LCD interface with another interface that can remotely be controlled. The GUI/LCD interface is completely available in the released sources. However, a much simpler solution is to use VNC. Start vncserver on the Pi. Start a VNC client on a PC/notebook, connect to the PI (wireless or Ethernet cable) and the PI can be remotely controlled from the PC. Then start HHGui and the display of HHGui will show up on the PC and can be controlled with either the PC's mouse or keyboard or both.
To use the Pi-OBD module (at least at the moment, the DXM module is not available), the HHGui software is not necessarily needed. The module can be controlled via any terminal software. The text commands it understands are given in its documentation.
Of course, an experienced developer could replace the HHGui GUI/LCD interface with another interface that can remotely be controlled. The GUI/LCD interface is completely available in the released sources. However, a much simpler solution is to use VNC. Start vncserver on the Pi. Start a VNC client on a PC/notebook, connect to the PI (wireless or Ethernet cable) and the PI can be remotely controlled from the PC. Then start HHGui and the display of HHGui will show up on the PC and can be controlled with either the PC's mouse or keyboard or both.
Antworten
Mehr anzeigen
1 Kommentar(e)
Updates vom Autor
Thomas Beck vor 3 Jahren
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. On the original OBD2-Analyser NG hardware, 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 foreseeable future, I plan to support OBDonUDS in HHGui 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.
Bugfix:
- fixed wrong text in InfoType 0x16 "fuel engine operation" -> "fueled engine operation"
HHGui installation and usage on the Pi:
HHGui installation, usage and compile instructions are given in file Readme_raspberry.txt. This file is in the hhgui350_usr.zip file which also contains the HHGui binary for Raspberry Pi. The German PDF manual is also in this archive.
There are two different hhgui binaries and two different libhhgui_pi.a libraries in the archives:
For the Raspberry Pi OS 2021/03/04 release, HHGui was compiled with gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1) and linked with GTK+ 3.24.5. These versions have not changed since the Raspian Buster September 2019 release.
For older Raspbian releases, HHGui was compiled with gcc version 4.9.2 (Raspbian 4.9.2-10) and linked with GTK+ 3.14.5.
hhgui350_dev.zip (2836kb)
Thomas Beck vor 4 Jahren
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 firmware 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.
- 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 man page
- 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 on the Pi:
HHGui installation, usage and compile instructions are given in file Readme_raspberry.txt. This file is in the hhgui340_usr.zip file which also contains the HHGui binary for Raspberry Pi. The German PDF manual is also in this archive.
There are two different hhgui binaries and two different libhhgui_pi.a files in the archives:
For the Raspbian Buster September 2019 release, HHGui was compiled with gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1) and linked with GTK+ 3.24.5.
For the older Raspbian releases, HHGui was compiled with gcc version 4.9.2 (Raspbian 4.9.2-10) and linked with GTK+ 3.14.5.
HHGui v3.40 OBD2 Software Raspberry Pi/Windows/Ubuntu Source Code (2713kb)
Thomas Beck vor 5 Jahren
Hardware Requirements
- Raspberry Pi 2, 3 or 4
- Diamex Pi-OBD module + OBD2 cable
- Android or iOS smartphone
Software Requirements
- VNC client app for the smartphone
- Raspbian OS for the Pi
- HHGui OBD2 diagnostic software of this Labs project for the Pi
Notes:
Pi 3 and 4 have WiFi onboard. I have tested this with Pi 3B and Pi 4B.
Pi 2 needs a USB-WiFi adapter which is supported by the Pi and can be configured as wireless access point. This has not been tested.
For the initial setup, a Raspberry Pi power supply is needed. I have installed the Pi-OBD module right from the start and powered the Pi through the OBD2 connector.
For the initial setup, a VNC client PC software is recommended, an SSH client is enough, though. I have tested this with TightVNC Viewer and RealVNC Viewer. For the first VNC connection, it is easier to test this from a PC than from a smartphone. When the Pi boots into the Desktop the first time, a graphical setup program is started which can be controlled from the VNC Viewer on a PC more easily.
For the intial setup, a SSH client must be installed on the PC. For Windows 10 this is in Settings->Apps->Optional Features. On my Windows 10 PC, the SSH client was already installed.
I have tested the VNC client apps VNC Viewer for Android from androidVNC team + antlersoft and RealVNC Viewer Android app from RealVNC Limited. An iOs app has not been tested by me.
I have tested this with the Raspbian Buster September 2019 release which comes with the RealVNC server installed. I have tested the full image file Raspbian Buster with desktop and recommended software and I have tested the image file Rasbian Buster with desktop. I recommend using the smaller image. The software update triggered during the installation process will be faster then.
For the initial setup, I hooked up the Pi to a router via a wired Ethernet connection. You could also use WiFi for the initial setup but this has not been tested by me.
1. Follow the Raspberry Pi foundation's guide to install a Raspbian image file on an SD card for the Pi.
https://www.raspberrypi.org/documentation/installation/installing-images/README.md
When you have prepared the SD card according to the above link, continue to prepare the SD card for installation of HHGui and VNC server in virtual mode.
2. Unzip the hhguisetup.zip archive attached to this project update and copy the files to the boot partition on the SD card. A folder /boot/tmp is created and an empty file ssh is put in /boot which enables SSH access during the first boot later.
hhguisetup.zip contains hhgui file v3.30. If there is a more recent version of the hhgui file, copy the hhgui file of the latest hhguixxx_usr.zip file to /boot/tmp.
Some of the files are text files. Do not edit them on a PC unless you use an editor which allows saving in unix format. If the files are saved in DOS format, they are unusable on the Pi unless converted back with a tool like dos2unix.
3. Put the prepared SD card into the Pi and power up the Pi.
4. Search for the IP address of the Pi in your router.
Furthermore, you should configure the router so that it always assigns the same static IP address to the Pi. If you use a WiFi connection and your router is configured to only allow known devices to connect to it, you will have to add the Pi to the list of devices which are allowed to connect.
5. On a PC, open a command shell and connect to the Pi via SSH.
You have to enter the default password raspberry for the user pi.
So, now you have command line access to the Pi via SSH.
There are at least two possible variants to connect Pi and smartphone.
Variant 1: Configure the Pi as wireless access point
Variant 2: Configure the smartphone as wireless access point
The initial setup for variant 1 is more complicated but allows any smartphone to connect to the Pi later. I have tested both variants and from a user perspective, there is no difference. In the following sections I describe variant 1.
6. On a Pi 3 and 4, disable Bluetooth to make /dev/ttyAMA0 available for the Pi-OBD module.
In the SSH command line, type
and in the editor window add the line
Note: You can also use dtoverlay=pi3-disable-bt like on the Pi 3 because these two overlay files are identical.
You could also disable the service that is still trying to start the UART for Bluetooth (but will fail, see sudo systemctl status hciuart).
7. To configure the serial interface and prepare the desktop for VNC, type
Select Advanced Options
Select Resolution - Set a specific screen resolution (to use when the system boots without a TV or monitor being connected.)
Change the Default 720x480 to anything else, e.g. DMT Mode 35 1280x1024 60Hz 5:4.
This is necessary on a headless Pi to get a virtual desktop of a size that is actually visible. If you do not change the default screen size, the VNC viewer will print an error message later that the display cannot be shown.
Select Interfacing Options
Select Serial - Enable/Disable shell and kernel messages on the serial connection
Answer question "Would you like a login shell to be accessible over serial?" with No.
Answer question "Would you like the serial port hardware to be enabled?" with Yes.
Select Finish. When you are asked to reboot, wait until the next step.
8. Trigger a full update of the Pi.
This takes some minutes. Afterwards, you should start a reboot with
Reconnect to the Pi with
9. Install the HHGui software and configure the VNC server.
The follwing lines assume that the software is going to be installed into a directory /home/pi/Desktop/HHGui and that the user on the Pi is named pi. If this is not the case, change the lines and the startobd.sh script accordingly.
In the shell type
This automatically runs the following commands for you:
The last commands in the above script configure the VNC server to automatically start at boot time in virtual mode to create a virtual desktop. Here I present a solution via Xinit.d which does not need a RealVNC Enterprise subscription which uses Xsystemd.
The question "How can I start a VNC server before log on?" has already been answered here
https://askubuntu.com/questions/83824/how-can-i-start-a-vnc-server-before-log-on/118645#118645
I have adapted this solution for the Pi in file /boot/tmp/vncserver.sh which is copied to /etc/init.d/vncserver by the above script.
Notes regarding file /etc/init.d/vncserver:
DISPLAY must be 1 or greater for a virtual desktop. 0 is the actual desktop if a monitor is connected.
If your user on the Pi is not named pi, change the export USER="pi" line in file /etc/init.d/vncserver accordingly.
If you do not know a suitable screen resolution for your smartphone yet, vncserver option -RandR= can take a comma separated list of screen resolutions in the format <width>x<height>, e.g. -RandR=800x600,1024x768. In a command shell, the command xrandr -s <width>x<height> can switch between any resolution in the comma separated list. Typing just xrandr shows this list and the active resolution.
10. Downgrade VNC security settings to VNC authentication
If you are using any other software or app than the RealVNC Viewer software or app to connect to the RealVNC server software on the Pi, the vncserver option Authentication=VncAuth" must be active to downgrade the security settings. In this case, you will also have to set a VNC password. On Android (not on iOS), the RealVNC Viewer app to this date has a non-configurable setting that tapping the smartphone display clicks where the cursor is located. So, you have to move the mouse cursor around all the time before clicking. However, HHGui can be controlled much faster if you click where your finger is. As a workaround for the Android RealVNC Viewer app, you could tap the mouse icon of the RealVNC toolbar. This will add a line at the bottom of the smartphone display which shows the arrow up/down/left/right cursor icons. When tapping these icons, HHGui can be controlled more easily with this app. A long press on these icons is still not detected, though. Therefore on Android, I would use another VNC viewer app. For the tests, I used the Open Source VNC Viewer for Android app from androidVNC team + antlersoft. This needs the follwing steps:
To manually start the VNC server in virtual mode, type
This generates the configuration file ~/.vnc/config.d/Xvnc.
To change the authentication, type
and at the end of the file add the line
To change the VNC password, type
and enter a VNC password twice. This will add a line Password=... below the Authentication=VncAuth line.
Note:
sudo vncpasswd -virtual would save the password in file /root/.vnc/config.d/Xvnc. However, the RealVNC Server in Virtual Mode Options dialog, which is accessible via the Pi's desktop, uses and shows the state of file ~/.vnc/config.d/Xvnc. Therefore, it is better to force this file being updated, so that a user looking at the Options dialog will see the actual settings.
11. Connect to the Pi via a VNC viewer software on the PC
The vncserver command above also prints IP address : DISPLAY number. You can try to connect from any VNC viewer to this IP address:port number (port number = 5900 + DISPLAY) now. Of course, the IP address is the same than for the SSH connection above. If you successfully try this from a PC first, doing this from the smartphone might be easier later.
In the VNC viewer software, you will have to enter
any name for the connection,
the Pi's IP address,
a port number.
The port number is 5900 + DISPLAY number. The display numbers start at 1 (see vncserver script). So, for the first vncserver started, it is 5901.
If the software does not request a port number, this has to be given after the IP address in the format IP address:port number.
For System-Authentication, you will have to enter the user name pi and the password of the user pi.
For VNC-Authentication, you will have to enter the VNC password.
You can also enter full screen options, remote cursor options or a color format. If you enter a 24bit mode instead of e.g. 64 colors, the virtual desktop looks nicer but needs a lot of network bandwidth.
After you have entered all of this, the VNC viewer software remembers the entries and associates them with the name of the connection.
Click the Connect button. A warning about degraded security settings might appear in RealVNC Viewer.
If you connect the first time, the Pi's desktop is opened the first time and another setup program is started. Here you can change locale options, the password for the user pi, Wi-Fi country and so on if you have not done this in raspi-config before. You should reboot before continuing with the next step.
12. Finally, follow the Raspberry Pi foundation's guide to setup the Pi as wireless access point:
https://www.raspberrypi.org/documentation/configuration/wireless/access-point.md
This guide has a section to create and edit a configuration file /etc/hostapd/hostapd.conf. A template for this file has been put in /boot/tmp. You could copy this file and provide the missing values for SSID and passphrase.
This guide has a section to setup the Pi's wireless access point to share a wired Ethernet internet connection (bridge). For HHGui, this section is not needed and can be skipped. Furthermore, the guide contains a line sudo systemctl reload dnsmasq. This does not work since the service was stopped at the beginning of the guide. I used instead.
Reboot and check if the Pi's wireless access point is visible from the smartphone or other mobile devices. The IP address of the wireless interface should be 192.168.4.1 if you have followed the above guide.
Now, setup the smartphone.
13. Install a VNC Viewer app.
14. Connect to the Pi's wireless access point using the SSID and passphrase that you have specified in /etc/hostapd/hostapd.conf during the Pi's wireless access point setup.
15. Start the VNC Viewer app to connect to the Pi
Basically, this works in the same way as described in step 11 above. The only difference is that you have to enter the IP address of the Pi's wireless interface.
Click the Connect button. A warning about degraded security settings might appear in RealVNC Viewer app.
If everything went well, you should now see the Pi's desktop on the smartphone.
16. Double-click the startobd.sh script on the desktop to initialize the Pi-OBD module and to start HHGui.
Choose Open and then choose Execute or better choose Execute in Terminal window if you want to see possible error messages.
To make HHGui fullscreen at once, I have added the fullscreen option to the hhgui command line in the startobd.sh script. I have also added the nocursor option. If you are using the RealVNC Viewer app on Android, you might want to remove this option from the startobd.sh script.
To close HHGui, you could send a q-character to it. Or you could tap the upper right corner of the HHGui background picture. There is a hidden field, 30x30 pixels in size. If this is clicked, HHGui switches from fullscreen to window mode. In window mode, it gets the normal window decoration with a close button which can be clicked.
Before disconnecting from the Pi in the VNC viewer app, do not forget to shutdown the Pi! To shutdown the Pi, double-click the provided shutdown.sh script, select open and execute. You could also add the content of this script at the end of the startobd.sh script. In this case, closing HHGui will automatically shutdown the Pi. After waiting for a few seconds you can unplug the Pi/Pi-OBD module from the OBD2 connector.
Thomas Beck vor 5 Jahren
1. Configuration of the serial interface
In raspi-config, the configuration of the serial interface has been moved from Advanced Options to Interfacing Options.
Like on the Pi 3, the first hardware serial interface /dev/serial0 (/dev/ttyAMA0) is occupied by Bluetooth on the Pi 4. To make this available for the Pi-OBD module on GPIO 14 and 15, in a command shell type
Select Interfacing Options
Select Serial - Enable/Disable shell and kernel messages on the serial connection
Answer question "Would you like a login shell to be accessible over serial?" with No.
Answer question "Would you like the serial port hardware to be enabled?" with Yes.
Select Finish to exit raspi-config. If you are asked to reboot, do not reboot yet.
In a command shell type
and in the editor window add the line
Note: You can also use dtoverlay=pi3-disable-bt like on the Pi 3 because these two overlay files are identical.
Then save the file and exit the editor.
2. New start script for the Pi-OBD module
The gpio v2.50 command of wiringPi that comes with the Raspbian Buster September 2019 release does not function on the Pi 4. The wiringPi author declared it deprecated but provides an updated version v2.52 for it on his website. You can either install and use his new version or use the new raspi-gpio command that comes with the Raspbian Buster release instead.
In a command shell type
and in the editor window enter the following lines
Then save the file and exit the editor.
Then to make the script executable, type
After installation of HHGui, the OBD2 diagnostic software can be started by double-clicking the shell script, then.
Notes:
raspi-gpio parameters:
op = output
pn = pull none
pd = pull down (~50 kOhm resistor)
pu = pull up (~50 kOhm resistor)
dl = drive low
dh = drive high
On the Pi-OBD module there is a pull-down resistor mounted or configured for the BIOS=low/Bootloader=high input connected to GPIO 23 because if the input is left open, BIOS is selected.
On the Pi-OBD module there is a pull-up resistor mounted or configured for the Reset=low (active low) input connected to GPIO 18 because if the input is left open, no reset is active.
Thomas Beck vor 5 Jahren
HHGui inherits most of the OBD2-Analyser NG firmware v1.13.0 changes, especially:
- 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 on the Pi:
HHGui installation, usage and compile instructions are given in file Readme_raspberry.txt. This file is in the hhgui330_usr.zip file which also contains the HHGui binary for Raspberry Pi. The German PDF manual is also in this archive.
There are two different hhgui binaries and two different libhhgui_pi.a files in the archives:
For the Raspbian Buster September 2019 release, HHGui was compiled with gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1) and linked with GTK+ 3.24.5.
For the older Raspbian releases, HHGui was compiled with gcc version 4.9.2 (Raspbian 4.9.2-10) and linked with GTK+ 3.14.5.
HHGui v3.30 OBD2 Software Raspberry Pi/Windows/Ubuntu Source Code (2665kb)
Thomas Beck vor 5 Jahren
HHGui inherits most of the OBD2-Analyser NG firmware v1.12.0 changes, especially:
- 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 missing define HHGUI_PI for HHGUI Pi/ncurses variant in makefile_dev_hhgui
- 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 on the Pi:
HHGui installation, usage and compile instructions are given in file Readme_raspberry.txt. This file is in the hhgui321_usr.zip file which also contains the HHGui binary for Raspberry Pi. The German PDF manual is also in this archive.
HHGui v3.21 OBD2 Software Raspberry Pi/Windows/Ubuntu Source Code (2565kb)
Thomas Beck vor 6 Jahren
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:
HHGui inherits most of the OBD2-Analyser NG firmware v1.11.0 changes, especially:
- 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:
In addition to the above changes incorporated from the firmware, the following has been changed:
- 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 on the Pi:
HHGui installation, usage and compile instructions are given in file Readme_raspberry.txt. This file is in the hhgui320_usr.zip file which also contains the HHGui binary for Raspberry Pi. The German PDF manual is also in this archive.
HHGui v3.20 OBD2 Software Raspberry Pi/Windows/Ubuntu Source Code (2561kb)
Thomas Beck vor 6 Jahren
Changes:
HHGui inherits most of the OBD2-Analyser NG firmware v1.10.0 changes, especially:
- 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.
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 on the Pi:
HHGui installation, usage and compile instructions are given in file Readme_raspberry.txt. This file is in the hhgui310_usr.zip file which also contains the HHGui binary for Raspberry Pi. The German PDF manual is also in this archive.
HHGui v3.10 OBD2 Software Raspberry Pi/Windows/Ubuntu Source Code (2556kb)
Thomas Beck vor 6 Jahren
Added vehicle's "inspection/maintenance readiness status since DTCs cleared" to the diagnostics info area.
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.
HHGui Changes:
- HHGui has been ported to Windows and Ubuntu (64bit).
If you connect the Pi-OBD module via a serial-to-USB adapter to a Windows or Linux PC, you can also control it from there.
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.
- HHGui inherits most of the OBD2-Analyser NG firmware v1.9.1 changes, especially:
- 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 shows a new line "RDY: Y" (I/M readiness status: Ready = Yes) or "RDY: N" (I/M readiness status: Ready = No)
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.
Bugfix:
- 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.
- 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 on the Pi:
HHGui installation, usage and compile instructions are given in file Readme_raspberry.txt. This file is in the hhgui300_usr.zip file which also contains the HHGui binary for Raspberry Pi. The German PDF manual is also in this archive.
HHGui v3.00 OBD2 Software Raspberry Pi/Windows/Ubuntu Source Code (2588kb)
Thomas Beck vor 7 Jahren
This update adds support for several new PIDs (mainly engine torque related).
This update contains a bugfix for diagnostic trouble codes of hybrid vehicles.
Changes:
- compressed the 4277 DTC texts (uncompressed ~220KB) of the standard SAE J2012:2007, so that they fit into the lower 64KB Flash of the AT90CAN128 of the OBD2-Analyser NG.
For HHEmu/HHGui this just reduces the file sizes of the hhemu/hhgui executable files to less than half of the V2.81 release.
- 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
- 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
- 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 on Pi displays several text lines can be displayed.
HHGui V2.90 Anleitung (German User Manual) (209kb)
HHGui/HHEmu Raspberry Pi Source Code (858kb)
Thomas Beck vor 8 Jahren
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 all of them to be available via OBD2.
HHGui/HHEmu Changes:
- added command line option "dtc=Xxxxx". This option can be given up to 16 times to specifiy 16 DTCS for the OBD2 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 HHGui/HHEmu, the full text of that DTC is available if the configured DTC is selected in the DTC Summary menu.
For further changes see the 2017/01/06 update in the OBD2-Analyser NG firmware update project here.
Developer Section:
I have created a special source/library package for HHGui/HHEmu.
That package enables you to compile your own version of HHGui/HHEmu with a configurable number of visible menu/list lines.
The supplied libraries are created with gcc 4.9.2.
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 (Windows program) that came with the original firmware is located in the HandheldOpen_130.zip file on the main project page of my other project.
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.
To be able to compile this update you have to install the developer archive of GTK3+.
sudo apt-get install libgtk-3-dev
HHGui/HHEmu compile instructions:
Unpack the hhgui_hhemu_281_dev.zip archive to a directory of your choice. A directory HHOPEN_BIOS containing several subdirectories will be created there.
Open a shell, change to the directory HHOPEN_BIOS and depending on the program type
make -f makefile_dev_pi_hhgui DISPLAY_HEIGHT=x (*)
or
make -f makefile_dev_pi_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 that matches your display best:
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. The x/y-positions defined in that file could also be changed to get e better fit for your display.
For my displays the following DISPLAY_HEIGHT values match perfectly (see attached images):
HHGui/HHEmu with 10 lines (DISPLAY_HEIGHT=80) on 7" (800 x 640) display.
HHGui/HHEmu with 12 lines (DISPLAY_HEIGHT=96) on 3.2" (320 x 240) display.
Of course if you use values greater than 64, the OBD2-Analyser NG background image does not fit anymore. Remove it and use HHGui without it.
If you later decide to change the x, you have to delete the old object files first. Depending on the program this can be done with:
make clean -f makefile_dev_pi_hhgui
or
make clean -f makefile_dev_pi_hhemu
HHGui Video:
Diamex have released a video showing the assembly instructions for the Pi-OBD case. At around 8:20min in the video you can see the Pi booting right into HHGui using a customized Diamex background image. After that, it is shown how HHGui can be controlled via the touch screen.
German User Manual/Deutsche Anleitung:
Änderungen in der deutschen Anleitung zu HHGui V2.81 betreffen die neue Kommandozeilenoption dtc=Xxxxx, sowie die jetzt unterstützten 4277 Fehlertexte (Kapitel 3.3 und 5).
HHGui/HHEmu V2.81 Raspberry Pi Source Code (891kb)
HHGui V2.81 Anleitung (German User Manual) (197kb)
HHEmu compiled with DISPLAY_HEIGHT=80 for 7" display (800x640) (104kb)
HHGui compiled with DISPLAY_HEIGHT=96 for 3.2" display (320x240) (124kb)
Thomas Beck vor 8 Jahren
Für Deutsch sprechende Anwender habe ich im Anhang eine Anleitung fertiggestellt, die die englischsprachigen HHGui/HHEmu Projektbeschreibungen und Updates zusammenfasst. Außerdem werden HHGuis englischsprachige Menüs erklärt. Ein großer Teil der Anleitung kann auch für HHEmu und den OBD2-Analyser NG verwendet werden.
Thomas Beck vor 8 Jahren
I use the stacking header to gain some space under the 3.2" touchscreen display, so that even my DXM add-on breadboard built without bent pin headers can be mounted under the display.
In order to use the Pi-OBD add-on board together with displays connected via the GPIOs, a stacking header comes in handy, too. However, if using a stacking header, you might need larger spacers. I have attached images of the results below.
The Pi-OBD add-on board and a cool case suitable for a Pi with the official 7" touchscreen have been released by DIAMEX in the meantime. With their permission I have added images of the final version of the Pi-OBD add-on board and the case to the main project page.
If you want to use the Pi-OBD together with a display connected to the 2x13 or 2x20 GPIOs of the Pi, I suggest doing the following:
After that change you can mount your display on top of the Pi-OBD add-on board. However, you have to check the data sheet of your display first if no GPIOs conflict with GPIOs used by the Pi-OBD: GPIO 14, 15, 18, 23.
Assuming that no display using the SPI GPIOs actively uses the serial interface GPIOs 14 and 15 (a conflict that cannot be resolved), the relevant GPIOs to check are 18 and 23.
In case of the Waveshare/Joy-it 3.2" touchscreen there is a conflict with GPIO 18 that simply can be solved. That GPIO is used by one of the 3 general purpose push buttons on the 3.2" touchscreen PCB. Pressing a button pulls the signal to ground. Since GPIO 18 is used as active low reset input by the Pi-OBD add-on board, pressing the button connected with GPIO 18 would force a reset of the Pi-OBD add-on board. However, since GPIO 18 is configured as output for the Pi, the output of the Pi could get fried if pulled to ground while being active high. Since according to the Waveshare schematics the push button is connected right to ground without using a pull down resistor, the GPIO 18 output of the Pi that is set to high by the Pi-OBD initialization script (described in the Pi-OBD manual) will be destroyed.
In order to avoid that, cut the extended pin of GPIO 18 after the Pi-OBD add-on board solder joint for GPIO 18 or bend it. So that there is a connection for GPIO 18 just between the Pi and the Pi-OBD add-on board and no connection for GPIO 18 between the display and the Pi-OBD add-on board.
If you have developed software that uses that push button, you could wire GPIO 18 of the display to another GPIO not used by the Pi-OBD add-on board. Of course the software using the button has to be changed, too.
If a conflict for GPIOs 18 and/or 23 cannot be resolved by cutting an extended pin of the stacking header, the solution is more complicated.
By the way, I suggest adding the commands of the Pi-OBD add-on board initialization script to the startobd.sh script presented on the main project page. If you use the gpio command of the Pi-OBD initialization script, you might need the full path to the gpio command if you run the script during boot time, when the PATH environment variable is not set, yet.
The command returns the path (in my case /usr/bin/gpio).
For the Pi-OBD and HHGui started without background image the resulting startobd.sh script could be like this:
DXM add-on breadboard with GPIO stacking header (135kb)
Pi-OBD add-on board with GPIO stacking header (126kb)
Pi-OBD add-on board with GPIO stacking header (123kb)