David's Astronomy Pages Notes - Session 1066 (2022-12-07)

Notes (S1065)

Notes Main

Home Page

Notes (S1067)

	Session Aims & Highlights
	- Observing Result  - Night Summary Plot  - Session Event Log
	Operational Issues
	- Critical Issues (0),  Major Issues (0),  Minor Issues (1),  Small Defects (2),  Continuous Improvement (0)
	Images from 2022-12-07 >>        [ Local Files >> ]

Session Aims & Highlights (2022-12-07)

Main aims

1. 29P/Schwassmann-Wachmann. Acquire further images of 29P/Schwassmann-Wachmann, as follow-up to images taken in last four sessions (S1061 - S1064) . Continue to look out for expanding coma following recent 4 mag outburst
2. Targets.  Acquire images of a selection of variable stars, nearby stars, comets & deep sky targets as allowed by sky conditions.
3. AstroMain.  Check new AstroMain version (3.59) for any issues introduced by several recent changes, bug fixes and additions.

 Equipment & Software

• 12" LX200 and ST-10XME
• 80mm APO and ZWO ASI 178MC
• CCDApp2, TheSky6, CCDSoft5, DeviceHub 6.6.1.1,  MeadeGeneric 1.3.5.414, UPB 1.5, ASCOM 6.6
• Pegasus UPB & Motor Focus, TCF-S
• SharpCap 3.2, PHD2  2.6.11dev2, deCONZ 1.18.2, ASCOM 6.6 SP1
   
