No saved flights.
Flights are saved automatically when loaded. Use the OpenSky Lookup or FlightAware Lookup tab to load a flight.
No flights match your search.
Import a KML or KMZ file containing a track or route.
Flight track data is provided by FlightAware AeroAPI, a flight tracking service with data back to 2011.
Steps:
FlightAware credentials are required to look up flights.
Set up credentials ↑Flight track data is provided by the OpenSky Network, a free community service.
Steps:
OpenSky credentials are required to look up flights.
Set up credentials ↑X-Rate-Limit-Remaining response header.Enter a US tail number (e.g. N123AB) or an ICAO 24-bit hex address (e.g. a05ed9). The other format will appear next to it.
Free Tier Comparison
| OpenSky Network | FlightAware AeroAPI | |
|---|---|---|
| Cost | Free credits granted daily | Users given $5/month of free credits |
| Historic data | 30 day window | 10 day window |
| Cost per lookup | Free (daily credit quota) | ~$0.017 per flight, after free credits are consumed |
| Overage charges | No (hard daily limit, resets at midnight UTC) | Yes (~$0.017 per flight, after monthly credit is consumed) |
| Search by call sign / flight number | Yes | Yes |
| Search by ICAO24 hex code | Yes | Yes |
| Search by tail / registration number | No | Yes |
| Military / unregistered aircraft | Yes (if broadcasting ADS-B) | No |
| ADS-B feeder bonus | No | A free Enterprise Account ($99.95/mo value) with access to 8 months of historic data |
| Credentials needed | Client ID + Client Secret (OAuth) | Single API key |
Paid / Institutional Access
| OpenSky Network | FlightAware AeroAPI | |
|---|---|---|
| Historic data | Full archive (~2013 to present) | Jan 2011 to present (15+ years) |
| How to access | Trino database (SQL queries) | Same REST API (Standard plan) |
| Eligibility | University, government, aviation authorities only | Anyone (paid subscription) |
| Cost | Free (must apply with institutional affiliation) | Standard plan (monthly subscription) |
| Academic / research | Apply at opensky-network.org with institutional email | May qualify for free access — contact FlightAware |
Writes this Fixed Mode setup — location, date/time, every control, filter and setting, and any imported orbital files — to a file you can re-open later or send to someone. Exporting while a saved session is open carries that session’s name and notes along with it.
All satellite groups are currently disabled, so no satellites will appear in the simulation.
Go to Settings → Satellite Groups to enable one or more groups.
No flight track has been loaded.
Use the Load Flight button in the Aircraft panel to load a flight track before using the playback controls.
When Combined brightness for satellite trains is turned on, every member of an unresolved formation (e.g. a freshly-launched Starlink train) is drawn at the train’s combined apparent magnitude instead of its individual brightness — matching what a naked-eye observer actually sees. The math below explains why that combined magnitude is much brighter than any one member: brightness adds linearly, while astronomical magnitudes are logarithmic.
Two light sources are unresolved when their angular separation is smaller than the observer’s resolving power, so the eye merges them into a single point or streak of light rather than seeing distinct dots.
Internally, CuriousPilot treats satellites as one cluster when their pairwise angular separation is within 0.1° (6 arcminutes) and the resulting group is cigar-shaped (length at least 5× the width). The threshold is intentionally looser than ideal naked-eye resolution to accommodate real-world viewing conditions (atmospheric turbulence, twilight glare, untrained observers) under which the practical resolving power is several arcminutes rather than one.
Suppose:
The flux from one satellite is proportional to:
F1 ∝ 10−0.4x
The total flux from N identical satellites is:
Ftot = N · F1
The combined magnitude is therefore:
mtot = −2.5 · log10(Ftot) + C
which gives:
mtot = x − 2.5 · log10(N)
This is the standard result for combining equal-brightness sources.
For N = 48:
2.5 · log10(48) ≈ 4.20
so:
mtot ≈ x − 4.20
| Individual satellite | Combined train (48 sats) |
|---|---|
| mag 5.0 | mag 0.8 |
| mag 4.0 | mag −0.2 |
| mag 3.0 | mag −1.2 |
| mag 2.0 | mag −2.2 |
Thus 48 unresolved magnitude-4 satellites would appear roughly as a magnitude −0.2 object.
More generally, if the satellites have individual magnitudes mi:
Ftot = ∑i=1..N 10−0.4 · mi
and the combined magnitude is:
mtot = −2.5 · log10( ∑i=1..N 10−0.4 · mi )
This is the formula used for a realistic Starlink train because illumination and orientation vary from satellite to satellite.
The calculation above assumes the satellites act as independent incoherent light sources and that their reported magnitudes already describe the brightness seen by the observer.
Specular reflections complicate things:
For example, if one satellite is magnitude −2 during a flare and the other 47 are magnitude 4, the combined magnitude is not simply (−2 + 4.2). Instead you sum the fluxes:
Ftot = 100.8 + 47 × 10−1.6 ≈ 6.31 + 1.18 ≈ 7.49
giving mtot ≈ −2.19. The flare contributes most of the light, and the total magnitude is only slightly brighter than −2.
If the train is visibly elongated (“cigar-shaped”) rather than point-like, the integrated magnitude is still:
mtot = x − 2.5 · log10(N)
but its light is spread over a larger angular area. The object may appear less conspicuous to the eye than a point source of the same integrated magnitude because the surface brightness is lower. Astronomers distinguish between:
For visual detection from aircraft or the ground, both quantities can matter.
If N identical satellites are unresolved and each has magnitude x, the train’s integrated magnitude is simply:
mtrain = x − 2.5 · log10(N)
— with the understanding that real Starlink trains often deviate from this because of differing phase angles, attitude variations, and occasional specular glints.
When Compute & show satellite flares is turned on, the simulator runs the specular-reflection geometry for every Starlink each tick and, when a chassis is aligned to reflect sunlight toward your observer location, boosts that satellite’s brightness and draws the flare. Starlink satellites can briefly become very bright this way — these flares are the most likely explanation for many recent UAP reports from pilots and ground observers near twilight.
When this option is turned off, the flare math is skipped entirely. A flaring Starlink will be shown at its dim baseline magnitude instead of its flare-boosted magnitude — so if its baseline is dimmer than the magnitude-slider cutoff, the satellite will not appear at all, even during a bright flare.
The ⚡ indicator flags Starlinks predicted to be flaring at the current simulated instant — the chassis is geometrically aligned to reflect sunlight toward your observer location. You’ll see ⚡ in three places:
You can also click the Predict flares button (below the checkbox) to sweep the loaded simulation timespan and get a sortable list of every predicted flare in your sky — with peak time, peak magnitude, elevation, and azimuth. Click any row to seek the simulation to ~5 seconds before that flare’s peak so you can watch it play out.
Predicted peak magnitudes come from the per-Starlink-generation log curves in Mallama & Cole (2024). The four generations (V1.0, VisorSat, V1.5, V2 Mini) are classified automatically from the SpaceX serial number; unclassifiable rows fall back to the V1.5 curve.
Important caveats:
Currently only Starlink is supported, because it is the only constellation with publicly characterized chassis geometry and a published per-version brightness model. OneWeb and BlueWalker / BlueBird may be added later.
When Curious Pilot hits an error, it can email a technical report so the problem can be fixed. Nothing is sent unless an error happens, and reports go only to the developer.
Sent:
Why this helps: most bugs only appear on certain browsers, graphics chips, or settings. Knowing which ones turns a problem that cannot be reproduced into one that can be found and fixed.
Never sent:
As with any web request, the delivery service can see your IP address. That is unavoidable for any internet connection.
Turning the checkbox off stops this completely.
When Show flare traces is turned on, any flaring satellite at or brighter than the chosen magnitude threshold draws its trace as a bright warm yellow-white wake instead of the normal gray. The trace appears even when the global “Show lines” option is turned off — that’s the point of the setting: to make flares easy to spot without having to enable lines for every satellite.
How it works:
The flare indicator and prediction model itself (the ⚡ icon, the Predict flares button) are described in the help dialog next to Compute & show satellite flares above. This setting controls only the trace color — it does not change which satellites are flagged as flaring.
The Satellites Visible list can display two related angles for Starlink satellites: Sun–Graze and LOS–Graze. They use the same convention — both are angles from the satellite's nadir-facing chassis panel surface — with Sun–Graze measuring the sun's ray and LOS–Graze measuring the line of sight to the observer. Both columns can be enabled together for cross-checking the sun-side and observer-side geometry against the panel.
Sun–Graze — the angle between the incoming sun ray and the satellite's chassis panel surface. Range: 0°–90°.
LOS–Graze — the angle between the satellite→observer line of sight and the same chassis panel surface. Range: 0°–90°.
←─── panel surface (horizontal) ───→
─────────────────────────●───────────────────────── ← Satellite (chassis panel —
╱│╲ faces Earth, normal DOWN)
╱ │ ╲
╱ │ ╲
╱ │ ╲
╱ │ ╲
╱ │ ╲
╱ ▼ ╲
╱ panel ╲
╱ normal ╲
╱ (toward Earth) ╲
╱ ╲
↙ ↘
☀ ● Observer
Sun
Both rays meet at the satellite impact point and lie on the
Earth-facing side of the panel (below the panel surface).
SUN-GRAZE = angle between the panel surface and the incoming
sun ray (the line going down-left to the Sun).
LOS-GRAZE = angle between the panel surface and the LOS to
the observer (the line going down-right to the
Observer).
At a specular reflection peak the panel normal bisects the
two rays, so SUN-GRAZE = LOS-GRAZE (mirror reflection — the
angle of incidence equals the angle of reflection, measured
from the surface).
If the satellite's chassis is exactly nadir-pointing (our model assumption) AND the geometry is at the peak of a specular reflection toward the observer, the two angles are simply equal — the law of reflection requires equal incidence and reflection angles measured from the panel surface:
Sun–Graze = LOS–Graze
At the peak the panel normal bisects the incoming sun ray and the outgoing LOS, putting both rays at the same angle from the surface (just on opposite sides of the normal). The closer your row's Sun–Graze and LOS–Graze values are to each other, the closer the geometry is to a specular reflection toward your observer location.
| Sun–Graze | LOS–Graze | Description |
|---|---|---|
| 0° | 0° | Both sun and observer near the satellite's horizon as seen from the panel — rays graze along the surface; no specular reflection geometry possible. |
| 15° | 15° | Steep grazing geometry on both sides — sun and observer both at low angles relative to the panel, on opposite sides of the panel normal. |
| 30° | 30° | Both rays at 30° from the surface = 60° from the panel normal — near the peak specular response of Starlink dielectric mirrors. |
| 45° | 45° | Sun and observer both at 45° from the panel surface; incoming and outgoing rays meet at a right angle in the panel's plane. |
| 60° | 60° | Both rays at 30° from the panel normal — near-normal incidence and near-normal reflection. |
| 90° | 90° | Sun directly below the satellite AND observer directly below the satellite — degenerate retroreflection along the panel normal; the rays coincide. |
Matching Sun–Graze and LOS–Graze values do not guarantee that the satellite is flaring. The two columns describe each ray's angle from the panel surface but discard where each ray sits azimuthally around the panel normal. Three conditions all have to be met for the panel to actually reflect sunlight toward the observer:
Conditions 2 and 3 depend on the azimuthal position of the sun and observer around the satellite — information the Sun–Graze and LOS–Graze columns don't carry. Rows where the two values match but the satellite azimuth is far from the sun azimuth (or vice versa) typically fail condition 2 or 3, and their displayed magnitude reflects only the diffuse contribution — which can be much fainter than a flare peak.
The unambiguous "all three conditions met" indicator is the ⚡ flare marker on a row. It fires when the actual 3D off-specular angle is below 5°, which checks conditions 1, 2, AND 3 together. Rows without the ⚡ marker are not in flaring geometry even when their Sun–Graze and LOS–Graze values agree.
In practice you'll often see Sun–Graze ≠ LOS–Graze even at a bright Starlink flare:
Satellites currently in Earth's umbra (shown with the ⊘ prefix and an ∞ magnitude) display “—” in both the Sun–Graze and LOS–Graze columns. No sunlight reaches a shadowed satellite, so even though the geometric angles still exist they have no physical meaning — there's nothing for the chassis to reflect. Both columns sort shadowed satellites to the bottom in ascending order, matching the displayed “—”.
Both columns are computed under the assumption that the satellite's chassis panel is pointed exactly at nadir (toward Earth). This is the operational attitude of in-service Starlinks once they've reached their final orbit (~550 km) and reconfigured to their on-station "shark-fin" configuration. Newly-deployed trains hold a different attitude during their multi-month orbit-raising phase; for those satellites the displayed values describe a counterfactual "if it were nadir-pointing" geometry rather than the actual physical incidence angle. See the project's references on Starlink deployment timing for context.
The Satellites Visible list can display two related angles for Starlink satellites: Sun–Graze and LOS–Graze. They use the same convention — both are angles from the satellite's nadir-facing chassis panel surface — with Sun–Graze measuring the sun's ray and LOS–Graze measuring the line of sight to the observer. Both columns can be enabled together for cross-checking the sun-side and observer-side geometry against the panel.
Sun–Graze — the angle between the incoming sun ray and the satellite's chassis panel surface. Range: 0°–90°.
LOS–Graze — the angle between the satellite→observer line of sight and the same chassis panel surface. Range: 0°–90°.
←─── panel surface (horizontal) ───→
─────────────────────────●───────────────────────── ← Satellite (chassis panel —
╱│╲ faces Earth, normal DOWN)
╱ │ ╲
╱ │ ╲
╱ │ ╲
╱ │ ╲
╱ │ ╲
╱ ▼ ╲
╱ panel ╲
╱ normal ╲
╱ (toward Earth) ╲
╱ ╲
↙ ↘
☀ ● Observer
Sun
Both rays meet at the satellite impact point and lie on the
Earth-facing side of the panel (below the panel surface).
SUN-GRAZE = angle between the panel surface and the incoming
sun ray (the line going down-left to the Sun).
LOS-GRAZE = angle between the panel surface and the LOS to
the observer (the line going down-right to the
Observer).
At a specular reflection peak the panel normal bisects the
two rays, so SUN-GRAZE = LOS-GRAZE (mirror reflection — the
angle of incidence equals the angle of reflection, measured
from the surface).
If the satellite's chassis is exactly nadir-pointing (our model assumption) AND the geometry is at the peak of a specular reflection toward the observer, the two angles are simply equal — the law of reflection requires equal incidence and reflection angles measured from the panel surface:
Sun–Graze = LOS–Graze
At the peak the panel normal bisects the incoming sun ray and the outgoing LOS, putting both rays at the same angle from the surface (just on opposite sides of the normal). The closer your row's Sun–Graze and LOS–Graze values are to each other, the closer the geometry is to a specular reflection toward your observer location.
| Sun–Graze | LOS–Graze | Description |
|---|---|---|
| 0° | 0° | Both sun and observer near the satellite's horizon as seen from the panel — rays graze along the surface; no specular reflection geometry possible. |
| 15° | 15° | Steep grazing geometry on both sides — sun and observer both at low angles relative to the panel, on opposite sides of the panel normal. |
| 30° | 30° | Both rays at 30° from the surface = 60° from the panel normal — near the peak specular response of Starlink dielectric mirrors. |
| 45° | 45° | Sun and observer both at 45° from the panel surface; incoming and outgoing rays meet at a right angle in the panel's plane. |
| 60° | 60° | Both rays at 30° from the panel normal — near-normal incidence and near-normal reflection. |
| 90° | 90° | Sun directly below the satellite AND observer directly below the satellite — degenerate retroreflection along the panel normal; the rays coincide. |
Matching Sun–Graze and LOS–Graze values do not guarantee that the satellite is flaring. The two columns describe each ray's angle from the panel surface but discard where each ray sits azimuthally around the panel normal. Three conditions all have to be met for the panel to actually reflect sunlight toward the observer:
Conditions 2 and 3 depend on the azimuthal position of the sun and observer around the satellite — information the Sun–Graze and LOS–Graze columns don't carry. Rows where the two values match but the satellite azimuth is far from the sun azimuth (or vice versa) typically fail condition 2 or 3, and their displayed magnitude reflects only the diffuse contribution — which can be much fainter than a flare peak.
The unambiguous "all three conditions met" indicator is the ⚡ flare marker on a row. It fires when the actual 3D off-specular angle is below 5°, which checks conditions 1, 2, AND 3 together. Rows without the ⚡ marker are not in flaring geometry even when their Sun–Graze and LOS–Graze values agree.
In practice you'll often see Sun–Graze ≠ LOS–Graze even at a bright Starlink flare:
Satellites currently in Earth's umbra (shown with the ⊘ prefix and an ∞ magnitude) display “—” in both the Sun–Graze and LOS–Graze columns. No sunlight reaches a shadowed satellite, so even though the geometric angles still exist they have no physical meaning — there's nothing for the chassis to reflect. Both columns sort shadowed satellites to the bottom in ascending order, matching the displayed “—”.
Both columns are computed under the assumption that the satellite's chassis panel is pointed exactly at nadir (toward Earth). This is the operational attitude of in-service Starlinks once they've reached their final orbit (~550 km) and reconfigured to their on-station "shark-fin" configuration. Newly-deployed trains hold a different attitude during their multi-month orbit-raising phase; for those satellites the displayed values describe a counterfactual "if it were nadir-pointing" geometry rather than the actual physical incidence angle. See the project's references on Starlink deployment timing for context.
When Show satellites in Earth’s shadow is turned on, satellites that are above the horizon but inside Earth’s umbra (the cone of complete shadow behind the planet) are rendered on the canvas instead of being hidden. They show as small dim slate-blue dots, marked with the ⊘ symbol throughout the UI, so the “this object is here but unobservable” signal is unmistakable.
What the rendering means:
Typical use: watching a freshly-launched Starlink train light up one satellite at a time as it emerges from shadow; confirming whether a specific satellite is geometrically present at a given instant; identifying which satellites are dark vs. lit when investigating a sighting that occurs near twilight.
This is a diagnostic affordance — it intentionally shows information that is not directly observable. If you want only what an observer could actually see, leave the checkbox off.
When Space-Track and Celestrak both list the same satellite, this picks which one to use. Switching re-applies instantly — no re-download.
Prefer Celestrak (default) — Celestrak wins. Most accurate for the supplemented constellations (Starlink, OneWeb, Kuiper, AST, Iridium): Celestrak serves operator SupGP data with sub-km accuracy, usually better than Space-Track’s.
Prefer newer epoch (either source) — uses whichever source’s data is freshest; a tie goes to Celestrak. A fresher epoch isn’t always more accurate.
Space-Track only — ignore Celestrak in the merge (it’s still downloaded).
Choose what to capture:
The Launch Date column shows when each object was actually launched into orbit (day resolution, from the catalog). It is not the same as the Epoch column, and the two answer different questions:
Why an epoch can fall after the simulation date. For a historical simulation, each satellite is propagated from its own nearest available element set. That nearest epoch may land a day or two after the requested date — and that is correct: SGP4 propagates accurately both forward and backward in time, so using the closest epoch (on either side) minimizes error. Seeing an epoch a little after your simulation date is the model picking the best-fitting data, not an object that doesn’t belong.
Why an object never appears before it launched. A freshly-launched object’s first element set has an epoch a day or two after launch, which could otherwise fall inside the data window for a date before the launch. To prevent a satellite from showing up in a simulation of a date when it did not yet exist, any object whose launch date is after the requested date is excluded from historical simulations. (Objects whose catalog launch date is still blank — common in the first days after launch — are kept, since there is nothing to compare against.)
So: an epoch after the simulation date is expected and fine; a launch date after the simulation date means the object is filtered out.
The Epoch is the UTC date and time at which a satellite’s orbital element set is defined to be valid — in effect, the timestamp of the orbit measurement the simulation propagates from. It tells you how fresh the orbital data is, not how old the object is.
Related columns: Element Age is this same epoch expressed as “days from the simulation moment” (a staleness / drift indicator); Launch Date is unrelated — it is when the object physically launched.
Element Age is how stale the orbital data is at the moment you’re simulating — the gap, in days, between the simulation time and the element set’s Epoch:
Element Age = simulation time − element-set Epoch
It is the Epoch expressed as a duration instead of an absolute timestamp, shown like 1.3d and sorted freshest-first by default.
Why it matters. SGP4 propagates each satellite from its own epoch; the further the simulation time is from that epoch, the more the predicted position can drift from reality — very roughly on the order of ~1–3 km per day for low-Earth-orbit objects. So a small Element Age (e.g. 0.4d) means near-current data; a large one (e.g. 8.2d) means the position is a looser estimate. Because the closest epoch can fall on either side of the requested date, the value is the size of that gap regardless of direction.
Related columns: Epoch is the absolute timestamp this is measured from; Launch Date is how old the object is, which is independent of data freshness (e.g. the ISS is decades old but usually has very fresh elements).
Object Type is the catalog’s classification of what the tracked object actually is. Space-Track reports one of four values:
Useful for separating working spacecraft from spent stages and fragments — e.g. when a bright, slowly-tumbling object in a photo is more likely a rocket body than a payload.
RCS Size is a coarse size bucket derived from the object’s radar cross-section — how strongly it reflects radar — as published by Space-Track. The three buckets are:
It is a useful rough proxy for physical size, but not a literal measurement: radar cross-section depends on shape, material, and the aspect angle the object presents, so a flat or edge-on object can read smaller than its true dimensions. The column sorts by physical size (SMALL → MEDIUM → LARGE), not alphabetically.
As a brightness hint, larger objects tend to be easier to see, but attitude and surface reflectivity (e.g. a Starlink’s flat panel flaring) often matter more than RCS bucket alone.
Type in the Filter box above the list. Matching ignores upper/lower case throughout.
Plain text matches anywhere in the satellite’s name:
starlink — every Starlinkiss — the Space Station (and anything else with “iss” in its name)Write field operator value. Numbers accept < <= > >= = !=; text accepts = (exact), != (not equal) and ~ (contains).
mag<3 — brighter than magnitude 3 (smaller number = brighter)el>30 — more than 30° above the horizoncountry=PRC — Chinese-operated objectsobjtype~rocket — anything whose type contains “rocket”launch>2024-01-01 — launched since the start of 2024&& means and, || means or. && binds tighter, so a && b || c reads as (a and b) or c. There are no parentheses.
starlink && mag<3 && el>20 — bright Starlinks, well up in the skyobjtype=payload && country=PRC — Chinese payloads onlyiss || mag<-1 — the Space Station, or anything flaring very brightlyPut - in front of any term to invert it:
-debris — everything except objects named “debris”alt<400 && -rcs=small — low orbit, excluding the small stuff-country=US && incl>80 — non-US, near-polar orbits| Field | Meaning | Example |
|---|---|---|
age | Age of the orbital data, days | age<2 |
alt | Orbital altitude, km | alt<400 |
az | Azimuth, degrees | az<90 |
bus | Starlink hardware type | bus=V2MD |
cospar | International designator | cospar~2024-129 |
country | Owner / operator | country=US |
dist | Distance to the satellite, km | dist<1000 |
el | Elevation above the horizon, degrees | el>45 |
epoch | Date the orbital data was measured | epoch>2026-08-01 |
group | Launch group | group=g10-31 |
incl | Orbital inclination, degrees | incl>80 |
launch | Launch date | launch=2024 |
mag | Brightness (smaller = brighter) | mag<2 |
magsrc | Where the brightness came from | magsrc=measured |
name | Satellite name | name~oneweb |
norad | Catalog number (Alpha-5 works too) | norad=25544 |
objtype | Payload, rocket body, debris, unknown | objtype=debris |
period | Orbital period, minutes | period>100 |
rcs | Size bucket: small / medium / large | rcs=large |
site | Launch site, code or name | site~baikonur |
var | Measured to vary in brightness | var=periodic |
A launch group can also be typed on its own, with no field name — g10-31 finds that Starlink group, and 2024-129 matches that COSPAR prefix.
magsrc tells you how much to trust a magnitude. Roughly a third of the catalog has never actually been observed, so its brightness is an informed estimate rather than a measurement.
magsrc=measured — observed by a telescope (MMT‑9, McCants, Stellarium)magsrc=derived — worked out from the object’s size, or from measured lookalikesmagsrc=assumed — hand-set, or guessed from the name-magsrc=measured — everything nobody has actually observedYou can also name one source exactly, using whatever the Magnitude source column displays: magsrc=mmt-9, magsrc=population, magsrc=estimated.
A satellite that has stopped controlling its attitude tumbles, and its brightness swings as different faces catch the Sun. The MMT‑9 survey has measured which objects do this — 3,284 of them.
var=periodic — the swing repeats on a timed cycle (1,469 objects)var=aperiodic — it varies, but no cycle could be timed (1,760)var=tumbling — flagged tumbling by McCants, with no photometry (55)var=variable — any of the threevar=none — nobody has measured this object varying. That is not the same as “it holds steady”: most of the catalog has simply never been watched.az, el, dist, mag) are ignored in that mode, because an object that isn’t being tracked right now has no position.az, el, dist, mag) are ignored for that purpose, for the same reason as above: which satellites to examine has to be decided before any of them is placed in the sky.= or ~, but it will match !=. So country!=US also returns objects whose country is unknown.alt=abc) matches nothing at all, rather than quietly falling back to a name search. An empty list usually means a malformed query.Simulation stopped at 3, due to the Fixed Mode Duration setting.
Change this setting in Settings & Info → Settings → Fixed Mode → Duration, if needed.
The date entered is not a real calendar date.
Common causes: a month that is one day short (April, June, September and November have 30 days), or February 29 in a year that is not a leap year.
The simulation has not been started. Please correct the date — if it were accepted, it would silently roll over to the following month and you would be shown a different day than the one you asked for.
Please enter a date between October 4, 1957 and December 31, 2200.
Earlier dates are not supported because orbital data sources do not contain records before the start of the space age. Later dates are rejected because satellite propagation diverges far past the orbital parameters' epoch.
Sky simulation works up to about 7 days ahead. Beyond that, satellite positions can't be predicted reliably.
Future positions are calculated by projecting today's latest orbital data forward, and that accuracy fades over time. Please pick a date within the next 7 days.
Curious Pilot is upgrading its local storage, but another open tab of this app is preventing the upgrade from completing.
Please close any other tabs running Curious Pilot, then reload this page.
Curious Pilot is a sky simulation tool built on real-world orbital and astronomical data. It recreates the sky from an observer’s exact location and time, so you can see what was — or will be — overhead: satellites, the Moon and planets, stars and constellations, all moving in accurate, time-synchronized motion. Whether you’re standing in your backyard, flying as an aircraft pilot or passenger, or planning a night at the telescope, it answers a simple question: what am I looking at?
The tool serves several kinds of observers:
Of nearly 31,000 cataloged satellites in Earth orbit, more than 26,000 are bright enough to potentially be seen by the naked eye under good viewing conditions, and the population is growing rapidly. Because they travel on many different orbital planes, an observer often sees several at once moving in different directions — easy to mistake for objects flying in circles or strange patterns.
Curious Pilot is driven by a rich set of real-world aeronautical, orbital, and astronomical data, all time-synchronized. Nothing is invented or approximated for effect — every position comes from published data run through standard orbital-mechanics and geometry calculations, so what you see reflects where objects actually were. It provides a dynamic, 3D visualization of satellites, celestial objects, and the Earth below. Use Fixed Mode to simulate the sky from any location on the ground — past or present — or Aircraft Mode to accurately replay a recorded flight and view the sky as the pilot or passengers saw it. Astronomy Mode is a third view, for telescope and camera work: name a target and a field of view, and Curious Pilot tracks, visualizes and reports exactly where and when every satellite crosses that field — whether you are planning an exposure or identifying the streak across one you already have.
Set your location, date and time and Curious Pilot does the rest — gathering and synchronizing satellite positions and astronomical data automatically. In Aircraft Mode, enter a flight and it also retrieves and aligns the aircraft’s recorded track. Press the Play button and the simulation begins.
Curious Pilot is free to use, runs in your browser, and requires no installation. It works on tablets (including iPad), laptops, and desktop computers.
The application integrates 19 independent data sources to accurately recreate and replay the sky. They are grouped below by what they contribute:
The OpenSky Network provides historical ADS-B flight track data. Given an aircraft’s ICAO24 hex code and a date, the app retrieves the recorded flight path including position, altitude, and heading.
FlightAware AeroAPI is available as a second flight track data source, with data back to 2011. It supports search by call sign, flight number, or tail number.
Aircraft flight track data can also be imported from .kml and .kmz files. These standard geospatial files are available from sources such as adsbexchange.com, which provides several years of historical data.
Space-Track.org, operated by the 18th Space Defense Squadron (US Space Force), is the primary source for satellite orbital parameters. It provides current data for tens of thousands of active satellites across all orbital altitudes, as well as a complete historical archive going back to 1957. These parameters are used with the SGP4 propagation algorithm to compute each satellite's position in real time. Both the classic 5-digit catalog numbers and the new Alpha-5 scheme are supported.
The historical archive is essential for accurately recreating past events—without historical data, satellite positions can only be estimated from current orbital parameters, which degrade in accuracy the further you go back in time. With Space-Track, the app can retrieve the exact orbital parameters that were valid on a specific historical date, ensuring satellites appear where they actually were at the time of a past sighting.
For today’s simulation date, the app auto-fetches five selected SupGP feeds from CelesTrak alongside Space-Track: operator-derived ephemerides for Starlink, OneWeb, Kuiper, AST SpaceMobile, and Iridium (typically more accurate than Space-Track’s standard catalog for those constellations, and often available within hours of a launch). All CelesTrak feeds are fetched in the CSV (OMM) format. Sources are stored separately and merged at parse time; you can choose which one wins per NORAD ID under Settings → Supplemental Orbital Data. CelesTrak also serves as a fallback when the Space-Track proxy is unreachable.
The Launch Lookup feature’s upcoming and past launch lists are provided by KeepTrack (CC BY-NC 4.0), which relays Launch Library 2 (CC BY 4.0) from The Space Devs.
Brightness is taken from real measurements wherever a measurement exists. Roughly two-thirds of the catalogue is covered by two observing programmes: the MMT‑9 (Mini-MegaTORTORA) robotic survey, operated by the Special Astrophysical Observatory of the Russian Academy of Sciences, and Mike McCants’ quicksat magnitude file. The Stellarium community satellite database is kept only as a last-resort backstop, because its values are largely McCants’ own without his convention correction. Objects nobody has observed are estimated from the measured brightness of genuinely similar objects, and debris from its radar-measured size—never from the object’s name. Those standard magnitudes are then combined with solar illumination geometry and observer distance to predict how bright each satellite appears from where you are. MMT‑9 also records which objects swing in brightness as they tumble, which the app reproduces on screen. See Settings → Satellite Brightness for the full method, each source’s conventions, and the model’s limits.
Star coordinates are from the HYG Database v4.1 by astronexus (David Nash) — a curated compilation of bright-star data drawn from Hipparcos, the Yale Bright Star Catalog, and Gliese. Constellation stick-figure topology is from the Stellarium-skycultures “western” set, covering all 88 IAU constellations.
The Astronomy Engine library computes precise positions of the Sun, Moon, and planets using VSOP87 and ELP/MPP02 analytical models.
The Moon is drawn with its real near-side surface, from a full-Moon render by NASA’s Scientific Visualization Studio built on Lunar Reconnaissance Orbiter topography and albedo data. The surface is held at its true orientation as the phase advances, so the familiar face stays put instead of turning with the lit limb.
NASA’s Black Marble imagery (VIIRS Day/Night Band) from the Global Imagery Browse Services (GIBS) provides the nighttime ground texture showing city lights as seen from above.
ESRI World Imagery satellite photography is used for the daytime ground plane, switching automatically based on solar illumination at the observer’s location.
The hills and mountains drawn on the horizon (Settings → Fixed Mode) come from AWS Terrain Tiles, a free public elevation dataset built from NASA’s SRTM, the USGS 3DEP national elevation program, and other public sources. The observer’s own ground elevation is looked up from OpenTopoData (SRTM).
Magnetic declination is computed from the World Magnetic Model 2025 (WMM2025), jointly developed by NOAA NCEI and the British Geological Survey. The model coefficients are evaluated locally so that toggling between True and Magnetic headings is instantaneous; the BGS web service is used as a refinement source when available.
The location-picker map uses three tile styles: a standard color style from OpenStreetMap, a dark style from Esri, and a terrain style from OpenTopoMap. Geocoding is provided by OpenStreetMap Nominatim.
The groups above describe what each source contributes. For the complete itemized list — every data source named individually with its license and attribution, plus the satellite-brightness catalogs and models and the software libraries — see the Licenses tab.
Selected references that informed the modeling and interpretation work in Curious Pilot:
Philip Giacalone is an aerospace engineer and software developer whose 40-year technical career has spanned spacecraft systems, autonomous drones, and Silicon Valley startups. He developed Curious Pilot as a free tool to aid investigations of pilot-reported UAP sightings. It combines real ADS-B flight data with published satellite orbital and astronomical data. He is also the developer of PCBTracer.com: a specialized web application useful for troubleshooting and reverse engineering electronics by tracing and documenting printed circuit board (PCB) details.
Number of digits shown after the decimal point in the “satellites visible” list. Magnitude is always shown to 1 decimal.
You can turn on up to 5 columns at once. When 5 are on, the remaining checkboxes dim until you turn one off. Name is always shown and doesn’t count toward the limit. Note: Az/El (or RA/Dec) is a single checkbox but two columns, so it counts as 2 of the 5. The other choices — Distance, Magnitude, Altitude, Inclination, Period, Epoch, Launch Date, Launch Site, Object Type, Bus Type, RCS Size, Country, Magnitude source, Launch Group, NORAD ID, COSPAR ID, and Element Age — each count as 1. The ? next to Launch Date explains how it differs from Epoch. Sun–Graze / LOS–Graze are separate Starlink diagnostics under Diagnostics below.
Click the ? for a complete guide to filtering the “satellites visible” list — every field you can filter on, the operators each one accepts, and worked examples running from a simple name match to a multi-part boolean query. The Filter box sits above the list itself; type part of a name to match it, or build a precise query from any column — brightness, altitude, country, launch date, and more — combined with and / or.
Shows catalog numbers of 100000 and above in their packed Alpha-5 form (e.g. 100001 → A0001) in both the “satellites visible” list and the satellite hover popup. Handy when you have an Alpha-5 ID from an import and want to spot it by eye. Searching is unaffected — norad=A0001 and norad=100001 both find the satellite whether this is on or off. Default off.
Choose which lines appear in the popup when hovering over a satellite. Groups and order mirror the Satellites Visible column picker — any column you can show in the list can also be shown here. Az/El and RA/Dec are independent, so you can show either pair, both, or neither. Magnitude source says where that satellite’s brightness came from — measured by a telescope (MMT‑9, McCants, Stellarium), derived from its size or from a median of measured lookalikes, or assumed (hand‑set, or guessed from the object’s name). Roughly a third of the catalog has never been measured, so this is how you tell a real brightness from a plausible one.
Each mode has its own preference. The T / M keyboard shortcuts toggle the currently active mode.
When a dense formation of satellites is visible (e.g. a freshly-launched Starlink train), each member is drawn at the train’s combined apparent magnitude instead of its individual brightness. This matches what naked-eye observers see — the train appears as one bright “cigar” of light rather than many dim dots. Has no effect on isolated satellites or on satellites separated widely enough to be resolved as distinct points.
Sets how large satellites are drawn in Enhanced mode, from full size down to one eighth of it. Each swatch is the true on-screen size of the brightest dot at that setting. Realistic mode is unaffected — it always draws satellites at their actual apparent magnitude.
How much of each satellite’s recent track the line shows, in minutes of simulated time. Every line keeps the same number of points, so a longer setting samples the track more coarsely rather than using more memory — at 10 minutes the spacing is 5 seconds, which on a near-straight orbital track is hard to see.
When more than this many satellites are visible at once, name labels are auto-suppressed (overlapping text becomes unreadable, and the per-label work slows the simulation clock).
Your own observing location. Fixed Mode and Astronomy Mode each start here the first time you use them, and then keep whatever location you move to — so changing where you stand in one mode never disturbs the other. Type the Name into the Observer Location box at any time to come straight back here; the plain word Home always works too. Home is stored only on this device: it is deliberately not included in a shared settings file, so opening someone else’s file runs their simulation at their coordinates and leaves your Home untouched.
Which format the Observation Dates/Times fields start in each time you enter Astronomy Mode. All three show the same instant to the millisecond — switching between them converts the values rather than reinterpreting them, so the observation never moves. Julian Date is the continuous day count astronomers use (2460904.51234567); UTC is the calendar clock; Local is the clock at the observing site, not in your browser’s timezone. A restored Session or Settings file keeps whichever format it was saved with, so this default applies to a fresh entry.
A satellite that has stopped controlling its attitude tumbles, and its
brightness swings as different faces catch the Sun. The MMT-9 survey has
measured this for 3,284 objects. Their dots vary at the measured rate and
depth. The timing is not predicted — nothing published says
where in its cycle an object is at a given instant, so read the rate, not
the moment. Add the Variability column, or filter with
var=periodic, to see which objects these are.
Hold the modifier key and hover over a star to see its name, magnitude, and constellation.
Messier and bright NGC/IC objects — galaxies, clusters, and nebulae — drawn as symbolic outline markers (not realistic images). Each object also carries a small crosshair marking its exact catalog position. Zoom in (Astronomy Mode) to see a large object’s true extent. Searching for one in the Celestial Search box always shows its marker, even with this off.
Shape marks the type — ellipse: galaxy, circle+cross: globular cluster, dashed circle: open cluster, circle+ticks: planetary nebula, dashed square: nebula. Color reinforces type: orange/gold/green/teal/blue in that same order.
Paints NASA Black Marble city lights at night (Esri World Imagery during the day) onto the ground around the observer. Visible when looking toward or below the horizon. Hidden automatically when Transparent Earth is on.
Draws the real terrain around your location as a silhouette against the sky, from public elevation data (AWS Terrain Tiles: NASA SRTM, USGS 3DEP). Reaches 150 km, and accounts for Earth’s curvature and atmospheric refraction, so distant peaks sit where they really appear. Objects behind a ridge are hidden from view. Two things to know: it is bare ground only — no trees or buildings, which in most backyards are what actually block the low sky; and it changes only what you see, so a satellite hidden behind a mountain is still counted and still listed. Fixed and Astronomy Modes only, and on by default. A thin grey line traces the ridgeline so the skyline stays readable against a dark sky, where the hills themselves are almost black. Turns semi-transparent along with the ground when Transparent Earth (G) is on, so you keep the shape of the skyline while seeing through it. Downloads a few megabytes of elevation data the first time you use a location.
The Sun and Moon are each about half a degree wide — a few pixels in a normal view, too small to show a phase, a crescent or the lunar surface. They are normally drawn larger than life so there is something to look at, by an amount that shrinks as you zoom in and reaches true size below about a 36° field. Turn this on to force true size at every zoom level. Worth knowing: magnifying the discs never moves them, but it does eat the gap between the Sun and the skyline, so a low Sun looks closer to the horizon than it really is. At the August 2026 eclipse over Majorca the Sun stood 5 of its own diameters above the hills, and in a normal wide view it is drawn about 2 diameters up. Turn this on when comparing a rendering against a photograph; leave it off for ordinary viewing.
The planets follow the same switch. Their real discs are tiny — Jupiter at its best is 50″, a fortieth of the Moon, a fifth of one pixel in a normal view — so they are normally drawn as legibility dots sized by how prominent each planet is. With this on, each planet is drawn at its true angular size, never smaller than a point of light (nothing can be drawn smaller than the eye or the sensor can resolve). Zoom in and the real disc takes over: Jupiter below about a 5° field, Mars below 2.5°, Saturn below 1.8°, each then growing with every further step of zoom and gaining a hard limb. Two limits worth knowing: Saturn’s rings are not drawn, so its disc is the globe alone and a photograph will look about twice as wide; and Venus and Mercury show no phase, so a crescent Venus is drawn as a full disc of the right size. This setting is on by default in Astronomy Mode and off elsewhere — until you tick it yourself, after which your choice applies in every mode.
How long the simulation runs in Fixed Mode before it stops automatically. Aircraft Mode uses the loaded flight's own duration.
Lifts objects near the horizon to match their apparent position — satellites, stars, planets, the Sun and Moon alike. ~29 arcmin at the horizon, ~1 arcmin at 45°. RA/Dec coordinates are always refraction-free, as on a star chart.
Renders satellites in Earth's umbra as small dim slate-blue dots instead of hiding them. Useful for watching a satellite train light up as it emerges from shadow. Magnitude slider still applies (very dim what-if sats are still hidden).
Appends a Sun-Graze column to the Satellites Visible list showing the angle between the sun's ray and the satellite's nadir-facing chassis panel. 0° = sun skimming along the panel surface (twilight Starlink-flare illumination geometry); 90° = sun directly below the satellite, lighting the panel at normal incidence. Computed under the nadir-pointing-panel model assumption. Starlink only — non-Starlink rows show “—”.
Appends a LOS-Graze column showing the same kind of angle for the satellite-to-observer line of sight — LOS measured against the same chassis panel. 0° = LOS along the panel surface (observer at the satellite's horizon); 90° = LOS along the panel normal (observer directly below the satellite). Symmetric companion to Sun-Graze; both can be enabled together to compare sun-side and observer-side geometry. Starlink only — non-Starlink rows show “—”.
For today's simulation date, CuriousPilot auto-fetches five selected Celestrak feeds alongside Space-Track to improve catalog accuracy for actively-launching constellations: operator-derived SupGP ephemerides for Starlink, OneWeb, Kuiper, AST SpaceMobile, and Iridium. These are fetched in Celestrak's CSV (OMM) format. Sources are stored separately in the local database. Celestrak-sourced satellites appear in italics in the Satellites Visible list; user imports appear in bold italics.
When Space-Track and Celestrak both have a record for the same satellite, this controls which one wins at parse time (applied instantly — no re-download). The ? explains each mode and why Prefer Celestrak is the most accurate default.
You can also import additional satellites as a TLE (2-line / 3-line), CSV, or JSON (CelesTrak OMM) file — the format is detected automatically. Imports are layered on top of the auto-fetched sources — they win on any NORAD ID collision (e.g. a fresh launch not yet in either feed) but otherwise leave the merge intact. Imports persist locally across sessions.
Force-refresh today's satellite data ahead of the regular auto-refresh. Most users will never need this — Play, Rewind, and Load Flight refresh today's data automatically once it's older than 12 hours.
Return every option on this Settings tab to its original default value. Your location, date/time, view, saved sessions, satellite groups, credentials, and imported orbital data are all kept — only the Settings-tab options change.
When Curious Pilot hits an error, send a technical report so it can be fixed. Includes your browser, operating system, graphics hardware, and the simulation settings in use. No name, email, account, or location is ever sent.
Delete every saved aircraft flight track and the per-flight satellite data that goes with it. Your settings, credentials, and the satellite group list are kept. This cannot be undone.
Toggle satellite groups to control which satellites appear in the simulation. Disabling large groups like Starlink significantly improves performance.
Satellite data not loaded yet.
Out of the box every group is on and Show All Satellites is on. Set the checkboxes above the way you want them, then save that as your own default. It is what the app falls back to when a loaded session or settings file does not say which groups to use. Stored on this browser only — it is never written into a saved session or a settings file you share.
Tutorials explaining how to use Curious Pilot software:
Have a feature request, found a bug, or just want to say hello? Contact the developer →
Curious Pilot has two modes, controlled by the Observer Mode switch at the upper left: Fixed Mode for observing from a fixed location, and Aircraft Mode for replaying a real flight.
Fixed Mode — Enter your location (or search by name), set the date/time, and press Play. Visible satellites appear as moving dots on the sky dome.
Aircraft Mode — Enter a call sign, flight number, or ICAO24 hex code along with a date, then click Load Flight. The app replays the flight path and shows satellites visible from the aircraft. Flight track data can be obtained from OpenSky Network or FlightAware AeroAPI — select your provider under Provider Credentials. Both require a free account. The developer has no relationship with either provider and receives no compensation.
Controls — Drag the sky to look around. Use the heading and elevation sliders for precise aiming. The magnitude filter limits which satellites are shown.
Satellite Info — Click the “x satellites visible” count at the upper left to see a list of visible satellites with details.
Satellite Data — Orbital parameters are fetched from Space-Track.org, the U.S. Space Command’s public catalog of tracked objects in Earth orbit. For today’s simulation, the app also auto-fetches supplemental data from CelesTrak — operator-derived SupGP feeds for Starlink, OneWeb, Kuiper, AST SpaceMobile, and Iridium (more accurate ephemerides for those actively-launching constellations). CelesTrak also serves as a fallback when Space-Track is unavailable. The app tracks active satellites across all orbital altitudes; use the Satellite Groups tab to choose which ones to display. The Update Satellite Data button at the bottom of the controls area re-fetches the latest data. Satellite data is cached locally and only re-fetched when you click the button.
Historical Satellite Data — For accurate replay of past events, Space-Track also provides historical orbital parameters going back to 1957, ensuring satellites appear where they actually were on a specific past date. Historical lookups require a free Space-Track.org account, which you can configure under Settings. There is no CelesTrak fallback for historical data.
| Space | Play / Pause simulation | C | Toggle constellations | |
| D | Toggle dome grid | E | Toggle Enhanced / Realistic display | |
| F | Toggle deep-sky objects | G | Toggle transparent earth | |
| H | Toggle highlight circles | |||
| I | Toggle white-sky (inverted) view | K | Keyboard shortcuts | |
| L | Toggle satellite lines | M | Magnetic heading | |
| N | Toggle satellite names | P | Toggle planetarium mode | |
| R | Realistic satellite display | S | Settings & Info | |
| T | True heading | V | Toggle satellites-visible list | |
| Z | Toggle magnify tool | Esc | Exit magnify (zoom unchanged) | |
| X | Snapshot (with controls) | O | Snapshot (without controls) | |
| 1 2 3 4 5 6 | Set zoom: 1:1, 2:1, 3:1, 4:1, 8:1, 16:1 (center stays centered) | 0 | Reset zoom to 1:1 | |
| [ | Rewind to start | ] | Fast forward to end | |
| ← → | Camera azimuth (left / right) | ↑ ↓ | Camera elevation (up / down) | |
| ⌥ Option + hover | Identify star or deep-sky object (name, magnitude, type) | ⌥ Option + click | Show position uncertainty for satellite |
Opens a dialog with the current Satellites breakdown, Stars currently above the horizon (click any star to point the camera at it), and an explanation of how satellite brightness is calculated.
Brave Browser. Brave’s Shields feature can cause the 3D sky view to go white or become blurry during a simulation. If this happens, click the lion icon in the address bar and turn Shields off for this site, then reload the page. This does not affect your Shields settings on other sites.
magsrc=analyst and magsrc=default.bus=V2MD search, and the Satellite Flares tab now explains how each satellite is classified.bus=V2MD). The type is read from the satellite’s name.ISS finds ISS (ZARYA), and Starlink 4304 (with a space) finds STARLINK-4304. When several satellites match, a short pick-list appears; click one for its details. Previously only an exact catalog name worked.g17-28) now resolves to the correct current launch by its NORAD/COSPAR ids, instead of occasionally matching an unrelated older launch.g4-26), a COSPAR id (2022-097), or a date (2022-08-10) and get the matching satellite, the whole launch group with its roster, or every launch on that date. Future Launches and Past Launches tabs list upcoming and completed launches with the rocket, launch site, and time (shown in your local time and UTC)..json file you can re-open later (or send to someone) to reproduce the simulation exactly. Open Settings… restores it. The satellite catalog is re-fetched by date on open, so the file stays small.-), and combining terms with && (and) / || (or) — e.g. country=PRC && objtype=payload, starlink && el>30, -rcs=small. A new Search all checkbox searches the entire ~30,000-object catalog, not just what’s currently visible..tle file (Settings → Manually Import .tle Data), the imported satellites could vanish after pressing Reset or Rewind — leaving only the date’s standard catalog. The import was being filed under the date shown on the running simulation clock, while Reset/Rewind reload by the start date; once the clock advanced past UTC midnight, the two no longer matched. Imports are now filed under the simulation start date, so they persist through Reset, Rewind, and Play.0° for geostationary, around 53° for most Starlinks, and near 98° for polar / sun-synchronous orbits.120, 300, or a slower-than-real-time 0.5. Typing a value applies it immediately and clears the preset buttons; clicking a preset clears the custom field.g10-31 — or the launch’s COSPAR international designator such as 2024-129 — into the satellites-visible search box to isolate just the satellites from that launch. Handy for locating a specific Starlink “train” shortly after deployment, when it’s a tight, bright line across the sky.run_local.sh would fail with “Could not load satellite data” on the first historical-date request of each session, surfacing the internal error res.headers.raw is not a function. The crash was introduced when the node-fetch dependency was removed in v1.60 — one cookie-extraction call in server.js still relied on a node-fetch‑only method. Switched to the standards-compliant Headers.getSetCookie(), extracted the helper into its own module, and added regression tests. The production site at curiouspilot.com was unaffected (it runs on Cloudflare Pages Functions, not server.js).2:1, 3:1, 4:1, or fractional values like 2.5:1 for click-zoom intermediate steps); clicking the indicator still resets to 1:1.2022-08-10T11:39:08) rather than rounding to the nearest minute. The Now-mode auto-update and the Aircraft Mode flight-load auto-populate paths preserve the seconds digit too. For comparison work against astrometric references this matters: the prior rounding could shift the rendered moment by up to 59 seconds, which at typical Starlink-train rates is several degrees of train movement.min/max attributes bracketing the recorded flight range, so the browser blocks any value outside the actual track.5·log₁₀(range / 1000) magnitudes. At typical Starlink ranges (~1500 km) the correction is about −0.88 mag dimmer per satellite; for a 51-sat train the combined cluster magnitude shifts by the same amount. Closer satellites would shift the other way (brighter), but the satellites that flare in practice are all at long range, so the user-visible direction is “Starlink flares are now predicted ~1 mag dimmer”, which agrees more closely with third-party flare prediction services that already used the observer-range frame. No change to the diffuse magnitude model — ISS-class predictions are unaffected (independently verified against heavens-above.com on 2026-05-23: predicted −3.5 mag vs heavens-above −3.6 mag, with shadow-entry within 4 seconds). Full technical write-up in docs/flare_range_frame_bug.md.docs/flares.md on rendering modes and photometric comparison — explains why Emphasized display mode (the default) renders any cluster magnitude from −4 to +2 at the same on-canvas size, and why anyone visually comparing the canvas to a real-world photograph should switch to Realistic mode first.Cluster est. mag: 3.42 (52 sats) when fully illuminated, (N of M sunlit) during partial shadow emergence, or omitted when the entire cluster is shadowed). Shadowed satellites get a slate-blue ⊘ In Earth’s shadow annotation, and their misleading per-sat magnitude is omitted (the satellite reflects no light, so any finite number would mis-represent it as something you could see).A0001 = 100001). Before this fix, Alpha-5 satellites would have silently fallen through to estimated brightness instead of the measured Stellarium value. Both Space-Track and CelesTrak issue the same scheme, so the fix covers both data sources. The About tab’s Space-Track and CelesTrak sections now mention Alpha-5 support.Az 245.3° El 33.2°) instead of rounding to whole degrees. The extra digit matters when cross-checking simulated positions against astrometric references — whole-degree rounding loses about half a degree of angular-rate accuracy on short time windows.——) during the mode transition instead of momentarily showing values from the previous mode.maxLabelSats; and trail-buffer setup is deferred to first-push.1…9 to −5…10 so you can dial the visibility cutoff into negative magnitudes for flare-only viewing.starlink || el>2 && el<20 were silently being treated as “Starlinks only.” The non-Starlink branch of such a filter now correctly admits matches that satisfy the numeric clauses.<, <=, >, >=, =, != with the fields az, el, or mag — for example mag < 3 shows only satellites brighter than mag +3, and el > 30 shows only those above 30° elevation.&& (AND) and || (OR) operators. Examples: starlink && mag < 4 && el > 20 (bright Starlinks well above the horizon); iss || mag < -1 (the ISS or anything currently flaring very brightly); starlink && el > 30 || cosmos && el < 30 (high Starlinks or low Cosmos sats). Operator precedence is unchanged — && binds tighter than ||.mag comparisons, the flare-boosted brightness is used when a satellite is actively flaring, so mag < 0 correctly includes a Starlink whose intrinsic magnitude is dim but which is currently flaring brightly — matching what you see on screen.E now toggles between Enhanced and Realistic display modes.N first, tightened blink cadence and overall timing, lowered the magnitude cap, and reworded the splash and data-source lines.&& (AND) and || (OR) operators, with && binding tighter than ||. Examples: starlink && v1.5 shows only Starlink V1.5 sats; iss || hubble || tiangong shows three named targets at once; starlink && v1.5 || cosmos shows Starlink V1.5 sats plus all Cosmos sats. Matching is case-insensitive substring; single & and | characters are preserved as literals (so AT&T still works)/about, /help) so you can share a direct link to a specific tab<gx:Track> blocks (e.g. adsbexchange exports that split taxi and airborne phases) — all tracks are merged, sorted by timestamp, and adjacent duplicate timestamps collapsed so the interpolator never sees a zero-duration segment.kmz file (zipped KML) and it’s extracted and parsed transparently using the browser’s native DecompressionStream API — no library requiredkml: or kmz: prefix, the file’s Placemark name as the displayed callsign (or the filename if no name is present), waypoint count, duration, and a notes field — identical UX to lookup-fetched flightsgl_PointSize in screen pixels — a magnitude-N satellite is drawn at the same pixel size as a magnitude-N star, and dots no longer enlarge near the edges of the canvasos:, fa:) instead of the misleading ICAO24: label, since FlightAware idents are not ICAO24 codesflightcache:* entries are migrated automatically on first launch after upgradeos:, fa:) so OpenSky and FlightAware records share one namespace without collisiontle_cache_* entries are migrated automatically on first launch after upgradeCurious Pilot is free to use at curiouspilot.com. Below are the license notices for the application and for the third-party libraries and data sources it relies on. Items marked ✓ have been verified against their canonical license; the rest are based on each project’s public documentation and remain under review.
Curious Pilot is committed to respecting the licenses and terms of all bundled libraries and data sources. If you identify any licensing concerns, please contact the developer and he will work promptly to address them.
Curious Pilot
Libraries
Data Sources
satellites.json. Stellarium is licensed GPL v2; we use only the factual {noradId, stdMag} numeric values to compute apparent brightness, in accordance with copyright fact / use boundaries. ✓ verified 2026-05-06.public/stars_data.js retains this license; per CC BY-SA 4.0 §3(b) the obligation attaches to the data file, not to the application as a whole. ✓ verified 2026-05-06.public/constellationData.js retains this license; per CC BY-SA 4.0 §3(b) the obligation attaches to the data file, not to the application as a whole. ✓ verified 2026-06-07.public/assets/moon_nearside.webp — a single full-Moon frame, cropped to the disc and downsampled. NASA imagery is not subject to copyright in the United States. Curious Pilot is not affiliated with or endorsed by NASA. ✓ verified 2026-08-12.User-Agent header. End-user-driven (button-click), not auto-complete. Bound by the OSM Foundation Nominatim Usage Policy. ✓ verified 2026-05-06.terrarium tiles on the AWS Open Data registry), fetched directly by the user’s browser. Required attribution per the project’s attribution notice: ArcticDEM terrain data DEM(s) were created from DigitalGlobe, Inc., imagery and funded under National Science Foundation awards 1043681, 1559691, and 1542736; Australia terrain data © Commonwealth of Australia (Geoscience Australia) 2017; Austria terrain data © offene Daten Österreichs – Digitales Geländemodell (DGM) Österreich; Canada terrain data contains information licensed under the Open Government Licence – Canada; Europe terrain data produced using Copernicus data and information funded by the European Union — EU-DEM layers; Global ETOPO1 terrain data U.S. National Oceanic and Atmospheric Administration; Mexico terrain data source: INEGI, Continental relief, 2016; New Zealand terrain data Copyright 2011 Crown copyright © Land Information New Zealand and the New Zealand Government (All rights reserved); Norway terrain data © Kartverket; United Kingdom terrain data © Environment Agency copyright and/or database right 2015. All rights reserved; United States 3DEP (formerly NED) and global GMTED2010 and SRTM terrain data courtesy of the U.S. Geological Survey. ✓ verified 2026-08-29.Satellite Brightness
http with no secure equivalent, so the values are compiled into the application ahead of time rather than fetched from the user’s browser. Refreshed monthly.quicksat magnitude file, published free for public use. Only the factual magnitudes are used; a +0.75 convention correction is applied so his full-phase values match our reference geometry. Refreshed monthly.Curious Pilot is not affiliated with or endorsed by any of the observatories, authors, or institutions named above. See About → Satellite Brightness → Sources for what each source contributes.
Curious Pilot does not redistribute any third-party library or dataset; libraries are loaded directly from their canonical CDNs in the user’s browser, and data sources are queried at runtime.
Philip Giacalone is an aerospace engineer and software developer whose 40-year technical career has spanned spacecraft systems, autonomous drones, and Silicon Valley startups. He developed Curious Pilot as a free tool to aid investigations of pilot-reported UAP sightings. It combines real ADS-B flight data with published satellite orbital and astronomical data. He is also the developer of PCBTracer.com: a specialized web application useful for troubleshooting and reverse engineering electronics by tracing and documenting printed circuit board (PCB) details.
| Space | Play / Pause simulation | C | Toggle constellations | |
| D | Toggle dome grid | E | Toggle Enhanced / Realistic display | |
| F | Toggle deep-sky objects | G | Toggle transparent earth | |
| H | Toggle highlight circles | |||
| I | Toggle white-sky (inverted) view | K | Keyboard shortcuts | |
| L | Toggle satellite lines | M | Magnetic heading | |
| N | Toggle satellite names | P | Toggle planetarium mode | |
| R | Realistic satellite display | S | Settings & Info | |
| T | True heading | V | Toggle satellites-visible list | |
| Z | Toggle magnify tool | Esc | Exit magnify (zoom unchanged) | |
| X | Snapshot (with controls) | O | Snapshot (without controls) | |
| 1 2 3 4 5 6 | Set zoom: 1:1, 2:1, 3:1, 4:1, 8:1, 16:1 (center stays centered) | 0 | Reset zoom to 1:1 | |
| [ | Rewind to start | ] | Fast forward to end | |
| ← → | Camera azimuth (left / right) | ↑ ↓ | Camera elevation (up / down) | |
| ⌥ Option + hover | Identify star or deep-sky object (name, magnitude, type) | ⌥ Option + click | Show position uncertainty for satellite |