Errors in ProTrack speed vs. time calculations

[pchapman 262]

We know that a ProTrack can give erroneous results in some circumstances, because of the changing airflow it is exposed to when head mounted.

I've noticed a different type of error, where the speed data does not match the altitude data, if one integrates the speed across time to give distance.

I figured that ProTrack speed data (as viewed on a computer with JumpTrack) would be calculated from the ProTrack's internal time clock and the altitude it calculates from pressure data.

The error is confusing because it is a mismatch between different data that the ProTrack outputs.

I noticed the error on a jump where I was coming out of head down and slowing down before pulling. I looked at a 5.75 second block of data (with data shown for every 1/4 second), in which the altitude changed 1012 feet. The speed at the start was 189 mph (TAS) and 122 at the end.

It's easy to see something is wrong: If we know that a jumper takes about 5.7 seconds to fall 1000 feet, at 120 mph, then how could I have taken about that much time for that much distance, when I was much faster at the beginning and only reached that sort of speed by the very end of the time interval.
(Using SAS speeds doesn't change the results significantly.)

Doing a rough integration of speed across time gives an altitude loss of 1400 feet or so during those 5.75 seconds, instead of the about 1000 the ProTrack showed.

To make the distance work out right, my freefall speeds would have to be about 30% less (134 to 87 mph). My gut feel is that the reported speeds are indeed too high, but that doesn't explain why.

I can't understand why the internal discrepancy exists. Is there something in the way that speed and altitude are calculated, and raw data is filtered??

I did email the manufacturers recently but haven't yet heard back.

[LouDiamond 1]

Sometimes rapid changes in speed confuse the Protrack. Birdmen have known this for some time as it is not uncommon to confuse the protrack into thinking you've deployed on exit. It used to happen to the Neptune but they worked the bug out and actually have a Birdman mode now.

"It's just skydiving..additional drama is not required"
Some people dream about flying, I live my dream
SKYMONKEY PUBLISHING

[pchapman 262]

A couple people PM'd to ask for the original data so a spreadsheet is attached, with the JumpTrack data and my calculations.

Its one thing if the Protrack can't accurately measure reality (because of the limitations of using air pressures around one's body to calculate altitude); it's another thing if the results it outputs are inconsistent within themselves.

Let me know if I've made an error somewhere.

[Unparagoned 0]

Is it possible that the error is a conversion error? Are the results in km and m/s inconsistent?

[pchapman 262]

The source of the error has been explained to me by a jumper who PM'd me. (She can speak up if she wishes.)

As suspected, there turns out there is averaging applied to the speed that the Protrack outputs. If one calculates speed from the altitude output (which is every quarter second for the Protrack), the speed bounces up and down rapidly, while the Protrack's output shows a smoother speed.

How large are the fluctuations? In the data collected each quarter second, the speed calculated from the recorded altitude often varies by 10 to 20 mph between each data point.

A spreadsheet provided to me shows that the Protrack's speed output exactly matches that calculated by averaging the previous 6 seconds of speeds (the ones calculated for every quarter second of data). I have confirmed the same with my data.

Technically, "averaging the last 6 seconds of speed" is exactly the same as "calculating the speed based on the altitude change from 6 seconds ago to now". I'm guessing that it is the latter that Protrack does, as it is easier computationally. (The exact match assumes using a simple "distance = speed times time" calculation, not a trapezoidal Simpson's rule etc.)

The benefit of averaging is a smoother, more easily interpreted speed graph in JumpTrack, that removes some of the error created by rapidly fluctuating airflow around the instrument.

The disadvantage is that rapid changes in the skydivers actual speed will create errors in the output. By averaging the previous 6 seconds of speed data, there is a significant lag in the output speed, compared to the real speed.

That created the discrepancy or error asked about when this thread was started. On my jump, when slowing down rapidly from head down to flat, the speeds reported were too high. Very roughly, the speed data was "about 3 seconds old". That accounts for the output TAS values implying (through integration) a greater distance travelled (1425 ft) than the Protrack altitude records showed (1012 ft).

If one makes the same calculations, using the speed from 3 seconds before the moment being calculated, then the speeds imply a distance of 1122 ft, much closer to the 1012 ft the Protrack recorded.

The averaging used also explains one reason why Protrack output is not shown for some seconds after the calculated time of exit.

CHOICE OF AVERAGING

The averaging method used by the Protrack is very simple, but may be appropriate given the cost vs. technology tradeoffs that are necessary. One possible improvement would be to average the speed over 6 seconds, centered on the present time, i.e., 3 seconds into the past and 3 seconds into the future.

Such averaging would remove the "lag" in the speed, but would introduce some "anticipation". For example, if a jumper were bellyflying and then suddenly sped up in a stand, the speed record would show a slight rise prior to the time where the jumper went into a stand.

The challenge is to find a smoothing scheme that dampens out sudden pressure fluctuations, but does not damp out (to too great a degree) actual changes in the skydiver's speed.

I made charts showing different averaging schemes -- averaging over the past 6, 3, or 2 seconds, and averaging over 6, 3, or 2 seconds centered around the present time period. My personal preference was for one of the centered averages (to avoid lag), over 3 seconds. Using a 6 second time period just seems too long relative to the time scale of actions in a skydive.

As for more sophisticated data smoothing techniques, I won't touch that now. (E.g., Fourier transforms & frequency filtering, rejection of data that implies excessive accelerations, etc.)

Attached are three charts. Because of the size, I haven't attached my original Excel spreadsheet.
Two charts compare the Protrack's averaged output to the raw speed data calculated from its quarter-second data. The charts also show what the curves would look life if shorter timer periods were averaged, and centered rather than using only data from the past.

[Edited to add: One chart is for a jump labelled as head down, but actually included a mix of body positions. The other jump was a 16-way bellyfly formation. ]

The third chart shows an idealized jump with hypothetical data, to give a clearer visual impression of some of the effects of data averaging. (It uses simple linear or instantaneous changes in speed for the most part.) It's really a bit simplistic, and not all that necessary if you are familiar with the concept.


IMPLICATIONS FOR PROTRACK DATA ANALYSIS

Knowing that there is this averaging over the past 6 seconds significantly changes the way we must look at ProTrack data in JumpTrack.

If one really wants to interpret the data better, one needs to export the data from JumpTrack to a text file, and then import it into Excel, and write any averaging scheme one prefers.

Otherwise, one needs to be aware that all speeds output are a little "out of date".

Therefore when slowing down (e.g., head down to flat, or after pulling) the speeds shown for a particular time and altitude are too high. The opposite is true when speeding up (e.g., acceleration early in the jump).

It is unfortunate that the manufacturer's calculation method is not mentioned in the manual (at least the one I have, to the best of my reading ability).

[pchapman 262]

I am kind of talking to myself in this thread, but I know a few people interested in these kinds of messy details.

I received a PM from Klaus (vidiot) who describes his experiences with the Paralog software he developed: (and didn't mind having this posted)

Quote

After some research, I ended up with the 6 seconds average centered on the present time you described for Paralog. Although 6 seconds might seem too much, 3 seconds do not smooth the data sufficently.

As you said, more sophisticated data smoothing techniques, (Fourier transforms & frequency filtering, rejection of data that implies excessive accelerations, even Wavelets) do not really help.

[AndyMan 7]

Quote

I am kind of talking to myself in this thread, but I know a few people interested in these kinds of messy details.

I'm certainly very interested. Thanks for doing the legwork and posting it. I'd always assumed there was some sort of smoothing algorithms, but I'm surprised at how crude it is, as well as that "better" algorithm didn't produce better results.

_Am

__

You put the fun in "funnel" - craichead.