laurence/itelescope
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Verify Cen A, book CrA on T8 for 22 Jul evening, rebuild the rate model

Browse source 
Cen A (reservation 749302, T32) completed at 11:16 UTC, 34 minutes early
because the plan finished, not because of a fault: NGC5128 images are on
t32.itelescope.net:8032 and transaction 851344 billed 160 points. Balance
is now 2,097 of the original 2,638.

That second bill settles the billing question the 20 Jul note left open.
T32 billed 160 for a 120 min plan (2.00 h x 80) and T59 billed 381 for a
180 min plan (3.00 h x 127); both land exactly on the plan's exposure
total and neither lands on wall-clock time. So billing is per imaging
minute as originally documented, and the x1.6 wall-clock multiplier is
withdrawn from CAMPAIGN.md, TODO.md and NOTES.md. What is actually wrong
is the rate card's per-scope numbers, so each scope's rate now has to be
derived from its first real bill. The practical consequence is the
opposite of the old warning: the campaign is now heading to UNDER-spend
by roughly 800 points, so later planning sessions should add or lengthen
runs rather than trim them.

Queue #2 (Corona Australis on T8) is booked at last. The original
01:35-04:35 slot was confirmed dead by probing New.aspx, which answered
"Conflicting reservation. Start time must be later than 2:25 AM" (user
hajo's reservation 749207, exactly as the previous session predicted).
Rather than take the leftover 02:30-05:30, where the target sits 3.5 to
6.5 hours past the meridian, the run moved to the next night's evening,
2026-07-22 21:45 to 2026-07-23 00:45 SSO local, which brackets the ~22:30
culmination so all 115 minutes of imaging happen near the zenith. This is
the geometry of the previously rejected option (c) on the night of option
(b): (c) was only rejected because Cen A held the reservation quota, and
that expired when Cen A completed. Verified via Reservation/MySummary.aspx;
quota now 6:50 of 8:00.

The New.aspx probe is documented in plans/README.md as the way to test a
slot for conflicts, since the DayPilot grid renders client-side and shows
nothing to a plain HTTP fetch.
This commit is contained in:
Laurence 2026-07-21 12:43:11 +01:00
parent f94ecce678
commit cd3de71361
4 changed files with 105 additions and 29 deletions
Download patch file Download diff file Expand all files Collapse all files

9
plans/README.md
View file

@ -84,6 +84,15 @@ Reservation. Success = response script `ModalStatic.result("OK")` AND the bookin
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