Reimagining the Porsche 928 Instrument Cluster – Part Two
From Digital Gauges to Vehicle Diagnostics
Imagine your battery gauge was more than just a voltmeter
The first version of this project was supposed to be three gauges. In hindsight, it’s laughable that I didn’t see the obvious flaw in that plan - my complete inability to stop developing something once it works.
My old boss used to say to me, “You love giving yourself work, don’t you?”
He was right.
It’s both a blessing and a curse. And a curse.
Unfortunately, the list of things I want to do with the gauges has been growing considerably faster than the amount of time I’ve had to actually do any of it. Between my day job, getting Sirius Fabrication established on Rennlist, and the rather welcome problem of having orders to build and ship, this project has been sitting on the bench squinting accusingly at me far more often than I’d like.
Version Zero. It’s not pretty, but it works (mostly)
It probably doesn’t help that my ADHD tendencies aren’t particularly interested in focusing on one thing at a time. So while I should probably have been concentrating on getting the original three gauges completely sorted, I’ve also been designing a new engine-bay PCB, investigating additional sensors, adding CAN capability and generally finding exciting new ways to increase the scope of the project.
But before getting into where all of that is going, I should probably talk about how the original system has actually been working.
Out of the Workshop
Since Part One, the prototype has made the fairly important transition from something scattered across my workbench to something actually installed in the car.
All three displays are now fitted in the centre console, along with the engine-bay electronics enclosure and the first of the sensors. The two ESP32-based systems communicate wirelessly, with the engine-bay node collecting data and sending it to the displays in the cabin.
At this point it stopped being a collection of interesting experiments and became something I could actually use.
And shortly after installing it, I had an excellent opportunity to find out whether it worked.
1,000 km of Testing
In August, I drove the 928 to the Sharks in Ontario event. Just like last year, it was a great weekend of Sharks putting smiles on their owners’ faces, and their owners sharing laughs, stories and a common appreciation for these wonderfully strange cars.
The trip put roughly 1,000 km on the car and became the first proper long-distance test of the complete gauge system. Three displays running continuously, the engine-bay node transmitting data, GPS tracking distance and speed, and the whole lot being subjected to the heat, vibration and electrical peculiarities of a 39-year-old Porsche for hours at a time.
Overall, the system performed remarkably well.
There was just one small problem.
While the car covered roughly 1,000 km (620mi), my shiny new GPS odometer, however, only showed 175km (110mi).
So that was encouraging.
When a GPS Problem Isn’t a GPS Problem
My first suspicion was fairly obvious: reception. The GPS antenna is tiny and lives in a dashboard containing three displays and their associated electronics. During the drive it seemed entirely plausible that the receiver was simply struggling to maintain a reliable satellite fix.
That sent me down the path of investigating antenna placement and ways of moving it farther away from the displays.
Except the GPS receiver wasn't really the problem.
Once I was able to do some proper debugging, I discovered that the receiver was getting considerably more valid GPS data than the odometer suggested. The code responsible for deciding when that data was valid was just discarding it most of the time.
That's an important distinction.
There’s a tendency with projects like this to assume that once a sensor starts producing numbers, that part of the job is finished. In reality, receiving data and receiving trustworthy data are two very different things.
That lesson was about to become something of a recurring theme.
Debugging a “16 volt” reading on a sweltering Ontario evening.
Trust, But Verify
It stayed at +-0.03V from the multi-meter reading
Battery voltage is one of the simpler measurements in the system.
The car's voltage is reduced through a voltage divider to something the analog-to-digital converter (ADC) can safely measure (no more than 5V). The software then reconstructs the original voltage and displays it on the gauge.
Simple enough.
Except I don't want these gauges to display numbers that merely look plausible. If the gauge says 13.78V, I want to believe the electrical system is actually at 13.78V.The trip put roughly 1,000 km on the car and became the first proper long-distance test of the complete gauge system. Three displays running continuously, the engine-bay node transmitting data, GPS tracking distance and speed, and the whole lot being subjected to the heat, vibration and electrical peculiarities of a 39-year-old Porsche for hours at a time.
So I spent some time measuring the actual resistor values, adjusting the calibration and comparing the gauge directly against a digital multi-meter under changing electrical loads.
Eventually, I had the two tracking each other to within about 0.03V.
I posted a short video of that test on Rennlist and Instagram, and the response was extremely encouraging. There were some very complimentary comments about the accuracy and about the gauge project generally.
That was particularly satisfying because accuracy is the entire point.
A beautifully animated gauge confidently displaying the wrong number is really just a very small liar mounted in your dashboard.
Which brings me to fuel pressure.
Fuel Pressure and another very small liar
Fuel pressure should have been straightforward…
I already had the ADC working.
I had a 100psi automotive pressure sender.
I had the software to convert its voltage into pressure.
I had an analog pressure gauge showing 40psi, but the pressure transducer would have me believe there were no fuel pressure
And so began the all-to-familiar debugging process…
Check the wiring. Check the ADC voltage. Check the conversion. Check the grounds. Question the code. Question the hardware. Question previous life choices.
Eventually, I tried a spare 30 psi pressure sender and suddenly, I had meaningful data.
That was actually excellent news because it demonstrated that the electronics and software were doing what they were supposed to do. The original 100 psi sender was apparently the culprit.
I ordered a 60 psi replacement and a 15 MPa sender arrived. For reference, 15 MPa is roughly 2,175 psi. Measuring 2,175 psi of fuel pressure might become important if I ever convert the 928 to run a hydraulic excavator.
Another sender was ordered.
Eventually I'll run out of ways for this particular measurement to go wrong.
Probably.
From Prototype to Purpose-Built
While I've been debugging the existing hardware, I've also been working on its replacement.
The engine-bay electronics shown in Part One were very much a prototype: perfboard, modules, wires and connectors assembled into something that proved the concept, but wasn't exactly an elegant long-term solution.
It worked, which was its job.
The next version is a properly designed custom PCB. Not exactly this AI-generated image, but something like it
Engine Bay PCB v1 should provide more than twice the available inputs while occupying roughly a quarter of the space. It also allows the power supply, signal conditioning, ADCs and communications hardware to be designed as a single system rather than assembled from separate modules.
The result should be smaller, cleaner, easier to install and considerably more expandable.
And those extra inputs aren't there just because I had room for them.
I've started finding things to plug into them.
Meanwhile, Someone Else Had a Very Cool Idea
Somewhere in the middle of all this, Instagram's algorithm did something useful and showed me another 928 instrumentation project.
It's a prototype for a much more comprehensive digital replacement for the original 928 instrument cluster, and it looks seriously cool.
What I particularly like about seeing projects like this is how differently people can approach the same basic problem.
That project appears to be reimagining the main instrument cluster itself. My approach has been to retain the original Porsche instrumentation and build an additional, modular information system around it.
Neither makes the other redundant. They're solving different problems, and it's great to see somebody else looking at a 928 dashboard and thinking that perhaps Stuttgart didn't necessarily have the final word on the subject in the 1980s.
It also got me thinking again about exactly what I want my own system to become.
Three Gauges Aren't Enough
Once the engine-bay node existed, something changed. I'd already done the difficult foundational work.
There's a computer in the engine bay capable of acquiring sensor data. There's another system in the cabin capable of receiving and displaying it. There's an ADC. There's GPS. There's persistent storage. There's wireless communication between the two.
At that point, adding another screen isn't particularly interesting.
Adding another measurement is.
I've subsequently started investigating manifold pressure and vacuum, oil pressure and temperature, coolant temperature, wide band O₂, and even measuring starter current during cranking.
Not because I intend to create a dashboard containing seventeen gauges demanding constant attention.
Quite the opposite.
Most of those measurements become considerably more interesting when you stop thinking about them as gauges.
From Gauges to Diagnostics
A conventional gauge tells you what something is doing right now.
That's cool (and was the initial goal), but consider oil pressure…
Knowing that the engine currently has 4.2 bar of oil pressure is useful information.
Knowing that this particular engine normally produces 4.2 bar at this RPM and oil temperature, but has gradually dropped to 3.8 bar over the last six months is something else entirely.
The same idea applies throughout the car.
Manifold vacuum can change. Fuel pressure can drift. Charging behaviour can deteriorate. A battery can turn the engine over slightly differently as it ages. Temperatures can take longer to stabilise.
Individually, those changes might be too small to notice while driving.
A computer doesn't have to notice them while driving - it can simply remember.
That's where this project has started becoming much more interesting to me. Having done a lot of programming & data science work on vehicle fleet telematics, those point-in-time numbers develop trends over time.Your car started fine, but the battery took just a tad more strain getting it fired up. How about “Hey your battery could do with a health check” after it starts, but before it fails to fire up next time?
Instead of presenting every available sensor as another gauge, the system could quietly collect information in the background and learn what normal looks like for this particular car.
Side note: “the system could quietly collect information in the background” probably raised some alarms. And rightly so! I still need to delve into that aspect, but the data would just be local to the device on a microSD card. Nothing uploaded to the cloud. Nothing sneaky. It’s not gonna start telling you there are hot singles in your area. I mean, unless there’s a demand for that
Ok, back on topic… Then the gauges only need to get our attention when something isn't normal.
That's the direction I'm heading next: more sensors, more inputs, data logging & trend analysis and eventually useful alerts rather than simply more numbers.
There is quite a bit of hardware to build before any of that works, of course.
Which should surprise absolutely nobody who has read this far.
I started this project because I wanted three better gauges.
I'm beginning to suspect I accidentally started building a vehicle telemetry system
