Vigil data, what's the red line?

[BlindBrick 0]

I had some work done on my Vigil and had them download the data while they were at it. I forgot however to ask what the red line charts. I'm talking about the the line's that's plotting something and not the horizontal line that inidcates the decision point.

Anyone have any ideas?

-Blind

"If you end up in an alligator's jaws, naked, you probably did something to deserve it."

[drudchen 0]

According to the legend in the top corner of the image you provided, you're plotting Altitude(height, green), Average Speed(yellow), Real Speed (red). It's the instantaneous speed at every point, and is not averaged out, so quite a bit of noise in the data.

[BlindBrick 0]

doh, never thought about the signal noise. I was thinking ti was real speed but the spikes from the noise led me to think I was wrong. thanks.

-Blind

"If you end up in an alligator's jaws, naked, you probably did something to deserve it."

[pchapman 262]

Interesting plot!
While I've seen Protrack and Neptune readouts, Vigil readouts are rarer.

What were you doing on the dive?

Looked like you were doing about 130 mph once up to terminal. (Without knowing how the device is calibrated for altitude and temperature.)

Then there's a dip to 95 and jump to 160, even in the smoothed data. Unless you were doing something interesting, I guess those are artifacts of body postion?

My Protrack, on the outside of my helmet, usually shows huge unrealistic spikes in speed when tracking away from an RW jump. Interesting to see, if my guess is right, that something similar is happening with an AAD buried in one's rig!

