itelescope/plans
Laurence 7bf834a184 Book a short-exposure core set for Cen A, and make it a campaign habit
Processing the 21 Jul Centaurus A data showed the nucleus is saturated: a
single 300 s luminance sub reads 65313 ADU in the core, so the deep stack
is clipped there and the core cannot be recovered by processing. The only
fix is more data at shorter exposures.

plans/hdrcore-t32.txt is that data: L 8x60s, 8x15s and 8x5s plus RGB
5x30s, all BIN2 so the frames register against the deep stack without
rescaling. The ladder spans a factor of 60 below the 300 s subs, which
covers the unknown true peak of the nucleus, and the RGB gives the core
its colour. 18.2 minutes of imaging, about 25 points.

Uploaded to T32 and verified byte-identical, then booked for the evening
of 22 Jul, 18:50-19:50 SSO local, which is the same window in which the
deep run actually succeeded (T32 has a 35 degree elevation floor and Cen A
is an evening target). Verified in MySummary; quota now 7:05 of 8:00.

The wider point is recorded in CAMPAIGN.md: bright targets need a short
set budgeted alongside the deep run. NGC 6744 has already been shot
without one, and 47 Tuc and the SMC in queue #5 will certainly need one,
a globular cluster core being the fastest thing there is to saturate.
2026-07-21 13:41:23 +01:00
..
catspaw-t8.txt Campaign plan files for every queued session 2026-07-18 23:25:54 +01:00
cena-t32.txt Campaign plan files for every queued session 2026-07-18 23:25:54 +01:00
cra-t8.txt Campaign plan files for every queued session 2026-07-18 23:25:54 +01:00
hdrcore-t32.txt Book a short-exposure core set for Cen A, and make it a campaign habit 2026-07-21 13:41:23 +01:00
ngc104-test.txt T33 first-light prep: 47 Tuc test plan and session runbook 2026-07-18 22:09:24 +01:00
ngc6188-haoiii-t59.txt Campaign plan files for every queued session 2026-07-18 23:25:54 +01:00
ngc6188-sii-t59.txt Campaign plan files for every queued session 2026-07-18 23:25:54 +01:00
ngc6744-t59.txt Drain campaign: spend the balance by 10 Aug, then close the account 2026-07-18 22:41:33 +01:00
ngc6752.txt Second free-session plan: NGC 6752 (Pavo globular) 2026-07-18 22:18:26 +01:00
README.md Verify Cen A, book CrA on T8 for 22 Jul evening, rebuild the rate model 2026-07-21 12:43:11 +01:00
scorpius-t70.txt Campaign plan files for every queued session 2026-07-18 23:25:54 +01:00
smc47tuc-t8.txt Campaign plan files for every queued session 2026-07-18 23:25:54 +01:00
tarantula-t32.txt Campaign plan files for every queued session 2026-07-18 23:25:54 +01:00

Observing plans and the T33 session runbook

ACP observing plans for iTelescope scopes, plus the procedure to run one on T33 (the free Siding Spring scope). Credentials are NOT in this repo: they live in the local claudetemp itelescope folder (creds.txt, username=/password= lines).

Plan format (ACP)

See ngc104-test.txt. Directives, then a target line: Name<TAB>RA_decimal_hours<TAB>Dec_decimal_degrees. Counts, intervals, binning and filters are parallel comma-separated lists. #shutdown parks safely at the end (iTelescope's own one-click plans do the same).