• AstroMain 3.59, AstroPlan 1.35,   AstroShCap 1.3.12, AstroGuard 1.10.1
  AstroVOE 1.12.0  AstroSN 1.8.6,  AstroProtect 1.7,  AstroMove 1.9.7
  (AstroWeather 1.19.6, AstroAllSky 3.17.2,  AstroObsCam 1.11.1, AstroLaunch 1.10.5

Highlights

• 29P/Schwassmann-Wachmann.  Poor quality images acquired due to cloud. Further attempts to acquire images twarted by threat of rain/snow and cloud.
• AstroMain. No new issues in AstroMain 3.59, but fully automated operations weren't conducted due to adverse conditions and therefore weren't tested.

Notes:

• Very short session. Observatory only opened in an attempt to acquire new image of 29P/Schwassmann-Wachmann following lack of oppportunities in since Nov 29th due to cloud cover.  Forecast snow showers and poor detection of stars by AllSky Camera (due to dew inside the camera's hemisphere, water drops on the outside, and very bright moon) prevented the instigation of an automated session.   After waiting from 21:42 for the threat of rain/snow to reduce,  the Observatory session was closed at 22:38.  Post-midnight the Cloud Sensor detected a nice clear spell between 01:00 and 02:00 but it was too late to utilise. Even then AllSky star detection remained below 8-10 stars.

Summary Plots & Logs

Observing Plan

None

Observing Result

Dome & Scope Slewing Performance

Slew/Centering Performance

None

Guiding Performance

None

Sky Conditions (Locate Frames)

Night Sky Summary Plot Top axis: Sky Brightness at Zenith (in ADU/s) Lefthand axis: Local Time (hh LT). Righthand axis: Sun Altitude (degs)

Actual Weather vs Pre-Session Weather Forecast

Session Event Log

Time     Event Detail 21:22:28   CCDSoft Restarting CCDSoft being restarted (to set AutoSave No.) 21:22:55   Camera1 Connected SBIG Camera connected (set point -25°C) 21:22:57 Session Created Session Created (Live, 2022-12-07 S01066, ImageSaveNum: 1066001) 21:23:30   Scope Switched On Telescope Power has been switched on via UPB Powerbox. 21:25:13   Services Started Observatory Services started 21:28:28   Dome Opened Dome opened (opening time 46s) 21:28:47   Telescope Connected Telescope connected (TheSky6) 21:29:29     Target Started (1/1) Target started (1/1, 29P/Schwassmann-Wachmann) 21:29:43       Dome Unparked Dome unparked 21:33:27       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 21:34:03       Focusing Failed Foc1 focusing failed - star lost 21:42:34   Critical RainThreat Alert Critical Rain Threat Alert (Obs.Manager will close the Dome) 21:42:36     Target Completed Target partially completed (1/1, 29P/Schwassmann-Wachmann) 21:43:19   Dome Closed Dome closed (closing time 45s) 22:28:13 User Intervention User request to close and finish session 22:28:15 Session Closing Session closing 22:28:17   Dome Closed Dome already closed (closed at 21:43, closing time 45s) 22:28:36   Dome Parked Dome parked (parking time 14s), Az: 90.0 deg 22:29:55   Telescope Parked Telescope parked (parking time 75s) 22:30:10   Telescope State Handbox reads 'Scope parked Turn scope off.' 22:30:32   Telescope Switched Off Telescope Power has been switched off via UPB Switch. 22:31:46   Services Stopped Night Services stopped 22:31:49 Session Housekeeping Session Housekeeping started (Create Fits Summary, Transfer Files) 22:31:54 Session Finished Session Finished

Session Alerts & Alarms

Time     Type       Name Detail --             No Alerts                --

Back to Top

Operational Issues (2022-12-07, S1066)

• Critical Issues (0)
• Major Issues (0)
• Minor Issues (1)
• Small Defects (2)
• Continuous Improvement (0)
  

[ Prev | Next ]

Critical Issues

• None

Major Issues

• None

Minor Issues

• When using the 'Close/Finish Session'  Obs.Overseer reported a warning "Obs.Manager is pending in 'Housekeeping Stage 4'. When using the 'Close/Finish Session' to manually instigate the closing & finising of S1066 session the Obs.Overseer posted a warning "Obs.Manager is pending in 'Housekeeping Stage 4' (last cycle at 22:31:54)" to AstroMain's Console Screen and a little later a message saying that the Obs.Manager had resumed again (after 44s). Checking the session's report file tin the morning it therefore somewhat of a surprise that the warning message wasn't present.  Housekeeping had proceeded normally and the session conclude and finished.  Investigating showed that the warning message was posted to the '2022-11-07' General Session report file after the S1066 session had finished (scrolling back the message output in AstroMain's console form confirms this).   Logs confirm that '2022-12-07 S1066' session was finished at 22:31:57.04 and the '2022-12-07' general session directly reopened at 22:31:57.04.   The time of last reported cycle (22:31:54) corresponds to when the Obs.Manager was still handling final Housekeeping taks for live session was conducting' prior to Obs.Manager freezing , but Overseer only reported that ObsManager cycling is overdue at 22:32:08 '(Obs.Manager is pending (14s) in 'Housekeeping Stage 4'),  and later at 22:32:28 as being  frozen ('Obs.Manager is frozen (34s) in 'Housekeeping Stage 4'). So that explains why the message appears where it does in the report & log files.  So why could Obs.Manager have frozen in HouseKeepingStage 4 and only resumed again at  22:32:38 ('Obs.Manager has resumed again at 22:32:37 after 44 sec').  Code shows that  'Housekeeping Stage 4' (HousekeepingStageNo = 4), simply calls 'SetState_Finished()' routine. Whilst this routine sets Session State to 'SessionState.Finished' and sets szTargetName to 'Finished', it should but doesn't set gObsManagerSection = "Finished" (Now fixed in AstroMain 1.59.1).   Execution is presumed to have frozen in this routine, since ObsManagerSection would have been set to "Finished" immediately execution returned to main loop and was about execute code block when SessionState = SessionState.Finished.   It seems most-likely that ObsManager appeared to freeze (thought it reality it was still executing stuff) when reached the last code line in  'SetState_Finished()' and made a call to 'AssignObservatorySession(SessionType.General ..).  This is a lengthy routine and involves Restarting CCDSoft and setting up a new session.  It would seem it took around 44s to complete which is normal.   Having ObsManager tied up for this time runs counter to its design aims which is to be always actively checking and managing the whole observatory every 5s.   The operation to proceed to a general session should be spawned out to a separate thread, which the Obs.Manager then keeps on an eye on. A new SessionState.ResumingGeneral = 15 has been created for managing the time when resuming a general session again after a live session has completed.  Fixed in AstroMain 1.59.1. The operation to proceed to a general session is now spawned out to a separate thread via a call to AssignGeneralObservatorySessionByThread() , this is done as part of a extended code for handling session state '.Finished' that utilises a new 'FinishedSessionStageNo' variable.
  Fixed 2022-12-08 (Session, AstroMain 1.59.1)

Small Defects

• Information from Ad-hoc Target 1/1 (29P/Schwassmann-Wachmann) wasn't drawn on the Centering Chart.. Sessions are normally conducted by Job Executor working with a target list extracted from an Observing Plan, and the slew/centering details for each target are automatically addded to the Centering Chart.   Whilst chart was created and adhoc targets uses much of the same target execution code (OB) the details of slew/centering weren't added to the chart or they were but the updated chart wasn't saved to the .png picture file.    Other charts & data files (apart from Observing Results Chart, see below) were updated with Adhoc target results ok, in particular a data record (01066001 29P/Schwassmann-Wachmann 14.03 0.97 0.37) was written to the '(slew)' data file ok.  Slew & Centre Points are added to chart by calls to CChart.AddSlewPoint() and CChart.AddCenterPoint() routines from the OB.CentreTarget() routine.  'CentreTarget' is executed when conducting an 'Ad-Hoc Target acquisition and report and log files indicate no problems during slew/centre operations.  Message written to target's TargetInfo chart demonstrate that at least  CChart.AddSlewPoint() must have been called.   Code shows that  CChart.SaveChartToFile() occurs once in CentreTarget() routine but is in only executed if TIS.Mode = "QSO".  Further more CChart.AddCenterPoint() in only called when TIS.Mode = "QSO".    TIS.Mode is only set once in the current code and that is where it is set to "QSO" when retrieving a plan. So it is likely that for this Ad-Hoc Target with no prior retrieval of a plan the TIS.Mode was either "" or Nothing and therefore Centre information wouldn't have been added to the chart and the chart with Slew Point wouldn't have been saved to file. Fixed in AstroMain 1.59.1 by removing the TIS.Mode = "QSO" condition check.
  Fixed 2022-12-08 (AstroMain 1.59.1) 
   
• Ad-hoc Target 1/1 (29P/Schwassmann-Wachmann) wasn't added to Session Observation table in database. AdHoc target should have been added as a partially completed target in the session observation table but wasn't, and therefore does appear on the Session Results chart. Target is recorded in Session Events table (Started, Critical Rain/Snow Threat, Target Partially Completed). Because the Ad-Hoc Target is submitted from RunTakeObjectOB_New() routine rather than the ExecuteQueue() routine that would be apply for a normally submitted Target, it goes through different follow-up code. Whilst it writes ''Target Completed    Partialy Completed" to target's TargetInfo chart, and  records "Target partially completed" in session events table,  it doesn't record the Observation in the Database using the codelines 
    QsoSequenceID = QsoSequenceID + 1
    ObservingDB.InsertObservation(T, Session.ID, QsoSequenceID)
  Fixed in AstroMain 1.59.1.
  Fixed 2022-12-08 (AstroMain 1.59.1) 

• None

[ Prev | Next ]

Back to Top