0
mccordia

US Performance Competition - Acro Invitational (November 2011)

Recommended Posts

Quote

I know you had Klaus from Paralog involved all the time. I recently tried to download a week's data from Lodi, Hollister and Elsinore into Paralog and had a lot of failures (about 50% or more) although I had clear audible feedback and green light on the FlySight during the jumps. When looking at the files with Explorer they showed reasonable size and table data but Paralog still would not accept them. Just saying, not wanting to blame the Flysight-Paralolg link.



You can always email me suspicious files - I might learn something from them...

There is a parameter in the FS settings to not log data points when the accuracy is below a certain threshold - even if the unit has afix and gives audible feedback - see one of the FS threads here.

Michael and I have agreed to do this filtering in the future in a post-processing step in Paralog, though.
My Logbook

Share this post


Link to post
Share on other sites
Quote

It brings up an interesting question though as to what advantage that the Flysight offers? Having not looked into them much since I don't own either unit, my only perception of the difference is that the Flysight can offer audible signals to provide performance feedback real time during a flight. I think it can even give directions to a waypoint, though that is being beta tested I hear. There might be more to it but is the data outputted to paralog the same?



Hi Scott,

I wrote the software that can give directions to a waypoint, however I have no commercial involvment with FlySight. Micheal made the unit's software freely available, I just added a couple of things to it.

I've used Flysight quite a bit, and have always found it to be very reliable. I was also part of a competition where it was used and the only problems were people forgetting to switch it on.

I have also used two other units over the years, a Delorme BlueLogger and Wintec 201.

The main advantages of Flysight (other than the tone indication) are:
1) The chipset used is one of the most recent, and best for our application. It can track lots of Sats, has fast aquire time, and is very sensitive.
2) The methods used by flysight to calculate various speeds are much more accurate than many other units as it's based on doppler shift rather than lat/lon change.
3) The GPS model is set to Avaition out of the box which works better with the kind of data we get, it can be canged easliy.
4) It's can log data at up to 5hz, without any hacks.
5) Accuracy data is also recorded in the logs, so Paralog can filter the data recorded to exclude suprious data.
6) It's small, easy to mount and easy to download data from without special drivers or software.
7) The units software is OpenSource, so people can add features to it specific to skydivers needs.

You can find other GPS's with a couple of the features above in them or with complicated ways to achieve some of them, but I'm not aware of any other GPS that offers all of the above for a similar cost. When you add the ability to give audible indications is makes it a no-brainer if you are looking for a GPS for skydiving.

There are lessons to be learned here for sure, and I'm sure the FlySight software and Paralog software will adapt to re-act better to such situations, but I doubt the result would have been better with any of the other common units.

Share this post


Link to post
Share on other sites
Quote

Quote

Here is more food for thought folks Provided by NAVCENT/US Coast Guard:.....

....China Lake, CA
(CHLK 11-13)
07 NOV 11 - 16 DEC 11 (Dates/Distance are Approximate)
100 NM RADIUS OF POSITION:
36 09 18N; 117 37 32W



This could very well be the reason and would fit my suspicion of jamming.

This could also explain why the units worked on side of the plane and not on the other. Was this maybe the side pointing to Crystal lake?

[Edit: From what Lurch describes (Signal was lost on the way up and re-aquired ont the way down): Is it possible the mountains were actually shielding the jamming signal?]



I was sitting opposite Lurch and as the plane flew it's base leg to the jumprun he would have been on the Northeast side of the plane, a little more towards Northwest on jumprun itself, but we were exiting almost immediately after the turn onto jumprun.

I also had jumps that only started recording at the bottom end of the competition window.

So I'd say it seems quite possible that it was that interference that was causing the issues, and as we got lower the mountains could have given us some shielding and allowed the units to function normally.

Share this post


Link to post
Share on other sites
Quote


On the comments that there might be better units out there I think I can speak for Michael when saying the FS has the most modern receiver available on the consumer market: a u-blox 6 module.

Klaus



+1

I purchased this unit mainly for its GPS module. On the rare occasions I have turned it on, it has worked very well. Much better than the last generation GPSes I own.


Share this post


Link to post
Share on other sites
Quote

Quote

Don't know where you can find out in advance.