T33 endpoints (base http://t33.itelescope.net:8033, HTTP auth = iTelescope creds)

Purpose Path
Status JSON (times, obsStat, obsOwner) /ac/SystemStatus/asystemstatus.asp
Console text /ac/SystemStatus/aconsread.asp
Scope connect control /ac/SystemStatus/ascopeconn.asp
Shutter/roof status /ac/SystemStatus/ashutterctl.asp
My plan folder (list/upload/delete) /plans/qisback/aindex.asp, aupload.asp, adelfile.asp
Run a plan ("Acquire Images") POST /ac/Plans/plan.asp
My logs /logs/qisback/aindex.asp
Finished data data.itelescope.net

Upload: multipart POST to /plans/qisback/aupload.asp, fields File1 (the file) and DestPath=/plans/qisback. Verified working 2026-07-18; content round-trips exactly.

Run: the web UI posts the plan select to /ac/Plans/plan.asp; the select's value is the WINDOWS path C:\ProgramData\ACP\ACP Web Data\Doc Root\plans\qisback\<file>. Field names seen: plan, optional VPhot, AutoLogoff. NOT yet exercised live (observatory was closed, daytime); the first live session must confirm whether a scope-connect POST (ascopeconn.asp) is required first, and capture the exact response shape.

The 47 Tuc free-session test (ngc104-test.txt)

  • Target: NGC 104 / 47 Tucanae, RA 0.4015 h, Dec -72.0814 deg (circumpolar at SSO).
  • L 4x120 s, RGB 2x90 s each, Bin2: about 17 min exposure, about 24 min with overhead, inside the daily free 30 minutes.
  • Uploaded to /plans/qisback/ on 2026-07-18 and verified.

When to run

47 Tuc clears T33's 20 degree minimum elevation in the second half of the SSO night. SSO local = UTC+10; the good window is roughly 14:00-19:30 UTC (UK afternoon/evening). Sunrise at SSO was 06:14 local (20:14 UTC) at recon time; stop well before dawn.

Procedure

  1. GET asystemstatus.asp: confirm observatory open (obsStat) and no other user (obsOwner n/a). If someone is on, wait and retry; T33 is first-come.
  2. Confirm the plan file is still in /plans/qisback/ (aindex.asp).
  3. POST plan.asp with the plan's Windows path to start acquisition.
  4. Poll aconsread.asp (console) every minute or two: slew, centering, filter changes, exposures. The run self-terminates via #shutdown.
  5. Images land in /images/qisback/ on the scope server and then on data.itelescope.net; logs in /logs/qisback/.
  6. Record the session outcome in state/NOTES.md.

Abort path if something looks wrong: the web UI exposes an abort on the console page; locate it live before starting exposures (not yet mapped).

Reservations (verified working 2026-07-18)

Reservations live at http://reservations.itelescope.net ("Reservations Pilot"), reached from each scope's /ac/MenuItems/reservation-edit.asp iframe as ?t=<scope-id>&u=<username> (scope ids look like GRAS059 for T59, GRAS033 for T33; full list in the resources JSON on go.itelescope.net/Reservation/Overview.aspx, whose embedded DayPilot events also show everyone's bookings, roof/sun times, and the moon discount per night). No separate login: it trusts the u= parameter once a session cookie exists.

Creating one is a three-step WebForms dance against New.aspx?start=<ISO local>&end=<ISO local>&r=<scope-id> (times are OBSERVATORY LOCAL): (1) GET the form, (2) POST tokens + DropDownStartTime/DropDownEndTime (e.g. "12:05 AM"/"3:45 AM") + PlanToRunListBox= + RescheduleCheckbox

  • ButtonRefreshPlans=Refresh Plans, which re-renders with Confirm enabled, (3) re-POST the fresh tokens with the same fields + ReservationOKButton=Confirm Reservation. Success = response script ModalStatic.result("OK") AND the booking appearing in the grid: the modal also says "OK" on silent failure, so ALWAYS re-fetch the grid and look for the reservation id + username.

Availability probing (2026-07-21): a plain GET of New.aspx?start=...&end=...&r=... is a cheap, side-effect-free conflict check. The form comes back with the two time dropdowns populated for +/-60 min around the requested times, and if the slot collides with someone else's booking it also renders "Conflicting reservation. Start time must be later than H:MM AM". No message plus a full pair of dropdowns means the window is clear. This beats reading the DayPilot grid, whose event divs do not survive a plain Invoke-WebRequest fetch (they are rendered client-side).

Rules learned: maximum reservation length 4:00; recommended duration 1.5x total imaging time; the attached plan is auto-started by iTelescope at reservation start (no walk-in POST needed); RescheduleCheckbox auto-rebooks the identical timeslot on the first available night of the next 30 if the run does not happen. Delete/edit via Edit.aspx?id= from the grid.