Honda D Series Forum banner

1 - 11 of 11 Posts

·
Registered
97 Del Sol
Joined
·
78 Posts
Discussion Starter #1
I was considering making a digital dash display for my 97 Honda Del Sol. I was wondering if anyone had details on the connections of the gauge cluster to the vehicle. I was considering using and arduino/atmega/raspberry pi to get the IO and run the display.

My manual tells me what the pins are for but I need to know the expected voltage or signals (pwm etc) sent to indicate the various levels of the analog displays, such as the fuel gauge, tachometer and speed sensor. I could possibly figure these out, but my lack of an oscilloscope makes things difficult.

Thanks in advance for any help you can provide.
 

·
Registered
Joined
·
6,242 Posts
find a del sol tech manual, and look up sensor tables.

You can get ranges for fuel level, coolant temp that shows on gauge (as its only a small sweep shown, but receives more), and you can dig into things to find the actual pulse rates for things like tachometer, and speed.

It would be under the diagnosing menus, verifying correct sensor data.
 
  • Like
Reactions: EFB055

·
Registered
Joined
·
6,242 Posts


This one isnt perfect, but would be a necessary addition if you plan on your digital display.

Keep in mind, since you are OBD2, you do have some advantages. there are several super cheap OBD2 data dispaly gauges you could cut apart and figure out, and reprogram.
 

·
Registered
93 Civic HB SI
Joined
·
918 Posts
Are you currently familiar with any object oriented programming languages? If not, Arduino uses a derivative of C++, and RsP uses Python. If not, you'll need to know basics of Object Oriented Programming (oop) to do what you plan on doing (youtube and online tutorials are your friend here).

I dont have the ranges all documented, but you would do well in this quest to invest in a cheap 2 channel usb PC based oscilloscope, and figure out all your IO the old fashioned way. If you're in the realm of diving into the world of multiple variable IO with Ard/RsP, you'll want one anyways. You'll want to know your signals BEFORE buying kits or parts, this determines your baseline requirements for hardware right off the bat.

This cluster project in the del slo is a good learning platform if you're really into this kind of stuff, as all the signals will be basic, primitive and all behavior for the different component types you'll be dealing with have been used in the automotive industry for well over 50 years, and they will be very well documented in places all over the internet.

You won't find everything you're looking for in this regard within a service manual, your talking about operational expression of actual signals within the wires. Roughly 95% of all a technician really cares about is if a circuit is good, components are good, and what the world looks like from the viewpoint of a multimeter. He rarely cares about how things actually function at a low level. The other 5% are the exception, and become engineers.

Engineering will write and document out the entire vehicle operation inside SRS (System/Software Requirements Specification) document(s), which are then peer reviewed by a panel of SMEs (Subject Matter Experts) and engineers to dumb it down even further. This dumbed down version becomes the basis for the troubleshooting guide. OEMs don't like to leak trade secrets, they let as little low level functionality out the door as possible. The very things you are looking for in this case.

The most direct route to what you're looking for, would be to get creative and reverse engineer you're own cluster. If your current car runs well, and the cluster works properly too, you're in the best possible position to correctly reverse engineer this. You'll need a scope, multimeter, a decent backprobe pinout kit, the internet and a notepad and pencil. It is entirely possible to do with these tools, coupled with the Arduino or RaspberryPi kits out there these days.

You should be able to do everything from the drivers seat with the cluster pulled forward, connectors exposed but still plugged in. Use the vehicle schematics, figure out what wires do what for the cluster operation, note the wire pin location and color on your paper, then scope the signal while functional.

  • For tach, you should be able to determine full operational characteristics by observing the scope measurements, KOEO, KOER, idle and redline readings. Determine the characteristic window and thresholds that express your RPM min/max. Done. Write code to interpolate a readout between your defined min/max range based on your current cluster, and configure some basic error handling for OOB and any foreseeable exceptions.

  • For speedo, just do exactly the same thing.

  • For temp sensor, this should be cake. This is actually something that should be documented in troubleshooting manual, a temperature/resistance or voltage relationship chart. Use the scope and an external thermometer or thermocouple to verify what your reading against the chart, or simply infer a scale based on your ambient vs operating temp measurements.

  • Fuel sender will be a bit tricky if the TS guide doesnt spell out the level/resistance or voltage relationship for you. You may opt to pull the sender out, or grab a junk one from a similar civic at a junkyard and plug into the harness connector for sending unit, and manually sweep the sensor to determine your range on the scope.

  • All your other lamps are simply inputs via supplying ground or power to the indicator circuit. Activate as many of them on the car as you can, and monitor the scope for the type of trigger signal present. Code those against an appropriate input and done.

