David, I think I have one along with a bunch of other archane Chrysler stuff. You would just have to come up with the needed signals.

 

It'll probably be easier for me to use Arduino/Raspbery Pi or similar to recreate the effect. I know there are CAN bus readers available for both embedded controllers. Another benefit to using MegaSquirt/MegaShift is that it can calculate MPG. Grab fuel level sensor inputs and there's DTE. I'd have to use an average MPG and I don't know if MS will do that or if I would need to do that via an embedded controller. Same with speed for ETA calculations. I could see using a 16x2 lcd in an overhead console to give it that OEM feel...

 

For the MPG display, go for the gusto like the Prius. The one I drove for the exjob had the last 30 min MPG shown in 5 min segments. I was thinking about MPG display every 30 seconds to give a really good measure and put that up as a graph/chart ect.

I though of programming a ECU to give the best MPG by running lean and watch the EGTs to keep it from getting too lean and hot. Use EGT for feedback insted of the fuel hog O2 sensor.

 

I eventually want to see if I can use a wideband in the stock single sensor location to control cruise mixture. I will be using dual sensors for normal control at the downpipes. As it is I have gone from 10mpg to 11.5 - 11.7mpg on mine by just going to EFI and E4OD. Since I did the EFI by swapping the top end, I'm probably only around 8:1 cr instead of where I want to be 9.2-9.5:1.

I'll be interested in what I can get using an EEC-V setup with MAF and sequential injection on a 460.

 

I plan on doing some lean burn during cruise so I can work on my mpg... I'm going to run a wideband 02.

The Innovate Wideband O2's can output a narrow band signal so you can run one sensor and give the computer a narrow signal off that.

I've collected all the information I think I need for the E4OD control using MegaShift on a GPIO board. I actually think I could control it right off the MS3X board but I'm not sure. All my research has been with the GPIO.

Since the trans I have works but is high mileage I'm going to do my testing before rebuilding... Yeah, I'll have to take it out to rebuild it at some point but if I burn it up with a tuning error hopefully I'll have learned what not to do for the rebuilt unit...

 

I made some progress on an "Analog" gauge...

Code is still dirty as hell but it looks good...

 

That's cute! I'm a fan of analog gauges, and watches for that matter, since I can remember the position of the pointer but not the value of a digital readout.

How fast will it "paint" a new reading?

 

Amen to that. I have had several vehicles with digital speedometers, fortunately nothing with an entire digital dash. My son found that with the Konvertible dash switch set to "export" it didn't go blank over 85 mph, it kept going until it read first 00 then got back up to 21. This was near DC at what is called the mixing bowl, the Springfield interchange. Someone tried to cut him off going for the exit ramp, so he floored it and outran him.

 

It paints the new reading really fast, so I have a delay in there to smooth things out. That part works well. The issue that I'm having with my code right now is that I 'paint' the line for the gauge pointer black, delay, then paint it white before painting it in it's new location. I did this to save from redrawing the whole display over and over. However, anywhere the pointer touches disappears.

So I need to limit the total sweep of the pointer and the height. The height is going to be a little tricky because if I need it to move in an arc to look right. So in the center I need to shorten it very little but at the ends I need to shorten it a lot. It's a side effect of how you reference the pixel positions.

Shouldn't be too hard, just have to do a little more coding. I've also been cleaning up the code by moving things to functions, etc. I did initially code it pretty dirty...

With the ability to light up an LED for under/over volt I don't think it's really an issue analog vs digital output on the gauge. I've decided to forgo the buzzer and with that there's no reason to cross check any sensor data to tell if the engine is running. I don't care if the 'battery' light is on when the key is on but the truck isn't running. That's how just about every other car/truck out there works...

 

Use a lookup table for the pointer length. Calc once and use many times.

But, with the light I'm not sure I would worry about it. If you had a button/switch that let you change modes so you could stop it on any input I think I'd leave it digital.

 

There are only a few data points needed for the pointer length. Where I have it now looks good for most of the sweep, it's the end points that need to be pulled back. I was just going to use a few if/else statements to pull it in. The bottom of the pointer is fixed and I've mapped the sensor value to the L-R pixel coordinate for the upper part of the pointer. So based on what range that's in I'll adjust the length accordingly. Easy, just have to code it.

For the light I was talking about the battery or charge warning light. Earlier I talked about adding a buzzer circuit to alert me on a charge fail and if I did that I would have linked it to the oil pressure output so the buzzer didn't sound when the motor wasn't running. I've decided the light is good enough and will set it up to come on for over/under a set voltage range.

I am planning on a switch to change modes and will likely include other sensor data like coolant temp and oil pressure. Those will be digital only since I have gauges. I may even do a multi report display that lists them all together. I can do 6 lines of text. I wasn't sure what would be involved in making an analog gauge so I wanted to try it. I kind of like it and would like to at least perfect it. Then if I ever need/want an analog output I can do that. Since it'll work I'll probably make that the default and have a mode switch that will cycle through a few other screens that will all be digital.

I have an OLED display coming that's normally black with white pixels. Because of that there's no need to back light the display. Also it has a higher pixel count so it should be a finer resolution.

 

Sounds like you have a good plan. But, are you going to monitor the oil pressure and temp inputs to provide an alarm. Maybe I misunderstood what you said. I would think that having an alarm, either light or buzzer or both would be very desirable. And, maybe have the normal mode on the readout such that it would change to whatever input was out of range, and maybe flash the display. You would probably want to be able to override the mode so you can look at other things though.

 

Very nicely done! I just need to see if I can figure out a way to make the later (89 up) oil pressure "gauge" actually provide usable data, not just a mid scale anytime it sees over 5 psi.

 

Gary, the alarm code is in a function and can be called from any readout, although the only one that uses it is the voltmeter currently. What I need to do now is read all the inputs in the main loop, alarm if needed and display the appropriate display based on what's been selected. It's going to default to a voltmeter, then a single button will cycle through displays.

I guess the next step would be a focus function to go to the display that's signaling the alarm, but I have to make sure it works right when there are multiple alarms. Probably cycle through the displays that are in alarm.

Bill, does the sender output a variable signal? I remember hearing something about that years ago and it was the sender, not the gauge. The sender was basically on/off and the gauge became a fancy idiot light. If that's the case it could be as simple as using the earlier sender, which I believe is what I was told years ago. We're talking almost 20 years ago so my memory could be a bit foggy...

 

I like the idea of cycling through the alarms.