The Telescope Net cloud server accumulates calibrated photometry measurements from every active node, batches them under the network’s AAVSO observer code, and POSTs the resulting Extended File Format document to the AAVSO WebObs API. No manual formatting or uploading is required — once your credentials are configured, the pipeline handles everything from quality filtering through audit-trail archiving. This page walks you through configuring those credentials, verifying the output format, and submitting your first live batch.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/ManiFed/TTN/llms.txt
Use this file to discover all available pages before exploring further.
Prerequisites
Before submitting to AAVSO you need:- An AAVSO observer code (OBSCODE) — register free at aavso.org
- Your AAVSO username and password — the same credentials you use to log in to the AAVSO website
- The cloud server running with at least one active node that has delivered measurements
First Submission — Step by Step
Set AAVSO credentials in cloud/config.yaml
Open The
cloud/config.yaml and fill in your observer code and login credentials. The username and password fields support environment variable expansion — you can set them directly or reference env vars:observer_code field is required for any submission. The username and password fields are required to POST live data to WebObs.Verify the Extended File Format (dry run)
Run The command prints a synthetic observation for the known variable BW Tau with your observer code filled in, so you can verify the header and data fields look correct before touching live data.
check-aavso to confirm credentials are configured and to print a formatted test observation. No data is submitted at this stage.Check active nodes
Confirm the network has registered nodes that are sending measurements:The output shows node count, online/offline status, the measurement queue size, and the AAVSO credential summary. Look for at least one node listed as
ONLINE and a non-zero pending measurement count.Trigger alert ingestion
Force the pipeline to ingest new variable-star alerts, score all targets, and regenerate observation plans immediately instead of waiting for the hourly background loop:The command reports new/updated/expired alerts per source, the number of node×target pairs scored, and the number of plans generated.
Run a night's observations
Connect a node agent to its Seestar telescope and allow it to execute the night’s observation plan. The node uploads each photometry result to the cloud as measurements are completed. You do not need to do anything manually during the night.
Preview the AAVSO batch (dry run)
Before committing to a live POST, inspect the exact Extended File Format document that would be sent to WebObs:The command runs the batch pipeline with
dry_run: true, saves the formatted file to cloud_data/aavso_batches/, and prints the first 40 lines to the terminal. No data is POSTed to AAVSO.Submit live
Once you are satisfied with the batch preview, submit to AAVSO WebObs:This command forces
dry_run: false for this run only — it does not modify config.yaml. The batch is POSTed to https://www.aavso.org/apps/webobs/submit/ and the raw HTTP response is saved alongside the submission file.Admin CLI Reference
| Command | Description |
|---|---|
status | Node count, measurement queue depth, AAVSO batch history, config check |
ingest | Trigger alert ingestion + scoring + plan regeneration immediately |
batch | Dry-run preview of the pending AAVSO batch (prints format, does not POST) |
submit | Live AAVSO submission (ignores config.yaml dry_run setting) |
check-aavso | Verify credentials config, print a formatted test observation |
nights | Generate or backfill night summaries for all active nodes |
generate-code sub-command
--config PATH with any command to point at a non-default config file:
AAVSO Extended File Format
Each submission is a plain-text document following the AAVSO Extended File Format spec. The pipeline generates one document per batch run and saves it before any POST attempt.| Field | Value | Notes |
|---|---|---|
NAME | Target name from VSX | Commas replaced with spaces |
DATE | Barycentric Julian Date (BJD_TCB) | 6 decimal places |
MAG | Calibrated magnitude | 3 decimal places |
MERR | Magnitude uncertainty | Includes Poisson + zero-point scatter |
FILT | Filter name | e.g. CV (clear visual) for Seestar |
TRANS | NO | Not transformed to standard photometric system |
MTYPE | DIFF | Differential photometry |
CNAME | ENSEMBLE | Ensemble of comparison stars used |
CMAG | na | No single comparison star magnitude |
KNAME | na | No check star |
KMAG | na | |
AMASS | Airmass | 2 decimal places; na if not available |
GROUP | na | |
CHART | VSP chart ID or na | Set via aavso.chart_id in config |
NOTES | Pipeline diagnostics | fwhm, snr, comp, zp_scatter, node, quality, fits |
Quality Gates
The pipeline applies automatic quality gates before including a measurement in a submission batch. A measurement must pass all of the following checks:SNR > 20
Signal-to-noise ratio must exceed 20. Low-SNR measurements indicate poor sky conditions, thin cloud, or target at the edge of detection.
Uncertainty < 0.3 mag
Magnitude uncertainty (Poisson + zero-point scatter) must be below the AAVSO quality ceiling of 0.30 mag.
≥ 3 comparison stars
Ensemble differential photometry requires at least three comparison stars. The pipeline queries AAVSO VSP first, falling back to Gaia DR3.
Airmass < 3.0
Observations at very high airmass suffer heavy atmospheric extinction and colour-dependent errors. Hard cut at 3.0.
poor are skipped by default. To include them, set aavso.submit_poor_quality: true in config.yaml.
Phase 0 success criterion: One observation accepted by AAVSO with magnitude agreeing within 0.15 mag of the known value for the target.
Audit Trail
Every submission — whether dry run, live POST, or rejected — generates a full audit trail under theaavso.audit_dir directory (default: cloud_data/aavso_batches/):
_response.txt file contains the raw HTML or JSON returned by WebObs and is the first place to look when a submission is rejected.
REST API Equivalents
If you need to trigger ingestion or replanning programmatically (for example, from a cron job or CI script), use the admin API endpoints directly:server.admin_key in cloud/config.yaml (typically sourced from the CLOUD_ADMIN_KEY environment variable).