D-DAQ

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.

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

Project Logs

Collapse

Hiatus Continues for a Spell
Michael O'Brien • 12/01/2014 at 20:19 • 0 comments

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.
OSH Park Manufacturing
Michael O'Brien • 09/18/2014 at 23:21 • 0 comments

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.
Read more »
Proto v4 Arrival & Other News
Michael O'Brien • 09/16/2014 at 15:52 • 0 comments

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.
Read more »
Comparing D-DAQ's Performance Characteristics
Michael O'Brien • 08/27/2014 at 08:23 • 0 comments

I've talked a bit about the performance I want, need, and expect to have out of D-DAQ. I've mentioned a long lost digital gauge with no known good video footage for people to have a benchmark of. There is also a "high end" gauge setup a friend of mine moved over to that is very popular around the diesel world made by the company ISSPro. All of this is fairly arbitrary for those less familiar with any of these than I am when I even have a glancing knowledge of them. I'd like to define the terms of performance that are present in digital systems and what I aim to achieve.
Read more »
Preview of v4
Michael O'Brien • 08/25/2014 at 08:10 • 0 comments

Here is where I'm currently at with version 4 of the prototype:
Read more »
The Future of D-DAQ
Michael O'Brien • 08/21/2014 at 16:44 • 0 comments

I've mentioned it before, but I just want to state it again for the sake of clarity. Even though I'm a participant of THP and like anyone else I do hope I place, I aim to complete D-DAQ within the deadlines established or as close to them as possible regardless of how I place. I want this device created and design as well as it possibly can be and I'm using the contest as motivation to get it done. Anyhow, good luck to those who are also participants and in the next few days I'll be having the schematic captures for the sensor boards up by sometime tomorrow.
Edit: Well, if you saw my video, you may recall my mention of maintaining TDI's other than my own. First thing this morning I was helping with a flat and a new set of tires as well as some previously overdue maintenance. Needless to say, my day quickly became occupied with anything but D-DAQ. Sorry for not being able to follow through with posting up the sensor board schematic captures.
The Case of Cases
Michael O'Brien • 08/07/2014 at 23:12 • 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
Michael O'Brien • 08/02/2014 at 01:24 • 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
Michael O'Brien • 08/01/2014 at 11:47 • 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 »
Still working...
Michael O'Brien • 07/27/2014 at 04:43 • 0 comments

Only 4 days since I've posted a log? Being on vacation messes with your sense of time if you stay home... Anyhow, I've been working on board layout for about a day and a half and I'm about half way done with the easy stuff, I think.
Read more »

View all 55 project logs

Discussions

shimniok wrote 03/11/2016 at 02:25

Cool project. I have a GM TBI data acquisition project on my to do list for someday. :)

Are you sure? yes | no

Michael O'Brien wrote 06/24/2014 at 02:26

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 06/24/2014 at 02:38

Exciting news! Always excellent when stuff arrives early.

Are you sure? yes | no

Tachyon wrote 06/21/2014 at 22:59

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

Michael O'Brien wrote 06/21/2014 at 23:09

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 06/21/2014 at 23:15

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

Michael O'Brien wrote 06/22/2014 at 00:57

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 06/17/2014 at 13:27

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

Michael O'Brien wrote 06/18/2014 at 02:28

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 06/18/2014 at 19:11

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 06/16/2014 at 20:49

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

Are you sure? yes | no

Michael O'Brien wrote 06/16/2014 at 22:10

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

WΛLLTΞCH wrote 06/16/2014 at 17:27

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

Michael O'Brien wrote 06/16/2014 at 19:47

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

WΛLLTΞCH wrote 06/16/2014 at 19:48

Oh well, impressive none the less...

Are you sure? yes | no

Adam Fabio wrote 06/12/2014 at 02:17

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

Michael O'Brien wrote 06/12/2014 at 02:53

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 05/10/2014 at 00:02

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

Michael O'Brien wrote 05/10/2014 at 03:04

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 05/24/2014 at 17:57

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

Michael O'Brien wrote 05/24/2014 at 18:38

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 05/24/2014 at 18:45

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

Are you sure? yes | no

zakqwy wrote 05/02/2014 at 13:22

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

Michael O'Brien wrote 05/02/2014 at 18:18

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 05/02/2014 at 19:11

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

Are you sure? yes | no

Eric Evenchick wrote 04/30/2014 at 04:56

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

Michael O'Brien wrote 04/30/2014 at 05:30

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 04/30/2014 at 07:27

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

D-DAQ

Become a Hackaday.io member

Just one more thing

Description

Details

Components

Project Logs Collapse

Enjoy this project?

Discussions

Become a Hackaday.io Member

Does this project spark your interest?

Report project as inappropriate

Send message

Remove Member

Project Logs

Collapse