Today I finally managed to measure the signals on the digital speed sensor. I don’t own any of the Rz-1 digital cluster parts, but luckily, a friend borrowed me his sensor and allowed me to reverse-engineer it.
The speed sensor has a connector with three pins: black (right), yellow (middle), red (left).
Based on what I measured, black is GND, red is +5V supply, and yellow is the speedometer signal. The based on my scope prints, it seems that per revolution of the speedo cable we can see 24 pulses:
When I rotate the pin of the speed sensor at about one revolution per two seconds, the cluster shows me – very roughly – 13 km/h.
When only connecting the +5V and GND, but leaving the signal pin open. the signal looks idential. When rotating the pin of the sensor, the 5V pulses on the signal line are still visible.
Therefore, it seems we can just use a 0-5V PWM, and bring it onto the cluster, and it should display the speed signal.
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:
window will pop up. Configure as follows:
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:
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:
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:
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.
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]
Displayed Fuel Level
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
With this information, you should be able to build your own adapter for the fuel sensor.
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.
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 🙂 ).
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
MBDAK 3 with highest details: real-time shadow calculation, fog, particles and hightest texture quality
MBDAK 3 menu intro. Graphics were hand-drawn, scanned and colorized… with Microsoft Paint.
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.