While talking with white Buffalo, Rich and I are comparing notes on AE, Torque, Infinity, and other log data the two of us have amassed over the years. Much of this data was used to help other owners with woes, some of it was just to confirm all is well. This data was sent to us on a one-on-one basis, so letting the data into the wild was never really discussed in most cases. Rich asked for some stock-performance data and I started sifting through my library for stock-equipped trucks.

That's when it hit me - with so many people acquiring scan tools/gauges and logging their data, it helps to see for yourself what "normal" is. I thought about how the data could be shared in a way that respects the privacy of those who shared in emails and PMs - and doesn't turn into a bash-fest for tuners that would rather not have some of this out there. I tinkered with the idea of having no names on the files - just generic information like stock or not, injector size, air mods, and having a tuner or not.

This would be a very time-consuming project that could take months. A select few volunteers who are data savvy would need to clean up the personal/professional information and organize the data before uploading it to a repository, then post an outside link - like the B.E.S.T. map in my signature. This is a Herculean task, and the work would need to be divided up, then a very small number of people would have the ability to edit the files on the cloud - to keep it tidy and untainted.

I have had a history of inviting people to special projects and some of those ideas were little more than soot out the tailpipe, while others put rubber to road and are used as reference threads for the future. You just don't know what mudball is gunna stick unless you fling it at the wall. This has just been flung.

What say you?

 

Rich, This would be very cool. Especially for that are less versed on the tools and need something to refer to. You are the best when it comes to thinking outside of the box!!

Dan

 

Rich, I think this is a great idea. I can't say how much all of white Buffalo's data has helped with my most recent issue. It has been great to not only have the data to compare to for issues, but as a learning tool as well. Rich has pulled up countless graphs or spreadsheets of data and pointed out whats going on in each. It is great for the less knowledgeable, like myself, to have data to look at when trying to learn this stuff. It really helps to see how trucks all over the place are performing.

Excellent idea!

Baatzy

 

I think this is a great idea. Especially if a collection of graphs that illustrate various faults can be shown to help with future troubleshooting.

If you "hide" the original data in graphs that users could pull up and look at, then the personal and specific tuner info could remain undisclosed. For this, Excel lets you save templates, for both charts and data, so if some standards are defined, then users can more easily "drop in" their data and have consistent charts / data to upload.

It might also make it easier for the volunteers to make all the data align, so we're not comparing apples to androids.

 

A universal format is in mind, but it's also helpful to have the data in the original format - so it can be played back in... say... AE or the like. I wouldn't want to post raw Infinity data - it has a distinctive signature to the data and it would reveal the tuner.

 

That's why I mentioned posting graphs. People like me (who don't know squat about tuning parameters and don't really need to), all I need is a graph to which I can compare my data. So I'm thinking your data miners can generate a catalog of graphs we could look at. Actual data could be held offline with trustworthy souls like you. From some of the graph's you've posted recently, it looks like you've done some filtering to make the graphs smoother as well. Why would any of us need the actual data?

I enjoy the theoretical stuff and the explanations of how the systems work together to make these things run, that info certainly helps one understand what happens when something goes wrong and cause and effect sequence.

Just like your AE Class, this could be Ford 7.3L 101.

 

Cleaning raw data files up is one thing, but making graphs from all that data with a mish-mash of PID readings in the order/scale/multipliers they were logged is daunting to say the least. If the work was dealt out to more than one data decipherer, a template would be needed to make the graphs consistent - and templates don't lend themselves well to data mish-mash. You wold need the work done by a few, then sent to one person to perform any editing tasks needed. I can see where this would land in my lap. I don't begrudge the task to support my friends, but I would be a choke point to get the graphs out in a timely manner - work, life, and all that.

This has merit, but I have to wonder if maybe one could be done first and quickly, then the other will follow as time allows. I am also curious who has that volunteer spirit with data/graph savvy willing to work within one graphing standard agreed upon - and enough spare time on his/her hands.

For those wondering what a graphing standard would look like:

• Do we set one MAX ICP for all graphs, or do we float the MAX to make the data stand out on every graph?
• What will be the universal colors/line styles for each PID, so nobody gets confused when going from one graph to the next?
• XLS? ODS? Both?
• Graph size to fit most modern screens?
• Images with arrows and text are helpful. Software and format standards are needed for this as well.