After you've written down all your operational boundaries for each parameter, and their underlying characteristics, you can begin to purchase your required Ard/RsP components based on your measurements, as well as begin the coding process.

Once you've roughed in some code, you'll want to install the whole setup on the car, and MAKE SURE to configure and code in some basic logging! You want to trace places where your parameters go out of bounds or any places where you might not be handling any exceptions.

Then make your logging and error handling more robust by coding in more levels and specifics related to the errors as you discover them. You want your error log to be YOU readable when you finish, and you'll know when your logging is robust enough when you can stumble across an error and read exactly what went wrong. "Unhandled Exception" is not a proper error haha, that just means you didn't account for the possibility when you coded things. Account for the errors, log everything, and prevent as many undefined issues as you can. Debug at its finest :)

Then modify the code to repair and handle any errors.

On TOP of all this, you'll need to learn the basics of Graphical User Interface (GUI) design to wrap up all your code into a cool looking package.

By the time you come out of this, you'll be electronics engineer, software engineer, automotive technician, and after a ton of money and time spent, wondered why you didn't just buy a plug and play dash from some other company.

If you're still up to the challenge after reading this and none of this intimidates you, you sir are part of the elusive 5% of technicians.
 

·
Registered
93 Civic HB SI
Joined
·
918 Posts
What mattliston said... since you're OBD2, digital plug and play dashes are a dime a dozen on Al Gore's internet.
 

·
Registered
97 Del Sol
Joined
·
78 Posts
Discussion Starter #6 (Edited)
Being a 97, I wasn't sure the latency on the OBD2, in what would be brand new tech back then. Hence the direct interfacing with the panel signals.

I am a senior software engineer and I work with autonomous (self-driving) vehicles. I literally write the software drivers to interface with the vehicle canbus (though I am given the dbc files). Which require safety, logging and testing.

I already wear all the hats (except for the AI or perception systems) when it comes to development so I have 90% of the skills already. I am a novice in electrical engineering, only haven made a full adder out of npn (RTL logic).

I am fully prepared for the stupid involved in this, short of owning my own oscilloscope (my fluke doesn't have the feature). We do have a couple grand osci at work, but I am not gonna pull my 97 Honda into the lab to use it.

But I thank you for your long write up.
 

·
Registered
97 Del Sol
Joined
·
78 Posts
Discussion Starter #7 (Edited)
I have done a little work, I will not post my research until I have a functional display, since it may not be completely accurate. But most of the normal lights are 12v, and the tachnometer appears to be a kind of pulsed modulation (maybe not pwm), where are the fuel gauge and the temperature gauge appear to be voltage or current based. The precise values for these is not yet known.

However here is an image of my first modifications to a spare gauge cluster.


I don't have a bunch of spare wire colors, so I just used two and labeled them instead. I have soldered the wires in place with some non-silver non-lead solder and doused it with super weld to isolate the solder joints and keep things from moving around too much. I plan to use some hot glue to give it some additional vibration padding and isolation in the more dense locations.

I have a 8v-40v to 12v 3a buck converter with a 12v to 3.3v 6a buck converter on top of that to handle the logic power (12v directly for display back lights). I have plans to use some optoisolators I had to handle the raw signals (to avoid frying my logic board), this may not work for the gauges, but it should for the status lights.
 

·
BATSLOMAN GIVES NO FUCKS.
Joined
·
4,704 Posts
 

·
Registered
93 Civic HB SI
Joined
·
918 Posts
Being a 97, I wasn't sure the latency on the OBD2, in what would be brand new tech back then. Hence the direct interfacing with the panel signals.

I am a senior software engineer and I work with autonomous (self-driving) vehicles. I literally write the software drivers to interface with the vehicle canbus (though I am given the dbc files). Which require safety, logging and testing.

I already wear all the hats (except for the AI or perception systems) when it comes to development so I have 90% of the skills already. I am a novice in electrical engineering, only haven made a full adder out of npn (RTL logic).

I am fully prepared for the stupid involved in this, short of owning my own oscilloscope (my fluke doesn't have the feature). We do have a couple grand osci at work, but I am not gonna pull my 97 Honda into the lab to use it.

But I thank you for your long write up.
Your response is like "the big dick in the locker room" response haha.

Everyone thinks their shit is above average till they see "that guy"...
 
1 - 11 of 11 Posts
Top