Gauge Cluster Tester Mark II

[Heineken]

The RPM control signal is technically the same as in the first generation tester. A 12 V rectangle signal needs to be created and send to the cluster. Instead of a dedicated transistor circuit the 12 V output drivers are going to be used. Required frequencies are comparably low, therefore no issues were expected.

As often as this sentence is uttered, the result isn't as expected. When trying it for the first time, the needle moved to a maximum of ~4000 RPM and fell back to 0 if a higher value was selected. Sounds like an issue with the signal quality. To further analyse it, my trusted Philips oscilloscope came to the rescue. Its doesn't offer any fancy calculations but it ideal to have a look at the overall wave form.

Looking the the input signal from the Arduino to the output driver, everything looked fine. It's 2 V per division on the display grid making it ~4.6 V peak-to-peak. As the Arduino's logic level is 5 V, that's fine.

Input Signal

The output on the other hand didn't look very much the same. Output voltage is at an OK 12.6 V peak-to-peak but the signal doesn't look very "square". It seems the output driver has issues dropping the voltage back to 0 V after being told to do so. The higher the frequency the bigger the problem until the RPM's detection circuit calls it quits.

insufficient Output Signal

A little research in the data sheet of the output driver showed that it's a so-called Open-Emitter driver and therefore can't actively bring down voltages at its output. As the cluster's detection circuit isn't good at either above waveform is the disappointing result. The good thing: It's easy to solve. Simply adding a 1,5 kΩ resistor between ground and output of the driver. Even if the driver is at 12 V the current at the resistor is very small (8 mA or 100 mW) but helps dramatically dropping the voltage to 0 V:

much better

Integrating this resistor into the tester would be possible without a new PCB design but as it's probably not the last change required, we are going to put on the list of upcoming changes for the next PCB order. For now let's enjoy the quick response of the RPM needle when changing the corresponding value on the tester:

[Heineken]

The gauge cluster used in all previous videos and pictures is from a 1997 AT NSX with manual shift control at the steering wheel. Due to this, the RPM dial contains an extended shift indicator. The '3' location has been renamed to 'M' and enables a small display on the side that shows the currently selected gear.

1997 AT (JDM)

Without any bus communication and considering the electrical backwards compatibility with existing switches and ECUs, this results in an overall number of 10 pins used to control the gear indicators on the dash.
Having individual elements to control them would be highly confusing, especially since some of the indicator lights work by connecting to ground other to battery voltage (depending on the indicator) and the three pins for the gear number display are of a rather uncommon standard used in older tabulator machines.

The issue can be nicely solved in software, though. As mentioned in a previous message, the signal module takes care of basic pin behaviour (like connecting to ground or to battery voltage) the element module one layer above groups signals into elements to be displayed and changed by the display module. Configuring the signals properly and introducing a new gear selection element with corresponding graphics resulted in a user interface that simply scrolls through all possible options:

Note that some of the indicators react a little slow - this is due the output pins of the Arduino not being put into the correct mode causing the outpur drivers to to be triggered insufficiently. It's already fixed and the indicators are now lighting up fast and crisp - just like they should.

[Heineken]

One big dial is still missing, the speedometer. The exact design of the corresponding signal can be found in this forum entry.

Utilizing the new hardware, a separate driving circuit is no longer necessary. One of the output drivers that provide ground can be used to simulate the VSS (Vehicle Speed Sensor). It was a little surprise to me that everything worked right away:

Testing the speedometer should not take too much time as the odo and trip meter starts running, too. All bench testing combined already put about 20 km on the car without moving it an inch ..

The number of cables running towards the gauge cluster in above video increased significantly. A nice example why bus communication became, at some point, necessary for modern cars.

All main functions are running now but three minor issues have been detected and need to be corrected in a new PCB design. We'll talk about those in the next days.

[Heineken]

This is the final update to complete the circuit and PCB design. Two issues have been observed while prototyping the tester:

• The output drivers are too weak to supply the gauge cluster illumination (driver chip overheats)
• The output drivers internal voltage drop is too high for the fuel gauge (doesn't reach maximum)
• Not enough ground pins

There has been some delay as the parts required to solve above issues where stuck in transit for almost two weeks, sorry for that.
Let's have a more detailed look at the problems and their solution.

Weak Output Drivers
The cluster's minimum current usage is ~1 A (at 12 V). Enabling all warning lamps pushes it over 3 A, adding illumination results in more than 4 A. Summing that up we are looking at ~50 W being used by the cluster (with illumination switched on). As most of that current is distributed across a large number of pins it's not a problem for the tester but illumination draws ~1 A across two pins with the left connector being responsible for 2/3rd or 0.75 A.
Each driver output pin can provide ~0.1 A. Enough for most of the cluster but not for those 0.75 and 0.25 A illumination pins.

Driver chips with similar characteristics but higher output rating aren't available so it becomes necessary to add more punch to the affected illumination pins by means of a discrete circuit. Out of curiosity, the decision was made to realize it with MOSFET transistors. Those are more and more common today as they typically have very low resistance, fast switching and are often controlled digitally with high frequencies.
Only the first of those main advantages serves as a bonus in this application but the others won't hurt either.

The circuit ..

.. the wire connected MOSFET ..

.. and the result

The internal resistance of the MOSTFET is so low (0.05 Ω in case of the IRF5305 used here) that it could handle up to 30 A and therefore didn't even get warm during testing. Note that another pull-down resistor is required to avoid the problems observed during RPM gauge control. Case closed, on to the next change.


Too high internal Voltage Drop
Driving the fuel gauge is done by periodically pulling down the reference voltage from the cluster to ground (PWM control). If it's permanently pulled to ground the gauge exceeds the "full" level. Unfortunately, the output drivers have a minimum voltage drop associated with them that prevents a complete pull to ground. The needle stops a few milimeters before hitting "F" so that gauge is not fully testable.

As mentioned above, MOSFETs feature a very low internal resistance (and a corresponding low voltage drop) so using one of them instead of the driver IC should solve the issue. As the order of the was delayed by several weeks it took a while until the circuit could be tested.

The circuit ..

.. more extra wires ..

.. and it works

The selected IRLD014PBF can be directly controlled by the Arduino and provides an internal resistance of 0.2 Ω. As the fuel gauge is specified to display "F" at 3 Ω, that is indeed low enough as it can be seen above.

Final location of the two MOSFETs and the one pull-down resistor was decided to be between the two green connector sockets. The 3D view of the PCB editor provides a nice preview of them on the final PCB:

Not enough Ground Pins
After one more careful review, new PCBs are going to be ordered. These will include a few more improvements (especially related to layout and pin numbering) and an additional ground pin. Most of the changes can be covered in software but one or two wires need to switch positions on the connector to make everything work.

Remaining Steps
Several items remain on the To-Do-List before the project can be considered done. One of them is to be able to return my cluster to the car which means the connection cable to the cluster needs to be documented and a PCB created that allows to check copies of that cable without connecting it to a real life cluster.
One more important step is to provide a cable supporting the <1995 clusters. As no such cluster is available to me, Drew from NSX Prime is gonna help with that.
To be able to continue working on the software without risking to break functionality an old Legend cluster (374,000 km) was acquired and needs a matching cable set, too
A significant amount of work but very much looking forward to it

[ozon02]

As always, full of professionalism, I look forward to the end result of your wonderful work

[Heineken]

As always, full of professionalism, I look forward to the end result of your wonderful work

Thank you very much, that keeps me motivated

[britlude]

looking good, nice to see useful stuff being designed and made