Enough people have asked in private to justify sharing this with everyone.
Before I start though, a couple of comments about "slagging off GEEZ!"
1) Bryon Short (the author of GEEZ!) is a great guy. He supports the SCCA
wholeheartedly, answers his phone and e-mail (we've had a number of
correspondences about GEEZ!) and works really hard to make his customers happy.
No question about it.
2) It is my opinion that GEEZ! makes it harder to get the information I want out
of the data. I found myself fighting the software more than using it, whereas
the Edelbrock software, despite being more basic in many ways, was easier to get
the answers I wanted out of it.
3) It is my opinion that a dedicated on-board datalogger computer (be it a Palm
or a purpose-built unit) is FAR superior to trying to fit and use a laptop
computer into a race car. My opinion is based on having tried both.
4) Given that you need a Palm to make best use of GEEZ!, you need to include the
price of the Palm into the system price. Depending on how you source the Palm,
that makes the price of a GEEZ! system about the same as the price of the
QwikData system - except that the QwikData gives you more data. If you don't
have a computer car like mine, that value drops somewhat as the basic QwikData
on a car with no stock sensors to tap into will only have LatG, LongG, RPM, and
Veh Speed, but that's still 2 more channels than GEEZ! gives you.
5) The QwikData requires a wiring harness, so it is somewhat less portable than
the GEEZ! system (you can use the same QwikData in multiple cars, as it has a
quick-release connector) but you will require a wiring harness in each target
car. For me, with one car, this is not an issue.
When you add all this up, for me, the QwikData system was a far better value -
same price of entry, more data, easier to use. If you already have a Palm, or if
you're willing to carry a laptop with you when you run and can put up with not
being able to read the screen, poor battery life, fragility etc., and you want
the lowest possible cost of entry, well, then GEEZ! may be the better choice for
you.
YMMV.
I wanted to give Byron my money, but his product did not meet my requirements. I
found something that did a better job for the same price, and I shared that with
everyone. I don't see anything wrong with that. I like and respect Hoosier Tom
too, but I don't run his tires. The product is not the man, the man is not the
product.
Anyway, to answer the question "How did you figure out that better braking in
that one corner would have saved 1.5 seconds?" (especially when it seems that
the G values reported are a little... optimistic)
I looked at the graph of the run with just Lateral G, Long G, and Vehicle Speed
turned on, and made a little sketch of the course on a piece of paper. I then
used the G peaks to make some tic marks on my sketch to indicate roughly where
on the course I was at the major event points. (ie, at 24 seconds in, I'm at
turn 3 - real rough stuff)
I then examined both the Long G peaks and the Veh Speed line (remember, on the
QwikData the Veh Speed line is an observed value taken from a sensor in the
transmission, not a calculated value like it is in GEEZ!, so accelerometer
absolute value errors don't influence results - or in other words, it makes no
difference if a G peak is 1.4G or .9G absolute, only that it is "the highest" or
"the lowest" or "in-between".)
>From this, I found the braking peak (it was at the finish) and noticed that the
slope of the speed line was much steeper here than anywhere else on the course.
I also noticed that it just so happened that the fastest point on the course was
at the finish, and that the slowest point was after the finish, and that I had a
long, steady brake application from one to the other. This slope could then
serve as a reference as to how much braking the car could do on that surface.
(it could also be used to correct the accelerometer value too, now that I think
about it)
I then went looking for the next highest speed drop, and it was at the entrance
to the tight left-hander mid-course. However, the slope of the speed line was
nowhere near as steep, nor was it as smooth, and the Long G line at this point,
while always negative, had 4 distinct peaks on it, unlike the finish that had
just one.
I measured the speed at the highest and lowest points at this corner entrance,
and then went over to my reference point at the finish to find how long it took
to slow down the same amount at the point of observed maximum braking - and
discovered that it took 1.5 seconds faster to slow down an equal amount. Note
that this was done with the speed line (a measured value), not by taking the
accelerometer value and doing some math. By doing it this way, we avoid any
accelerometer-induced errors.
Now that "1.5 seconds" value is not absolute. There may well be reasons why that
exact rate of deceleration was possible at the finish (it may have been uphill,
the grip there may have been better, the tires may have been warmer, etc) that
would not have allowed the same rate of deceleration at that corner entry.
Furthermore, by delaying the braking point, it follows that there would be more
acceleration prior to braking, so more ground covered, and a harder braking
application to get slowed down to the same speed at the same spot in the turn -
so it follows that simply "snipping out" the difference between the two observed
braking points isn't _exactly_ correct. It should, however, be in the ballpark.
But be it 1.5 seconds, or 1.2 seconds, or 1.7 seconds, or even 1 second isn't
important. What is important is that the driver broke too early and not hard
enough, and by doing so gave away a large chunk of time, which may well have
been on the order of the margin of victory at this event - at this one corner.
It thus follows that if the driver's braking technique can be improved, that he
should see some dramatic improvements in times - possibly dramatic enough to
start winning - assuming that this is a reoccurring problem. Knowing the driver
like I do, it probably is. :)
It would be interesting to run the accelerometer data through GEEZ!, and see if
I could arrive at the same conclusion. Having a speed sensor means no
accelerometer error, but I wonder if it would make any difference in this case.
The speed magnitudes would be off, but as mentioned before, absolute magnitude
isn't important, *relative* magnitude is. As long as speed and acceleration
peaks are internally consistent, it makes no difference what the absolute values
reported are.
Anyway, that's how I did it. If anyone can find problems with my methodology,
please feel free to bring them to my attention.
Incidentally, no matter *whose* product you choose to you, datalogging of this
nature looks to be (as RJ said) the single most important way to drop times
since the race tire - and for similar money. If you're not using this stuff yet,
you probably should be....
DG
|