UAP Finder

The node

A sky camera that measures directions

A UAP Finder node is a small computer and a wide-angle camera under a clear dome. It watches the sky all day and night, explains away what it can, and reports the exact direction and time of everything else. Two nodes miles apart turn those directions into a position.

Build a node Parts and cost

New and not yet hardware-tested. The ready-to-flash system image, the setup page and the automatic star calibration described here are new. They are tested in simulation and in containers, but have not yet run on a real Jetson with a real camera and GPS. Figures marked as estimates have not been measured on a complete node.

Anatomy of a node

Everything sits in one weatherproof box on a rigid mount. The camera looks up through a clear dome; the computer, GPS and optional extras live underneath. Only power and, ideally, an Ethernet cable go in.

Cutaway of a finished UAP Finder node A weatherproof box on a rigid pole. On top, a clear dome with a dew-heater ring around its base covers the camera, which points up through the dome with a wide-angle lens; an optional orientation sensor is fixed to the camera bracket. Under the lid are the GPS antenna and the GPS module. Lower down sits the Jetson Orin Nano developer kit with its heatsink and fan, an NVMe SSD on the underside of its carrier board and an optional ADS-B USB receiver, connected to an external antenna beside the box. Cable glands in the bottom let in power, Ethernet and the antenna cable, next to a breather vent. Numbered markers match the list below the drawing. ≈ 90° power Ethernet 1 2 3 4 5 6 7 8 9 10 11 12 13 14
  1. Clear dome. Acrylic, about 100 mm across; keeps rain off the lens while the camera sees the sky.
  2. Camera and lens. A 12.3 MP IMX477 camera run at 1920 × 1080, 60 frames per second, with a wide lens (about 90° across), focused at infinity.
  3. Dew heater. A small heater ring that keeps the dome a little warmer than the air so it does not fog or frost.
  4. Orientation sensor optional A BNO055 fixed to the camera bracket. It notices if the mount moves; the stars give the actual pointing.
  5. GPS antenna. Active antenna under the lid (or outside), for a reliable fix.
  6. GPS module with PPS. Wired to the computer's 40-pin header: position, and a pulse at the start of every second for precise time.
  7. Jetson Orin Nano developer kit. The computer: module with heatsink and fan on a carrier board. The UAP Finder system runs from a microSD card in the slot under the module.
  8. NVMe SSD recommended In the M.2 slot under the carrier board; holds clips and calibration.
  9. ADS-B receiver optional A USB radio that hears aircraft broadcasting their own positions.
  10. ADS-B antenna optional A 1090 MHz antenna outside the box, connected by coax.
  11. Enclosure. Weatherproof, shaded and ventilated so the computer stays within its temperature limits.
  12. Cable glands. Sealed entries, facing down, for power, Ethernet and the antenna cable, with drip loops outside.
  13. Breather vent. Lets air pressure and moisture equalise without letting water in.
  14. Rigid mount. A stiff pole or bracket: pointing must not change once the node has calibrated itself.
Schematic, not to scale. Parts and layout vary between builds.

What happens inside, frame by frame

The node does the heavy work itself. Sixty times a second it compares the new frame with what the sky normally looks like, follows anything that moves, and drops what it can explain. Only a few hundred bytes per sighting leave your house.

