How it works
Video is analysed where it is recorded. Only small metadata packets travel to a shared server, which pairs simultaneous sightings, intersects their sight lines and reports every position with its uncertainty.
Each node is a small computer (an NVIDIA Jetson Orin Nano) in a volunteer's home with a sky-facing camera, a GPS receiver for position and precise time, and optionally an orientation sensor. The server is shared. The design keeps the heavy data, the video, on the node, and moves only what triangulation needs.
1080p video at 60 fps into a rolling buffer in memory. Video never leaves the device by default.
Background subtraction finds moving points; a tracker links them frame to frame.
Stars, clouds, birds, insects and ADS-B aircraft are labelled and dropped.
A signed, roughly 0.5 KB packet: time, position, direction. Ten per second while visible.
Packets from nodes within 80 miles and 50 ms of each other are paired.
Sight lines are intersected; every fix carries its own error estimate.
Fixes join into 3D tracks; speed and acceleration come from fitted curves.
Only after two or more nodes agree, each is asked for ten seconds of HD video.
The clip request is the only message the server sends to a node, and it is signed with that node's key.
Step 1
The camera streams video (by default 1920 × 1080 at 60 frames per second through a lens with a field of view of about 90°) into a pre-allocated buffer in memory that holds the last 10 seconds. A detector compares each frame with a slowly updated model of the background sky and picks out small moving points; a tracker links them from frame to frame into local tracks. A sky mask ignores everything below a minimum elevation (3° by default) and any pixels the host marks as rooftops, trees or neighbouring buildings.
Before anything is reported, each confirmed track goes through false-positive filters:
| Filter | What it looks for |
|---|---|
| Stars and planets | Objects moving at or below the sidereal rate (0.0042° per second) and fixed lights. |
| Clouds | Large, diffuse, low-contrast structure that is slow or drifts with the wind field measured across the frame. |
| Birds and insects | Objects close to the lens: large apparent size plus rapid growth or shrinking, a periodic wingbeat flicker (2–25 Hz) or defocus. |
| Aircraft | Tracks that follow an aircraft broadcasting its position by ADS-B, projected to each frame time, from a local receiver or an online feed. |
| Satellites and meteors | Off by default: one camera cannot tell a straight-flying unknown from a satellite. Triangulated altitude settles it on the server. |
Filtered tracks are not sent. Their label and the reason are logged on the node, so an operator can audit what was suppressed and why. A track that has manoeuvred is never labelled as a satellite or meteor.
Each detection's pixel position is converted to a direction in the sky (azimuth from true north and elevation above the horizon) using the lens calibration and the camera's pointing. Pointing accuracy dominates the error budget, so fixed cameras are calibrated against the star field; an orientation sensor, if fitted, is used to notice that a mount has moved, not to measure direction.
Step 2
For each surviving track the node sends a telemetry packet ten times a second for as long as the object is visible, plus a heartbeat every 10 seconds with its health and camera geometry. A packet holds the capture time in nanoseconds from a GPS-disciplined clock, the node's position, the camera's pointing, the direction to the object and a few image measurements. It is signed with a key unique to the node, so the server can reject forged, stale (more than 10 seconds old) or replayed messages.
{
"type": "telemetry",
"node_id": "4f9a2c1e-7b3d-4e8a-9c6f-1a2b3c4d5e6f",
"gps_coordinates": {"latitude": 33.6292, "longitude": -112.3679, "altitude_m": 357.2},
"imu_orientation": {"pitch_deg": 45.0, "roll_deg": 0.0, "yaw_deg": 0.0},
"timestamp_ns": 1782345600000000000,
"vector_target": {"azimuth_deg": 142.521, "elevation_deg": 65.104},
"pixel_metrics": {"angular_velocity_deg_s": 12.4, "relative_intensity": 0.85},
"seq": 1042,
"track_id": "t-000173",
"anomaly_score": 0.91,
"sig": "<64 hex characters: HMAC-SHA256 with the node's key>"
}Example from the wire protocol. Serialised compactly and signed, a packet like this is about 520 bytes. Packets travel over UDP to a self-hosted server or over HTTPS in batches.
The packet contains the node's exact GPS position because triangulation needs it. The server uses it internally; public responses round node positions to two decimal places, about 1 km.
Step 3
The server keeps a spatial index of active nodes (heard from in the last 60 seconds). For every incoming sighting it looks for sightings from other nodes within 80 miles whose timestamps fall within 50 milliseconds. Fifty milliseconds matters: an object at Mach 6 covers about 100 m in that time, so when the neighbour has samples of the same track on both sides, the server interpolates its sight line to the exact moment of the packet.
A candidate pair is accepted as the same object only if:
Competing candidates are ranked by how small their miss distance is relative to that prediction.
Step 4
Two sight lines in three dimensions almost never intersect exactly. The server finds the shortest segment between them; its midpoint is the position estimate and its length, the error margin, is a direct check on consistency.
With three or more nodes the server solves a weighted least-squares problem: the point that minimises the squared perpendicular distances to all sight lines, with each line weighted by 1/(range × σ)², so that distant observers, whose sideways error is larger, count for less. The result is converted to latitude, longitude and height above the WGS84 ellipsoid.
Derivations and tests: docs/MATH.md and the shared
skynet_common.triangulation module.
sigma_m.
Step 5
Each sight line constrains the position in the two directions perpendicular to it, with a standard
deviation of range × σ, where σ is the angular error. Combining all lines gives a covariance for the
position; the API reports its square-root trace as sigma_m, the 3D RMS error in metres. A
Monte-Carlo test confirms that simulated errors match this prediction.
Predicted 3D position error (1σ RMS) for two nodes due east–west and a target at 10 km altitude midway between them, for three levels of pointing accuracy. From the project's error model (docs/MATH.md).
| Node spacing | Range | Parallax | Elevation | σ at 0.01° | σ at 0.05° (default) | σ at 1° |
|---|---|---|---|---|---|---|
| 8 km (5 mi) | 10.4 km | 45° | 68° | 4 m | 386 m | |
| 16 km (10 mi) | 12.5 km | 79° | 50° | 4 m | 351 m | |
| 32 km (20 mi) | 18.7 km | 118° | 31° | 6 m | 570 m | |
| 64 km (40 mi) | 33.4 km | 146° | 17° | 15 m | 1.5 km | |
| 128 km (80 mi) | 64.7 km | 162° | 8° | 53 m | 5.3 km |
A 1080p sensor behind a 90° lens covers about 0.047° per pixel, and finding a point's centre gives 0.01–0.05°. A consumer orientation sensor manages about 1°, which is 20 to 100 times worse. That is why fixed cameras are calibrated against the stars.
Too close and the sight lines are nearly parallel for distant objects. Too far and the object sits low on both horizons, where refraction, haze and obstructions dominate: at 80 miles it is only 8° up.
Nodes discipline their clocks with the GPS pulse-per-second signal. Ordinary internet time over a home connection is only good to a few milliseconds, and the capture delay of each camera is calibrated once.
Not modelled yet: atmospheric refraction (about 0.5° at the horizon, under 0.02° above 45° elevation), residual lens distortion and the node's own GPS position error (about 2–5 m, negligible next to angular error at these ranges).
Step 6
Every node labels its own tracks, so successive triangulations that share a node's track are linked into a single 3D track. Individual fixes are noisy (tens of metres at typical ranges), so velocity and acceleration are never taken from point-to-point differences. Instead the server fits a straight line and a parabola to the last second of points, and again to a once-per-second history of the last 30 seconds, and keeps each parameter's standard error.
Flags use the 2σ lower bound of the fitted value, so measurement noise alone cannot trigger them. The published maximum acceleration is that lower bound.
| Flag | Rule |
|---|---|
hypersonic | Speed above 1,715 m/s (Mach 5 at sea level). |
high_g | Acceleration above 98 m/s² (10 g). |
ballistic | For at least 5 s, moving at 100 m/s or more with an acceleration that matches gravity (within the larger of 3σ and 2 m/s²) and is known to within 3 m/s². |
stationary | Speed below 2 m/s for 30 s. |
unknown | The default when no rule has fired. |
A flag describes motion; it does not identify anything. Meteors, for example, routinely exceed the hypersonic threshold: they enter the atmosphere at roughly 11–72 km/s and burn up around 80–120 km altitude, and that altitude is what identifies them.
Step 7
Only when two or more nodes confirm a match does the server send each contributing node a
signed clip_request for the 10 seconds around the event (5 seconds either side). Because the node
keeps the most recent seconds of video in memory, the moments before the request can still be saved.
The design target for delivering the request is under 20 ms on the UDP transport. By default nodes also keep short clips of their own detections on their own disk, for up to 14 days, and upload nothing unless asked.
The map and the public API are read-only and open to anyone. This is what they contain.
Rounding is a safeguard, not a guarantee: published sight lines combined with triangulated positions could, in principle, narrow a node's location further. This is under review before launch. See the privacy notice.
Read this