Rig Reality Check
Four things you know — budget, sky, what you want to photograph, how much fiddling you will tolerate — in. Builds that hold together out: priced from dated catalogue prices, checked against the mount’s imaging payload, and each with what it cannot do.
Ranking is never influenced by commission. The weights are published below, in full. When the honest answer is a smart telescope, or more budget than you planned, the tool says so.
Your constraints
Mount, tripod, optics, corrector and camera.
What do you actually want to photograph?
How much fiddling will you tolerate?
Portability
Your sky, stated plainly. Enter your usable clear nights per year and this turns them into hours of integration and calendar time per project. Only you know that number for your site; a regional average is not your backyard.
Refine: guiding, and your own part weights
Weights of parts the catalogue does not hold. Blank uses the assumption shown, which is a round placeholder, not a measurement.
Catalogue: 29 mounts · 45 telescopes · 8 smart telescopes · 70 cameras. Some cameras, correctors and tripods have no dated price yet; a build that uses one is listed apart, never ranked on a partial total.
Still needed: your budget, your sky, as a Bortle class or an SQM reading, what you want to photograph, how much fiddling you will tolerate.
Or start from one of these:
How this is computed
imaging mass = OTA + rings/dovetail + corrector + camera + filter drawer + guiding + cables/dew/focuser
utilization = imaging mass / rated payload gate: ≤ 60 % or not offered
image scale = 206.265 × pixel[µm] / FL[mm] "/px
FOV = 2 · atan(sensor[mm] / 2·FL[mm]) degrees, each axis
sampling = seeing FWHM / image scale
guiding demand = guided RMS / image scale needs < 0.8 × scale to be comfortable
fill = max(major / FOV width, minor / FOV height)
score = budget + payload + sampling + guiding + framing + complexity (+ uncooled)A build is offered only when its payload can be computed from catalogued figures and sits at or below 60 % of the mount’s rated capacity, and its image scale and field can be computed. It is ranked only when every part has a dated price and the total is within budget. A build missing a price is listed apart, with the missing part named, rather than ranked on a partial total. A scope that needs a separate corrector is priced with the cheapest priced corrector its catalogue row names; a scope that names none shows the corrector as unpriced. A mount sold without a tripod is priced with the cheapest tripod whose maker names that mount; where no maker names one, the tripod line stays unpriced rather than paired by guesswork.
A missing price is never a reason to tell you not to buy. The smart-telescope answer and “you need more budget” appear only when every build that passes the checks is over budget on its priced parts alone, or nothing passes. When builds fail only because a part has no price yet, the page says the catalogue is incomplete.
The OTA weight is the manufacturer’s, and so are the camera and corrector weights where the manufacturer publishes one. Rings, guiding and cables are not in the catalogue, so they are assumptions until you enter your own (0.9, 0.8 and 0.35 kg: the prototype’s round placeholders, not measurements). The camera and filter drawer together are assumed at 0.7 kg when the camera has no published weight; when it has one, that figure is used and only the drawer and filter are assumed (0.2 kg). A corrector with no published weight is left out of the sum, and the build says so. Every build says how much of its mass is assumed. Moment arm is not modelled: a long tube loads a mount harder than its mass says, and the reference gives no formula for it.
Resale value is not yet estimated. There is no data source for it, and we will not publish a percentage we cannot source. The essentials (guiding, dew control, filters, power, control, storage, a focus mask) are listed on every build, each priced with a typical, commonly bought product (as a rule, the in-stock item with the most customer reviews at High Point Scientific, fitted to the build by filter size, aperture or camera support) with its dated source. They are shown, never scored: the ranking and the budget check use hardware only. The headline shows a twelve-month total only when every essential and every hardware line is priced; otherwise it shows the priced hardware and counts what is missing. Tube rings are never priced: they are sized to a tube diameter the catalogue does not hold. Processing software is $0; the free chain is sufficient.
The scoring weights
Signed off (2026-09-27)This is the whole ranking. No term takes commission, retailer margin, brand or seller as an input. The explanations are in docs/rig-reality-check-weights.md.
Budget use (u = priced hardware ÷ budget)
| Range | Points |
|---|---|
| u > 0.95 | 4 |
| 0.5 < u ≤ 0.95 | 10 + (u − 0.5) × 8 |
| u ≤ 0.5 | 5 + u × 10 |
Payload — reference § 4 bands (rule of thumb)
| Utilization | Verdict | Points |
|---|---|---|
| < 40 % | Real headroom for a future upgrade | 17 |
| 40–50 % | Comfortable | 14 |
| 50–60 % | Workable, wind will find you, little room to grow | 8 |
| > 60 % | Do not recommend | not offered |
| > 70 % | Reject outright | not offered |
Sampling — reference § 1 bands (a presentation choice, not a gate)
| Factor | Meaning | Points |
|---|---|---|
| < 0.8 | Badly undersampled — pixel wider than the seeing disc, stars land as blocky squares | -9 |
| 0.8 – 1.4 | Undersampled — the standard, deliberate wide-field trade | 9 |
| 1.4 – 3.2 | Practical band for typical seeing | 15 |
| 3.2 – 4.5 | Oversampled — per-pixel signal cost, tighter guiding needed, binning recovers most | 9 |
| > 4.5 | Heavily oversampled — you will not out-resolve the atmosphere | 0 |
When you ask for wide targets, "undersampled" scores as practical (15): deliberate undersampling is the right trade there.
Guiding demand — reference § 4 bands (rule of thumb)
| RMS ÷ scale | Meaning | Points |
|---|---|---|
| < 0.8 | Comfortable — errors hide inside the seeing disc | 12 |
| 0.8 – 1.3 | Achievable with careful polar alignment; expect some rejected subs | 7 |
| > 1.3 | You will fight this — the classic “why are my stars eggs” trap | -5 |
| no RMS given | Manufacturers publish periodic error, not guided RMS. Not scored. | 0 |
Framing, per target
| Fill | Fit | Points |
|---|---|---|
| < 0.25 | tiny in the frame | 0.4 |
| 0.25 – 0.92 | fills the frame | 3 |
| 0.92 – 1.4 | tight crop | 0.5 |
| ≥ 1.4 | needs a mosaic | -2 |
Summed over the five targets, × 2.2. If the first (headline) target’s fill is above 1.5, -7 more.
Complexity against your patience
points = 8 − |complexity − target| × 1.6; target is 4 for “none”, 6 for “some”, 8 for “lots”. Complexity sums: mount (tracker 2, strain-wave 2, GEM 3); optics (petzval and refractors 1, SCT and Maksutov 2, Newtonian, RC and RASA 3); a separate corrector +1; guiding +1; a cooled camera +1. An uncooled camera adds -3 to the score.
Other thresholds
“Needs a mosaic” in the can’t-do list above a fill of 1.2; “too small” below 0.12. A field narrower than 25′ or wider than 150′ gets its own line. A mount over 55.00000000000001 % loaded “cannot grow”. A narrowband filter is listed from Bortle 5 for emission targets. The shortlist holds 3 builds, no two on the same mount and telescope.
The pictures, your sky and portability — none of them scored
Framing check. Each target is drawn at its OpenNGC angular size against the sensor field at native focal length, at one scale for both, with the major axis along the frame’s width as the fill figure assumes. The glow and stars are synthetic and seeded; no survey imagery is used.
What your data will look like. Sky and target rates are e = F₀ · 10^(−0.4·m) · A · s² · QE and each frame’s SNR is the stacked CCD equation, both from the Exposure Planner’s physics (reference §§ 2–3). Assumed: 4-minute subs, a 21.5 mag/arcsec² stand-in target, no filter, dark current or obstruction. Read noise and QE come from the camera’s sensor profile, or a labeled placeholder. The frames are noise of σ = 1/SNR over a synthetic scene: the shape of the SNR curve is real, the pixels are not.
Your sky, stated plainly. Hours a year = your clear nights × usable hours a night (an assumption you set, 4 h by default); calendar time = project hours ÷ hours a year × 12 months, for an example 20-hour project. The Moon, season and target visibility all cut into it.
Portability. Display only. Every build shows what you carry (mount head, counterweights, tripod and OTA, from their catalogue rows). “Travel” flags builds over 10 kg — our judgment of one trip from a car without a cart, not a sourced figure — and never changes the ranking. The budget is checked on hardware only; a build whose first year, essentials included, runs past it is flagged “over budget in year one”, again without changing its rank.
Rules of thumb in this tool
- Imaging payload should stay within 50–60 % of the rated capacity; the number on the box is a visual figure. — Cloudy Nights, “Mount weight capacity for imaging — disconnect”: “for astrophotography one should not use more than 50% to 60% of stated capacity”; a CGE Pro rated 90 lb “began to lose precision once I exceeded 70 lbs”. Forum practice, not a manufacturer specification.
- The five utilization bands (< 40, 40–50, 50–60, > 60, > 70 %). — docs/03-physics-reference.md § 4 — a presentation of the derate evidence above.
- A finished imaging payload runs 30–40 % over the bare OTA. — docs/03-physics-reference.md § 4 (“in practice”). A cross-check only; the tools sum components instead.
- Guided RMS should sit comfortably below the image scale (bands at 0.8 and 1.3). — docs/03-physics-reference.md § 4, “Guiding demand” — labelled a rule of thumb there.
- Moment arm is a separate penalty from mass and is not modelled. — docs/03-physics-reference.md § 4 gives no formula or bands for it.
Target sizes: OpenNGC by Mattia Verga (tag v20260501), CC BY-SA 4.0. This table is shared under the same license.
Source: docs/03-physics-reference.md §§ 1 and 4; Cloudy Nights, “Mount weight capacity for imaging — disconnect”. Implemented in packages/physics/src/payload.ts, optics.ts, scoring.ts and rig-reality-check.ts, each with unit tests from the reference's worked examples.