Both documents mention this information is spread through NOTAMs, so the pilots shoudl know. The questions is how far in advance...



I asked one of our pilots to look through his NOTAMs, as this was mentioned by someone else at the competition. He wasn't able to find any notices.
Advance notice would be the only way to make this work. Still investigating this as best we can; we don't want to see it happen here again. We'll be using a similar system in April and at the next Cup comp August 31-Sept 3 2012.

Share this post


Link to post
Share on other sites
Hi All--

I'm a bit late to this thread, as I've been on holiday, but wanted to add what I can.

Unfortunately, I wasn't at the competition myself, so am gathering as much information as I can here and elsewhere to be as sure as I can about what happened. I appreciate all the reports I see here, as they will go a long way toward narrowing things down.

The terrain shouldn't have a noticeable effect in this case. The only reports I've received of terrain having any effect at all are from Lauterbrunnen, where most of the satellites disappear behind mountains very quickly at the start of a jump. Jumping with a FlySight myself, I've been pleasantly surprised at how well it handles half the sky disappearing on more typical walls--generally without even a single glitch in the data. I would be very surprised if even rugged terrain had any effect at all on a skydive.

The only other reports we've received of FlySights dropping data during jumps have been because of abbreviated startup procedures. The recommended procedure is as follows:

  1. At the start of the day, turn the FlySight on for at least 15 minutes. To be precise, the green light should be blinking for 15 minutes. Turn the unit off once this is done.

  2. Just before boarding the plane, the FlySight should be turned on for one minute, then turned off again.

  3. Turn the FlySight on during jump run. If you're using Paralog, you'll need to leave the FlySight turned on all the way to the ground, so it has an altitude reference there.


To expand on these instructions a bit: The initial 15 minutes it the time during which FlySight downloads rough orbital data from the satellites. This information is valid for about 2 weeks, and helps the FlySight get a faster lock in difficult conditions (for example, when falling from a plane). The one minute before boarding the plane allows the FlySight to download more precise orbital data for the visible satellites. This information is only valid for 4 hours or so, which is why you need to do this before each jump. Again, the information helps FlySight get a lock quickly.

We've had a handful of people report that their FlySight only started beeping late in the jump, or under canopy. In all of these cases, the issue was resolved by underscoring the above procedure. Basically, if the "warm-up" procedure is skipped or abbreviated, FlySight is going into the jump blind, and it takes much longer for it to figure out where it is.

Although the recommended procedure is to turn the FlySight off before boarding the aircraft, this is mainly to conserve battery. I have no reason to believe that leaving the FlySight on during the ride to altitude would cause any problems.

With regard to FlySight's hardware, Klaus has correctly indicated that it uses the u-blox 6 chipset--the latest from u-blox and a significant step up from the u-blox 5 chipset used in, e.g., the WBT-201. Of particular note, they've gone from 1 million correlators to 2 million. In real-world terms, this translates into improved performance in difficult conditions (e.g., sitting in the plane) and a shorter time to first fix--both very important characteristics in our sport. This is the main reason why the FlySight is able to get a fix in many situations where other units are not.

I hate to chalk the problems up to jamming--it sounds a bit too much like people who tell me they must have a "virus" when their internet browser slows down. However, in this case the evidence seems to be pointing in that direction. Over the next few weeks, I'll be gathering as much information as I can to determine what happened here. If you have anything you think might be helpful, please let me know.

Finally, of course, if you have any questions, I am always happy to answer them.

Michael

Share this post


Link to post
Share on other sites
Quote

Looks like this site should be checked before all future events - else we'll have to do an illegal night flock demo jump into the MZ to take out the jamming hardware (Lurch knows how!)

Does something similar exist for Europe?



LOL @ Lurch knows how.

Quote

I just wonder how he will carry in that concrete packing weight so he can do his ninja "repairs" to the jamming device.



LOL because I get this reference. Never, ever ask Lurch to fix any part of your camera gear.
www.WingsuitPhotos.com

Share this post


Link to post
Share on other sites
Quote

Quote

Quote

Here is more food for thought folks Provided by NAVCENT/US Coast Guard:

