Remote Imaging Setup

What “remote” means here

This article is about self-hosting your own rig, unattended, at a site you control — your own backyard, a pier in a field you own, or space you rent from a host but still run yourself. It is not about renting observing time on someone else's telescope. Services like Telescope Live sell that experience outright, and the same hosting companies referenced below for their technical know-how — Utah Desert Remote Observatories and Starfront Observatories — also sell hosted time on their own equipment as a separate business line. Whether a paid-hosting comparison deserves its own article is an open question this hub hasn't settled yet; nothing below assumes you've picked a side.

DD-019's site-setup guide maps a backyard rig into six subsystems and marks network and remote control as the one it names but doesn't detail. This article is that missing depth — specifically, the layer that has to work correctly on the one night you aren't standing next to the equipment.

The four things that must survive without you in the room

A rig you can babysit tolerates almost any failure — you notice, you walk outside, you fix it. A rig running unattended only tolerates the failures it can survive on its own, or that get flagged loudly enough for you to intervene remotely before real damage happens. That reduces to four systems, each covered here for the unattended-session angle only; the deeper mechanics of three of them are already owned elsewhere on the site.

Power that survives a mains blip

Astronomy.com's remote-imaging guide states plainly that most remote facilities require an uninterruptible power supply Astronomy.com. The point of a UPS here isn't to run the rig through an outage — it's to buy enough time for a graceful, automatic shutdown instead of a hard power loss mid-exposure or mid-slew. Schneider Electric's general UPS buying guidance — a generic reference, not an astro-specific one — describes basic units as typically covering roughly five to fifteen minutes of runtime for a safe shutdown, with extended-battery configurations running longer, which matters if the goal is bridging time for a generator to start rather than just closing files cleanly Schneider Electric.

Sizing the battery itself — how many watt-hours your particular mount, cooled camera, and mini-PC actually need to survive that shutdown window, and for how long — is DD-020's full job, not this article's; this section only establishes that a UPS belongs in a remote build at all.

Connectivity that survives a dropout

The shared starting point, before any specific tool: Astronomy.com recommends installing two different remote-access applications on the remote system, not one, so a single app failing doesn't strand the session Astronomy.com. Which two tools, and how they reach the rig, is where opinions genuinely diverge.

One more figure worth flagging rather than trusting outright: a low-authority blog, astrophotographyexpert.com, suggests aiming for at least 10 Mbps of upload and download bandwidth for a remote session astrophotographyexpert.com. No higher-authority source in this hub's research corroborates that number, so treat it as a loose starting point for a connection check, not a spec to build a bandwidth plan around.

A mount that knows where it is when power comes back

Two genuinely different approaches solve the same problem — what does the mount do if it loses power mid-session and comes back on with nobody there to re-align it.

The stronger approach is a mount built around absolute encoders, which read true axis position directly rather than counting steps from a known start point. Astronomy.com names the Astro-Physics Mach2GTO and the 10Micron series as remote-friendly for exactly this reason Astronomy.com, and Astro-Physics confirms the mechanism at the manufacturer level for its own mount: the encoders track axis position continuously, whether the mount is parked, unparked, powered, or unpowered Astro-Physics.

The alternative, for mounts without absolute encoders: define a fixed home position the mount returns to on a remote command after any restart, and add a pier-mounted camera so you can visually confirm where the OTA actually ended up before resuming — Starfront's own recommendation for exactly this gap Starfront Observatories. Buying a mount, and whether the encoder premium is worth paying for your own build, is our Mounts hub's job; this section only covers the remote-recovery angle.

Remote power cycling

Even a mount that recovers its own position, and a connection that survives a dropout, both depend on the equipment actually being powered. Astronomy.com recommends keeping a network-controlled power switch in the build specifically so a locked-up device can be power-cycled without walking outside Astronomy.com. Starfront makes the same case with a cheaper, consumer-grade version of the same idea — a WiFi-capable smart plug, naming a Kasa Smart Plug as one example, used to turn equipment fully off and back on from anywhere Starfront Observatories.

Two things this section deliberately doesn't re-teach: how a dew controller's own power behavior fits into that cycling — that's this hub's dew-control guide's territory — and what any given device actually draws once it's back on, which is the amp-hour guide's per-device tally.

Monitoring and failure recovery

The four systems above reduce, but don't eliminate, the chance something goes wrong while you're not watching. The last layer is knowing it happened at all.

Lunatico Astro's Good Night System (GNS) is a free smartphone app paired with a small PC watchdog program, with a native NINA plugin built by Nick Hardy Lunatico Astro. The watchdog doesn't need to understand your imaging software to be useful — it tracks session timers, catches process hangs, and specifically flags extended silence from the observatory PC, which could mean a power cut, a crash, or a network dropout, and sounds an alarm on your phone either way Lunatico Astro. This is a free download with no purchase or affiliate relationship attached — the rail link below earns this site nothing.

Roof-status monitoring is a related but separate piece, and it's worth stating correctly. An ASCOM Generic File SafetyMonitor driver, written by Nicolàs de Hilster, watches a plain text status file for a roof-open or roof-closed marker and reports safe or unsafe based on what it finds ASCOM Standards; dehilster.info. NINA reads that driver like any other equipment through its own Safety Monitor tab, and can pause or resume a running sequence off it two ways: NINA's own built-in safety-monitor loop conditions, or the separate Sequencer Powerups plugin, written by Marc Blank, which adds explicit when-becomes-unsafe and once-safe trigger conditions nighttime-imaging.eu; Sequencer Powerups plugin.

What the roof-status driver and the loop conditions or Sequencer Powerups triggers don't cover is the flip itself — the actual meridian-flip automation logic inside a sequencer. That's the Mounts & Tracking hub's meridian flip planning guide's job — distinct from this hub's existing Mounts hub pillar, which covers buying and payload only, not automation logic — and isn't re-taught here; this section is only about knowing the session is in trouble, not about executing the flip.

What this article does not cover

Consistent with the rest of this hub, several adjacent topics are named here and taught in full elsewhere — repeating them would duplicate, and likely drift from, the article that actually owns each one.

• Battery watt-hour sizing — the full per-device tally and chemistry math live in How many amp-hours do you need for a full night?
• Dew-controller mechanics, including the auto-vs-manual dispute — covered in full in Dew Control: Heaters, Controllers, and Power Draw.
• Cable routing and the meridian-flip service loop — this hub's cabling article is Planning Your Imaging Site: Power, Dew, and Cables.
• Meridian-flip automation logic itself — covered in full in the Mounts & Tracking hub's Meridian Flip Planning guide, distinct from this hub's existing Mounts hub pillar (which covers buying and payload only); not re-derived here.
• Buying a mount, and payload/derating math — the Mounts hub's job, including whether an absolute-encoder mount is worth its premium for your own build.
• Comparing paid remote-hosting services against self-hosting — flagged above as a possible future topic, not decided, and not covered here.