How to setup the ESP32 to visualize OBDII Data…

This manual describes how to use an ESP32 as an extension to the existing OBDIIC&C device, available for the Honda Insight ZE1. This device will not add any new features, but will allow you to visualize the OBDII data on your smartphone.

If you are looking for a tutorial on how to read data from an OBDII connector, this ist the wrong place.

First, you’ll need an ESP32. Connect the ESP32 via a Micro USB cable to your PC. Install the drivers, if necessary. The ESP32 should be recognized as a COM port:

Download the ESP32 Flash Download Tool from the website:

Select “Tools” -> Flash Download Tools (ESP8266 & ESP32) .

After downloading, start the flash download tool.

Select “ESP32 DownloadTool”.

The main window will pop up. Configure as follows:

SPI flashing, 32Mbit flash, 40 MHz SPI speed.

Add the binary to the list of files to flash, and set a start address of 0x0. Also make sure to choose the correct COM port. After setting up everything correctly, press „START“.

If everything works OK, the download should take about ~ five minutes.

After reset the target, you should see some debug output in the serial interface, looking like this:

How to Connect the ESP32 to the OBDIIC&C

To make sure the ESP32 can talk with the OBDIIC&C, we need to connect three wires:

  • GND
  • UART Rx
  • UART Tx

However, the logic levels of the two MCUs are different. The PIC uses 5V TTL logic for the UART, the ESP32 3.3V. Additionally, the logic levels are inverted.

Hence, you need two transistors to adapt the signal levels, and invert the logic levels at the same time. Have a look at the example schematics below to understand how to wire things up:

How to connect the ESP32 to the OBDIIC&C data logging port

Note that the pins of the ESP32 used for UART communication are D22 and D23, not the pins labeled “RXD” and “TXD” next to it (this is a different UART channel). The ESP32 supports connecting the second UART to any pin of the device. The first UART peripheral is available via USB or the RXD and TXD pins, and is used for flashing an debugging. The second UART, on pin 22 and 23, is used to communicate with the OBDIIC&C.

Please double-check the pinout on the “headphone” plug on the OBDIIC&C, make sure to measure which pin is GND first.

3V3 are directly available on the ESP32, 5V you’ll need to get from the OBDIIC&C.


Below, you will find the download link to the ESP32 software:

Honda Insight ZE1 OBDII Smartphone App

I’ve been using Peters OBDII C&C for quite a while now, and while I like it’s features, it lacks the intuitiveness of a modern smartphone app. So I thought it’s about time to improve this!

System Architecture

Two MCUs are working together to read the OBDII data from the car, and transmit it vie BLE (Bluetooth Low Energy). The data is transmitted to the smartphone, where it is visualized.

The two controllers are one PIC and one ESP32, the PIC is programmed by Peter, and used to interface the OBD, while the ESP32 is programmed by me, used for forwarding the data to the smartphone.

Both MCUs communicate via UART.

See a first running demo of it here:

Nissan Rz1 Digital Cluster Conversion

A few years ago, I modified a LHD Nissan Sunny B12 Coupé Rz1 and fitted a RHD JDM digital clusters, and uploaded a short video of it on youtube.

I received a lot of questions on this modification, and decided to publish the knowledge I gained here.
Most importantly, here is the pinout.

Pinout Comparison of the RHD JDM loom and the LHD EUDM/USDM loom

Connector Pinout

The connectors are drawn on the left side. Basically, you see five connectors here. Connector “A”, “B”, and “C” under the header “Digitaltachostecker” describe the connector of the digital cluster. Connector “A” is the large one that powers the talltales and warning lights, connector “B” is the hard-to-find black one, that provides all the actual digital signals. The three-pin connector “C” can not be found on the cluster, but is the connector on the tachometer sensor in the engine bay (you need that part too).

The connectors labeled with “EU stecker” refer to the ones that you will find in your LHD Rz1s that came with analog clusters. You should most likely find them in your car if you remove the cluster.

In case you have a low-end spec B12 that came without a rpm gauge (some U.S. Sentras maybe?), your connector layout is probably different again.