TEST PERIOD APPROVED BY DEPARTMENT OF DEFENSE JOINT CHIEFS OF STAFF.
TEST LOCATION
EXACT DATES AND TIMES OF TESTING, DURING APPROVED PERIOD, WILL BE DETERMINED BY TEST RANGE EVENT PLANNERS.
GPS NAVIGATION SIGNAL WILL BE UNRELIABLE
WITHIN A: xxx NM Radius of Position


China Lake, CA
(CHLK 11-13)
07 NOV 11 - 16 DEC 11 (Dates/Distance are Approximate)
100 NM RADIUS OF POSITION:
36 09 18N; 117 37 32W



After doing a Radius measurement from China Lake to Lake Elsinore... it is only 23 NM outside of the testing range. This is very possibly that this was the cause of all the signal conflicts over the weekend.



So far the most plausible explanation, although we were competing on the 5th of november.. Any way we can contact these guys and get them to confirm they were testing last weekend?




Everyone seems content with placing blame on there being interference/Jamming from China lake. However, as noted in bold above, the day of the event, there was no testing scheduled to happen.If there was by some chance activity on that day it makes all the data that was gathered by the flysights questionable at a minimum as they were logging when there shouldn't have been an accurate and or reliable GPS signal to receive. This would be akin to spoofing when it used to be implemented. That's also taking into account and accepting that even though the event was 23 Nm outside of the declared radius, that it somehow still affected the GPS signal.

Having read the accounts here in the thread from different people that were at the event, I still believe it was a series of things that were done/occurred, that have nothing to do with China Lake, that caused there to be no useable data for some of the participants jumps. Having not been there and not having all of the details, only what has been provided in this thread, leaves me with an idea of what the cause(s) might have been but it is purely speculative on my part at this point.


As for the scoring question(s). A zero for no data just like a camera failure could be considered a bit harsh since in this case, the camera/flysight was provided by the event. Hence my also comparing it to an aircraft that breaks during an event( no fault of the competitor). Both represent the extremes that this could be compared to given current rules for recognized disciplines. Since this was of no fault of the competitors and the equipment provided failed to log their jumps, the competitor should be given every chance to complete and score the round before the judges move to the next round......similar to how it is currently written in the USPA competition manual for other disciplines.
"It's just skydiving..additional drama is not required"
Some people dream about flying, I live my dream
SKYMONKEY PUBLISHING

Share this post


Link to post
Share on other sites
Quote



Having read the accounts here in the thread from different people that were at the event, I still believe it was a series of things that were done/occurred, that have nothing to do with China Lake, that caused there to be no useable data for some of the participants jumps. Having not been there and not having all of the details, only what has been provided in this thread, leaves me with an idea of what the cause(s) might have been but it is purely speculative on my part at this point.


.



then speak your speculative idea rather than hold us all in typical suspense.:S
I'd very much appreciate hearing how "something was done/occurred" that identically affected more than 30 units at random points regardless of what was done/occurred.
I'm sure everyone else would, too.

Share this post


Link to post
Share on other sites
Quote

Quote



Having read the accounts here in the thread from different people that were at the event, I still believe it was a series of things that were done/occurred, that have nothing to do with China Lake, that caused there to be no useable data for some of the participants jumps. Having not been there and not having all of the details, only what has been provided in this thread, leaves me with an idea of what the cause(s) might have been but it is purely speculative on my part at this point.


.



then speak your speculative idea rather than hold us all in typical suspense.:S
I'd very much appreciate hearing how "something was done/occurred" that identically affected more than 30 units at random points regardless of what was done/occurred.
I'm sure everyone else would, too.


Instead of wasting time running down rabbit holes based on incomplete details of how the event was run, how about you explain exactly how things were run and how they transpired? After we all have a better understanding of your procedures from the time the competitor was handed a GPS receiver until he/she landed and then post processing took place, it will be less speculative as to what the causes might have been.

Another question that needs to be asked is how did X amount of units successfully log and download data in relation to the number that failed to. Were some of the ones that failed to log data also ones that had successfully logged data? This is the kind of information that also needs to be known to better identify the issue. Without this kind of info, I could post what I think might have caused it to happen but I think it would be a waste of everyones time and it would put you even more on the defensive having to address the causes I am assuming happened. So just lay it all out in details of what your procedures were, what went right, what went wrong, what changes if any were made and what if any data you got off of the receivers in post and we can go from there based on your and the competitors accounts.


