ESMOTOR 1/4 mile record - 9.59 @ 146 mph
Registered User
Joined: Aug 2014
Posts: 1,062
From: Austin, Tx
Rep Power: 124
For those who don't know, I wrote the vboxtools.com software that a lot of you use to validate your results and Emre used above. I've had email with WRS about how my software works. In the email I told him how the VBox doesn't provide distance, but instead provides velocity. Velocity isn't available on all GPS receivers, but is available on some high end ones (like the ones used by the VBOX). I'm not sure how it calculates velocity, whether it differentiates against distance, but I do know high end GPS receivers do provide velocity.
Given velocity and sampling rate, my vboxtools.com software calculates distance by using integral calculus (it integrates velocity over time). Using this method, I break each sample up into 32000 sub-pieces, and use those sub-pieces to in both time samples and distance samples. This is how I calculate starting and ending time, starting and ending position. For trap speeds, I use NHRA rules of a 1-ft roll-out and 66-ft trap distance, and I average velocity over this 66-ft distance.
Questions often come up about the accuracy of my software for trap speeds. The best I can do is compare against known time slips. When I emailed 'wrs' about this, I mentioned that for the most part my trap speeds compare withint 1/3 MPH to the actual time slip, but that I had seen some anomalous results of 3-5 MPH. I'm bringing that up as a mea-culpa because my recollection of this anomaly came from these results at Las Vegas motor speedway in 2011. When I made that original comparison in 2011, I hadn't yet written vboxtools.com software, and I was using scripts (macros) written for the original VBOXTOOLS software by RaceLogic. Since writing vboxtools.com software, those values were updated and the biggest error was 0.899 MPH trap speed on a 125 MPH 1/4 mile run. In other words, my memory was based on a comparison I had done before I wrote vboxtools.com, and the 3-5 MPH anomaly I mentioned simply did not exist as I thought it did (because I wasn't comparing against vboxtools.com software). Anyways, I hope that makes sense.
But tonight, I did some large amounts of data collection on 40 time slips I have from ATCO and compared them to the vboxtools.com software results. IMO, the accuracy of vboxtools.com software on these 40 time slips is nothing short of impressive.
In 40 1/4 mile time slips, there are 200 opportunities to compare the time slip to the vboxtools.com (60', 330' 1/8 mile, 1000', 1/4 mile), and 80 opportunities to compare trap speed calculations (1/8 mile, 1/4 mile).
In the 200 timing comparisons, the smallest error was 0.001 seconds, and the largest was 0.204 seconds (not sure why that one entry was so far off). The average error was 0.042 seconds.
In the 80 trap speed comparisons, the smallest error was 0.002 MPH, and the largest error was 0.753 MPH. The average trap speed error was 0.294 MPH.
The trap speeds were all in the 122 - 126 MPH range, and frankly the difference between 126 MPH trap speed error and 142 MPH trap speed error is negligible. If there's a desire for the raw data, I'll be happy to post it. I could also post a direct comparison between the vBox running at 100 Hz, 20 Hz, and 10 Hz on a 300 MPH trap speed. I've already done this comparison, and the results are accurate to each other down to 3-decimal places. If the assumption is that higher trap speeds will gain larger error with vboxtools.com with a 10 Hz sampling rate, then the comparison showing approximately 0.005 difference between the 100Hz vBox, 20 Hz VBox, and 10 Hz VBox on a 300 MPH trap speed implies that assumption may not be correct. Again, if there's a desire for a lot of raw data, I'll be happy to provide. I didn't post it now because it's a bit time consuming as it is.
Anyways, I hope this explains a bit about the vboxtools.com software and the accuracy of timed runs, and trap speed calculations. If anybody has any questions, or wants to see the raw data (including scanned images of the time slips and download the vbox files themselves), feel free to ask.
Given velocity and sampling rate, my vboxtools.com software calculates distance by using integral calculus (it integrates velocity over time). Using this method, I break each sample up into 32000 sub-pieces, and use those sub-pieces to in both time samples and distance samples. This is how I calculate starting and ending time, starting and ending position. For trap speeds, I use NHRA rules of a 1-ft roll-out and 66-ft trap distance, and I average velocity over this 66-ft distance.
Questions often come up about the accuracy of my software for trap speeds. The best I can do is compare against known time slips. When I emailed 'wrs' about this, I mentioned that for the most part my trap speeds compare withint 1/3 MPH to the actual time slip, but that I had seen some anomalous results of 3-5 MPH. I'm bringing that up as a mea-culpa because my recollection of this anomaly came from these results at Las Vegas motor speedway in 2011. When I made that original comparison in 2011, I hadn't yet written vboxtools.com software, and I was using scripts (macros) written for the original VBOXTOOLS software by RaceLogic. Since writing vboxtools.com software, those values were updated and the biggest error was 0.899 MPH trap speed on a 125 MPH 1/4 mile run. In other words, my memory was based on a comparison I had done before I wrote vboxtools.com, and the 3-5 MPH anomaly I mentioned simply did not exist as I thought it did (because I wasn't comparing against vboxtools.com software). Anyways, I hope that makes sense.
But tonight, I did some large amounts of data collection on 40 time slips I have from ATCO and compared them to the vboxtools.com software results. IMO, the accuracy of vboxtools.com software on these 40 time slips is nothing short of impressive.
In 40 1/4 mile time slips, there are 200 opportunities to compare the time slip to the vboxtools.com (60', 330' 1/8 mile, 1000', 1/4 mile), and 80 opportunities to compare trap speed calculations (1/8 mile, 1/4 mile).
In the 200 timing comparisons, the smallest error was 0.001 seconds, and the largest was 0.204 seconds (not sure why that one entry was so far off). The average error was 0.042 seconds.
In the 80 trap speed comparisons, the smallest error was 0.002 MPH, and the largest error was 0.753 MPH. The average trap speed error was 0.294 MPH.
The trap speeds were all in the 122 - 126 MPH range, and frankly the difference between 126 MPH trap speed error and 142 MPH trap speed error is negligible. If there's a desire for the raw data, I'll be happy to post it. I could also post a direct comparison between the vBox running at 100 Hz, 20 Hz, and 10 Hz on a 300 MPH trap speed. I've already done this comparison, and the results are accurate to each other down to 3-decimal places. If the assumption is that higher trap speeds will gain larger error with vboxtools.com with a 10 Hz sampling rate, then the comparison showing approximately 0.005 difference between the 100Hz vBox, 20 Hz VBox, and 10 Hz VBox on a 300 MPH trap speed implies that assumption may not be correct. Again, if there's a desire for a lot of raw data, I'll be happy to provide. I didn't post it now because it's a bit time consuming as it is.
Anyways, I hope this explains a bit about the vboxtools.com software and the accuracy of timed runs, and trap speed calculations. If anybody has any questions, or wants to see the raw data (including scanned images of the time slips and download the vbox files themselves), feel free to ask.
Here is your explanation from your email:
So here's how it works. The vBox (device) doesn't give distance,
it only gives velocity. To calculate distance, we need to
(calculus) integrate velocity over time. To get specific
distances, I break up each sample into 32000 sub-pieces. So let's
say the integration calculated sample #999 at 1292 ft, and sample
#1000 at 1329 ft, I would take that difference and subdivide it
32000 times until I located where it crossed 1320 ft. Let's say
we cross 1320 ft at sub-sample was 999-28824 (of 32000). I would
then interpolate velocity the same way: taking the difference in
velocity between sample #999 and #1000, and subdivide it 32000
times, using subsample 28824 to mark the velocity at 1320 ft. In
a nutshell, that's how vboxtools.com and vboxtools (program from
Race Logic) both work.
First of all, let me pick a small but important nit with you. You are not using calculus when you produce a numeric integral, you are using function approximation and there is higher order math involved behind these techniques that is well beyond the scope of this forum in which I am fairly well versed. I have a BSCS, BSEE and MS Eng and I took advanced numerical analysis as an undergrad and actually programmed a number of numerical methods as well as using packaged products throughout my 30 year engineering career. My product was a software measurement product that made measurements on other software from within the kernel of the OS. Prior to that I worked on the development of a digital accelerometer with 20 bit resolution in the late 80s on which I wrote my masters thesis. I have written my own FFT and windowing programs as well as digital filters and am well acquainted with sources of numeric error in both approximation and measurement. I am very well acquainted with processing acceleration, velocity and position data using numeric techniques. Position and time are the only things that can be directly measured. Velocity and acceleration are measured with special transducers which involve error themselves but of course we are not using those, we are using position data with known inaccuracy.
Secondly, since the velocity data you have are numerically derived from position in the Vbox computer, we don't know how they do that or what error might be introduced there. What method are you using to "integrate" the velocity data? Are you solving the DE or attempting to use some simple integration method like Newton Cotes or Trapezoid Rule which depend on even spaced data grids?
The vbox tool does give lattitude and longitude from which actual position may be derived and those are subject to large errors (I actually converted some of them). Where do you suppose the GPS receiver device produced it's calculated velocity from? Velocity is the derivative of position and finite differences used for differentiation are subject to large numerical errors and non-integrable functions due to the fact they are all ill-conditioned. So this mitigates against you getting back to good position data from the velocity data, you might be better served converting the longitude and latitude to actual position and then making your calculation but good luck with that.
Furthermore, whatever processor being used in the Vbox we don't know the resolution of the internal representation of numbers but we do know there are substantial errors in the GPS positional data as admitted to by the Racelogic guys themselves. In fact, they offer a device that can improve accuracy for an extra price but the basic box still has a 10ft CEP of 95% which means each sample is in question by a circle of 10 feet. How can you dismiss that error in a 66ft trap where in the case of a 20hz sample at 143mph the distance between samples is less than the error in the sample or in the case of a 10hz sample where it amounts to 50% of the difference between the samples? How can you compare that to fixed sensors at a track? The biggest error at the track is clock jitter (if you know what that is) and wheel diameter.
I believe the reason your times are accurate has to do with the number of samples and distances and times involved as I believe I have explained here. 10 feet of error out of 1320 feet is .75% so that would be your maximum distance error but likely there could be cancellation of errors resulting in much lower error of less than .1%. Your times are in generally good agreement with both tracks but your traps are significantly in disagreement with two different tracks 225 miles apart. I would tend to question your results and not the track in the case of the trap speeds based on the known sources of error.
What numerical integration are you using? Did you code it? Runge Kutta is what I used back in the day and I bought it already coded but I have written my own using Numerical Recipes in C as well as writing my own FFT code and windowing code for a number of popular windows.
Your 32,000 sub pieces doesn't mean anything at all except for time where we can assume a regular subdivision. The positional or velocity data isn't known at those time points so you are making up data based on an unknown underlying function. That is a source of error right there. How do you generate the 32,000 velocity points that you integrate to obtain position and then which you then use to compute an average speed based on the assumed times due to the fact you assumed a position at those times?
Here are my slips with trap speeds and your computational results
distance-----Vbox------------------Ennis---------------------------------Error
1/8 7.119@101.86------------------7.138@103.51-----------------------1.01%
1/4 10.983@127.404---------------11.03@130.33------------------------2.3%
1/8 7.111@101.671----------------7.094@103.87------------------------2.2%
1/4 10.969@127.333---------------10.964@128.47----------------------.8%
1/8 7.279 @ 101.76----------------7.302@98.93-------------------------2.8%
1/4 11.147 @ 127.040-------------11.175@127.16-----------------------0%
1/8 7.160 @ 101.659--------------whited out on slip
1/4 11.000 @ 128.558-------------10.972@131.34-----------------------2.2%
1/8 7.084 @ 103.469---------------7.058@105.70------------------------2.1%
1/4 10.859 @ 130.508--------------10.839@133.38----------------------2.1%
1/8 7.136 @ 103.333----------------7.144@100.91----------------------2.4%
1/4 10.912 @ 130.494--------------10.893@130.72----------------------.2%
distance---------Vbox----------------SAR------------------------------ Error
1/8 6.853 @ 103.848---------------6.88@103.93------------------------.08%
1/4 10.628 @ 130.249--------------10.65@135.42----------------------4%
1/8 7.013 @ 103.546----------------7.02@103.81-----------------------.2%
1/4 10.795 @ 130.106--------------10.80@135.18-----------------------3.9%
1/8 6.940 @ 103.860----------------6.94@104.07------------------------.2%
1/4 10.719 @ 130.159---------------10.71@135.09----------------------3.8%
1/8 7.067 @ 103.175-----------------7.08@103.5------------------------.3%
1/4 10.869 @ 129.294----------------10.877@134.37--------------------3.9%
1/8 7.045 @ 103.542------------------7.08@104.77---------------------1.2%
1/4 10.832 @ 129.867-----------------10.86@132.82--------------------2.3%
These are two different tracks on two different days with the same car running the same mods and the last 8 runs were all on a 50/50 race gas and 93 mix. DAs were different at the tracks but what I think may be one issue is having the satellite change in the middle of a run. That happened at Ennis in the second run around he 1/8 mile mark. It changes back and forth between 8 and 9 starting about 99mph. I will look at other runs to see if the same thing is happening where there are larger errors. However, I think the biggest problem is what I have already stated and you have simply hand-waved away, the error in the data itself and how large it is compared to the length of the trap interval.
Last edited by wrs; Oct 27, 2015 at 03:17 PM.
Registered User
Joined: Nov 2009
Posts: 95
From: Morgan Hill, CA
Rep Power: 22
Would you like my slips and .dbn files? 40 out of 8000 (which you mentioned is how many files have so far been submitted) is statistically insignificant. If you want to verify your methodology then do a real mathematical error analysis on it that includes all sources of error both numerical and measurement and then tell us where the inaccuracies are. I appreciate the effort you have put into your site, I use it but I don't want to rely on something that I can't trust and my experience says I have to mistrust either the slips I got at the track or your software.
Here is your explanation from your email:
So here's how it works. The vBox (device) doesn't give distance,
it only gives velocity. To calculate distance, we need to
(calculus) integrate velocity over time. To get specific
distances, I break up each sample into 32000 sub-pieces. So let's
say the integration calculated sample #999 at 1292 ft, and sample
#1000 at 1329 ft, I would take that difference and subdivide it
32000 times until I located where it crossed 1320 ft. Let's say
we cross 1320 ft at sub-sample was 999-28824 (of 32000). I would
then interpolate velocity the same way: taking the difference in
velocity between sample #999 and #1000, and subdivide it 32000
times, using subsample 28824 to mark the velocity at 1320 ft. In
a nutshell, that's how vboxtools.com and vboxtools (program from
Race Logic) both work.
First of all, let me pick a small but important nit with you. You are not using calculus when you produce a numeric integral, you are using function approximation and there is higher order math involved behind these techniques that is well beyond the scope of this forum in which I am fairly well versed. I have a BSCS, BSEE and MS Eng and I took advanced numerical analysis as an undergrad and actually programmed a number of numerical methods as well as using packaged products throughout my 30 year engineering career. My product was a software measurement product that made measurements on other software from within the kernel of the OS. Prior to that I worked on the development of a digital accelerometer with 20 bit resolution in the late 80s on which I wrote my masters thesis. I have written my own FFT and windowing programs as well as digital filters and am well acquainted with sources of numeric error in both approximation and measurement. I am very well acquainted with processing acceleration, velocity and position data using numeric techniques. Position and time are the only things that can be directly measured. Velocity and acceleration are measured with special transducers which involve error themselves but of course we are not using those, we are using position data with known inaccuracy.
Secondly, since the velocity data you have are numerically derived from position in the Vbox computer, we don't know how they do that or what error might be introduced there. What method are you using to "integrate" the velocity data? Are you solving the DE or attempting to use some simple integration method like Newton Cotes or Trapezoid Rule which depend on even spaced data grids?
The vbox tool does give lattitude and longitude from which actual position may be derived and those are subject to large errors (I actually converted some of them). Where do you suppose the GPS receiver device produced it's calculated velocity from? Velocity is the derivative of position and finite differences used for differentiation are subject to large numerical errors and non-integrable functions due to the fact they are all ill-conditioned. So this mitigates against you getting back to good position data from the velocity data, you might be better served converting the longitude and latitude to actual position and then making your calculation but good luck with that.
Furthermore, whatever processor being used in the Vbox we don't know the resolution of the internal representation of numbers but we do know there are substantial errors in the GPS positional data as admitted to by the Racelogic guys themselves. In fact, they offer a device that can improve accuracy for an extra price but the basic box still has a 10ft CEP of 95% which means each sample is in question by a circle of 10 feet. How can you dismiss that error in a 66ft trap where in the case of a 20hz sample at 143mph the distance between samples is less than the error in the sample or in the case of a 10hz sample where it amounts to 50% of the difference between the samples? How can you compare that to fixed sensors at a track? The biggest error at the track is clock jitter (if you know what that is) and wheel diameter.
I believe the reason your times are accurate has to do with the number of samples and distances and times involved as I believe I have explained here. 10 feet of error out of 1320 feet is .75% so that would be your maximum distance error but likely there could be cancellation of errors resulting in much lower error of less than .1%. Your times are in generally good agreement with both tracks but your traps are significantly in disagreement with two different tracks 225 miles apart. I would tend to question your results and not the track in the case of the trap speeds based on the known sources of error.
What numerical integration are you using? Did you code it? Runge Kutta is what I used back in the day and I bought it already coded but I have written my own using Numerical Recipes in C as well as writing my own FFT code and windowing code for a number of popular windows.
Your 32,000 sub pieces doesn't mean anything at all except for time where we can assume a regular subdivision. The positional or velocity data isn't known at those time points so you are making up data based on an unknown underlying function. That is a source of error right there. How do you generate the 32,000 velocity points that you integrate to obtain position and then which you then use to compute an average speed based on the assumed times due to the fact you assumed a position at those times?
Here are my slips with trap speeds and your data
distance-----Vbox------------------Ennis---------------------------------Error
1/8 7.119@101.86------------------7.138@103.51-----------------------.6%
1/4 10.983@127.404---------------11.03@130.33------------------------2.6%
1/8 7.111@101.671----------------7.094@103.87------------------------2.2%
1/4 10.969@127.333---------------10.964@128.47----------------------.8%
1/8 7.279 @ 101.76----------------7.302@98.93-------------------------2.8%
1/4 11.147 @ 127.040-------------11.175@127.16-----------------------0%
1/8 7.160 @ 101.659--------------whited out on slip
1/4 11.000 @ 128.558-------------10.972@131.34-----------------------2.2%
1/8 7.084 @ 103.469---------------7.058@105.70------------------------2.1%
1/4 10.859 @ 130.508--------------10.839@133.38----------------------2.1%
1/8 7.136 @ 103.333----------------7.144@100.91----------------------2.4%
1/4 10.912 @ 130.494--------------10.893@130.72----------------------.2%
distance---------Vbox----------------SAR------------------------------ Error
1/8 6.853 @ 103.848---------------6.88@103.93------------------------.8%
1/4 10.628 @ 130.249--------------10.65@135.42----------------------4%
1/8 7.013 @ 103.546----------------7.02@103.81-----------------------.2%
1/4 10.795 @ 130.106--------------10.80@135.18-----------------------3.9%
1/8 6.940 @ 103.860----------------6.94@104.07------------------------.2%
1/4 10.719 @ 130.159---------------10.71@135.09----------------------3.8%
1/8 7.067 @ 103.175-----------------7.08@103.5------------------------.3%
1/4 10.869 @ 129.294----------------10.877@134.37--------------------3.9%
1/8 7.045 @ 103.542------------------7.08@104.77---------------------1.2%
1/4 10.832 @ 129.867-----------------10.86@132.82--------------------2.3%
These are two different tracks on two different days with the same car running the same mods and the last 8 runs were all on a 50/50 race gas and 93 mix. DAs were different at the tracks but what I think may be one issue is having the satellite change in the middle of a run. That happened at Ennis in the second run around he 1/8 mile mark. It changes back and forth between 8 and 9 starting about 99mph. I will look at other runs to see if the same thing is happening where there are larger errors. However, I think the biggest problem is what I have already stated and you have simply hand-waved away, the error in the data itself and how large it is compared to the length of the trap interval.
Here is your explanation from your email:
So here's how it works. The vBox (device) doesn't give distance,
it only gives velocity. To calculate distance, we need to
(calculus) integrate velocity over time. To get specific
distances, I break up each sample into 32000 sub-pieces. So let's
say the integration calculated sample #999 at 1292 ft, and sample
#1000 at 1329 ft, I would take that difference and subdivide it
32000 times until I located where it crossed 1320 ft. Let's say
we cross 1320 ft at sub-sample was 999-28824 (of 32000). I would
then interpolate velocity the same way: taking the difference in
velocity between sample #999 and #1000, and subdivide it 32000
times, using subsample 28824 to mark the velocity at 1320 ft. In
a nutshell, that's how vboxtools.com and vboxtools (program from
Race Logic) both work.
First of all, let me pick a small but important nit with you. You are not using calculus when you produce a numeric integral, you are using function approximation and there is higher order math involved behind these techniques that is well beyond the scope of this forum in which I am fairly well versed. I have a BSCS, BSEE and MS Eng and I took advanced numerical analysis as an undergrad and actually programmed a number of numerical methods as well as using packaged products throughout my 30 year engineering career. My product was a software measurement product that made measurements on other software from within the kernel of the OS. Prior to that I worked on the development of a digital accelerometer with 20 bit resolution in the late 80s on which I wrote my masters thesis. I have written my own FFT and windowing programs as well as digital filters and am well acquainted with sources of numeric error in both approximation and measurement. I am very well acquainted with processing acceleration, velocity and position data using numeric techniques. Position and time are the only things that can be directly measured. Velocity and acceleration are measured with special transducers which involve error themselves but of course we are not using those, we are using position data with known inaccuracy.
Secondly, since the velocity data you have are numerically derived from position in the Vbox computer, we don't know how they do that or what error might be introduced there. What method are you using to "integrate" the velocity data? Are you solving the DE or attempting to use some simple integration method like Newton Cotes or Trapezoid Rule which depend on even spaced data grids?
The vbox tool does give lattitude and longitude from which actual position may be derived and those are subject to large errors (I actually converted some of them). Where do you suppose the GPS receiver device produced it's calculated velocity from? Velocity is the derivative of position and finite differences used for differentiation are subject to large numerical errors and non-integrable functions due to the fact they are all ill-conditioned. So this mitigates against you getting back to good position data from the velocity data, you might be better served converting the longitude and latitude to actual position and then making your calculation but good luck with that.
Furthermore, whatever processor being used in the Vbox we don't know the resolution of the internal representation of numbers but we do know there are substantial errors in the GPS positional data as admitted to by the Racelogic guys themselves. In fact, they offer a device that can improve accuracy for an extra price but the basic box still has a 10ft CEP of 95% which means each sample is in question by a circle of 10 feet. How can you dismiss that error in a 66ft trap where in the case of a 20hz sample at 143mph the distance between samples is less than the error in the sample or in the case of a 10hz sample where it amounts to 50% of the difference between the samples? How can you compare that to fixed sensors at a track? The biggest error at the track is clock jitter (if you know what that is) and wheel diameter.
I believe the reason your times are accurate has to do with the number of samples and distances and times involved as I believe I have explained here. 10 feet of error out of 1320 feet is .75% so that would be your maximum distance error but likely there could be cancellation of errors resulting in much lower error of less than .1%. Your times are in generally good agreement with both tracks but your traps are significantly in disagreement with two different tracks 225 miles apart. I would tend to question your results and not the track in the case of the trap speeds based on the known sources of error.
What numerical integration are you using? Did you code it? Runge Kutta is what I used back in the day and I bought it already coded but I have written my own using Numerical Recipes in C as well as writing my own FFT code and windowing code for a number of popular windows.
Your 32,000 sub pieces doesn't mean anything at all except for time where we can assume a regular subdivision. The positional or velocity data isn't known at those time points so you are making up data based on an unknown underlying function. That is a source of error right there. How do you generate the 32,000 velocity points that you integrate to obtain position and then which you then use to compute an average speed based on the assumed times due to the fact you assumed a position at those times?
Here are my slips with trap speeds and your data
distance-----Vbox------------------Ennis---------------------------------Error
1/8 7.119@101.86------------------7.138@103.51-----------------------.6%
1/4 10.983@127.404---------------11.03@130.33------------------------2.6%
1/8 7.111@101.671----------------7.094@103.87------------------------2.2%
1/4 10.969@127.333---------------10.964@128.47----------------------.8%
1/8 7.279 @ 101.76----------------7.302@98.93-------------------------2.8%
1/4 11.147 @ 127.040-------------11.175@127.16-----------------------0%
1/8 7.160 @ 101.659--------------whited out on slip
1/4 11.000 @ 128.558-------------10.972@131.34-----------------------2.2%
1/8 7.084 @ 103.469---------------7.058@105.70------------------------2.1%
1/4 10.859 @ 130.508--------------10.839@133.38----------------------2.1%
1/8 7.136 @ 103.333----------------7.144@100.91----------------------2.4%
1/4 10.912 @ 130.494--------------10.893@130.72----------------------.2%
distance---------Vbox----------------SAR------------------------------ Error
1/8 6.853 @ 103.848---------------6.88@103.93------------------------.8%
1/4 10.628 @ 130.249--------------10.65@135.42----------------------4%
1/8 7.013 @ 103.546----------------7.02@103.81-----------------------.2%
1/4 10.795 @ 130.106--------------10.80@135.18-----------------------3.9%
1/8 6.940 @ 103.860----------------6.94@104.07------------------------.2%
1/4 10.719 @ 130.159---------------10.71@135.09----------------------3.8%
1/8 7.067 @ 103.175-----------------7.08@103.5------------------------.3%
1/4 10.869 @ 129.294----------------10.877@134.37--------------------3.9%
1/8 7.045 @ 103.542------------------7.08@104.77---------------------1.2%
1/4 10.832 @ 129.867-----------------10.86@132.82--------------------2.3%
These are two different tracks on two different days with the same car running the same mods and the last 8 runs were all on a 50/50 race gas and 93 mix. DAs were different at the tracks but what I think may be one issue is having the satellite change in the middle of a run. That happened at Ennis in the second run around he 1/8 mile mark. It changes back and forth between 8 and 9 starting about 99mph. I will look at other runs to see if the same thing is happening where there are larger errors. However, I think the biggest problem is what I have already stated and you have simply hand-waved away, the error in the data itself and how large it is compared to the length of the trap interval.
I had a few simple points -- or at least I thought they were simple.
1. When I looked back over my 3-5 MPH anomalies, I realized they weren't real. When I used my new software, they were less than 0.9 MPH error.
2. When I compared 40+4+4 time slips to three known NHRA drag strips, three time slips from the Texas Mile, three time slips from the Mojave Mile, the error is usually less than 1/3 MPH.
I'm pretty satisfied with that.
Registered User
Joined: Aug 2014
Posts: 1,062
From: Austin, Tx
Rep Power: 124
Is that what's up on the site now?
I don't see how you can claim that your 40 results mean anything when I just posted more than 1/4th that number that show larger errors than the largest you claim to have now with your "new" software which I assume is responsible for the data I just posted. I say that because I re-ran those same .dbn files against vboxtools.com in generating the data for this post.
Registered User
Joined: Nov 2009
Posts: 95
From: Morgan Hill, CA
Rep Power: 22
Is that what's up on the site now?
Your level of satisfaction doesn't correct errors that I posted that are obviously larger than those you claim to have in your possession. I have posted all of these time slips and you can check them if you want.
Your own observations fail to vouch for the timing equipment at the track, nor the health of your (much) older vbox design, nor account for the differences in GPS engines between your older vbox design and my newer vbox design, nor the slightly down-revision firmware you are running on it. I can't say with any certainty that these are factors any more than you can say with certainty that they aren't.
You did mention satellite reception in your earlier post. My software does have some filters to detect anomalies caused by satellites going in and out of reception, and I flag the results as invalid when the data swings a little too far. I document those guard bands when you submit a file in the "Error Descriptions" section of the results page. I think three of those errors deal with anomalies caused by satellite reception issues. So at least I try to flag these errors.
I don't see how you can claim that your 40 results mean anything when I just posted more than 1/4th that number that show larger errors than the largest you claim to have now with your "new" software which I assume is responsible for the data I just posted. I say that because I re-ran those same .dbn files against vboxtools.com in generating the data for this post.
BTW, if you "re-ran" those files, then you got cached results...the software is smart enough to know that you submitted them before and it doesn't do any real work on the re-runs. If you want to force a re-run, then I'll be happy to tell you how.
Registered User
Joined: Aug 2014
Posts: 1,062
From: Austin, Tx
Rep Power: 124
Missed that I think.
The Ennis track runs NHRA events on a regular basis and SAR has been in business a long time but had just been reopened when I collected the 135mph traps. I didn't use my Performance Box the second time I went back but I will be this weekend.
I just bought it a year ago and it's the 10hz version. The CEP is the same on both the 20hz and 10hz versions and that is the primary error of concern. True, you can buy a box with higher accuracy that can be used to correct data on the lower accuracy boxes but I don't have one and don't plan to buy one. I think OBD data logging will probably be a more accurate measure anyway. It is the errors in the data that I am referring to. You can't produce better results than the quality of the data and most people with Vbox's bought them a while back and thus they are subject to the limitations which you point out. What I am trying to point out to you is that the errors are more likely in the GPS, Vbox and to an extent your own calculations than they are due to the track measurement equipment which is far more simple and direct.
Not sure I noticed any of these being flagged as the results I posted were all labelled valid. I am going to investigate all the files to see how often that happened and if it's related to the results with larger errors, that would make sense to me as a good reason for the divergence in track data and your results.
No, in fact those are what I am concerned with. I don't believe the track is the problem in either case. It's either the Vbox or some combination of the error in the data and the way your estimates are produced but not the fault of the track measures.
Well I suppose all I should need to do is clear the cookies but it seemed like it took a while to process the results after the upload was completed.
I am just trying to help here because I don't like the idea that people begin to invalidate timeslips because they don't like what's printed on them and that most certainly has happened here where the claims are that the track is wrong and the vbox is right. I simply pointed out the numerous sources of Vbox error as documented and compared it to the very simple setup and limited sources of error in the track trap speed measurement.
nor the health of your (much) older vbox design, nor account for the differences in GPS engines between your older vbox design and my newer vbox design, nor the slightly down-revision firmware you are running on it. I can't say with any certainty that these are factors any more than you can say with certainty that they aren't.
You did mention satellite reception in your earlier post. My software does have some filters to detect anomalies caused by satellites going in and out of reception, and I flag the results as invalid when the data swings a little too far. I document those guard bands when you submit a file in the "Error Descriptions" section of the results page. I think three of those errors deal with anomalies caused by satellite reception issues. So at least I try to flag these errors.
I am just trying to help here because I don't like the idea that people begin to invalidate timeslips because they don't like what's printed on them and that most certainly has happened here where the claims are that the track is wrong and the vbox is right. I simply pointed out the numerous sources of Vbox error as documented and compared it to the very simple setup and limited sources of error in the track trap speed measurement.
Registered User
Joined: Nov 2009
Posts: 95
From: Morgan Hill, CA
Rep Power: 22
I just bought it a year ago and it's the 10hz version. The CEP is the same on both the 20hz and 10hz versions and that is the primary error of concern. True, you can buy a box with higher accuracy that can be used to correct data on the lower accuracy boxes but I don't have one and don't plan to buy one. I think OBD data logging will probably be a more accurate measure anyway. It is the errors in the data that I am referring to. You can't produce better results than the quality of the data and most people with Vbox's bought them a while back and thus they are subject to the limitations which you point out. What I am trying to point out to you is that the errors are more likely in the GPS, Vbox and to an extent your own calculations than they are due to the track measurement equipment which is far more simple and direct.
I don't claim the infallibility of the vBox, but I'm probably more inclined to blame the track and/or satellite reception to explain the anomalies. Sacramento was a good example of a track that set a lot of records. I heard through the grapevine that their trap lights were misplaced by a few feet and that accounted for the unusually high trap speeds at Sac. I've also heard of strips whose timing equipment was "bumped" by cars as they crash or run into the sides. Sometimes that isn't noticed and corrected until some time later. Anyways, that's just my thoughts, and all just anecdotes.
Not sure I noticed any of these being flagged as the results I posted were all labelled valid. I am going to investigate all the files to see how often that happened and if it's related to the results with larger errors, that would make sense to me as a good reason for the divergence in track data and your results.
...
Well I suppose all I should need to do is clear the cookies but it seemed like it took a while to process the results after the upload was completed.
...
Well I suppose all I should need to do is clear the cookies but it seemed like it took a while to process the results after the upload was completed.
I am just trying to help here because I don't like the idea that people begin to invalidate timeslips because they don't like what's printed on them and that most certainly has happened here where the claims are that the track is wrong and the vbox is right. I simply pointed out the numerous sources of Vbox error as documented and compared it to the very simple setup and limited sources of error in the track trap speed measurement.
Registered User
Joined: Nov 2009
Posts: 95
From: Morgan Hill, CA
Rep Power: 22
No cookies, the file you submit has an md5sum hash stored in an SQL database. So when you resubmit, it first calculates the md5sum, compares against the database, and gives you the cached results if it's already been submitted. That's why the results page always has the original IDXXXXXX number of the original submission. The perfdb.org site has an internal setting to ignore the database lookups. That's why perfdb.org will always deliver fresh results with a new IDYYYYYY value every time.
Registered User
Joined: Aug 2014
Posts: 1,062
From: Austin, Tx
Rep Power: 124
No cookies, the file you submit has an md5sum hash stored in an SQL database. So when you resubmit, it first calculates the md5sum, compares against the database, and gives you the cached results if it's already been submitted. That's why the results page always has the original IDXXXXXX number of the original submission. The perfdb.org site has an internal setting to ignore the database lookups. That's why perfdb.org will always deliver fresh results with a new IDYYYYYY value every time.
I will rerun the data at perfdb. This issue of claiming slips are invalid is really annoying when the results are better than those of another car owner who is seeking to minimize them. The tracks generally do their best to make sure they are providing accurate times unless it's a rinkydink operation but neither Ennis nor SAR are what I would call rinkydink and they do have good equipment that I have seen with my own peepers.
I have the Cobb AP and the OBDIIlink for bluetooth and one for Wifi which I used in addition to my Vbox out on my county road a couple weeks ago. In that case the Vbox produced really low trap speeds with a car that had done far better with less tuning, and more tire wear in the past. I was able to see some timing reduction in a couple of the cylinders above 100mph which helped explain some of it but I am pretty sure the car ran faster than the 127 reported by the tools. I have run faster out there according to the box in the past and there was just no reason to believe what it told me. The AP is capable of timing 1/4 miles and I may just use it going forward.
Last edited by wrs; Oct 28, 2015 at 06:24 AM.
Registered User
Joined: Dec 2014
Posts: 2,202
From: New York City
Rep Power: 172
This thread has definitely turned into an engineering discussion that is far over my simple litigator mind. I am good with words but not numbers or engineering concepts.
What I really want to know is what tires Emre was running to get those scorching times. I have to believe they were some sort of slicks or drag radials. Just no way street tires could put down that kind of power I want to run a set of those myself once I get the VTG upgrade for events.
What I really want to know is what tires Emre was running to get those scorching times. I have to believe they were some sort of slicks or drag radials. Just no way street tires could put down that kind of power I want to run a set of those myself once I get the VTG upgrade for events.
Registered User
Joined: Nov 2009
Posts: 95
From: Morgan Hill, CA
Rep Power: 22
I will rerun the data at perfdb. This issue of claiming slips are invalid is really annoying when the results are better than those of another car owner who is seeking to minimize them. The tracks generally do their best to make sure they are providing accurate times unless it's a rinkydink operation but neither Ennis nor SAR are what I would call rinkydink and they do have good equipment that I have seen with my own peepers.
I have the Cobb AP and the OBDIIlink for bluetooth and one for Wifi which I used in addition to my Vbox out on my county road a couple weeks ago. In that case the Vbox produced really low trap speeds with a car that had done far better with less tuning, and more tire wear in the past. I was able to see some timing reduction in a couple of the cylinders above 100mph which helped explain some of it but I am pretty sure the car ran faster than the 127 reported by the tools. I have run faster out there according to the box in the past and there was just no reason to believe what it told me. The AP is capable of timing 1/4 miles and I may just use it going forward.
I think all the vBox's uses an accelerometer and GPS engine in tandem. Probably use the accel to know when they start moving, or to stabilize the GPS engine? Beats me...but I'm pretty sure they have both.
Registered User
Joined: Aug 2014
Posts: 1,062
From: Austin, Tx
Rep Power: 124
Just make sure you submit to perfdb.ORG not perfdb.COM. perfdb.com and vboxtools.com have the caching mechanism, whereas perfdb.org does not.
I'm pretty sure the AP does 1/4 mile timing from an accelerometer. BMW performance steering wheel and other auto devices like it all use an accelerometer to emulate performance tests.
I think all the vBox's uses an accelerometer and GPS engine in tandem. Probably use the accel to know when they start moving, or to stabilize the GPS engine? Beats me...but I'm pretty sure they have both.
I'm pretty sure the AP does 1/4 mile timing from an accelerometer. BMW performance steering wheel and other auto devices like it all use an accelerometer to emulate performance tests.
I think all the vBox's uses an accelerometer and GPS engine in tandem. Probably use the accel to know when they start moving, or to stabilize the GPS engine? Beats me...but I'm pretty sure they have both.
My feeling is that I would trust the track he most unless they mispositioned the sensors as you said happened at Sacramento but otherwise, the sources of error are fewer and smaller at tracks. I really bought the Vbox to let me know how much difference mods are making and what I noticed is that guys at the dragstrip with the same car and mods were getting higher trap speeds than me. It bothered me that my M5 wasn't as fast as it should be but now I see in my experience that tracks tend to measure a higher speed for the trap while the Vbox does a good job with timing and the 0-60 or 60ft measures but gives a lower estimate on trap speed. That is my experience anyway.
I do appreciate your tools and I used perfdb.com and got the same results so I will try perfdb.org now to see if that helps.
ETA: Same results at .org and I had never used perfdb before so there were probably no cached results. All I knew about was vboxtools.com. I think the issue is my Vbox data and that isn't anything you can help with very much no matter how small you slice your sections. I didn't mean to say my credentials were superior, all I was trying to do was impress upon you that I wasn't making comments out of left field. I have done this kind of work and it's painstaking and frustrating to find and understand sources of error, clock jitter was an especially tricky one for me back in the 80s when I was working on the high dynamic range accelerometers that produced a digital output. I developed a sigma-delta codec around the accelerometer that produced the output but first we had to prove the technique with an electronic A-D converter that could do 20bit resolution at a time when 16bit was the standard. We used a frequency multiplier to run the sampling circuit based off a crystal oscillator and what we discovered was that we needed a base oscillator that had a very small clock jitter error since that was a fixed error that would show up in the multiplied frequency as a constant. For instance we had a 1mhz base clock that was multiplied by 16 to run the digital circuits. The jitter in that clock was say only .01% of 1mhz but that was 16 times larger in a 16mhz signal because it was a fixed error. A factor of 16 is basically 4 bits and so our error was as big as 4 bits at the higher clock rate. Finding a clock with a lower jitter was the key and that meant a lower base oscillation rate because that turned out to be what the jitter error was related to in crystal oscillators. So we just lowered the base frequency and increased he multiplier. Finding that error took several weeks and it was very frustrating because I didn't have it properly modeled in the simulations but it was showing up in he built circuits. All of the other parameters we messed with in the simulation would translate directly into the built circuit but this jitter error wouldn't show up until the data was put through the FIR decimation filter and that was why it was so frustrating because the raw bit stream showed the proper resolution but the decimated parallel output was 4 bits less resolution. I did solve the problem though it took some time. Engineering is a painstaking business and not for those in a hurry for results, like managers and marketing guys and often, customers.
Last edited by wrs; Oct 29, 2015 at 06:14 AM.
Registered User
Joined: Nov 2009
Posts: 95
From: Morgan Hill, CA
Rep Power: 22
Yeah that makes sense to have a small strapdown accelerometer in there to detect the initial movement. The Vbox is very good about knowing when you start moving. I know the phones have them because Harry's Lap Timer references them. I would think that is how the Vbox detects the initial movement. However, one of the areas where strapdown systems suffer, is continuous integration errors that accumulate. I don't know what the dynamic range of these accelerometers is either and that would matter as well.
I do appreciate your tools and I used perfdb.com and got the same results so I will try perfdb.org now to see if that helps.
ETA: Same results at .org and I had never used perfdb before so there were probably no cached results. All I knew about was vboxtools.com. I think the issue is my Vbox data and that isn't anything you can help with very much no matter how small you slice your sections. I didn't mean to say my credentials were superior, all I was trying to do was impress upon you that I wasn't making comments out of left field. I have done this kind of work and it's painstaking and frustrating to find and understand sources of error, clock jitter was an especially tricky one for me back in the 80s when I was working on the high dynamic range accelerometers that produced a digital output. I developed a sigma-delta codec around the accelerometer that produced the output but first we had to prove the technique with an electronic A-D converter that could do 20bit resolution at a time when 16bit was the standard. We used a frequency multiplier to run the sampling circuit based off a crystal oscillator and what we discovered was that we needed a base oscillator that had a very small clock jitter error since that was a fixed error that would show up in the multiplied frequency as a constant. For instance we had a 1mhz base clock that was multiplied by 16 to run the digital circuits. The jitter in that clock was say only .01% of 1mhz but that was 16 times larger in a 16mhz signal because it was a fixed error. A factor of 16 is basically 4 bits and so our error was as big as 4 bits at the higher clock rate. Finding a clock with a lower jitter was the key and that meant a lower base oscillation rate because that turned out to be what the jitter error was related to in crystal oscillators. So we just lowered the base frequency and increased he multiplier. Finding that error took several weeks and it was very frustrating because I didn't have it properly modeled in the simulations but it was showing up in he built circuits. All of the other parameters we messed with in the simulation would translate directly into the built circuit but this jitter error wouldn't show up until the data was put through the FIR decimation filter and that was why it was so frustrating because the raw bit stream showed the proper resolution but the decimated parallel output was 4 bits less resolution. I did solve the problem though it took some time. Engineering is a painstaking business and not for those in a hurry for results, like managers and marketing guys and often, customers.
Best of the Best
Registered User
Joined: Mar 2015
Posts: 506
From: Apalachin, New York
Rep Power: 40
What type of tires are you Porsche drag racers using?
Do you have dedicated pair for drag racing or are you using a street tire.
Thanks
David
Do you have dedicated pair for drag racing or are you using a street tire.
Thanks
David
Missed that I think.
The Ennis track runs NHRA events on a regular basis and SAR has been in business a long time but had just been reopened when I collected the 135mph traps. I didn't use my Performance Box the second time I went back but I will be this weekend.
I just bought it a year ago and it's the 10hz version. The CEP is the same on both the 20hz and 10hz versions and that is the primary error of concern. True, you can buy a box with higher accuracy that can be used to correct data on the lower accuracy boxes but I don't have one and don't plan to buy one. I think OBD data logging will probably be a more accurate measure anyway. It is the errors in the data that I am referring to. You can't produce better results than the quality of the data and most people with Vbox's bought them a while back and thus they are subject to the limitations which you point out. What I am trying to point out to you is that the errors are more likely in the GPS, Vbox and to an extent your own calculations than they are due to the track measurement equipment which is far more simple and direct.
Not sure I noticed any of these being flagged as the results I posted were all labelled valid. I am going to investigate all the files to see how often that happened and if it's related to the results with larger errors, that would make sense to me as a good reason for the divergence in track data and your results.
No, in fact those are what I am concerned with. I don't believe the track is the problem in either case. It's either the Vbox or some combination of the error in the data and the way your estimates are produced but not the fault of the track measures.
Well I suppose all I should need to do is clear the cookies but it seemed like it took a while to process the results after the upload was completed.
I am just trying to help here because I don't like the idea that people begin to invalidate timeslips because they don't like what's printed on them and that most certainly has happened here where the claims are that the track is wrong and the vbox is right. I simply pointed out the numerous sources of Vbox error as documented and compared it to the very simple setup and limited sources of error in the track trap speed measurement.
The Ennis track runs NHRA events on a regular basis and SAR has been in business a long time but had just been reopened when I collected the 135mph traps. I didn't use my Performance Box the second time I went back but I will be this weekend.
I just bought it a year ago and it's the 10hz version. The CEP is the same on both the 20hz and 10hz versions and that is the primary error of concern. True, you can buy a box with higher accuracy that can be used to correct data on the lower accuracy boxes but I don't have one and don't plan to buy one. I think OBD data logging will probably be a more accurate measure anyway. It is the errors in the data that I am referring to. You can't produce better results than the quality of the data and most people with Vbox's bought them a while back and thus they are subject to the limitations which you point out. What I am trying to point out to you is that the errors are more likely in the GPS, Vbox and to an extent your own calculations than they are due to the track measurement equipment which is far more simple and direct.
Not sure I noticed any of these being flagged as the results I posted were all labelled valid. I am going to investigate all the files to see how often that happened and if it's related to the results with larger errors, that would make sense to me as a good reason for the divergence in track data and your results.
No, in fact those are what I am concerned with. I don't believe the track is the problem in either case. It's either the Vbox or some combination of the error in the data and the way your estimates are produced but not the fault of the track measures.
Well I suppose all I should need to do is clear the cookies but it seemed like it took a while to process the results after the upload was completed.
I am just trying to help here because I don't like the idea that people begin to invalidate timeslips because they don't like what's printed on them and that most certainly has happened here where the claims are that the track is wrong and the vbox is right. I simply pointed out the numerous sources of Vbox error as documented and compared it to the very simple setup and limited sources of error in the track trap speed measurement.
Registered User
Joined: Aug 2014
Posts: 1,062
From: Austin, Tx
Rep Power: 124
Funny you should ask. I manage a software group to write the drivers for sensors such as accelerometer. A typical cell phone will use the Invensense or Bosch sensors. They have an absolute dynamic range of +/- 16G, and for typical cell phone/tablets, we program them to +/- 2G. I'm speaking off my head here, but I think this is right: older parts were 12-bit, and the new ones are either 14-bit or 16-bit. I'm a manager, don't have the specs memorized any longer. :-)
Thank you.
I'm not a EE but I deal with clock jitter and all that stuff. Are you saying you were sampling the accel at these high clock rates? Typically in the cell phones, we sample no higher than 200 Hz, even if the part is capable of 1k, 2k, or 4kh sampling. Do you think clock jitter affects these low sampling rates? I realize we're really off topic here, but I'm curious if jitter affects these low sampling rates.
Thank you.
I'm not a EE but I deal with clock jitter and all that stuff. Are you saying you were sampling the accel at these high clock rates? Typically in the cell phones, we sample no higher than 200 Hz, even if the part is capable of 1k, 2k, or 4kh sampling. Do you think clock jitter affects these low sampling rates? I realize we're really off topic here, but I'm curious if jitter affects these low sampling rates.
So we had a 1Mhz clock to drive the sampler but the FIR filter ran at 16Hmz so we used the frequency multiplier to generate that clock. However that FIR circuit would read the output of the 1mhz bit stream and the jitter error was a large chunk of the 16mhz signal and it was making errors about where it actually synced on he basic 1mhz bit width. So the FIR filter didn't read a 1 as a complete 1, it would read it as either more or less than a 1 when the clock jitter error showed up. I believe in a crystal oscillator it's a Gaussian distribution but don't remember for sure. Ultimately IIR, what we did was to use a 16 Mhz oscillator to drive the FIR filter and then divided it down by 16 to run the Sigma Delta oversampler. I think that other thing where we tried a lower frequency oscillator with lower jitter didn't work but it's been since 1988-89. We were validating we could do 20bits with a 1khz baseband using an electronic circuit and the FIR filter was initially implemented with a TMS32010 Signal Processing chip. Later we designed the final ASIC FIR but the micromachined acclerometer never really worked. However, we were able to do a 20 bit A-D before anyone else could.
I don't think clock jitter would be an issue for 200hz sampling and anyway, your timing is probably run off an interrupt from an external clock. You could be affected by interrupt latency inside the Android or IOS low level interrupt processing anyway. I am talking about a pure electronic circuit in the case of what we had developed.
Last edited by wrs; Nov 1, 2015 at 05:40 PM.