The drawings show the connectors (sockets) on the cluster, as if you look on the backside of the cluster. They do not show the connectors on the harness!

The first problem you’ll face is that you need to get the small connector “B”, which, if it is not attached to your digital cluster, is pretty much unobtanium. You could try to find the original part number or a the part number from the supplier who made this connector, or in the worst case, replace the connector with a diffent type of similar size / pin cont and just solder everything together.
The white, larger connector “A” is physically identical to connector “A” of your LHD harness, but with a different pinout.

You got your hands on some plugs? Good, then you can already solder everything together, and your digital cluster should already party come to life. PRM, turn indicators, telltales (except exhaust temperature), temperatur gauge and fuel should come to life.

Vehicle Speed Sensor

The next difficult task it to get a speed sensor. The analog clusters uses a mechanical speedo cable that connects the gearbox to the speedo pointer – that is 100% mechanical oldschoolness!

For the digital cluster, NISSAN chose to go half they way – they still use a mechanical cable, about 50 cm long, that connects the gearbox to an electrical sensor. That sensor converts the motion into PWM signals, that are electrically supplied to the cluster. For the conversion, you will need both the cable and the sensor. If you don’t have these parts, then the installation will be a bit more difficult. They will plug&play fit to any gearbox.
The digital sensor is connected with two cables, C2 and C3, to the main plug of the cluster. So you will need to add two wires from your engine bay to your cluster.

If I remember correctly, the speedo singal is triggered twice per revolution. If you don’t have a sensor, you might want to use a function generator and try to get your cluster displaying something. If you are struggling here, feel free to leave a comment, then I will look up the technical details.

From the youtube comments on my channel, I understood that there seem to be different types of sensors, depending on which engine / gearbox your donor car had. It is likely that non-matching gearboxes will provide false readings on the speedo! If this is the case, then you would need to invest more engineering into the problem, e.g. use a small microcontroller to correct the signal.

I once tried to fit a digital sensor from the B13/N14 series into an E16i gearbox, but they wouldn’t fix plug&play. The main problem was that while the diameter was the same, the axis of the sensor was slightly offset. With some fiddling you might be able to mount them, though.
These sensors might fit for the GA16i gearbox, though. If you tried going this way, please leave a comment and share your experiences! it would definitely be cleaner looking than the OEM B12 parts.

You will have to figure out a solution to mount the speedo sensor in your engine bay, as the LHD / RHD firewalls are different. I suggest to use a little metal plate to mount the sensor to, and then adapt that to the firewall.

Incorrect mounting with too much tension on the cable might lead to the speedo not working at all, faster wear-out or not working at all.

Fuel Level Sensor

A problem which is not yet solved, it the fuel gauge. The fuel sensors used in the JDM digital cluster cars have a different characteristic.

The analog clusters use an 8V voltage regulator, which is connected to the fuel gauge and the fuel sensor in series. The resistor value of the LHD fuel sensor is as follows:

Resistor Value [Ohm]10100
Displayed Fuel Level100% (full)0% (empty)

The digital cluster characteristic is quite different. I used a JDM cluster and measured the fuel input. The fuel sensor is supplied by 5V, and depending on the resistor values, the following fuel level is displayed:

Resistor Value [Ohm] Number of bars
14,9 14 (full)
20,414 (full)
10000 (empty)

With this information, you should be able to build your own adapter for the fuel sensor.

Propeller Clock

This project started in 2010 as a university project with the goal do develop a rotation clock. Main objectives of the project was to develop an induction power supply using a MOSFET H bridge and and to layout a PCB. The PCB contains a 8051 microcontroller and ten OSRAM RGB LEDs as well as an optical reflex coupler. The board is mounted on a rotateable motor, which propels the board to 40 rotations per second. Based on the input data of the reflex coupler, the microcontroller then calculates the current position and switches the LEDs on or off so that the user sees a stable image.

Layout of the PCB.

