Mocked up observation planning tool (aka phase 2 tool)
Observers generate observing blocks “prior” to the night
Live demo by Tyler of draft UI
Carlos: how handle orbital ephemerides?
Luca: TBD
Carlos: need to incorporate features of the guide star tool
Carlos: need to be able to upload own finder chart
Carlos: visibility plot for targets
Josh: need diff tool for OBs
Jim: editable Obs during execution? e.g. want to change exposure time during execution because got on target late and need to finish before handover
Carlos: how does this change acquisition?
Will provide info to user (e.g. OA or observer), not take over control
2:04
Words from John
John
Concerns or questions on return to site?
FY22 planning in full swing
2:05
Words from Jim
Jim
Jim gone starting tomorrow for a week, randy back on Monday, John covering operations calls in the mean time
2:06
Instrument Tech / Engineer Coverage
Josh
No grand plan yet
Grant is starting to transition to this new instrument ops role
SAs are welcome to come up and work on instrument PMs with Grant
Filling these roles is a high priority
Grant: typical progression to instrument tech is from electronics tech, but our current ETs and senior, so this would not be a step up
InstTech is tough to find based on our past experience
Jim: will this change KNIT/ITL priorities?
2:20
VNC connection monitor process (noc2). Do we need it?
Carlos
Was looking at vm-nirc2, found noc2 process. Scans who is connected to VNCs and when. Not running on deimos.
Kyle: past discussions say we don’t need alerts, but we do need log
Most systems have a tail of the log in a terminal somewhere
The KRO API shows observers asking for info on particular numbered account sessions
The original need/requirement for this came from fears during the early design stages of mainland observing. It’s solving a 20 year old problem, which may no longer be an issue.
