This project is in this list

Description

The inspiration for D-DAQ was a digital boost gauge a user named Doniol. Unfortunately, less than 2 years after his creation was running in the wild, he disappeared from the community. No gauge of this performance caliber has been made since. A friend of mine owned one and had to sell it due to the design being tied to fixed OE sensors. However I was granted a moment to take a few photos of the PCBs so I could possibly bring it back.

D-DAQ is the new incarnation of the Doniol Boost Gauge. It is designed with around a modular paradigm and high quality parts. Though by it has battery voltage, EGT, Boost up to 85 psi, and a 5V aux sensor of your choosing, it can be expanded via 10 additional analog inputs, 2 impulse inputs, and future CAN integration. As for outputs, you can add up to 3 OLED displays to view everything on, though this too is not limited to the displays in development.

Details

A breif overview of why I started working on D-DAQ and what it's designed to do:

Oh, watch it on youtube with annotations turned on please. I've included CC too.

The original Doniol gauge used a 128x128 pixel, OLED displays and a MSP430 MCU. It tapped into a stock/OE Bosch MAP (manifold absolute pressure) sensor with a range of 2.5 or 3 BAR. It optionally had a daughter board for connecting a K-type thermocouple. It was simple and elegant as it fit right over an unused portion of a MK IV Jetta's instrument cluster. After researching the hardware and beginning my dive into electronics, I was able to figure out which display driver and which interface was used to interact with it. About a year ago I had the opportunity to talk to the creator and he was kind enough to answer a few questions for me even though I was in the process of starting my own project inspired by his creation.

Anyhow, onto the details about D-DAQ, you'll soon can see that for just a *simple* boost gauge and data acquisition logger, there is quite a bit of complexity here. Shush all of you who say it's undue. As a general overview to the base system design I've kept the layout simple. Feel free to start reading after the break for the nitty gritty details.

Project logs

Hello everyone. I've not forgot or abandoned D-DAQ. If you've been following from when I moved the project to here, you may recall that I've said that this project was near 3 yrs old, though at this time its a few months older than 3 yrs though I digress. It's taken a while because its developed in my free time just like nearly everything on here.

The hiatus is development is simply due to that free time or the definitive lack thereof. Had to pull my transmission this past week to replace a spring and found that the release lever was starting to fatigue and bend. Came across the cause of the fluid leak I've been experiencing as well and have to re-grease a CV joint and it's boot in the very near future as well. Either I spend the money and have a mechanic do it, mind you I rebuilt the engine myself 13K miles ago, and take the time and do the work myself and save a few hundred dollars.

If I can get back to the design work, I can build the power supply subsystem which will be a isolated SEPIC to 2 buck converters. I promise I've not forgotten nor abandoned D-DAQ, but life happens and I'm sorry I haven't made any visible progress in the past few months.

Hello once again. So, most of you who've used OSH Park probably know that they don't officially support plated slots. On my 3rd prototype, I overlapped some drills to see what they'd give me in return and I got plated slots. Taking this into account, I figured I could play around a little and see what results I would get. Now that my proto 4 boards are in, here are some photos of the good and bad.

Progress is slow, but I should have the PCB for the 4th revision here tomorrow. I still need to make the power supply end to have a functional device and that has been delayed, but is still in progress. Don't worry, D-DAQ is still kicking, but things may stay on a slower pace due to some changes in my personal life.

Discussions

Become a member

So, this isn't "log worthy" but back on the 12th I ordered up a batch of PCBs from Osh Park. Expected 2 weeks before getting a shipping notification, i.e, Friday at the very soonest. Well, today I got the said shipping notification; 6 business days later. My promised BOM isn't complete since I've been slimming down oddball part numbers to try and avoid one-off's while balancing cost & quality, so I figured I had a couple more days, a week at most, to finish that up. Well, looks like I *have* to get it done in a tonight or tomorrow to get my parts in a reasonable about of time. I still have about 80% of what I need to solder onto the boards, but there are a few critical sections like my 14V rail that will not be functional right away. Either way, any time delay will help in getting the initial firmware coding further along.

Digital Corpus
Just to clarify, I wasn't criticizing the name. I'm just all to aware that these days there are way too many lawyers with too much free time on their hands that love to jump on stupid stuff like "rounded corners" and "similar names" etc. ;')