This all sounds very ****, but please believe me when I say mixed formats can confuse the observer and actually lead to more disinformation than understanding. It can also lead to a bad case of I-give-up-itus when constantly reversing mental gears from one graph to the next.

 

Hi. I'll volunteer!

Being fairly new to the 7.3 PSD world, so far my only participation on this forum has been limited to one PM sent to Tugly (thanks for the reply).

Coming from the Cummins 12/24-valve world, these 7.3s are a whole new animal, and I'm eager to learn more about them.

This data sharing database seems like a great idea. Being a new to these engines, I'm finding that most of my time is spent looking for examples of how other peoples engines run, so I can compare to mine.

As I said, I don't know much about the 7.3, but I'm a big DIYer, and I can work with Excel files somewhat OK (just one of the tools I use at work).

So if you all experts think I can help; I'd be happy to participate on this project.

 

Just go ahead and call me Mr. Cynical Wet Blanket.

This is a truly amazing concept, and it could be truly valuable to many, many people. It could even be worthy of a full-time job where individuals would have to pay subscription fees for access (short term or long term, sort of like the way Carfax is run).

I guess I might be over thinking what you are wanting to do, though, Rich. It would be feasible on a limited basis with some representative samplings of data logs... categories like bone stock, lightly modified, moderately modified, with some additional subcategories like aftermarket/rebuilt tranny, aftermarket/rebuilt sticks, etc. It would still be a really big task.

I say that because it can be a MASSIVELY HUGE task you're talking about, Rich, and it would take a very specially gifted individual (or individuals) to get it setup and make it "live long and prosper". I've had to maintain a similar database myself before, and do not want to ever do it again. This "previous life" was in a paper manufacturing plant making roughly 2,500 tons per day of product, and I had to manage and maintain customized COA's on over two hundred grades of paper products for over 600 customers, each COA having anywhere from 6 to 20 test parameters and included statistics for the recent order as well as YTD stats for the same product grade... just that database was almost 25% of my working week for over 4 years, and it just kept getting bigger every day. Having lived that routine once, I've learned that is is NOT for me, especially as an unpaid part-time on-the-side effort.

This kind of one-stop-shopping database would be a truly amazing resource, but I have trouble envisioning how an unpaid individual would have or take the time to not only establish an initial repository, but then to also clean it up, standardize it, and THEN maintain it. I would expect that whomever it is would be inundated with tons of extraneous bits and pieces of data logs as all of us cheerleaders begin to "pitch in" on the effort. The REAL pitching in, though, needs to be in terms of a shared responsibility for maintaining the database once it has been compiled and standardized - you know... folks who can and will be a real part of the boots on the ground as opposed to the Suggesting Sideliners who help specify the product but are not involved in the actual building and maintaining part of the effort.

Personally, I know that I have the ability to help, but I simply do not have the spare time or energy to spend on it. If I were retired and not working a full time job, I might be in a much better position to help with the effort, but my 401K says that I'm probably at least 20 years away from that point of life, and that's assuming I'll even live into my mid-70's.

 

I don't think it sounds **** at all. You have provided a set of parameters/rules that would almost certainly have to be adhered to. I would be willing to help adjust tables into a predetermined order for queries.

I am limited though....MS Access 97 is where I stopped...

 

If you need excel work I will volunteer!
As an accountaqnt by day,and a tire tech - mechanic - parts counter guy in a past life I love data and I am reguarded as one of the office excel gurus in every job I have had.

 

My thoughts - the idea of putting this catalog/database of info together is both awesome and a huge load of work. Like F250, I do computer work all day, and I help (at least try to) others here when I've got the knowledge. But taking on a ton of data and further compiling it is daunting.

HOWEVER, one thing I absolutely agree on is a standard PID list, max values, and scale factors. Heck, Rich, you're pretty much already there if you go through the AE threads. But, maybe one ultimate new thread defining those PIDs, max values, and scale factors should be created.

With that established first, and people starting to adopt it, the future task of compiling would be far easier (as you suggested).

 

Good point, Steve.

 

I also have software that can read pdf files into excel documents, if needed...

 

The Torque PID list pretty much covers this in detail, so we already have a data collection template to work from. Different versions of AE have quirks with scale values in the PIDs, and that would have to be resolved at the time of recording, because data like MPH is lost without the correction.