Ephemeris - PHD2 Log Viewer

Total RMS (root-mean-square) is the average size of your guiding error in pixels or arc-seconds, computed across every included frame in a session. It's a single number that summarizes how much your star wandered from the lock position during exposures. Lower is better, and it directly affects how much trailing or smearing shows up in your final integrated image — RMS bigger than the diameter of a star at your image scale will show as elongated stars. Ephemeris reports RMS RA and RMS Dec separately, plus the geometric total — that decomposition matters because the two axes fail in different ways.

The honest answer is "it depends on your image scale." A total RMS of 1.0″ is fine on a wide-field rig at 3″/pixel, terrible on a long-focal-length rig at 0.5″/pixel. The general rule deep-sky imagers use: total RMS should be smaller than your image scale, and ideally smaller than half of it. So at 1.5″/pixel, you want total RMS under ~0.75″. At 0.5″/pixel, you need under ~0.25″. The Ephemeris stats strip shows your pixel scale right next to the RMS values so you can do this comparison without leaving the chart.

Pixel scale (arcseconds per pixel) is a function of your imaging camera's pixel size and your telescope's focal length. A short refractor with a small-pixel camera might run at 3″/pixel — the seeing limit is fundamentally above your pixel resolution and guiding errors of half an arc-second are invisible. A long-focal-length CDK with the same camera might run at 0.4″/pixel — now every guiding twitch is recorded and the same 0.5″ RMS that was invisible before is a star-elongation problem. Ephemeris doesn't decide what's good for you; it surfaces the pixel scale right alongside the RMS so you can make the call yourself.

Because stars are points, not lines. If your RA RMS is 0.3″ and your Dec RMS is 0.2″, the total error is the geometric combination — about 0.36″ — and that's the radius of the smear circle your star paints on the sensor during an exposure. RA-only or Dec-only RMS is useful for diagnosing the cause of poor guiding (worm-gear period error shows up in RA, polar misalignment shows up in Dec drift), but for assessing your final image quality, total RMS is the number that matters.

The signature is in the axis. Persistent Dec drift — a slow, monotonic line in the chart over many minutes — is almost always polar alignment. Mount tracking errors show up as RA periodicity (worm-gear cycles) plus possible random scatter. Ephemeris computes the König-formula polar-alignment estimate from your Dec drift and declination, displays it in arcminutes, and suppresses it near the celestial pole where the math becomes unstable. If your polar-align estimate is reading a few arcminutes after a session that was supposed to be well-aligned, your Dec drift is telling you something.

The chart shows error as a function of time. The FFT shows error as a function of frequency. They surface different things. A worm-gear period of 478 seconds will show up in the chart as a slight repeating wave (often invisible in the noise) and in the FFT as a sharp spike at exactly 478 seconds. That spike is impossible to miss. The dominant period in the FFT is almost always your mount's worm — Ephemeris labels it for you in the modal — and once you know the period, you know which mechanical component to investigate. PEC training, gear regreasing, or replacement.

Calibration measures how the mount's RA and Dec axes are oriented relative to the camera. If those axes aren't actually 90° apart in the calibration plot, PHD2's correction pulses won't move the star in clean RA and Dec directions — they'll have a cross-axis component that fights the guiding algorithm. Below 1° is excellent. 1–5° is fine. Above 5° is a flag, and Ephemeris colors it orange so you can't miss it. High orthogonality error usually means your mount's polar axis isn't level, your axes are mechanically misaligned, or the calibration ran while the star was being affected by something else (cable drag, dew building on the corrector).

Functionally, they're close — same analyses, same answers. phdlogview is the canonical viewer, written and maintained by Andy Galasso (who also maintains PHD2 itself), and Andy ships builds for Windows, Linux, and macOS. The current Mac download is an Intel binary built with the wxWidgets cross-platform UI toolkit and GSL for math; on Apple Silicon it runs translated through Rosetta.

Ephemeris is a complementary Mac-native rewrite in Swift and SwiftUI, with Apple Accelerate for the FFT, a universal binary that runs natively on both Apple Silicon and Intel, the Liquid Glass design language, drag-and-drop, native menus, sandboxed file access, and Apple Help. Both projects are GPLv3 and aim at the same thing — helping you understand your guiding. Pick the one that fits your platform and your taste.

phdlogview, the upstream codebase, is GPLv3. Any work derived from a GPLv3 project must also be GPLv3 — that's how the license is designed to work. The Mac App Store's licensing terms are fundamentally incompatible with GPLv3 (the App Store imposes additional restrictions on redistribution that GPLv3 explicitly forbids), so GPL'd apps cannot ship through the App Store. Direct distribution from macobservatory.com is the right answer for a GPL'd app — the binary is still notarized, hardened, and runs sandboxed.

No. There aren't any locked features in Ephemeris and there won't be — that would make the app non-free in spirit even if it remained free in license. The Patreon exists for people who want to support open-source work and help fund the next utility. Donating gets you the satisfaction of having paid for something you believed in. That's it.