This project looks great so far, can't wait to see if it works. I'd love to implement it into my daily driver, doing some heavy modding to it, gotta make it my own after all. I'd love to help test this, contact me if you need a beta tester, I'm a mechanic by profession, web developer by teaching, & electrical engineer by hobby.

I looked around and there doesn't seem to be a way to pass off email addresses and the like here on the site. I have a lot of bits and pieces to work out on the backend like getting everything up on github, et al, so please keep an eye on my links on the side. Tonight, I finish my BOM.

I most definitely will, following both you & this direct project. Finding me on email shouldn't be too hard, I'm on gmail with this same username. Anything you could use a hand with please feel free to let me know, I'd love to assist.

The photo is a B&W conversion but leaving the yellow/orange/red for gold, i.e. Selective color. I did that because the purple silk screen don't show due to the light source in that photo. Though they take a while, I'm going with Osh Park for my prototype production of the PCBs purely to keep costs low but quality decently high.

Wow - this is an amazing project - so much work for a turbo gauge makes me realize how hard it must be actually controlling an engine's operation with an ECU. Thanks for entering this in The Hackaday Prize!

It started as a boost gauge, but I decided to build it out into data acquisition. On top of that, I don't want this locked into a specific manufacturer or generation of car so added complexity is a function of this modularity. It'll take up to 16 inputs, 2 being pulse-based and the other being good 'ole analog inputs. Yes, originally a turbo boost gauge, but now it's [potentially] so much more. Thank you for the kind words.

This is a very cool project and it's probably one of the best projects you can tackle to learn a lot about a variety of electronics in a small period of time. One device I might suggest looking into is called "MegaSquirt". It's very similar to the project that you are undertaking and the website is packed with formulas and techniques you can use for learning every single thing you need to program all the sensors in your car. It's essentially an Engine ECU. If you look at the forums I guarantee you can get your question answered. Using the formula of your choice (Volumetric Efficiency is the best one for an vehicle. It's based on engine volume and incoming air mass based on temperature and pressure) it can be used to control an engine based on timing, IAT, MAP, and A/F ratio. You will find everything for. IAT - Intake Air Temp, MAP -Manifold Air Pressure or MAF - Mass Air Flow, Coolant Temp, Sequential or Bank fuel injector time/resistance, and of course air/fuel ratio sensors.

One of the things I noticed with your project is that you have a sensor capable of measuring a huge PSI (up to 100).. however the problem is that no turbo will ever make that much pressure and I think you would be better off with a sensor that is more accurate as opposed to one that measures a high pressure. 0.25% is decent, however it is not accurate enough to get a really good a/f ratio without mapping out the entire system over it's whole RPM range. Once you get into a really high RPM range even milliseconds and small percentages make a huge different in a proper A/F ratio. Another thing is that you need to check to make sure it measures vacuum pressure. When you start any engine there is a negative pressure at low RPM until the turbo kicks in.

Lastly I will leave you with some tips for programming the resistive sensors. To figure out the temperature range on you coolant temp sensor or IAT or Oil Temp sensor. Measure it's resistance in a cup filled with ice water and salt for the low OHM reading and then measure it again in a pot of boiling water for it's high OHM reading. This is the only range you will need and it's pretty linear in between those two readings. You don't actually need a very fast sensor for measuring temps. If you start with air that is 70 degrees chances are the temperature outside isn't going to change to 80 withing 3-5 seconds. Anyway good luck with your endeavor and I hope that you learn a lot. This was one of my favorite electronic projects to tackled as a young enthusiast.

Thank you very much for your comments. With how "thorough" I'm attempting to be, I am just a stone's throw away form ECU-land. You first sentence is what I have loved about this project from the get go as the dynamic range of theory is simply immense and enjoyable; albeit, it's a bit overwhelming at times.

I can tell from you comments that you're somewhat familiar with gasoline engines. This is an absolute pressure sensor so I can easily measure vacuum and my test bed is a diesels engine, which do not produce vacuum natively. Though less common in gas applications, diesels commonly use VNT/VGT (variable nozzle/geometry turbos) base turbos. I'm witness to several compound builds where the working pressure is 40-50 psi. I myself run 29-32 psi. Due to the VNT application, exhaust manifold pressures are required to be monitored and are tuned to be no higher than 1.5x IMP/Boost, thought when initially starting out 2:1 isn't uncommon. This is why a 100 PSI-a sensor, ~85 psi-g is a design criteria. Though 0.25% isn't that great across 100 psi, my ECU has little concern keeping me smokeless with a 4-bar sensor with an 8-bit DAC. The sensor's response time is 1 ms, fyi. Because AFR is highly desirable by some using a dedicated WBO2 sensor instead of fudging it, but we'll see how things go.