James: While that does fall within the radius and the window is very big (several months) it is a possibility but if you look in the circumference of that radius during that time are there any other reports of poor/no GPS? It is far from a definitive means to ascertain but with a footprint that size and distance there would also be more reports from others of a disruption to help confirm/deny a disruption.
"It's just skydiving..additional drama is not required"
Some people dream about flying, I live my dream
SKYMONKEY PUBLISHING

Share this post


Link to post
Share on other sites
Quote

Instead of wasting time running down rabbit holes based on incomplete details of how the event was run, how about you explain exactly how things were run and how they transpired?



So why give the illusion you know what 'might have' happened, when you have no actual details or input to offer on what may have caused the issues?

The people with the experience and knowledge to deal with this equipment and situation have all been involved from the start (even during the event). In terms of GPS use (switching them on, location on jumper etc) this event was 100% identical to A LOT of other events held in EU, where none of the issues happened. These where the same units used in Italy, Gransee, Hungary,Holland etc etc. Operated in the same way.

The information you seem to miss is all in the thread above. The units had been switched on in the morning to aquire signal. Had been switched on in the plane a couple of 1000 ft before jumprun, as well as switched on on the ground before boarding. With similar results. Regardless of where the units had been switched on.

Quote

I think it would be a waste of everyones time and it would put you even more on the defensive having to address the causes I am assuming happened.



So in typical Campos fashion, you rather type 10 long posts on the reason why you DON'T mention any actual information, instead of a simple one that names a few reasons:ph34r:

Queue next response with explanation for not explaining?B|:P
JC
FlyLikeBrick
I'm an Athlete?

Share this post


Link to post
Share on other sites

The answer to your question can be seen in a video, if I can just find the time to go through my archives.
Or, look in my new book. It's coming soon (honest):ph34r:

Seriously, the Flysight units were all on for longer than 15 minutes. Closer to 30. Three people monitoring them, kind of playing a game as to which would acquire first, next, etc.

Share this post


Link to post
Share on other sites
Just a thought since RAIM issues and jamming don't seem to be the problem:

Some older aircraft NAVCOMS (such as the NARCO12 series and some King radios) have local oscillators that emit radiation that interferes with GPS signals when the radio is tuned to certain frequencies. It could have been an issue related to the jump plane's avionics preventing a lock while in the plane. Different brands of aircraft radios do this on different frequencies.
...

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

Share this post


Link to post
Share on other sites
Quote


Time....is for skinny lil' guys in big suits; no talent required. They can be a leaf that goes nowhere.



That is a clear prejudice on your part that has no basis in fact since it is so easily addressed with a miniscule amount of thought.
...

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

Share this post


Link to post
Share on other sites

Wow, I offer to help and ask for a little claification of what transpired and that's the response you give me.:S I don't have time to play games on the internet, if you want an explanation give me a call, you have my phone number.

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

Share this post


Link to post
Share on other sites
Guys... Please... No pissing contests... Let's try and keep this constructive... It's really quite embarrasing to be part of a community where the same set of people are always screwing up a perfectly fine thread...

From my perspective I can't say what happened with the devices. What I witnessed however, is that out of 34 units that where available there were only few jumps that actually got any data. We let people jump with the same unit for the first three jumps, after which they were turned in, data downloaded for judging. At this point we started seeing that virtually every unit had one or two jumps missing or corrupted. From that moment we had people randomly swap units, jump with two units etc etc to try and give them the best chance of getting valid data. Some people made 7-8 jumps that day and still only got 2-3 valid data sets.

How do you get 34 units with the same symptoms? I for one do not beleive that 34 units could all break at the same time, and I'm more inclined to beleive this was due to external factors.

That said, we jumped on the 5th, and the coastguard thing was not scheduled until the 7th. Its close but not conclusive proof. Also it was really ff'ing cold that day, which I though could have been a factor, but I been driving it around here in Vancouver and it's working fine so far.

Anyway, all in all it sucked balls, but it hardly seems worth it to derail this thread with off topic and pointless ranting towards each other. So while I'm no moderator here i would suggest that unless you have something of value to add, you stay out of this thread.

Oh and LouDiamond, I'd love to hear your ideas, but I actually do not have you phone number.. PM me if you wish to discuss, or post it here if you can/want.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

0