Methodology
How SkyLara Canopy Intelligence turns a FlySight recording into canopy analysis — what is measured, what is calculated, how sure we are, and what we deliberately never do. Engine versions: turn turn270-v3 · data quality dq-v3 · metrics ins-m2 · pattern pat-v2 · updated 2026-09-26.
1. What FlySight measures
FlySight is a GNSS (satellite navigation: GPS, Galileo and others) logger. Several times a second (typically 5 Hz) each record contains:
- Time (UTC) of the fix.
- Position — latitude and longitude.
- Altitude above mean sea level (hMSL, metres, relative to the WGS-84 reference).
- Velocity components — north, east and down (velN, velE, velD, m/s), from the Doppler shift of the satellite signals.
- Accuracy estimates — horizontal, vertical and speed accuracy (hAcc, vAcc, sAcc) reported by the receiver.
- Satellites used and fix type, where the file contains them.
FlySight 2 can also record SENSOR.CSV (barometer, humidity, temperature, IMU); where present we use it only for clearly labelled extras.
2. What FlySight does not measure
No GNSS logger can see what the pilot does with their body or controls. FlySight does not measure:
- toggle or riser position, or a percentage of brakes;
- harness input or pressure;
- the pilot's intent, plan or decisions;
- other traffic;
- the actual wind at the canopy or at the landing area;
- aerodynamic lift, angle of attack or canopy trim directly.
When a page describes the braked/search phase it shows only what the speeds show (e.g. “ground speed fell 18%”). Anything about controls is a tag entered by a person and labelled as such.
3. What Canopy Intelligence derives
- AGL (height above ground) — hMSL minus the ground reference at touchdown (see section 7).
- Ground speed — √(velN² + velE²): speed over the ground, wind included.
- Vertical speed — velD. Convention: negative when descending in stored data; descent rates are shown as positive numbers.
- Heading — direction of travel over the ground (from velN/velE), lightly smoothed. It is the ground track, not where the canopy points.
- Turn rate — change of heading per second (°/s).
- Gates — heights where cumulative rotation reached 45/90/180/270°.
- Landing point, touchdown and stop — from the flight → landing transition and when movement ends.
- Final approach — from the last descending crossing of 1,500 ft to touchdown.
- Two descent figures for the final 1,500 ft, kept separate because they come from different signals: average GNSS vertical speed (time-weighted velD) and altitude-derived descent (altitude drop ÷ time). When they differ by 12% or more the jump's altitude check is marked Limited.
- Pattern, comparisons, consistency — computed only against your own jumps; never a ranking of speed, height or turn size.
4. Turn and recovery events (exact definitions)
| Turn start | Rotation rate reaches 15°/s; extended back over samples already rotating the same way at ≥8°/s. |
|---|---|
| Gate (45/90/180/270°) | Cumulative rotation in the turn direction reaches the value (interpolated). No tolerance: 89° never produces a 90° gate. The 270° gate is low confidence when the turn ends less than 15° past it. |
| Turn end | Rotation stays below 8°/s for 1.5 s — the heading has stopped turning. Slow rotation after the last gate keeps the turn open, so this can be lower than where the pilot felt they rolled out. |
| Peak descent (dive peak) | Maximum descent rate after the turn started. Recovery (plane-out) begins here; by the gSwoop convention the rollout phase starts here too. It can occur before the turn end. |
| Descent inflection | After the peak, where the descent rate is decreasing fastest. |
| Ground speed stable | Ground speed within ±10% for 1.5 s. |
| Stable final | After the turn end, heading rate within 8°/s for 1.5 s. |
| Recovery time | Turn end → stable final. Often 0 when the heading settles as the turn ends. |
| Peak descent → stable final | The whole plane-out; used for comparisons with your own baseline. |
| Touchdown | Flight → landing transition. |
5. Uncertainty and confidence
Every analysed jump gets three states per check — High confidence, Limited confidence or Unavailable — with the measured reason:
- GPS error: positions and heights carry receiver-reported accuracy; heading becomes unreliable below ~8 m/s ground speed.
- Sample gaps: a gap over 2 s lowers confidence; over 5 s in the final approach only the part after the gap is used.
- Smoothing and interpolation: heading is smoothed and gates are interpolated between samples, so a gate is located to within a fraction of a second.
- Inconsistent signals: GNSS altitude vs integrated vertical speed; implausible vertical-speed jumps; tracks dipping below ground.
- Detector confidence: sections with few samples, slow ground speed, heading spikes or very slow rotation are marked low.
Limited or unavailable values are excluded from your averages and baselines — never replaced with guesses. Missing gates are shown as “Not confidently detected” rather than invented, because a made-up gate height would look exactly like a real one.
Weather and canopy provenance are reported as context; they never lower the telemetry confidence.
6. Weather limitations
Wind is taken from stored records only: an airport METAR, a nearby weather-station observation or a weather model. We show source, time, distance and confidence, and head/tail and cross components against your landing heading. This is contextual — a station 10 km away, or a model grid cell, can differ from the wind at canopy altitude or on your landing area. Only a wind reading entered for the landing area (e.g. by a coach) is treated as on-site.
7. Height above ground (AGL) limitations
AGL = GNSS altitude minus a ground reference taken from the touchdown cluster of the same recording (cross-checked with a terrain model where available). GNSS vertical error is typically a few metres; terrain that slopes, landing on a different elevation than the turn, or a poor vertical fix all shift AGL. Heights are reported to the foot for readability, not because they are that precise.
8. Detector limitations
Phases — braked/search, turn, gates, peak descent, recovery, stable final — are inferred from speed and heading patterns by deterministic rules (above). Rules can mis-segment: a heading correction can extend a turn; low ground speed makes heading noisy; a surge caused by wind looks like a surge caused by input. Pilots and coaches can add phase tags; tags keep who made them (pilot / coach / system-observed) and never overwrite the system's own inference.
9. Why we never prescribe turn altitudes
A safe turn-initiation height depends on the canopy and its size, wing loading, the pilot's technique and currency, air density, wind and turbulence, traffic, drop-zone rules, the landing area and coaching. A recording of past jumps cannot determine a universal safe altitude — so the platform never suggests one, never says a turn was “safe”, and never rewards lower turns, higher speeds, longer dives or bigger rotations.
10. Personal baselines are not ideal lines
Comparisons use your own comparable jumps (same turn type, medium/high confidence). A median or “most repeatable” jump describes what you usually did — it is not an ideal, recommended or safe path.
11. How coach review fits
Data helps a coach see repeatability and context: where height went in each quarter of the turn, how the recovery developed, how steady the final was. The coach supplies judgment, technique and progression decisions. You choose what to share; links can be stopped at any time.
12. Manufacturer guidance
Canopy sizes, charts and flight descriptions come from the manufacturers' own documents, each with a source link and revision. They are kept separate from platform explanations. Wing loading = exit weight (lb) ÷ canopy area (ft²) — information only, not approval to fly a size.
13. Provenance labels
| Measured | Recorded by the GNSS device — FlySight or another supported source (time, position, altitude, velocity, accuracy). |
|---|---|
| Derived | Calculated from measured data by the rules on this page. |
| Inferred | A detector's interpretation (phases, events, a default canopy at upload). |
| User-entered / User confirmed | Entered or confirmed by the pilot. |
| Coach-entered | Added by a coach through a share link, with their name. |
| Manufacturer-published | From the manufacturer's document, with source. |
| Contextual estimate | Weather from a station or model, not measured on site. |
| Legacy assignment | A canopy set before provenance tracking existed — kept, but not treated as confirmed until you confirm it. |
14. Analytics versioning and reprocessing
Algorithms improve. Every stored result carries the version of the engine that produced it (currently turn turn270-v3, data quality dq-v3). When a version changes, affected jumps are recomputed from the original recording — results are never silently patched. Original uploads are kept, so any jump can be reprocessed; manual tags and corrections are stored separately from the system's inference so both remain traceable.
15. Data sources and import adapters
Every recording passes through a source adapter that converts it into one canonical track: timestamp, latitude, longitude, altitude above mean sea level, north/east/down velocity, horizontal/vertical/speed accuracy, satellite count, plus any heading the device itself reported. The source is detected from the file's content (its header and columns), never from its name, and is shown on the jump page, the dashboard and Data Quality. The original file is kept unchanged with its SHA-256 fingerprint so the jump can always be reprocessed.
| FlySight 2 | Imported. Full analysis; SENSOR.CSV adds barometric and IMU context where present. |
|---|---|
| Deep and Steep (Insight / Stratos) CSV | Imported. Verified against the official Deep and Steep sample file (end to end); real-device exports from individual pilots are not yet independently verified, so we do not claim compatibility with every Insight/Stratos recording. Same analytics as FlySight; no sensor file, so barometric/IMU context is unavailable. The device logs the climb at a low rate by design, which is noted rather than counted as a gap. |
| FlySight 1 | Imported. Original FlySight track files (HH-MM-SS.CSV in date folders). Verified end to end against real FlySight 1 recordings published under the MIT licence by an open-source project; we do not claim compatibility with every firmware version. Same analytics as FlySight 2; FlySight 1 records GNSS only (no barometer, IMU or magnetometer), so sensor context is unavailable. |
| Altitude-only logs (e.g. barometric altimeters) | Recognised, not analysed. Altitude alone cannot give a ground path, heading, ground speed or turn geometry, and we never fabricate them. |
| Anything else | Listed as unsupported with the reason, never guessed. |
Heading, turn rate, gates and every other derived metric are computed the same way for every source — from velocity and GNSS altitude — so results are comparable across devices. Each jump has a “Data source & capabilities” panel listing which fields were recorded and which analyses are available as a result.
16. Measurement mode
Pick any two moments, A and B, on the altitude profile, the map or the 3D view. Every click lands on the nearest recorded sample — nothing is interpolated. With snapping on, an end within 1.5 s of a detected event (turn start, 45/90/180/270° gate, turn end, peak descent, stable final, touchdown) or a pilot/coach tag moves onto it.
- Δ time, Δ altitude — between the two samples (GNSS altitude above the touchdown point).
- Horizontal / 3D distance — the straight line A→B (great-circle, then with height); distance flown sums the path between them.
- Heading change — heading comes from the GNSS velocity (north/east). Net change = B minus A; cumulative change adds every step, so a 270° turn reads 270°, not 90°. Below 1 m/s ground speed heading is undefined and skipped.
- Average speeds and turn rate — path ÷ time, height ÷ time, cumulative heading ÷ time. When the selection contains 60° or more of rotation the turn block adds altitude consumed, duration and distance travelled.
A selection is only a selection. It is labelled “Custom selection”, or “From X to Y” when both ends sit on events or tags — it never becomes an official phase, and it never changes the detected events. Confidence drops when the selection contains recording gaps, poor horizontal accuracy or long stretches of undefined heading. Saved measurements (bookmarks) keep the two moments, the result and the engine version (meas-v1).
17. Assumption-of-risk acknowledgement
Before you first use advanced analysis or planning (the 270 Analysis, 3D, winds and the pattern planner) you are asked once to read a short notice and acknowledge it. It repeats, in plain words, what section 3 of the Terms already says — it adds no new legal term. We record the notice version, a SHA-256 fingerprint of the exact words you were shown, the Terms version in force, the time, and your IP address and browser, sealed so a later edit would be detectable. You are not asked again unless the notice changes materially. Coach review links and shared views only show a one-line reminder. The record is included in your data export and erased when you delete your account.
18. Pre-jump planner, wind and density altitude
What it draws. Only what you or your coach enter: the target, the landing heading, the turn direction, the maneuver type, and your own reference points with any altitude you type. The planner never fills in or suggests an altitude, and never says where to start a turn. Where you entered nothing, the drawing is labelled: a final line without a length is “direction only”, and the maneuver arc is a schematic that is not scaled to any canopy. 450° is available for education only.
Wind. Two sources are shown side by side and never merged: the nearest station observation (METAR — station, distance, observation time) and a model forecast (Open-Meteo — valid hour, lead time, fetch time, grid distance), plus forecast winds aloft by pressure level with approximate heights above your field. Neither is measured at your landing area. Head/tail and crosswind components are plain trigonometry against your landing heading.
Wind-context estimate. For each of your points that has an altitude you entered, it shows how far the selected wind layer moves the air while you descend from that altitude at a descent rate you enter (or the median measured on your own jumps: straight flight, 1,000–300 ft). One layer is applied to the whole descent, and gusts, shear and local effects are ignored, so confidence is low unless the wind is a recent nearby observation and the descent rate is your own. It is never an “expected landing path”.
Density altitude uses temperature, pressure reduced to field elevation, and humidity (virtual-temperature method); the inputs, source and confidence are shown. It is context for you and your coach — the planner makes no maneuver recommendation from it.
Versions. Every save creates a new, immutable version with the weather snapshot used, the drawing, the engine version (plan-v1) and a SHA-256 fingerprint. A version linked to a jump is marked as used; later edits create a new version and never change what you flew against.
19. Plan vs Actual
When you link a jump to a plan version, the recorded GNSS track is compared with that exact, immutable version. Four sections, always in this order:
- What matched — differences within descriptive tolerances (15 m, 10°). They describe closeness, not a standard.
- What changed — measured facts: touchdown vs target (along and across the landing heading), final heading, how far the final was flown from the planned final line, turn direction and rotation, turn start vs your turn-start reference (and altitude difference only if you entered one), and the closest pass to each of your points.
- Context — your traffic and briefing notes, the wind you planned with vs the weather stored for the jump, and the jump's telemetry confidence. Context is never a verdict.
- Questions for review — questions to take to your coach. Never instructions.
Forecast vs actual compares the forecast and observation saved with the plan against the weather stored for the jump. It is a weather comparison only: a forecast that differed from the day says nothing about how you flew. Results are stored with the engine version (pva-v1) and recomputed when the plan, the track or an engine version changes. A coach with a review link that allows plans can propose a new version; the version you flew is never changed.
20. Plan-vs-Actual progression and plan consistency
Across every jump you linked to a plan, each measure is a difference between your plan and your recorded flight: setup point → closest pass, turn reference → detected turn start, turn-start altitude (only when your plan contained one), final heading, planned gate points → gates observed with medium/high confidence, final-line displacement, touchdown → target, pattern-shape deviation, and the wind difference between planning and the jump.
Trends compare the spread (median absolute deviation around your own median) of the earlier and the recent half of your jumps — “spread narrowed / widened / similar”. There is no generic ideal and no target value. Plan consistency: component = 100 × max(0, 1 − spread ÷ reference spread) with published reference spreads (setup 50 m, heading 20°, gates 40 m, final line 20 m, target 30 m); overall = mean of the components that have at least 3 qualifying jumps (at least 2 components). Jumps with unavailable core telemetry do not participate. Nothing about speed, turn size, initiation height or dive length is scored, and a higher number is not a reason to change what you fly.
21. Personal Reference Track
Your own median path and middle-50% corridor from comparable jumps: same pilot, same maneuver class, same canopy when recorded, wing loading within ±0.15 lb/ft² when known, High core telemetry confidence and a turn that is not low confidence. Every candidate jump is listed as included or excluded with its reason. Each jump is placed relative to its own touchdown and rotated so its final heading points up, then sampled every 25 ft of height above the touchdown point, so jumps from different days and drop zones line up. It is a description of what you usually fly — never an ideal, correct or recommended line. At least 3 comparable jumps are required.
22. Side-by-side playback
Two jumps play together, synchronised by elapsed time, altitude, turn start, the 90/180/270° gates, peak descent, stable final or touchdown. An event can only be used as the anchor when it was detected in both jumps (gates only with medium/high confidence); otherwise the option is disabled with the reason. Videos follow the shared moment only when they were synced to touchdown in Video Studio.
23. Drop zones, landing areas and briefings
Drop zone pages keep four layers apart: official (provided or approved by the drop zone's authorised staff), public reference (taken from the drop zone's own website, with the URL and check date), community/context (not official), and system-derived aggregates, which are only shown when at least 5 pilots and 20 jumps are involved and never include tracks or coordinates. Landing areas and briefings are versioned; a change creates a new version, and plans keep a snapshot of the briefing version they imported. Briefings cannot contain maneuver-initiation altitudes, and the planner never imports one. A drop zone page is only offered to search engines once its staff have verified it.
24. Events, camps and coach proposals
An event links a drop zone, its briefing, coaches and pilots. A pilot's plans and jumps stay private; coaches see plan-vs-actual summaries for the event only after that pilot opts in, and never raw tracks. A coach with a review link that allows plans can propose a plan version with its purpose; it stays a proposal until the pilot accepts or declines it. An accepted version is kept exactly as proposed; any change the pilot makes becomes the pilot's own new version. Only the pilot's own or accepted versions can be linked to a jump.
25. Weather replay
During 3D playback you can show the planning forecast by altitude and the weather stored for the jump, with source, valid time and confidence. It is context only: no “corrected” flight path is drawn from it, and neither source was measured on your canopy.
26. Source capability engine and import diagnostics
What each jump can show is derived from the fields its recording actually contains (position, GNSS velocity, device heading, accuracy, satellites, barometric/IMU sensor data) — never from the device name the file claims. Features are available, limited (for example a low-confidence turn) or unavailable, and the page hides what the data cannot support. After every upload, “View import diagnostics” lists each file: detected source, adapter, samples, sample rate, start/end, fields present and missing, warnings, rejected rows, skipped files, and which analyses are unavailable and why.
27. Maps, satellite imagery and 3D terrain
Terrain is contextual elevation, not FlySight telemetry. The 3D ground comes from the public AWS Terrain Tiles dataset (Terrarium encoding; a blend of public elevation models such as SRTM, national lidar/DEMs and others, maintained by Mapzen/Linux Foundation contributors and hosted on the AWS Registry of Open Data). Tiles are fetched by canopy.skylara.co and cached on our server, so your browser does not contact a new third party for terrain. Map imagery comes from Esri. Neither was measured by your device.
Accuracy. The terrain model is not survey-grade. Its resolution at the zoom we use is roughly 10–30 m per cell (finer where national lidar exists), and its vertical error is typically several metres on open flat ground and can reach tens of metres on steep slopes, in forests and near buildings. It may not reflect recent construction, trees or water levels.
How the flight is placed. Flight heights are GPS heights above your detected touchdown point (see §7). In the 3D view the ribbon is drawn at touchdown ground + that height, so relief in the terrain model under the track does not lift or lower the flight. The page shows the difference between the GPS altitude at touchdown and the terrain model there, the terrain relief under the track, and any segment where the terrain model lies above the GPS track (a model/GPS disagreement, drawn at ground level rather than hidden). Terrain is drawn at true scale — no vertical exaggeration.
Checked against national lidar. At Voss, the terrain tiles agree with Kartverket's 1 m lidar terrain model (DTM1) within 2 m at five touchdown points (mean −0.7 m). On the same flat landing area the FlySight GPS altitude at touchdown varied by −11 m to +12 m between jumps — so the “GPS vs terrain” difference shown in the 3D view mostly reflects GPS altitude error, not a terrain or height-above-touchdown error. Other regions can be much less accurate (steep slopes, forest canopy, older global models).
What not to conclude. Clearance from trees, buildings or terrain cannot be judged from this view. Use it to understand the shape of your approach in its surroundings, not as a measurement of obstacle clearance.
Questions or a result that looks wrong? Tell us from your account's help page. See also the glossary and FAQ.