Yeah, these guys are a bugger. It's relatively simple for either you or I to create a simple calibration profile for a one off design and the application for this device means that it should be a simple technical procedure for those who know enough to know why they want to use a device like this, but including some software smarts is bound to help. with IATs in forced induction, temperature can change really easily. that 3-5 second slew rating is a bit of a concern, but it can be predicted with a little differential equation math, if I recall my Calculus properly. For example, I live is SoCal (Southern California) and this week we will have ambient temps of 100˚F. The output air temp of the turbo at 29 PSI will easily be north of 300˚F. Toss D-DAQ into a car in the Mid-West, mountainous regions, and even Canada and we'll see temps of -20˚F quite easily too. With inherent inaccuracy of RTDs, +/- 20%, these are one of those things I want to make sure I get right.

Anyhow, thank you very much for your comments. I appreciate the thoughtful words and advice more than you know. Despite working on this for the better part of 3 yrs, I know I've not thought of everything so I'm love reading up one any of these aspects to make sure I've not missed anything. I'm trying to make D-DAQ configured to where if I can, it's relatively simple to adjust a bit of code to make a correction and/or make a new sensor board for a new parameter to monitor. Again, thank you very much.

Don't be afraid to step up to an instrumentation-grade 3-wire Pt100 RTD element. They often have thick stainless sheathes that can slow down response time, but paired with a suitable Wheatstone bridge and a 2-point calibration you can _easily_ hit +/- 1% or better. Thin film devices are pricier and a bit more delicate than wirewound units, but they're even better. Worth the $50-100 or so IMHO if accuracy is that important. Platinum is incredibly linear in your range of interest.

I get where you're coming from because it'd be simpler and more accurate to use a better sensor. however, using an external RTD means more work. Tapping into existing sensors on the car means you do not have to go add fabrication and engineering of a creating a new hole for custom sensor and securing it when they typically don't have any threading. Welding is out of the question. If done sub-par or not in account of corrosive fluids/gasses, and accounting that they would see around 100 psi in an oil temperature environment, using alternative sensors creates another possible point of failure in the vehicle.

Fascinating project, glad someone is picking this one up! Can you provide more details on the pressure transducer you're using? Are you reading the raw output from the piezo element and filtering the value based on a calibration curve, or are you using a unit with built in circuitry? In my experience, pressure transducers (and transmitters) tend to vary widely not only in accuracy, but also in response time; the high end units designed for industrial applications often come with a fairly high level of hardware averaging that could make the gauge response less smooth than you want.

Originally I was going to use the SSCSANN100PAAA5 from Honeywell. However, over the course of the project Honeywell introduced the NBPLANN100PAUNV, which is similarly spec'd but 1/3rd the cost and it allows for a variable supply voltage, which I plan on taking advantage of. ThoughI too am dubious of the real world performance over it's range, I have no problem switching to a different device. This is coupled with the fact that if there isn't a physical buffer (like a tiny in-line RC car fuel filter) before sensors, the individual variations of boost pressure from opening intake and exhaust valves can change the actual pressure by 5 PSI or move at 30 Hz or so. To compensate, RMS and a running average will be utilized for smoothing. Also, as I have other sensor devices that will need calibration, namely reading RTDs, so it's not cumbersome to allow for curve corrections in software.

Anecdotally, I have used the Freescale MPXH6400A in my car to read the higher boost pressures and it's been running strong for well over a year so I know these small transducers are capable of what I'm looking to do with them.

This looks like a pretty intense project. I'd definitely like to know more about how you're driving multiple displays, and how you're using mini DisplayPort. I'll have to look into that OLED driver IC.

Since the SPI channels are hardware driven, they way I understand it is that once data is written to their buffer, the CPU can go off and do other things. Also, as they are independent channels, they should function in parallel, technically (see my links). I won't know for sure until I get code running on the PIC32MX after building a board.

After my Eagle files are sent to OSHPark sometime this weekend, fingers crossed, I will be cleaning up the schematic and will see what i can do by creating a github account to put things up. I'm considering porting the schematic capture to KiCAD too...