Also, the averaging / smoothing that is applied does create a lag of 2 to 2.5 seconds, very roughly, in the speed. I assume (but don't know) that the averaged speed is the same one the Vigil is using for its firing calculations.

Note that the averaging does not fix the very wide spikes of what I'm guessing are artifacts from changed body position.

The raw speed data suggests you went below Vigil firing speed (the red horizontal line I believe) at about 36 seconds. That raw speed data was very smooth in the seconds before and after. But the smoothed data that the Vigil is using, doesn't show you slowed down enough until about 39 seconds. At around 80 mph 3 seconds is worth 350 feet in altitude.

Which doesn't matter up above 2000 ft where you had your canopy open, but it can matter below 1000 ft near firing altitude.

Hmm, I wonder how that sort of lag is taken into account by the AAD.

Although the raw speed reading bounces around a lot (based on rate of change of pressure) at least the altitude reading (based on pressure) doesn't fluctuate as much. Both altitude and speed are of course needed for an AAD. (And I'm ignoring for the moment whatever Vigil says about it's own method of calculating time remaining to firing altitude.)

Perhaps altitude is fairly reliably measured, using pretty much raw pressure data (or with minor filtering), but it seems like its derivative, speed, needs more smoothing and even in smoothed form doesn't as closely resemble reality as desired. The lag could affect both the issue of low pulls (jumper slowed down before the firing altitude but device doesn't know that yet), and the issue of firing after a low cutaway but no reserve pull (jumper accelerated to firing speed but the device won't know that for a couple more seconds). At steadier freefall speeds, however, the lag won't be an issue. The body position artifact issue could however come into play.

I had often thought about the limitations of devices like altitude alerts ("don't trust all the numbers"), but not so much how similar issue affect lifesaving AAD's ("trust them"?). The assumption had been that a position within the parachute container would create better raw data than one on the back of the hand or outside a helmet, subject to much more varying wind blasts at different angles.

This is all good food for thought. I don't have the answers yet, and the AAD companies aren't telling us their secrets. I don't think I'm ready to design one yet...

[BlindBrick 0]

Quote

Interesting plot!
While I've seen Protrack and Neptune readouts, Vigil readouts are rarer.

What were you doing on the dive?

Wingsuit flight. I was trying for max horizontal speed and then right before I began my pull procedure, I transitioned to max slow fall position to kill horizontal speed. I then collapsed my wings and arched so that I hit belly terminal (typically about 167 for me, but my SuperMach has a lot of fabric flapping around when the wings are collapsed) before I pulled which tends to improve my openings with a wingsuit.

-Blind

"If you end up in an alligator's jaws, naked, you probably did something to deserve it."

[drudchen 0]

Quote

I assume (but don't know) that the averaged speed is the same one the Vigil is using for its firing calculations.

The raw speed data suggests you went below Vigil firing speed (the red horizontal line I believe) at about 36 seconds. That raw speed data was very smooth in the seconds before and after. But the smoothed data that the Vigil is using, doesn't show you slowed down enough until about 39 seconds. At around 80 mph 3 seconds is worth 350 feet in altitude.

It looks like it's not directly using the smoothed average values. Maybe an algorithm dependent on a blend of both real speed and avg values?
Look at the green line (altitude). Notice, at 0 seconds, there's a red dot. That seems to be the time instance when vigil's speed parameter got activated. Now, look further on the same line, and notice a yellow dot around 37s. Seems like this is the point where it thinks the firing speed parameters are not satisfied. Notice that it's where the red (real) speed drops below threshold, and not the yellow line...

edit: and if i take a ruler (use a side of another window), the yellow dot is not directly under where there red graph crosses the threshold.. so i think it's really an algorithm that's looking at both real and average speeds, and maybe altitude.. just thinking out loud

[BlindBrick 0]

Per Vigil USA, the red dot corresponds to freefall speed exceeding 78 mph while the yellow dot corresponds to the freefall speed dropping below 78 mph for more than 5/8's of a second. It's not mentioned rather that's real, average or smoothed air speed.

If I was a smaller jumper with a wingsuit, I bet there'd be multiple sets of dots.

-Blind

"If you end up in an alligator's jaws, naked, you probably did something to deserve it."

[pchapman 262]

ISSUE 1: LAG

Quote

just thinking out loud

Nice, I glossed over the yellow dot issue and missed that.

That apparent use of the raw speed data gets rid of the problem (that I had erroneously thought might exist) with using the yellow line averaged data that lags by 2-3 seconds.

I wonder if the averaged speed is really needed at all by the Vigil. Maybe it is just for making a pretty graph on the ground.

In which case, they could better have done the averaging by using raw data data from the seconds before and after the point being calculated, instead of just the seconds before it, to avoid that 2 or 3 seconds of lag. That's something one can do after the jump, but not in real time during the jump.


ISSUE 2: LARGE SPEED CHANGES = ARTIFACTS?

Since it turns out to be a wingsuit flight (by a big guy), with slow flight and then wings-collapsed flight at the end, that explains some of the large variation in the speeds shown at the end.

But if the Vigil is using the raw data after all (red trace not the yellow), then it is still seeing 50 to 220 mph, which seems more range than I'd expect. Thus the issue of artifacts from body position (or wingsuit wings) doesn't entirely go away.

If one thinks the extremes of 50 and 220 are too much, then from the graph it seems like one might be able to fool an AAD about speed for say 2 or 3 seconds, just like one can fool a Protrack or similar. It is good that (at least in this case) any extremes in speed are accentuated rather than diminished.

BUT all that is a weak conclusion based on just one jump, with a wingsuit which likely will have more than the usual effect on pressures over one's back.

(I'm not picking on Vigils, all this is just of interest in the general field of measuring skydivers' speeds and altitudes.)

Thanks for sharing the graph, Blindbrick.

[peek 20]

Peter, the graph sure looks familiar to me of course!

Who knows how much or little filtering they did for those plots. We assume they are filtered and unfiltered, but unfiltered pressure sensor data usually looks much more ragged, so perhaps they added a slight bit of filtering just to make the graph look reasonable.

Quote

The assumption had been that a position within the parachute container would create better raw data than one on the back of the hand or outside a helmet, subject to much more varying wind blasts at different angles.

It does, but as far as what I have heard, the AAD manufacturers wanted it between the main and reserve for protection, and just dealt with the pressure issues resulting from that.