Flysight problems, anyone know why?

[Hellis 0]

A friend mailed me some Flysight data and by some reason the freefall part is missing.
It was BASE jumps so nothing is blocking the sky and it should be easier to get a good fix.

I find it very odd as the device had 9 sattelites in range on one of the jumps and 8 on the other.
I have don't have the settings file yet, but I will mail him and ask for it.
So either he uploads it here or I will when I get it.

Is there perhaps some setting that is better suited for BASE?
The following zip contains three of the jumps in excel format (I can upload raw data too if needed), two of the jumps there is no freefall data at all, and one there is just a ~5 sec lag.

http://www.hellis.me/BASE.zip

[Hellis 0]

Config file:

Quote

; GPS settings



Model: 6 ; Dynamic model

; 0 = Portable

; 2 = Stationary

; 3 = Pedestrian

; 4 = Automotive

; 5 = Sea

; 6 = Airborne with < 1 G acceleration

; 7 = Airborne with < 2 G acceleration

; 8 = Airborne with < 4 G acceleration

Rate: 200 ; Measurement rate (ms)



; Tone settings



Mode: 2 ; Measurement mode

; 0 = Horizontal speed

; 1 = Vertical speed

; 2 = Glide ratio

; 3 = Inverse glide ratio

; 4 = Total speed

Max: 300 ; Maximum value

; cm/s in Mode 0 and 1

; ratio * 100 in Mode 2 and 3

Threshold: 1000 ; Threshold for tone (mode 2 and 3)

; cm/s vertical in Mode 2

; cm/s horizontal in Mode 3

Volume: 8 ; 0 (min) to 8 (max)



; Log settings



Speed_Acc: 150 ; Speed accuracy threshold (cm/s)

Speed_Acc? Does that mean all data that is less accurate than 1.5 m/s should be omited?
Should that be set higher? Or can it be deleted completly?

[crwper 7]

Quote

Speed_Acc? Does that mean all data that is less accurate than 1.5 m/s should be omited?
Should that be set higher? Or can it be deleted completly?

The "Speed_Acc" threshold prevents the FlySight from logging points when the speed accuracy drops below a certain level. This was added to prevent spurious points--e.g., points recorded while still inside the plane--from interfering with post-jump analysis, but it does have the downside that offending points are not logged at all.

In the most recent firmware, this threshold has been eliminated, and the filtering is instead done in software (e.g., when Paralog imports the file). To disable the threshold, you can set it some large value--say, "9999" or so. This should cause the FlySight to log every data point, even if the speed accuracy is quite high.

BASE jumping is actually a slightly more difficult environment for GPS. What can happen is that the unit will get a fix at the exit point using, say, 8 or 9 satellites. Immediately after exit, half the satellites in view disappear because of the cliff. The receiver can suddenly be stuck without enough satellites to get a position fix, and at the same time in very dynamic conditions, in which it is difficult to reacquire the fix.

That said, I've had really good results on BASE jumps myself, and have only ever heard of consistent issues for jumps in Lauterbrunnen, where most of the sky suddenly disappears when you drop off the wall.

One factor which can play a big role in these cases is the "warm-up" time of 15 minutes at the start of the day and 1 minute before the jump. This time needs to be measured from the time the light starts blinking, and should not be shortened--i.e., you're better off to leave it on for 20 minutes after the light starts blinking, just to make sure the full 15 minutes has elapsed.

Does this help?

Michael

Edit: Looking at the files you uploaded, it does indeed appear that the data points were chopped by the speed accuracy threshold. If you bump the threshold up to "9999" for future jumps, the problems should disappear completely.

[Hellis 0]

Thank you!
Will try that!

So when the Speed_Acc is higher is that due to weak signal (not enough satelites) or is it because the Flysight does not predict you jumping?
It seems the problem occurs as you jump but then it "catches up" on you again, I see that pattern on all jumps.
Maybe you should teach the Flysight the skydivers handshake and it will be ready for the jump

[crwper 7]

An increase in speed error is sometimes due to a sudden loss of satellites, in which case there is no easy way around the problem other than the usual warm-up procedures.

It can also be caused by flight parameters that push the bounds of the selected model. For example, if you've selected the "Airborne with < 1 G acceleration" model, and find yourself exceeding 1 G (common, for example, with swooping), then you'll see the speed error increase as the u-blox receiver tries to reconcile the two. In this example, you could improve the speed accuracy by stepping up to the "Airborne with < 2 G acceleration" model.

So, really, both of the causes you mention are a possibility.

Michael

[kallend 1,625]

Quote

An increase in speed error is sometimes due to a sudden loss of satellites, in which case there is no easy way around the problem other than the usual warm-up procedures.

It can also be caused by flight parameters that push the bounds of the selected model. For example, if you've selected the "Airborne with < 1 G acceleration" model, and find yourself exceeding 1 G (common, for example, with swooping), then you'll see the speed error increase as the u-blox receiver tries to reconcile the two. In this example, you could improve the speed accuracy by stepping up to the "Airborne with < 2 G acceleration" model.

So, really, both of the causes you mention are a possibility.

Michael

By "model", would this be the parameters of, say, a Kalman filter?

...

The only sure way to survive a canopy collision is not to have one.