Close

Does this project spark your interest?

Become a member to follow this project and don't miss any updates

D-DAQ

automotive parameter & performance monitor & logger

27 61 32
Enjoy this project?
Share on twitter   Share on Facebook

This project was created on 04/29/2014 and last updated an hour ago.

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.

Read more »

Components
  • 1 × PIC32MX795F512L Microprocessors, Microcontrollers, DSPs / ARM, RISC-Based Microcontrollers
  • 1 × XTC7009 Frequency Control / Oscillators
  • 1 × DS1099 Clock and Timer ICs / Clock Generation and Distribution
  • 1 × NBPLANN100PAUNV Sensors / Pressure, Force
  • 1 × MAX4239ASA+ Amplifier and Linear ICs / Operational Amplifiers
  • 1 × MMA8491Q Semiconductors and Integrated Circuits / Misc. Semiconductors and Integrated Circuits
  • 1 × MPL3115A2 Sensors / Pressure, Force
  • 1 × AS7C31026B-12TCN Memory ICs / Static RAM (SRAM)
  • 2 × 74LVC573APW,112 Logic ICs / Buffers, Drivers, Transceivers
  • 1 × MP2209DL-LF-P Buck Power Regulator

See all components

Project logs
  • The Case of Cases

    13 days ago • 0 comments

    See Update Below

    Context being more that of the puzzle of cases not one case "to rule them all," but I digress. The past week I've been going through a few catalogs to find an enclosure for D-DAQ's mainboard. Previously, the PCB's form factor was based off of an idealistic & minimal footprint to make it easy to put anywhere and I needed a common IRL item to build from, of which a credit card's dimensions were chosen. Now that the design is maturing, I need to actually put the PCB in something for practical use and that is more irksome than one might think.

    Read more »

  • JTAG Adapters

    19 days ago • 0 comments

    Here are 2 JTAG adapters for D-DAQ.

    For those with an ARM 20-pin cable

    For those with a MIPS 14-pin cable

    Since I'm putting neither a 20-pin or 14-pin receptacle on the mainboard, an adapter is required. As long as your JTAG tool speaks PIC32/MIPS 4K, these should work for you. For the pins, I'm using Mill Max's 9976 series pins that have an insertion  diameter of 0.018" or 0.46 mm. I've chosen this route to keep the mainboard's layout compact, simple, and to lessen routing complexity.

  • Half way there

    20 days ago • 0 comments

    I'm about 50% done in the amount of time I have left to complete the rest of the board layout. PCB dimensions will be changing a bit, but I'm not sure my how much. I also changed the pinout of the display plugs. It'll take only a few minutes to apply that change to the adapter boards. Screen cap to show where I'm at after the break.

    Read more »

View all 49 project logs

Discussions

Digital Corpus wrote 2 months ago null point

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.

Are you sure? [yes] / [no]

zakqwy wrote 2 months ago null point

Exciting news! Always excellent when stuff arrives early.

Are you sure? [yes] / [no]

Tachyon wrote 2 months ago null point

This looks pretty cool. It also seems like it's going to be really well engineered. Looking forward to the final outcome.

One concern I have is the name. I'm worried you might run into trouble with IP from the company that makes the DashDAQ which has a similar function (digital gauges).

Are you sure? [yes] / [no]

Digital Corpus wrote 2 months ago null point

I'm not a creative linguist. It is better than DC's Multi-Function Digital Gauge, though since I'm still in development I'm very open to suggestions.

Are you sure? [yes] / [no]

Tachyon wrote 2 months ago null point

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. ;')

Are you sure? [yes] / [no]

Digital Corpus wrote 2 months ago null point

I take no criticism to the thought :). It is meant as a short, working title but if I don't have anything better form either community or friends, it is what it is.

Are you sure? [yes] / [no]

Oryanbaker wrote 2 months ago null point

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.

Are you sure? [yes] / [no]

Digital Corpus wrote 2 months ago -1 point

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.

Are you sure? [yes] / [no]

Oryanbaker wrote 2 months ago null point

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.

Are you sure? [yes] / [no]

bentbobb wrote 2 months ago null point

This will be perfect for my vintage car with it's notoriously unreliable gauges.

Are you sure? [yes] / [no]

Digital Corpus wrote 2 months ago null point

I only have a limited idea of what sensor inputs to make. A definitive list is at the bottom of my log post. If you would like anything specific, please let me know:
http://hackaday.io/project/964/log/3553-more-on-the-way

Are you sure? [yes] / [no]

Walltech wrote 2 months ago null point

What a beautiful pcb! Where did you have it made! I've been looking for a manufacturer with black mask that's affordable for a while.

Are you sure? [yes] / [no]

Digital Corpus wrote 2 months ago null point

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.

Are you sure? [yes] / [no]

Walltech wrote 2 months ago null point

Oh well, impressive none the less...

Are you sure? [yes] / [no]

Adam Fabio wrote 2 months ago null point

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!

Are you sure? [yes] / [no]

Digital Corpus wrote 2 months ago null point

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.

Are you sure? [yes] / [no]

fuelbrain wrote 3 months ago null point

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.

Are you sure? [yes] / [no]

Digital Corpus wrote 3 months ago null point

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.

Are you sure? [yes] / [no]

zakqwy wrote 3 months ago null point

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.

Are you sure? [yes] / [no]

Digital Corpus wrote 3 months ago null point

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.

Are you sure? [yes] / [no]

zakqwy wrote 3 months ago null point

Good call. K.I.S.S. is an excellent mantra.

Are you sure? [yes] / [no]

zakqwy wrote 4 months ago null point

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.

Are you sure? [yes] / [no]

Digital Corpus wrote 4 months ago null point

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.

Are you sure? [yes] / [no]

zakqwy wrote 4 months ago null point

Sounds good. That Honeywell unit looks like a solid choice, and the price is definitely right.

Are you sure? [yes] / [no]

Eric Evenchick wrote 4 months ago null point

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.

Are you sure? [yes] / [no]

Digital Corpus wrote 4 months ago null point

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...

Are you sure? [yes] / [no]

Eric Evenchick wrote 4 months ago null point

Ah, that makes sense. I guess it'll be a matter of making sure you can do the SPI transactions fast enough for all three displays. Should be an interesting challenge!

Are you sure? [yes] / [no]