This page will outline efforts to develop a "Hello World" version of Obs. Status Sharing by "end of summer" 2023. "end of summer" ~= Autumnal Equinox = September 23, 2023 
High level design diagram
Component Descriptions
GBT data sender - will retrieve GBT schedule data and send to Obs Status DB as schedule data becomes available. Schedule data is usually available well in advance of 20 minutes prior to observation, but schedule can change.
VLA data sender - will retrieve VLA schedule data and send to Obs Status DB as schedule data becomes available. VLA schedule is not currently fixed 20 minutes prior to observation. Will require coordination with Science Ops, but if 20 minute commitment can be agreed schedule data is available to send to Obs Status DB.
Obs Status DB - will aggregate GBT and VLA schedule data for query by API process. Will be hosted on VLA database server. Growth is not anticipated to be that large even over a few years. Schema needs finalization, but proposed columns are:
site - GBT or VLA
effective datetime UTC - used to determine effective schedule when previous schedule has been updated.
obs start datetime UTC
obs end datetime UTC
RA of source
Dec of source
tracking rate of instrument
frequency range of observation (in Hz or MHz)
text field (for notes)
API process - will expose REST interface to SpaceX. API process will receive request from SpaceX, query Obs Status DB for GBT and VLA observation status data and format and send response to SpaceX. API format to be finalized. Interface security needs to be finalized. API process will be deployed on a VLA web server.
Tasks
1) Finalize DB schema and deploy DB.
2) Finalize API process security requirements and document here.
3) Finalize API format and document here.
4) Develop GBT data sender.
5) Develop VLA data sender.
6) Develop and deploy API process.
Open Questions
1) How will the exposed interface be secured?
2) Which VLA web server will host the API?
3) Will VLA observational data be fixed 20 minutes in advance?
4) What VLA will send to DB and expose in the API during Maintenance and Test periods (or when OST is not used)?
General Notes
- "tracking rate of instrument": to distinguish between sidereal vs non-sidereal tracking (TBD)
- The API component units need to be defined (ISO 8601 for UTC date-time, RA+Dec in degrees, etc), and API component units need to be easily translatable from DB column data types.
- At this initial phase, the Operators are not interacting with this service (i.e., it need to be fully automated)
VLA Notes
- Even if VLA Operations agree to set targets 20 minutes in advance, there is no guarantee that observations will end on time (for example, due to a sudden change in weather conditions or hardware failure).
- Manual observation scripts can be read, but may not meet the 20-minute advance notice.
- The VLA executes multi-band observations. For example, Super Novae explosions can be characterized by all VLA bands, with just a few minutes of separation between each band. The "frequency range of observation" needs to be compatible with what the API consumer are expecting.
- The VLA data sender needs to be per scan instead of per SB. Flux and polarization calibrators are usually far from Science target field, and some SBs have Science Targets in different fields.
- For the VLA, the initial 10 minutes of observation are critical. It is when the Observers are instructed to set the Attenuation gains. If the flux of a satellite changes the this setting, all the Observation block can be compromised (TBD).
- The array configuration is not relevant (TBD).