I've been using Craig's software to get rid of any knock retard and reading the plugs as I adjust FP and timing. Tonight I decided to try and use page 8 of the program as a "performance change" meter. Since my tranny won't make the WOT 2-3 shift, I decided to just use 0-60. I made 5 runs in a row with only +/-.03 difference. It doesn't seem to read true (like at the track or g-tech) since the 60ft.'s were ~1.7, even though I had much wheelspin. I guess if the wheelspin is about the same each time it should tell me if I've made the car slower or faster. Anybody else used it? Should wheelspin cause the times to be faster or slower in comparison to a track timer?

------------------
'87 Formula WS6 - ZZ4 Crate TPI, ported heads, LT4 hot cam, 1.6RR, Accel runners, Accel lower, ported plenum, Edelbrock 58mm TB, pulleys, SLP cold air, headers and full exhaust, gutted cat, Walbro 255, Koni yellows, aftermarket panhard & LCA's.

 

I cannot answer how how Craig's software works, but I had done made a "track" measurement calculation in a spreadsheet using Diacom data and I had to put a factor in the calculation to compensate for wheelspin.

I found that if you had a high amount of wheelspin, the calculation would result in a underestimating the distance travelled, especially for the 60' times. This is because I used the MPH reading from the ECM, and if you had wheelspin, you MPHs are higher because the wheels are spinning and not travelling at the true road speed. Other factors to consider is how accurate the MPH reading is at the ECM. With the SD ecm, there is a constant "Pulses/mile" that may need to be adjusted if the ECM's MPH is off. I have not found a similar constant within the 165 ECMs, though it may exist.

The good thing is that unless you have excess wheelspin, the effect over the whole 1/4 mile is not a lot. This is because wheelspin does not generally occur over the entire 1/4 mile: generally the first 60' is the problem. But it will cause you to calculate that you have travelled 1,320 ft sooner than you really have.

My solution was to only take a fraction of the MPHs for all MPH readings below 20 mph or the first 2 seconds to compute the distance travelled. Thus, if you have a "great launch" it will actually cause you to calculate the 1/4 mile times slower than it really is: which is nice for the track.

Now, if you are measuring 0-60 MPH performance, this is irrelevant because it is impossible (unless you have an extremely high HP engine) to spin the wheels to register 60 MPH (unless I am specifically trying). And I just calculate the time to get from the beginning of my "start" to where I hit 60 mph.

But, there still is a built in "error" because each frame is approximately .15 seconds (400 frames/minute at the quickest frequency on a fast ECM). Your first frame may have just started (when compared to when you launched) or you just missed it. So there is an automatic "error" of up to .15 seconds. So I wouldn't go "hanging my hat" on the times, but if you wish to measure performance from 0 to a high MPH (60 mph is a little low IMO) or to practice your launches, I did find it useful for seeing the difference and seeing where I am having problems "hooking up".

BTW, I found that my 0-60 MPH would increase as much as 2 seconds if I got a lot of wheel spin.

 

I did put in some extrapolation/interpolation algorithms for the 0.15s deal, so that the program will account for that and determine where in time the speed slope intersects. I also was meaning to put in a 'dead-time' to allow for wheel spin. If I remember correctly, I was going to make the program just extrapolate back to integrate linearly a distance from time zero to some time which follows. I played around with it some already, and found that it didn't make a hill of beans difference unless you had massive spin.

You're right about the MPH bias. I'm also using the MPH at the ECM as the independent variable, so errors will propagate. In my own personal experience, I found my MPH via G-Tech to be around 97 at the 1/4, while the program showed more like 88. Times were off too, by about 0.7s. A correction factor for MPH will be needed in the program.

-Craig

 

Craig, that may not be necessary. It really depends on the accuracy of the MPH reading at the ECM. My car, with 255s is basically "bang on" at 66% tread. New tires will make it slightly underestimated, and old tires slightly overestimated.

But I still found the ECM to be slightly off from my real speed. I cannot say about the MAF ECM, but on SD, I found changing the "Pulses/mile" from 4007 to 4024 gave a true reading.

Also agree that, except in the case of MASSIVE WHEELSPIN, the distance is not terribly off, but it is slightly. That is why I put a "factor" for the first 20 mph or 2 seconds.

When I was finished, I got my readings to within .1-.2 seconds @ the end of the 1/4 mile and with 1 MPH. The .1-.2 is the best I could due to the .15 variance in the "frame capture rate". A faster ALDL transmission rate is the only solution.

BTW, have you tried incorporating an HP component? If you BIN is properly "tuned", it is possible to get a reasonable estimate of HP based on the injector pulse width.

Seems like we have done the same thing with different methods.

 

After playing around alot with a VSS triggered stop watch, I set it up to ignore the first 3 wheel revolutions. 1/4 mile stuff gets you into serious ticket stuff. 60' times are for chassis tuning.
I ignore the first 3 revolutions start the watch and stop 100 revolutions later.
Makes for very repeatable results.
I care about the 1/4 when at the strip.
Direct Scan uses air, and fuel flow, in conjunction with weight gearing, to do a HP calculation.