Strange-looking Gauge Cluster

Hey all! I am working on building a small gauge/screen that interfaces with CANbus to display various engine paramters. Part of my idea was to get that "grid" background on the screen to match the stock Bullnose gauges. I was looking through image results of gauge clusters to see if I could get a good sample pic and I saw this odd-looking cluster. The 55 and the 75 are highlighted red, along with the cross in the middle of the tach delete. Anyone seen this before? Is this a rare edition or did someone just paint it?

https://borthautoparts.com/parts-products-catalog/ford/ford-mercury-speedometers-gauges-clocks/1980-86-ford-f-series-speedometer-no-e0tf-10c956/ 

Could it be for a medium duty truck that is governed to 75mph?
I don't recall seeing a pickup that has that circled in red.

In any case the red looks 'off', like they did a poor job repainting the needles.

Good eye, yeah. Looks like the needles are repainted. Probably some old guy painted the 55 and the 75 to remind him of the speed limits. My dad would totally do something like that back in the day.

This sounds pretty cool, what sensors/modules would you be using to generate the CAN data?  It'd be pretty cool to have CAN bus on a Bullnose. :)

In my specific case, the CAN data is generated by the aftermarket Edelbrock EFI. I'm just making a CAN reader that will replace the digital dashboard clock and buttons with a 1.8" tft screen. It displays the clock by default, and then the buttons will cycle it through the CAN data from the engine computer.

Eventually, I want to make something that also generates some CAN data for those of us with a stock EFI or carb setup. This is not really in development yet, it's just on paper. It would require a whole different wiring harness with separate CAN-friendly sensors, so it would kind of be an "engine management system" at that point.

As for the reader, I'm soldering components as we speak. I got a few extra clocks from the salvage yard and am working to fit everything up so it just plugs into the stock plug for power, and then has a Deutsch connector out for data. Software-wise, it is programmed in Python.

Another feature that was really easy to add is a USB-C port where you can charge a phone, or plug in a laptop to reprogram and customize your reader if you have Python knowledge.

Pardon me, but what is CAN?

CAN stands for Controller Area Network. It is a small two-wire data network that modern cars have. It transmits and receives the data from multiple controllers, modules and sensors in the car.

It saves on vehicle weight by using two small data wires to communicate between multiple modules all over the car rather than having one central module in the middle with a wire from every sensor being half the length of the car.


CAN sends all data from all sensors and modules at once in a single "package" that any other device can theoretically pick up and dissect in order to function properly. My idea is to make a device that takes that package of data, split it into the separate components (RPM, engine temp, AFR, air temp, etc) and parse them in a way that is easy to read for humans.

That's cool, but way beyond me. I'm still in the stone age and run a carburetor.

The cool thing about CAN is that you can use it no matter what engine situation you have going on. As long as you have a place to put the sensors, you can still monitor all kinds of stuff about your engine. Adding a wideband O2 sensor, coolant temp sensor, hall effect sensor, etc along with some wiring to the central unit could be instrumental in tuning the carb perfectly. The O2 sensor in the exhaust can tell you your exact AFR for instance.

For people like me who actually like the wiring aspect of a project, it's not a big deal. But the annoying part is that you can't use the stock engine temp/oil pressure sensors that go to your gauges so you have to find places for the additional ones.

It could be beneficial to run some CAN device like that on a carburated engine if you wanted to keep the carb but run a really new transmission that is electronically-controlled behind it. Those new transmissions need to know a lot of engine data to be able to know when to shift.

I applaud your willingness to wire.  However, with that amount of wiring it would seem easier to go to EFI and have the benefits of a modern fuel system as well as the ability to get about any information you want.

For instance, I'm running Ford's EEC-V system on Big Blue's 460 and have a mass airflow sensor as well as sequential port injection and two O2 sensors.  I can get about any parameter I want via the OBD-2 port and a laptop or my iPhone.

And I am running Bullnose-style coolant temp and oil pressure senders so my gauges work.  Plus I'm running the EEC-V inlet air temp and coolant temp sensors, so the ECU has all the info it needs to do its job.  And the AFR sits right where I've programmed it to sit regardless of the conditions, which can't happen with a carb.

I'm not knocking your plans with the CAN, but am wondering what the advantages are over an EEC-V system?

I replaced my Ford EFI stuff with the Edelbrock Pro-flo 4 system, which uses CAN, and I'm wanting to interface with that. Adding all the wiring and sensors was just a hypothetical for those who love data but still want a carburetor. The device I'm working on just reads CAN data and displays it on a screen so I can check on engine parameters that aren't being displayed by my gauges without having to use a phone and bluetooth to connect to the Edelbrock computer.

I only have to run 2 wires to the ECU, as the Edelbrock EFI already has all the right sensors and prepares the data for me. Later on, when US Shift releases their promised CAN interface for their transmission controllers, maybe I can gather data for that too. Later iterations of my device will hopefully offer logging of all the data to an SD card, which would help people visualize what is causing weird engine/trans issues they may be experiencing.

I don't have much experience with EEC-V, but a lot with EEC-IV (not my favorite). I could probably(?) make a version of the device that reads and logs data from that system, too, but that'd be a lot of learning before it could happen.

EEC-V is fully OBD-2 compliant so it should be easy to pull data.  There are sketches for things like a Raspberry Pi to get data, although I've not tried it.  But in theory you could easy log to an SD card and show the data on a dedicated display.

So if your device could interface to a number of different EFI systems it could be quite handy.