For the average motorist, the speedometer and the fuel indicator are the primary gauges of interest. Owners of performance or modified cars tend to like having more information on the way the car is running. [JustinN1] is firmly in that camp, and built some WiFi-enabled gauges for his Subaru WRX STi.
The gauges run on the ESP32 platform, chosen for its WiFi hardware and its ease of use with the Arduino platform. This makes programming a snap, and interfacing to a smartphone easy. OLED displays were chosen for their good visibility in both day and night conditions, which is important for automotive applications.
[JustinN1] developed both a boost/vacuum gauge and an oil pressure gauge, both useful for keeping an eye on what the engine is doing. Measuring boost is as simple as using an off-the-shelf analog air pressure sensor. The oil pressure sensor is a resistive part, and must is hooked up through a resistor divider to create an analog voltage for the ESP32 to read.
Code is on Github, and there’s even a version that displays a grinning face when you get into higher boost levels. There are also a series of housings to suit various mounting choices, to help give the gauges a more finished look. We’ve seen other gauge builds too, like this gear indicator for a Suzuki motorcycle. Video after the break.
Plan on replacing those displays about once every six months for burn in… Otherwise, looks good!
Now I want to see how long they last. The modules themselves are only about $18 on amazon (probably cheaper on aliexpress or eBay).
(For reference a good boost gauge from a reputable company is around $200. )
I’m a little surprised this information isn’t available via the ODBII port. (That may be a major project: to interface to a bluetooth obdii adapter and extract the information.) This is a lovely build and now I want to make one like it for our STI.
Got a WRX myself here. Boost is available via obd. boost is also available from the loom in a rather trivial manner (already logged MAP+TPS+Lambda on a picoscope)
Was about to say something similar.
Almost all cars that are turbocharged and have EFI has a manifold pressure sensor already, it’s just a question of tapping into its (often, but exceptions exist especially on very old or very new cars) 0.5v to 4.5v analog signal output.
0v or 5v is recognized as shorted to ground or shorted to sensor power input (sometimes used by internal mcu of sensor to tell it is defective), respectively.
Also many newer tachometer “pod” gauges (those 52mm diameter ones) have a bipolar stepper motor driving the needle, so with a replacement “dial face” and internal control pcb you got yourself a pod gauge that’s ripe for fiddling with.
Dont go splitting the single from the sensor which is measuring boost and talking to your ECU.
Just add another sensor.
Last thing you need is a voltage offset and your ECU seeing the wrong boost level and going lean.
A MAP sensor can be bought new for very little or obtained from the scrapyard for even less.
Yah, OBD2 – an extra level of complexity vs reading a 0-5v signal.
Vertical video vision. And struggling to get the gauge and the phone in the same shot – priceless :)
This ^^ even when looking for a pipe to T in a boost gauge, never use the oe map plumbing or fuel pressure regulator reference pressure plumbing, a leak in either of those will cause lean under boost. K.I.S.S when it comes to a simple hose that could trash your engine :)
As I mentioned in another reply, I used the Freescale MPX5700AP to read boost/vac from a nipple on the manifold and feed a 0-5v analog signal into my project. They’re cheaper and smaller than a used MAP (Megasquirt PNP uses a different model of the same sensor).
Much simpler to deal with than an OBD2 library with much, much faster refresh rates than the 10 updates/sec my AccessPort reads the factory MAP over OBD.
Any “good” ecu is going to have the ability to set limitations upon which the motor can be operated if any of the sensor data becomes out of bounds. Also, the map sensor being used as a lookup reference in a fuel/timing table only happens during openloop operation….. which is to say, a small percentage of the time you’re driving unless you’re racing and in boost constantly….. or you have a small turbo that gets into boost very quickly (~<3500rpm).
Many cars are able to continue to operate in what's called alpha-n fueling mode if any of the sensors fail…. which is where it reads out of a table and references throttle positions vs. rpm to determine fueling requirements.
One last thought, while this is a cool project and I love seeing people tinker with turbo cars, I've considered several times over the years of just removing any kind of gauge I have in my car because I really don't need them that much. I have two center a/c bezel mounted 52mm gauges in my car. I rarely look at the gauge while I'm doing spirited driving and I know my boost pegs and stays where it's supposed to. Anytime the car has had any issue it was immediately noticeable and seeing the value on the gauge wouldn't have improved anything. I understand people like to have data in their car or feel like there's "alot going on" inside this cockpit….. but really it's a lot of distraction and if you study true race cars you'll notice their displays are very consolidated and minimal to keep the driver engaged in the most important task at hand.
At least on the 32bit ECU found in the 2006 and up cars, you can get data from the manifold pressure sensor over OBDII, but it’s much simpler from a programming standpoint to use an absolute pressure sensor like the MPX5700AP to read manifold pressure directly. Subaru’s don’t have an oil pressure sensor, just a pressure switch for low pressure. That would need to be removed and replaced with a pressure sender.
I have a similar project for the GD WRX/STi (2002-2007 if you’re not a Subaru nerd) that replaces the factory clock with a 3.2″ 256×64 OLED that displays Boost/Vac, OIl Temp, Oil Pressure and Wideband A/F ratio.My project is running on a Teensy 3.2 with an ADS1115 ADC breakout to handle the 5V sensor input, which the Teensy can read over I2C. I’m using the MPX5700AP for boost/vac, a custom calibrated NTC thermistor for oil temp, a knockoff of an AEM 100psi oil pressure sensor for oil pressure and an AEM inline UEGO A/F controller for air/fuel ratios.
Only boost/vac is available over OBDII, and the EJ series engines/ECU’s don’t have oil pressure, oil temp or wideband air/fuel sensors, so it’s not too surprising that they aren’t available on OBDII. I didn’t want to have to implement OBDII for just one sensor, so the MPX is reading manifold pressure (boost/vac) directly from the intake manifold. I’m already considering expanding it to display any OBDII info plus 4 programmable analog inputs, which shouldn’t be too hard on the Teensy. But that’s for a nother time!
Out of curiosity, why an AEM UEGO rather than a Bosch? I’m working on adding fuel injection to a Datsun engine in an old Triumph, and am still looking at A/F ratio sensors. An awful lot of people love Bosch AFs.
Never mind: AEM uses a Bosch sensor.
Yeah, it’s definitely a Bosch sensor with a power supply and processor encased in a relatively small plastic case that was cheap and had a 5V analog output, which I fed to the ADC and a serial output that could be logged with AccessTuner on a laptop. The Bosch seems to be widely used because it’s accurate, not terribly expensive and well supported.
Which engine management are you looking at for the Triumph? Are you swapping an L-series into a GT6 or a Spitfire?
can’t reply directly to boostretard’s question because it’s nested too deeply: A-series Datsun in a Spitfire, that I’ve been driving for seven years. Nissan licenced the A-series from Triumph. It’s basically the same engine the Spitfire came with, only with an alloy head, a five bearing crank, and modern Japanese construction. And it fits under the hood, which is really difficult without cutting up the frame. Right now I’m working on some other parts, but probably microsquirt when I take that step.
Dont open the can of worms which is the “my wideband is better than xyz brand” internet debate :)
Many established brands are using the LSU 4.2 bosch sensor, there are advantages to using the LSU 4.9 instead as it doesn’t require reference air for calibration (which in an engine bay might not be clean air.)
Comes down to cost vs application as ever.
If staying NA I wouldn’t pay extra for the 4.9 solution and just be mindful of placement and ensuring your exhaust doesn’t leak near the sensor !
There’s really no good “can of worms” to open here IMO. None of the consumer grade hardware that anyone is using samples fast enough to be accurate enough to matter at 10k rpms. They are also notoriously inaccurate at idle because of the amount of time between exhaust pulses.
The NTK sensors are more accurate than the Bosch are…. from my research. The majority of all name brands sell Bosch sensors though. In summary, a wideband of any sort should only be used to get you into the right ball park for motor safety, once you’re there you use the dyno to squeeze the rest of the setup…. or a logger and gps.
OBD2 port doesn’t have a fast enough sampling rate to be feasible in motorsports. It’s for basic diagnostic use only and I would strongly avoid using obd2 values as reference for making changes to your car’s tune. The one exception I can think of is viewing long term fuel trims to adjust injector voltage offset…. but that is usually very fine tuning of cruise/idle and takes a while to iron out in some cases.
Data is often available at the OBD port but the major downside to that is often lag, busy bus (CAN, K-line, KKL which ever) , having you own off board sensor is a must in high power situations as factory sensors often cant keep up. MAP and O2 sensors a often narrowband so again wont be that acurate in high power or out of spec usage :-) , One vehicle that I know that suffers from CAN bus lockup is cummings based pickups, if you scan the bus prior to engine start it wont start until a full cycle of the ignition, if you scan the bus after engine on then windows will randomly lock up or move on their own.
some older vehicle that do have “some sort of obd” are limited to baud rates below 9600 , thats far from realtime so again a separate sensor will assist.
darkspr1te
First I’ve got to say I’m flattered to be featured here. Second I’m embarrassed by the crummy vertical video I posted to the instructable (I was in a rush and wanted to submit to a contest sooner rather than later).
A couple of comments on the comments:
-You can absolutely get boost/turbo/etc pressure from the ecu on turbo subaru’s. Using only OBD II it isn’t fast enough for good data logging. It is about right for a visual gauge. If you do use subaru’s SSM protocol you can get better data rates and more data fields about other things the ECU is doing (Subaru like all other manufacturers have a proprietary protocol that is on the canbus and accessible via a 2 wire interface or the OBD II that gets better data rates and more queries about the ecu (this is how people can log more and actually tune an ECU…which if you want a rabbit hole to go down essentially uses fuzzy logic and tables of “good” or “goal” values and learned corrections over time to get good engine timing and fueling).
-These ECU’s don’t have oil pressure. Most cars these days don’t. Unfortunately they have dummy switches that only go off when the oil is crucially low. So by the time you notice the light in the dash the engine is probably toast.
-I make gauges for cars as a hobby. The interesting thing which isn’t touched on in the write up is the the ESP32 is running as a WiFi AP and a web server and is serving up a JavaScript webpage (with no internet connection for library references) that you can view from a web browser to get a live updating line graph from. (Smoothiecharts was the awesome library for this that I stumbled on).
I did open a rabbit hole for some in terms of the fuzzy logic and how an ecu works. I think Hackaday should read this guide (now old by internet standards (and also not my work)) and write an article about it.
It is of interest especially if you like automation, learning systems, fuzzy logic, engines, industrial control, etc. Oh and reverse engineering.
https://forums.nasioc.com/forums/showthread.php?t=1626520