• Content

  • Joined

  • Last visited

  • Feedback


Everything posted by raymod2

  1. FLCPA #1 Skydive City Z-Hills February 24-25 FLCPA #2 Skydive Sebastian March 24-25 FLCPA #3 Skydive City Z-Hills April 21-22 FLCPA #4 West Tenn Skydiving May 19-20 FLCPA #5 Skydive Paraclete XP June 9-10 MWCPA #1 Skydive Midwest July 28 NECPL. Old school pond swoop comp. August 11th. Skydive Cross Keys Pink Open 16-19 August Klatovy MWCPA #2 Skydive Midwest August 25 French Nationals September 7-9 Orleans - France FLCPA #6 Skydive Sebastian September 22-23 USPA Canopy Piloting Nationals 2018 - Registration and Practice, September 24 - Competition, September 25 - 28 PD Tveir 2018 Sebastian Sept 28-30 MWCPA #3 Skydive Midwest October 6
  2. We are up to version 2.18 now. Recent changes include the following: 1) Fix a crash that can occur when closing swoop files. 2) Fix a crash that can occur with corrupt CSV files. 3) HiDPI is supported on Windows (in addition to OS X and Linux). 4) Single instance mode: prevent multiple gSwoop windows. 5) Fix problem with window size not remembered correctly. 6) Improvements to end of rollout detection (described below). 7) Other miscellaneous improvements/fixes. In previous posts I described how rollout detection works by finding the point 1 meter above level flight. The idea is that you can score the entry gate and subsequently sink another meter without impacting the surface. Occasionally this algorithm doesn't work well because GPS inaccuracies make it appear that the pilot is sinking for a long period of time (and more than 1 meter) after finishing the rollout. With these GPS tracks it works better to look at the vertical speed instead. The idea is that you can fly through the entry gate with a vertical speed as high as 1.25 meters/sec (2.8 mph) and still avoid impacting the surface. With version 2.18 both algorithms will be used and the one that produces the shorter rollout time will be selected. This will improve the accuracy of the rollout time metric (and implicit gate location) even with less than perfect GPS data.
  3. Yes, please send me a few of your best runs (preferably with competition scores) and I will post it to the website. The same goes for anyone else willing to share. We can learn all learn from each other regardless of experience level.
  4. Windmiller - 450 Shull - 630 Raymond - 630 Price - 450 Tagle - 630
  5. The most powerful way to interpret GPS swoop data is to compare your swoops to those of other canopy pilots. In that spirit I want to start sharing data with the community. I have started by posting a few files on the gSwoop website that contain GPS data from the following pilots: Greg Windmiller Matt Shull Dan Raymond Justin Price Jonathan Tagle I hope to add others as long as pilots are willing to share their data. I will try to focus on competition runs to ensure wind conditions are under limits and scores can be verified. The files are compressed for easier sharing and they do not require a license key but you will need to download the latest version (v2.15) to parse them.
  6. There have been a few new releases and we are up to v2.14 now. The biggest changes are: 1) Support for HiDPI displays on OSX. Devices with Retina displays use a high screen resolution in a physically small display (HiDPI is an acronym for "high dots per inch"). This can make things like fonts and icons appear too small. To address this OS X uses more pixels to draw objects. For native OS applications this makes everything appear smooth and sharp. For third party apps that don't support HiDPI display modes, the OS uses "zooming" which magnifies each pixel into a 2x2 pixel grid. The result is that icons and fonts appear at the correct size but they are blocky and blurry. gSwoop now supports HiDPI display modes on OSX so it looks as clear and sharp as native apps. 2) The pond is drawn in overhead plots even when no swoop is open. This makes it easier to view gate files. Also the IPC accuracy course is drawn on distance/accuracy plots. 3) Linux support has been added. The website now has .deb and .rpm packages. These have been tested on Ubuntu 16.04 and Fedora 23. Both of these OSes have issues installing 3rd party packages from the GUI. If you have trouble installing from the GUI it is much more reliable to use the command line (using dpkg and rpm).
  7. A new version of gSwoop (v2.11) has been uploaded to the website. The changes are primarily improvements to implicit gate detection.
  8. Sure, there are other considerations when choosing a turn. A bigger turn gives you more time to adjust but also more time to get pushed out of position by strong uppers. I'll say that one advantage of going from a 450 to a 630 is that the turn initiation height is not nearly as important.
  9. Over the years there has been lots of debate over the optimal turn or how many degrees of rotation are needed to achieve maximum speed for a given wing. Competitive pro level swoopers fly anywhere from a 450 degree turn to an 810 degree turn. I've personally been using a 630 degree turn for about a year and a half. While analyzing my GPS data I have noticed that on most swoops I nearly reach my peak vertical speed after only 270 degrees of rotation. While training for Nationals yesterday I did an unplanned 270 degree turn and I was surprised to discover that this was my best run of the weekend. It's food for thought and I'm sharing my data as my contribution to the conversation. I was flying a Petra 67 with 206 lbs exit weight for a wing loading of 3.08. The elevation was 5000' MSL and the ground winds were 5-10mph (downwind). video: https://vimeo.com/159000246 plots: (attached) metrics: exited airplane: 4964 ft AGL initiated turn: 1374 ft AGL, 444 ft back, -527 ft offset max vertical speed: 440 ft AGL, 412 ft back, -18 ft offset (94.8 mph) started rollout: 357 ft AGL, 391 ft back, -27 ft offset (93.5 mph) finished rollout: 12 ft AGL, -8 ft back, -3 ft offset max total speed: 175 ft AGL, 293 ft back, -27 ft offset (102.0 mph) max horizontal speed: 34 ft AGL, 96 ft back, -7 ft offset (89.2 mph) degrees of rotation: 308 deg (right-hand) time to execute turn: 11.70 sec time during rollout: 3.92 sec time aloft during swoop: 7.26 sec entry gate speed: 84.1 mph distance to stop: 628 ft touchdown estimate: 605 ft (23.6 mph) speed carve time: ---- sec (---- mph)
  10. Davi, I have attached a PDF with plots from the swoop you posted. I have also pasted the metrics below. If you look at the "speed during dive" plot you can see the speed in all axes and the total speed (the sum of all axes) which is in purple. The purple line shows a steady increase in total speed despite a brief dip in vertical speed. You are still building power - you are just (temporarily) trading off some of that vertical speed for horizontal speed. You can get rid of that dip in vertical speed simply by reducing the time spent on double fronts and rolling into your turn earlier. I don't know if I would recommend that, however, because you are doing a small turn (270 degrees) and you need time to build power. Staying on double fronts gives you extra dive time. Just don't take it too far. If you see a dip in total speed then you are staying on double fronts for too long and losing power. exited airplane: 13353 ft AGL initiated turn: 533 ft AGL, -6 ft back, -248 ft offset max vertical speed: 170 ft AGL, 168 ft back, 36 ft offset (59.9 mph) started rollout: 170 ft AGL, 168 ft back, 36 ft offset (59.9 mph) finished rollout: 9 ft AGL, 0 ft back, 0 ft offset max total speed: 127 ft AGL, 160 ft back, 23 ft offset (63.0 mph) max horizontal speed: 25 ft AGL, 60 ft back, -2 ft offset (50.0 mph) degrees of rotation: 253 deg (right-hand) time to execute turn: 8.00 sec time during rollout: 3.04 sec time aloft during swoop: 6.16 sec entry gate speed: 45.6 mph distance to stop: 182 ft touchdown estimate: 182 ft (1.2 mph) speed carve time: ---- sec (---- mph)
  11. I don't tuck it anywhere. I just place the lanyard on top of the folded canopy and close the bag over it. I haven't noticed any line burns.
  12. I also stow my lanyard at the top of the deployment bag. I just coil it up and place it directly under the center locking stow when I close the bag. I haven't had any problems with line burn in over a thousand jumps like that.
  13. I was able to get above my cutaway main and watch it land while flying a PD 160 reserve loaded at 1.3. You have to fly in deep brakes, obviously. It was not a bag lock (the main was fully inflated when I cut it away).
  14. I just want to add that these descriptions of the corner are a simplification of a complex process. It's not just how high you start your turn or even how high you finish your turn that determines the safety and performance of your swoop. I've seen swoops where the jumper finished his turn higher than intended and still impacted the pond. Every canopy (and size and loading) is different but swoopers typically need to provide some input during the rollout. The type of input, amount of input, and timing of the input are all variables that need to be considered.
  15. I visualize "the corner" like this: Imagine a side view of your swoop. Draw a vertical line from your initiation point to the ground. Now draw a horizontal line from the previous point to where the swoop ends. This is an imaginary flight path that is not possible under a parachute because of the sharp 90 degree bend at ground level (the corner). Your actual flight path during a normal swoop will be a smooth curve that never gets very close to that corner. When you finish your turn too low or you delay the recovery (for example when you are too close to the gate and you don't want to miss it) then your flight path will bring you closer to that imaginary corner. You can only get so "deep" in the corner before an impact with the ground becomes inevitable.
  16. Occasionally gSwoop does not get the turn degrees correct because of one or more snaps in the turn. The GPS only records position and velocity, not orientation, so during a very steep dive it is problematic to determine your rotation. Usually gSwoop can infer the amount of rotation during a snap based on the start and end points but this is not foolproof. If you share your CSV file I will take a look to make sure this is what happened.
  17. Your GPS data looks very clean to me. I don't see any missing samples and the accuracy plots look pretty good. What you are seeing is normal. The "kink" (discontinuity) in the overhead plot occurs just under 600 feet AGL and coincides with a spike in your turn rate (see the turn rate plot). In other words, there is a "snap" in your turn and when you do that your flight path is nearly vertical (see the dive angle plot). As you fly straight at the ground you are not moving in the overhead plot but you are still rotating. As your dive angle decreases you start moving again in the overhead plot but since you rotated a little over 200 degrees during the snap your direction of flight has suddenly changed (hence the "kink").
  18. Do you mean that you are missing samples (ie. there are sporadic large gaps between samples)? If so, that is not caused by your configuration. It could be caused by turning on your FlySight too late (I recommend turning it on 1 minute before boarding the plane). It could also be caused by interference from a GoPro. Try moving the FlySight farther away from other devices.
  19. Here is the gate location for Klatovy, CZ.
  20. On the site it's written that Flysight is the only supported GPS receiver, and according to my knowledge the maximum frequency is 5 Hz. How are you using 10 Hz? The latest FlySights have a newer GPS chip that supports 10 Hz. I think it has been about a year since the newer version has been shipping.
  21. gSwoop approximates the entry gate location based on when you achieve level flight. This is more reliable than using your height because GPS error sometimes causes all your data points to have a vertical offset.
  22. There is no assumption made about gate height. Gate width is assumed to be 10 meters and that is reflected in how the overhead plots are drawn.
  23. Hi, Mikko. Did you read my previous post on the subject (post #22)? 1) The start of the rollout is the point where your vertical speed begins to monotonically decrease. "Monotonic" means that every GPS point during the rollout has a slower vertical speed than the previous point. 2) The end of the rollout is 1 meter above the point where level flight is achieved. The first GPS point during the rollout where the height is the same or higher than the previous point marks the transition to level flight. The algorithm in gSwoop seeks back through the rollout until it finds where the height was 1 meter above level flight. 3) The time aloft during swoop is how much time elapsed between the end of the rollout and the estimated touchdown. These three metrics are independent of the gate location. You can open and close the gate and you shouldn't see any change to them. Regarding 2G and 4G: I have seen similar results between these two settings. You will see slightly smoother plots using 2G. I have been using 4G in 10 Hz mode myself. If you are comparing your data to others it is probably more important that you both use the same settings since the setting might affect your peak speeds.