A camera frame of the night sky with a cloud, two stars, an aircraft and a small moving point. 1 · Camera frame
The background model: the slowly updated average sky, with the cloud and the stars but without the moving aircraft or point. 2 · Background model
The difference between frame and background: only the aircraft and the moving point stand out as bright spots. 3 · Difference
Tracks after filtering: the aircraft's track is labelled as an ADS-B aircraft and dropped, the stars and cloud are not reported, and the unexplained point's track is reported. aircraft (ADS-B) report stars, cloud: not sent 4 · Tracks, filtered

  1. Capture

    The camera streams 1920 × 1080 video at 60 frames per second. Each frame is time-stamped the moment it arrives, on a clock locked to GPS, and kept in a memory buffer holding the last 10 seconds.

  2. Background model

    A slowly updated average of recent frames (a 2-second time constant) absorbs the sky's brightness gradient, haze, clouds that barely move, and the slow drift of the stars.

  3. Detections

    Subtracting the background leaves what changed. Pixels well above the local noise become candidate points, each with a sub-pixel centre. Areas the host masks out, and anything below 3° elevation, are ignored.

  4. Tracking

    A tracker links detections from frame to frame into local tracks, predicting each one's next position and bridging the odd missed frame.

  5. Filters

    Each confirmed track is checked against what is already understood: stars and planets (moving at the sky's own 0.0042° per second, or not at all), clouds (large, diffuse, drifting with the wind), birds and insects (big, close, flapping or out of focus) and aircraft broadcasting their position by ADS-B, from the node's own receiver or an online feed. Explained tracks are logged on the node and not sent.

  6. Direction

    The pixel position becomes a direction in the sky, azimuth from true north and elevation above the horizon, using the lens model and the pointing the node worked out from the stars.

  7. A signed, GPS-timed message

    Ten times a second while the object is in view, the node sends about 520 bytes: the frame's capture time in nanoseconds, the node's position, camera pointing, the direction to the object and a few image measurements, signed with the node's own key. A heartbeat with the node's health follows every 10 seconds.

What leaves the house

  • Sight-line messages for tracks no filter explains: time, position, pointing and direction.
  • A heartbeat every 10 seconds: health, camera geometry, GPS and clock state.
  • Ten seconds of video, only when the server asks after two or more nodes agree on the same object.

What stays on the node

  • The continuous video stream.
  • Everything the filters explained: stars, clouds, birds, insects, ADS-B aircraft.
  • Short clips of its own detections, on its own SSD for up to 14 days, unless requested.
  • The setup page's live preview, which the node serves on your local network, not to the server.

More detail, including each filter's rules, in How it works.

Two nodes working as a pair

One camera knows only the direction to an object, not how far away it is: a small bird near the lens and an aircraft 10 km up can look the same. A second node miles away sees the same object along a different line. Where the two lines cross is the object's position, and how well they cross tells us how certain it is.

Two nodes 12 km apart triangulating one object Side view, to scale. Node A and node B stand on the ground 12 kilometres (about 7.5 miles) apart, both cameras pointing straight up with a 90 degree field of view. Their fields of view overlap above about 6 kilometres altitude. An object near 10 kilometres altitude sits in the overlap. A sight line runs from each node to the object, each surrounded by a narrow wedge of angular uncertainty, exaggerated for visibility. The small quadrilateral where the two wedges overlap is the position uncertainty. A dashed line drops from the object to the ground to show its altitude. A's view B's view overlap object 10.4 km up Node A Node B 12 km (7.5 mi)
What camera a sees: the same stars at the same places, with the object right of centre Camera A toward B →
What camera b sees: the same stars at the same places, with the object left of centre Camera B ← toward A
Parallax at the object: 60°. In a 1920-pixel frame the object sits 1,112 pixels further left in B's view than in A's, while every star stays put. Side view to scale, both cameras pointing straight up for simplicity. The error wedges are drawn at 1.4°, about 30–140 times the 0.01–0.05° a star-calibrated node achieves, so they are visible.

Overlap is the point

Two nodes only triangulate in the patch of sky both can see. In the drawing, 12 km apart and both pointing straight up, it starts 6 km up and widens with altitude; aiming cameras towards a shared area lowers it.

Parallax gives distance

Against the background stars the object sits in a different place in each camera's frame. The larger that angle, the better the range is pinned down, which is why nodes need to be miles apart.

Every fix has an error

The overlap of the two uncertainty wedges becomes the published sigma_m. With a 16 km baseline and a target at 10 km it is about 18 m at 0.05° pointing precision (computed, not measured).

Timing: one clock for every node

Triangulation only works if both sight lines describe the same instant. A Mach 6 object moves about 100 m in 50 ms, so every node needs to know, very precisely, when each frame was taken.

How GPS time lets two nodes' frames be compared A timeline from 0 to 200 milliseconds. GPS satellites drive a pulse-per-second signal at the start of each second, which disciplines both nodes' clocks to the same time. Node A and node B each capture a frame every 16.7 milliseconds, at different moments, and every frame is stamped with that shared clock. While tracking, each node reports a sight line ten times a second. For node A's report at about 135 milliseconds, the server takes node B's sight line at exactly the same instant, interpolated between B's reports before and after it; if B has no reports on both sides it uses B's nearest report within 50 milliseconds. GPS satellites PPS Node A Node B Server start of the second: both clocks locked to it B interpolated to A's instant fallback: nearest sample within ±50 ms 0 50 100 150 200 ms
  • a frame, every 16.7 ms (60 fps), stamped with its capture time
  • a reported sight line, 10 a second while tracking
  • B's sight line at A's exact time
Frame times are illustrative; the frame rate, report rate and 50 ms window are the defaults.

  1. GPS gives the second

    The GPS module sends the time as text, and a separate pulse-per-second (PPS) wire that rises exactly at the start of each second. That pulse is far more precise than the text.

  2. chrony locks the clock

    The node's clock software (chrony) locks the system clock to that pulse, to around a microsecond. Without a PPS wire, internet time is only good to a few milliseconds.

  3. Frames are stamped on arrival

    Each frame gets its capture time from that clock, minus the camera's own delay. Both nodes therefore stamp their frames on the same timescale, even though their frames are not taken at the same moments.

  4. The server lines them up

    For each packet it takes the other node's sight line at exactly that time, interpolated between its samples, or the nearest one within 50 ms. The setup page warns if the clock's estimated error exceeds 2 ms.

From fixes to a track

Ten fixes a second become a 3D track. Individual fixes are noisy, so speed and acceleration are never taken from one fix to the next: they come from curves fitted to many fixes, each with its own error bar. Flags such as high_g use the 2σ lower bound, so noise alone cannot set them off.

Successive fixes and the fitted path Thirty-one fixes of a simulated object, ten per second for three seconds, each drawn with its one-sigma error ellipse of 12 metres. The points scatter around a smooth fitted curve that rises gently from left to right. The vertical scale is exaggerated about 2.3 times so the curvature shows. 0200400600 050100150 along track, m height gain, m (×2.3)
Each fix with its 1σ error (simulated: 12 m per axis). The line is a parabola fitted to all of them.
Speed from point-to-point differences versus fitted speed Speed against time over three seconds. Speeds from differences between consecutive fixes scatter wildly, from about 85 to 653 metres per second. Speeds from straight-line fits to the last second of fixes stay close to the true speed of about 200 metres per second, each with an error bar of about 11 metres per second. 0123 0200400600 time, s speed, m/s
  • from consecutive fixes, 0.1 s apart
  • line fitted to the last 1 s, ±2σ
  • true speed in the simulation
Speed at the last fix (whole-track fit)
206 ± 9 m/s
Acceleration (whole-track fit)
16 ± 6 m/s²
Acceleration used for flags: 2σ lower bound
4 m/s²

Simulated data (true acceleration 12 m/s²), not a real observation. The values are the actual outputs of the fits shown.

Self-calibration from the stars

Knowing exactly where the camera points matters more than anything else in the error budget. Nobody can aim a camera to a hundredth of a degree by hand, so the node measures its own pointing from the stars on the first clear night.

Before calibration: catalogue stars predicted from a rough guess of the pointing are rotated and shifted away from the stars the camera detects Before: the rough guess
After calibration: the catalogue stars fall on the detected stars once yaw, pitch, roll, focal length and distortion are solved After: solved
  • star detected in a stacked night frame
  • where the catalogue says a star should be
  • a tentative match the solver tests

How it works

  1. Every 30 minutes the node checks whether it is properly dark (the Sun more than 12° below the horizon), whether it has a GPS fix, and whether it still needs a calibration (none yet, or the last one is more than 7 days old).
  2. If so, it stacks several night frames, finds the stars and matches them to a bundled catalogue of bright stars, starting from a rough guess: the orientation sensor's reading if fitted, otherwise "pointing up, heading unknown".
  3. It solves the camera's heading, tilt and roll, its focal length and the lens's distortion together, and saves the result. Clouds or a failed solve just mean it tries again later.

Until the first clear night

The node reports with a large angular uncertainty and the status page says "Pointing: waiting for a clear night". Because the server accepts only geometrically consistent matches, an uncalibrated node rarely produces false fixes.

The same solve also measures the lens: its exact focal length and how it bends straight lines near the edges, so a direction is right across the whole frame, not just in the middle.

Why it matters

One pixel, 1080p behind a 90° lens
≈ 0.047°
Pointing from the stars (centroiding)
0.01–0.05°
Orientation sensor alone
≈ 1°
Error at 16 km baseline, 10 km up: 0.05° vs 1°
18 m vs 351 m

A 1° heading error alone puts a fix about 870 m sideways at 50 km range. Figures from the error model in docs/MATH.md; the automatic calibration is new and not yet tested on a real night sky with node hardware.

The setup page

A node has no screen. It serves its own small web page on your network, at http://uapfinder.local. If it has no network, it opens a Wi-Fi hotspot called UAPFinder-XXXX (password uapfinder) with the page at http://10.42.0.1.

Illustration Before enrollment. Mock-up, example values; the real page may differ.
Illustration Status, after enrollment. Mock-up, example values; the real page may differ.

Before it is claimed

Choose a network, enter the claim code your network coordinator sent you (eight characters, like 7KQ2-M9XD; upper or lower case, dash optional, single use), and set a device password. The node exchanges the code for its own identity and key; there is nothing to copy by hand.

Afterwards

The page shows what hardware it found and how it is doing: camera, GPS fix and satellites, PPS lock, the clock's estimated error, orientation sensor, ADS-B source, storage, server connection, pointing calibration and software version. A live preview with a horizon and elevation overlay helps with aiming. Restart, shut down and a diagnostics download are there too.

Once the device password is set, anything that changes the node needs it; the status view stays readable on your local network.

Setting it up, step by step

Specifications and limits

Defaults of the software with the recommended parts. Values marked estimate are calculated, not yet measured on a complete node.

Node specifications with the recommended parts
Item Value Basis
Computer NVIDIA Jetson Orin Nano 8 GB developer kit The image is built on Jetson Linux R36.5.2 (JetPack 6.2.3, Ubuntu 22.04).
Video 1920 × 1080 at 60 frames per second Software default; the IMX477 camera has this mode on Jetson.
Field of view ≈ 90° × 59° With the recommended ≈ 90° lens; the exact value comes from calibration.
Pixel scale ≈ 0.047° per pixel 90° over 1920 pixels.
Angular precision 0.01–0.05° (estimate) Sub-pixel centroids with star-calibrated pointing; about 1° from an orientation sensor alone.
Position error of a pair ≈ 4–30 m at 5–20 miles apart (estimate) Error model, target 10 km up, 0.01–0.05° precision; about 50–270 m at 80 miles.
Timing GPS PPS-disciplined clock The setup page warns above 2 ms estimated error; without PPS, network time (a few ms).
Reports 10 per second per tracked object, ≈ 520 bytes each Plus a heartbeat every 10 seconds; signed with the node's key.
Video memory Last 10 seconds in RAM A 10-second clip around a confirmed event is uploaded only on request.
Storage microSD 64 GB+ (system), NVMe SSD (clips) A blank NVMe drive is formatted on first boot.
Power 15–30 W average (estimate) NVIDIA's power modes plus peripherals. Details.
Upload ≈ 5 MB a day idle (UDP); ≈ 5 KB/s while tracking (estimate) From the wire protocol's message sizes. Details.
Spacing 5–40 miles from another node The server pairs nodes up to 80 miles apart; beyond about 40 miles objects sit low on both horizons.

What a node cannot do

  • Measure distance on its own: one camera gives only a direction.
  • See through cloud, or detect faint objects against a bright daytime sky as well as at night.
  • Identify what an object is. It measures position and motion; flags describe motion only.
  • Measure accurately near the horizon, where refraction (about 0.5°) and haze dominate.

Not yet known

  • Real power draw and temperatures in a sealed box in summer.
  • Whether the Orin Nano sustains 60 fps on the CPU path; the benchmark exists, a Jetson result does not yet.
  • How quickly the star calibration succeeds under real skies and light pollution.
  • Detection limits for small, faint or very fast objects.

Build one

The complete guide covers the parts, a one-time firmware check, flashing the card, wiring, the enclosure, placement and setup, in the order you do them.

Build a node, step by step Register your interest first