Skip to content

Onboarding

This page is for telescope owners — universities, research groups, and educational institutions — who want to bring an observatory onto the Skynet Global Observatory.

It covers two things:

  1. Why partner with Skynet — what you gain, and what you keep control of.
  2. What the onboarding flow looks like end-to-end — the concrete steps from "we're interested" to "our telescope is taking observations through Skynet."

If you're a researcher looking to use telescopes on Skynet rather than contribute one, see the Observers section instead.

Why partner with Skynet

Skynet is an end-to-end, API-first observing platform that connects telescopes, researchers, educators, and students into one global ecosystem. Joining Skynet lets your observatory:

  • Reach a global user base without giving up local control. Skynet's scheduling layer matches incoming observation requests to telescopes that can fulfill them, and your access-control policies decide who's eligible.
  • Stay productive year-round. Idle time on your telescope can be made available to partner organizations, exchange programs, or the Skynet community — at your discretion — instead of going unused.
  • Run educational programming through a turnkey platform. Classroom integrations, lab-style observing assignments, and student accounts come out of the box. Academic observatories get a real audience for their instruments.
  • Participate in coordinated science. Skynet powers kilonova searches, supernova monitoring, asteroid tracking, exoplanet surveys, and alert-driven follow-up campaigns. Partner observatories earn publication credit on resulting science.
  • Integrate heterogeneous hardware. SkyNode supports a wide range of optical and radio instruments via plugin drivers; common combinations (ASCOM mounts, MaxIm cameras, off-the-shelf weather sensors) work without custom code. See the device wiring pages for current driver coverage.
  • Keep authority over your telescope. You decide who can submit observations to your queues, how time is prioritized, when the telescope takes manual override, and what data goes public. Skynet is the coordination layer; it is not a replacement for your control system.

The platform follows the AILA standard, which is what lets a federation of differently-designed telescopes behave as one coordinated instrument.

What you keep control of

Joining Skynet does not transfer ownership or operational authority. Every participating observatory retains:

  • Hardware ownership — the telescope, mount, instruments, and site are yours.
  • Access policy — which users, organizations, or consortiums can submit observations, and how their requests are prioritized.
  • Queue configuration — the ordered list of observing queues on each telescope, their prioritization model (static, schedule-based, or usage-based), and who can hold time on each.
  • Operational windows — operational constraints (weather, sun altitude, battery, storage, custom interlocks) that gate when the telescope is eligible to take observations.
  • Manual control — at any time, the telescope's controlAuthority can be set to manual, suspending automated scheduling and giving the local operator full control.

Skynet's job is to coordinate; your observatory's job is to operate.

Onboarding flow

The realistic path from interest to first automated observation looks like this. Steps marked (staff) are completed by Skynet operators on your behalf; steps marked (you) are owner-driven.

1. Get in touch — (staff)

Contact Skynet (contact@skynetgo.org) to start the conversation. We discuss your hardware, science goals, network expectations, and how your observatory fits into the broader federation. There's no application form to fill in at this stage.

2. Create user and organization records — (you)

Sign up at the Skynet web app. Your university or institute creates an organization record; you and other operators are added as members.

  • The organization owns the observatory record (created in step 3).
  • Roles within the organization control who can edit observatory settings, manage telescope queues, grant access, and so on. RBAC is fine-grained; see Entities for the model.

3. Provision the site and observatory records — (staff)

Sites and observatories are admin-provisioned today (POST /v1/sites and POST /v1/observatories are not exposed; only edits via PATCH). Skynet staff create:

  • A Site record for the physical location (lat/lon, elevation, country, optional IAU code).
  • An Observatory record on that site, owned by your organization.

Once the records exist, the rest of the configuration — name, slug, description, gallery, weather sensors, public/private visibility, operational constraints — is editable through the observatory settings UI.

Why this is staff-only: Sites and observatories anchor scheduling, location-aware ephemerides, and resource reservations; mis-provisioning them has wider blast radius than mis- provisioning a telescope. Staff-driven provisioning is the stable model for the foreseeable future. Self-service site / observatory creation is on the long-term roadmap but not in any current milestone.

4. Register telescopes — (you)

For each telescope at the observatory, create a Telescope record via POST /v1/telescopes or the dashboard. A Telescope ties together a mount, optional enclosure, a set of devices (cameras, filter wheels, focusers, OTAs, …), and an ordered list of observing queues.

The full Telescope schema is at developers/schemas/Telescope.md; the owner-facing view is at Telescope.

5. Install and pair SkyNode — (you)

SkyNode is the agent that runs at your site and bridges your hardware to Skynet. Install it on a machine that can talk to your devices, then OAuth- pair the install with the hub. Pairing creates a SkyNodeInstallation record bound to your telescope (or to the observatory, for observatory- level deployments).

See SkyNode → Overview for the install path and configuration reference.

6. Wire up devices in SkyNode — (you)

In the SkyNode local GUI's configuration page, declare each physical device (mount, camera, filter wheel, focuser, OTA, enclosure, weather sensor, …). For each, choose the driver, set connection parameters, and verify the device comes online. Skynet currently ships drivers in three families:

  • ASCOM — mounts, cameras, filter wheels, focusers, enclosures.
  • MaxIm DL — cameras and filter wheels.
  • Native — GBTwenty mount; AAG CloudWatcher, Aurora Eurotech, Boltwood I/II, Cumulus, and Davis WeatherLink weather sensors.
  • Simulator — every device type has a simulator driver so you can rehearse a configuration before hardware is on site.

The full list lives in apps/sky-node-desktop/backend/sky_node/drivers/; per-device-type wiring guides are under SkyNode → wiring. Receiver and radio-backend drivers are interface-only at present.

7. Configure access — (you)

Decide who can use the telescope.

  • Observing queues — set up one or more queues per telescope (ToO, general observing, maintenance, education, …). Each queue has its own prioritization model and access grants.
  • Telescope access grants — grant read/update/delete authority over the telescope itself to specific users, organizations, or groups.
  • Observing accounts — entities can aggregate one or more queues across telescopes into a single observing account, which is what observers submit requests against.

See Telescope access for the model.

8. Run a shakedown observation — (you)

With the telescope active and queues configured, submit a test observation against your own observing account. Verify that:

  • SkyNode picks up the task from the hub.
  • The mount slews, the enclosure opens (or the operator opens it manually), and the camera/receiver acquires.
  • Results are uploaded and visible in the observation detail page.

9. Go live — (you)

Flip the telescope's isAvailable flag to true (and isPublic if you want it discoverable to all Skynet users). Open up queue access to the intended audience. From here forward, the telescope is operating as a member of the network.

What's next

If something here is wrong or out of date, please flag it — onboarding flow is the part of the docs that decays fastest as the platform evolves.