The PCB features a power supply that suported AC/DC inputs, ranging from 7 to 20V, while delivering a stable 5V DC current used to power the 8051 microcontroller soldered onto the PCB. The board is powered using induction. A MOSFET H bridge is used to power the primary coil, while the secondary coil is mounted on the rotateable part. Programming started in Assembler (requirement of university), but will be finished in C. The project is not yet completed – the PCB works as expected and the induction power supply is working, but the current mechanical setup is not fast enough to create a stable image. Development is still ongoing (only problem is time 🙂 ).


Data sheets:

Technical drawings:


Project documentation on my university’s website:

MBDAK 3 – A 3D Flight Simulator

MBDAK 3 is one of my software projects that I wrote in the years 2007 and 2008. It is a 3D engine designed for flight simulator games written in Delphi 7. In this project, I focussed on creating an engine of highest compatibility and flexiblity. It was the first time I came in contact with dynamic linked libraries which I have used to create a flexible interface to the 3D and the sound API. Both the graphical and the audio subsystem are encapsulated in separate DLL files. Different implementations of these DLLs allow the use of different graphic libraries. Implementations were done for the Direct3D 8 and OpenGL API, thus it is possible to change the 3D output API by just exchanging the DLLs. This is no problem as both provide the same interface. The sound subsystem uses the FMOD audio library, which is also stored in an encapsulated dynamic library file.

The levels are stored in text files. Each level iteself consists of a set of building blocks, the so called level entities (i.e. scyscrapers, cranes, streets and other level elements). Each entity provides a file containing the 3D data for rendering and a collision model file, which is mostly a simplified version of the 3D data and several attributes (destroyable, material properties, additional data for light and particle effects). Each entity can then be placed multiple times at any position in the 3D scene. Other data which is being configured in the level file is the type of aircraft the player is flying, its weapon arsenal and other important attributes (starting position, position light data, etc). This was done to provide a maximum of flexibility in the level design.

Another important goal during the development of this engine was to make the simulation as realistically as possible and to become familiar with the latest rendering technologies at that time. The engine therefore uses MipMapping texture filters, fog and dynamic lighting and, most importantly, is able to perform dynamic real-time shadow calculation with the help of the stencil buffer using the Carmack’s Reverse method. However, interesting things such as bump mapping or shaders were not been used. The reason for this was first, because compatibility with non-T&L-capable video cards (I am a huge fan of old 3dfx video cards and the game was developed on a Voodoo5) was desired and second, because of the lack of time. I still had to go to school at this time.

I would like to thank Mr. Plöchinger, also known as DungeonKeeper1 in the german VoodooAlert board, for providing the MBDAK 3 soundtrack! The 3D models were partially created by myself using Milkshape 3D, while some others were extracted from older computer games. For this reason, I unfortunately cannot publish this game.

Abilities of the 3D Engine

  • Selectable 3D API: Direct3D 8, OpenGL und 3dfx Glide are supported
  • Support of real-time dynamic stencil buffer shadows
  • MipMapping texture filters
  • Dynamic environment loading systen
  • Collision detection using separate collision models based on a combination of octree data organisation and spheres / triangle collision detection for best performance
  • A simple particle system supporting alpha blending and z ordering

Shown below are several screenshots of the current development stage. Unfortunately, I cancelled the project after two years of development due to other priorities (studying). Besides that, creating 3D simulations using Delphi was not the smartest choice and the quality of the source code was miserable as only structures and no classes were used.

MBDAK 3 - Flugsimulator

MBDAK 3 with highest details: real-time shadow calculation, fog, particles and hightest texture quality

Screenshot of the main menu

MBDAK 3 menu intro. Graphics were hand-drawn, scanned and colorized… with Microsoft Paint.

Menu screen starfield simulator

MBDAK 3 menu. Graphics were done with Adobe Fireworks. The little preview window in the top left corner is inspired by Nintendo’s Starwing. It contains a little starfield simulator.



You can download the documentation of the project “MBDAK 3” under the following link:

Facharbeit Facharbeit “Entwicklung eines 3D-Spieles” and its attachement  Anhang containing the graphics.

If you have any questions please contact me under “Imprint”.