A few jumpers equiped with FlySight 2 SMDs reported SSScore crashes. These are resolved in SSScore 2.1.8 and later versions – feel free to use it! The crashes were caused by a weird bug where the SMD has entries for MSL / AGL elevations of 38,000 ft or more. It took some sleuthing to realize that the problem isn’t unique to FlySight 2, and that it’s caused by a combination of too short warmups prior to boarding and too much metal around the speed skydiver during the climb to altitude. The SMD corrects itself when the speed skydiver is near the door and can sync with the GPS satellites. The track CSV file, though, is often corrupted to a point where FlySightViewer and other tools can’t process it. Prior to the latest release, SSScore would crash when it found speed skydive track files for “stratospheric jumps.” This document details what changed in this release, and how SSScore helps speed skydivers with training.
What’s the issue?
I understood something was wrong when this error screen made its way to me:
This was a weird new condition not contemplated in the unit tests or found so far in any of the test files. The bug report included two “bad” track files, both of which listed interesting data at exit or near exit and in the first few seconds of the speed skydive:
There were several rows showing stratospheric altitudes. Further analysis of the track file revealed that only a few seconds of data show this problem, and the rest of the file, including the actual exit, are fine for scoring in training. None of these stratospheric elevation data rows occurred later than 4 seconds into the jump. The rest of the speed data is fine, and can be scored without issues and without breaking any ISC / FAI / USPA rules.
Solving the issue
Given the nature of the error, the solution is straight forward and involves an important change to how SSScore and SSScoring deal with speed files. Prior to this change, the UI and the API could process files from any exit as long as the time series was consistent. Version 2.1.8 imposes an important restriction: it only scores data rows where the elevation AGL (adjusted to DZ elevation) is between 15,100 and 10,999 feet. Any data rows with elevation AGL > 15,100 ft are discarded, and the rest of the speed file is scored using the usual methods, compliant with ISC / ISSA / FAI / USPA rules.
The implementation is straight forward:
data = data[data.altitudeAGL <= MAX_VALID_ELEVATION]
Where:
- data := the full dataset converted to SSScoring format and adjusted for DZ elevation
- MAX_VALID_ELEVATION := 4,602.48 m / 15,100 ft.
After this change it’s possible to take the same file that caused the crash, scrub the stratospheric elevation data off, and generate the score, maps, plots, and summaries as usual. The new implementation works in the single and multiple files analysis views.
Conclusion
Speed Skydiving scoring has a lot of nuances when processing data from the real world. There may be situations where a bad jump is caused by the GPS glitches. SSScore helps jumpers with training by eliminating bad data from an otherwise legit track file and jump, and focus on technique, flight, peace of mind, and going fast rather than worrying track file glitches.
The next post will be more about the art and science of speed skydiving, and less about the technical aspects of the SSScoring tools. Until then, blue skies and #gofast!