A Question

[Pi_guy]

That is how my my son starts a conversation, I have a question.
Well I get a bit of a headache with this one.
As some of you know I have put on tech conferences in the past.
Thinking about doing one again.
But I have a question, what type of format would you want in a data conference.
So if this is an area that would interest you please share your ideas.
I have been to most conferences/training sessions from those that you need time on an IBM mainframe to solve some of the discussions to this is the on switch variety.

thanks

[Pi_guy]

So out of the brain trust here no comments.
I am not trying to get anyone to commit or give out trade secrets.
I am sure some of you have attended informational meeting that provided technical material.
This will be done in conjunction with the local SCCA region.
So any ideas?

One thought I have been floating is a panel of 6 to 8 race engineers with different perspectives and sort through a bunch of problems with varying options to a solution. In front of 20 or so participants and run a 5 minute explanation from each engineer as to their choices in solving the problem or achieving the answer they seek.

[BeerBudgetRacing]

For me I think having someone help me analyze my data to point out things I'm not even 'seeing' would be a great help.

Then, these types of issues could branch into other discussions.

So, several engineers in a workshop format working with students that moves into a discussion panel and then probably back to the workshop format...

Using the students issues brings the discussion level to what the audience wants.
Not some theoretical problem (that I probably have) that is 10th on my list of issues to resolve.

[Rick Kirchner]

"five easy things your data is trying to tell you that you haven't been able to understand"

[tapandrack]

For me I think having someone help me analyze my data to point out things I'm not even 'seeing' would be a great help.

I think BBR nailed it. Make it relevant for the customer. Let them bring a data file (preapproved file format) and have some time with a data engineer to interpret the data. Data is NOT the same as information, and information is what racers want.

If you had a panel of engineers talking about possible technical solutions to problems it could either be exhilarating for a data engineering audience or complete boredom for a results-based racer who wants to know how to use data to improve.

[S Lathrop]

Decades ago Richard Pare and I did race car engineering seminars around the country. Data logging was very rare at the time.

The biggest issue we faced was determining the audience we would have. Turned out that a good third of the attendees were solo drivers.

I found that all the attendees knew something about what we were teaching. What they lacked was an organized way to interpret what they were feeling as they drove. And a systematic way to analyzing the data they were acquiring as they drove.

I have worked as a race engineer for decades in cars from FV to Indy Lights. I have had the opportunity to work along side some of the very best race car engineers. What I think is most critical is the driver debriefing as soon as he gets out of the car and before anyone looks at the data.

The problem with data logging is that it is a reading of what the car did at an instant in time. The drivers brain is working on the next moment down the track as the data is being gathered. When you drive a car, your inputs are based what you think will work, what you have gotten away with on the previous lap and what you anticipate the car will do if you do something different. What is critical, I think, is to down load the driver based on his perception of what happened and what he did to make those things happen. Once I have a good understanding of what the driver was expecting, doing and the results he felt, I can then look at the data and see what was actually happening. Getting a driver to down load himself is really tricky. He may not have any idea the questions he should ask himself/herself.

It always helps if the driver has a good understanding of what the car needs to do differently so he can go faster. Drivers who are good at this type of analysis are usually the most successful and always seem to be consistently fast.

The very best known engineer I ever worked with would ask me to look at the data to answer questions he would have. He would write several pages of notes on a legal pad and would continually review the notes as he developed a revised setup. We won a lot of races that year. I have seen him to get the driver to go over his notes after he spent some time working on them. A second driver down loading.

It goes without saying that having an understanding of how the setup on the car produces the results on sees on the computer is vital to understanding what one is looking at in the data.

I have worked with driver's coaches. What I have found lacking in driver's coaches is an understanding that to drive a car on the fast or proper line, the car has to be setup properly to do that line at speed.

A driver won't turn in at the proper point if the car is slow to respond to steering inputs. How that will show up on the data logger other than the driver was turning in early and the cornering loads were slow to build up, I don't know. The driver would be my source of that information. Now maybe if you can point out to a driver that he is slow on entering a corner, he might say that the car won't let him turn in later or he may not even realize that he should go deeper and the car should rotate faster to get to the apex of the corner.

I would not have a clue how to organize a course on data analysis. One thing I found useful is comparing fast laps for several drivers on the same track. Maybe that could be a place to start.

[Pi_guy]

thank you
I am slammed right at minute till some time tomorrow.
Great input, spurred a bunch of ideas.
I will be more forth coming in the next few days.
Part of what I am trying to do it make it beneficial for all parties involved.

thanks again

michael