David's Astronomy Pages Notes - Session 1456 (2026-09-27)

Notes (S1455)

Notes Main

Home Page

Notes (S1457)

	Session Aims & Highlights
	- Observing Result  - Night Summary Plot  - Session Event Log
	Operational Issues
	- Critical Issues (1),  Major Issues (1),  Minor Issues (3),  Small Defects (8),  Continuous Improvement (1)
	- Figures (0)
	Images from 2026-09-27  >>
	CCDSoft Camera Issues in Session S1456
	2026-09-28
	AllSky/Weather Computer Failure (2026-09-28)
	2026-09-30
	Potential AllSky/Weather Computer Replacement

Session Aims & Highlights (2026-09-27)

Main aims

1. Targets.  Acquire images of a selection of variable stars, nearby stars, comets & deep sky targets as allowed by sky conditions.

 Equipment & Software

• 12" LX200 and ST-10XME
• 80mm APO and ZWO ASI 178MC
• TheSky6 6.0.0.65, CCDSoft5 5.0.201, DeviceHub 7.1.0.4707, MeadeGeneric 1.3.12.522, UPB 3, PulsarDome 6.4.0.0
• Peg-Unity 2.12, Peg-Focuser 2.12, Peg-Switch 2.12, TCF-LSI 3.3.5
• SharpCap 3.2.6482, PHD2 2.6.14, Siril 1.4.2, deCONZ 2.18.2, ASCOM 7.1.0.4707
   
• AstroMain 3.83.12, AstroPlan 1.47.2, AstroShCap 1.3.23, AstroGuard 1.13.2
  AstroMag 1.5.12, AstroVOE 2.0.1, AstroSN 1.16.2, AstroProtect 1.7, AstroMove 1.18.4
  AstroAllSky 3.28.6, AstroWeather 1.30.4, AstroObsCam 1.14, AstroNorthCam 1.13.1, AstroLaunch 1.14.9

Highlights

• Targets. 4/19 planned targets were completed. 3 targets failed due to CCDSoft Camera Issues whilst other targets failed due to cloud / session suspension.
•  Dome. No issues open/closing shutter. Dome was successfully parked at the end of the session.

Notes

• .

Summary Plots & Logs

Observing Plan

Observing Result

Dome & Scope Slewing Performance

Slew/Centering Performance

Guiding Performance

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) Note:  The NorthCam Star Count line is unreliable and should be ignored (The AstroNorthCam 'Find' Star method is producing many false positives from clouds)

Actual Weather vs Pre-Session Weather Forecast

Session Event Log

Time     Event Detail 00:04:13 Session Monitoring AutoStart monitoring for Live Session opportunity between 00:04 & 05:29 00:04:18   AutoStart Delayed Session delayed due to rain 00:04:33 Session AutoStarting Session autostarting (00:04) 00:04:39 Session Created Session Created (Live, 2026-09-27 S01456) 00:04:42   CCDSoft Restarting CCDSoft being restarted (to set AutoSave No.) 00:05:01   Scope Switched On Telescope Power has been switched on via UPB Switch 00:06:45   Services Started Observatory Services started 00:06:54 Observatory (Auto) Observatory placed in Fully-Automated Mode 00:06:56   AutoStart Delayed Session delayed due to rain 00:06:58 Session Pending Session pending (2026-09-27) 00:07:01 Session Initiating Session initiating (2026-09-27) 00:07:22   Camera1 Connected SBIG Camera connected (Set point -20°C) 00:07:26   Plan Requested Observing Plan requested from AstroPlan (1.47.2) 00:07:57   Plan Loaded Observing Plan loaded to queue (PlanID: 1257) 00:08:37   Telescope Connected Telescope connected (TheSky6) 00:09:02 Session Equilibration Session ready to Open Dome 00:09:47   Dome Opened Dome opened (Opening time 45s, Zigbee 40s) 00:09:52 Session Running Session running 00:09:54   Queue Started Observing Queue started (19 targets selected) 00:10:01     Target Started (NrZen) Target started (Focus Field 23, HIP 113729) 00:10:18       Dome Unparked Dome unparked 00:16:48       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 00:19:16       Focusing Completed Foc1 AutoFocus Completed (Profile No 1, wide) 00:21:11       Focusing Completed Foc1 AutoFocus Completed (Profile No 1) 00:21:19       Focusing Started-Foc2 Foc2 Focusing Started (Secondary Scope, using ShCap) 00:23:03       Focusing Completed Foc2 AutoFocus Completed (Profile No 2, wide) 00:24:49       Focusing Completed Foc2 AutoFocus Completed (Profile No 2) 00:25:09     Target Completed (NrZen) Target completed (Focus Field 23, HIP 113729) 00:25:14     Target Started (1/19) Target started (1/19, NGC 7331 w/SN2026aaiv) 00:28:43       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 00:31:05       Focusing Completed Foc1 AutoFocus Completed (Profile No 3) 00:47:07     Target Completed Target completed (1/19, NGC 7331 w/SN2026aaiv) 00:47:11     Target Started (2/19) Target started (2/19, Nova Aql 2026 (Nova)) 00:51:24       Focusing Skipped Foc1 focusing skipped - star is lost (TCF-LSI) 00:57:49     Target Completed Target completed (2/19, Nova Aql 2026 (Nova)) 00:58:34     Target Started (3/19) Target started (3/19, 61 Cyg) 01:01:06       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 01:03:00         SBIG Camera Take Image failed (Command timed-out) 01:03:19         Camera1 Connected SBIG Camera connected (Set point -20°C) 01:03:53       Focusing Completed Foc1 AutoFocus Completed (Profile No 4) 01:07:53     Target Completed Target completed (3/19, 61 Cyg) 01:07:57     Target Started (4/19) Target started (4/19, GCVS BL Lac) 01:11:21       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 01:13:27       Focusing Completed Foc1 AutoFocus Completed (Profile No 5) 01:17:18     Target Completed Target completed (4/19, GCVS BL Lac) 01:17:22     Target Started (5/19) Target started (5/19, GCVS Z And) 01:20:48       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 01:22:20         SBIG Camera Take Image failed (Command timed-out) 01:22:39         Camera1 Connected SBIG Camera connected (Set point -20°C) 01:23:54         CcdCamera Frozen CcdCamera appears to be frozen at around 01:23 in section 'GetProperty / Status' 01:29:12       Focusing Failed Foc1 focusing failed - star lost 01:30:17       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:31:12       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:32:07       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:33:09       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:34:04       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:35:06       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:36:04       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:36:18     Target Failed (5/19) Target failed due to no images (5/19, GCVS Z And) 01:36:22     Target Started (6/19) Target started (6/19, UGC 622 w/AT2026mjx) 01:37:51       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:39:30       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:41:09       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:42:48       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:45:45       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:46:41       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:47:36       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:48:32       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:49:27       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:49:41     Target Failed (6/19) Target failed due to no images (6/19, UGC 622 w/AT2026mjx) 01:49:45     Target Started (7/19) Target started (7/19, WDS GRB 34) 01:51:08       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:52:46       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:54:24       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:56:03       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:58:57       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 01:59:54       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 02:00:50       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 02:01:45       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 02:02:41       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 02:03:36       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 02:04:31       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 02:04:46     Target Failed (7/19) Target failed due to no images (7/19, WDS GRB 34) 02:04:50     Target Started (8/19) Target started (8/19, M31 w/AT2026aabo) 02:06:08       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 02:07:46       CCDSoft Issue CCDSoft has encountered an image save issue [0000] 02:08:21   Critical Cloud Alert Critical Cloud Alert (Obs.Manager will close the Dome) 02:08:23   HardSuspend Called Hard Suspend called due to Critical Conditions (cloud) 02:08:34     Target Aborted (8/19) Target aborted (8/19, M31 w/AT2026aabo) due to cloud 02:08:36   Queue Paused Queue paused for Session Suspension 02:08:38 Session Suspending Session suspending 02:09:26   Dome Closed Dome closed (Closing time 50s, Zigbee 43s) 02:09:31 Session Suspended Session suspended 02:16:01     Target Cancelled Target cancelled (8/19, M31 w/AT2026aabo) due to too few stars 02:33:57     Target Cancelled Target cancelled (9/19, GCVS U And) due to too few stars 02:49:11     Target Cancelled Target cancelled (10/19, 11P/Tempel-Swift-LINEAR) due to cloud 03:08:56     Target Cancelled Target cancelled (11/19, LEDA 166393 w/AT2026ljo) due to cloud 03:27:40     Target Cancelled Target cancelled (12/19, 88P/Howell) due to cloud 03:44:24     Target Cancelled Target cancelled (13/19, 220P/McNaught) due to cloud 03:54:42     Target Cancelled Target cancelled (14/19, GCVS ER UMa) due to cloud 04:15:02     Target Cancelled Target cancelled (15/19, NGC 3310 w/SN2026sqf) due to cloud 04:37:02     Target Cancelled Target cancelled (16/19, UGC 4316 w/SN2025advo) due to cloud 04:59:22     Target Cancelled Target cancelled (17/19, UGC 4424 w/AT2026aaee) due to cloud 05:12:30     Target Cancelled Target cancelled (18/19, GCVS RZ LMi) due to cloud 05:43:20     Target Cancelled Target cancelled (19/19, NGC 3437 w/SN2026kie) due to cloud 05:43:24   Queue Completed Job Queue completed 05:43:26 Session Closing Session closing 05:43:28   Dome Closed Dome already closed (closed at 02:09, closing time 50s, zigbee 43s) 05:44:38   Dome Parked Dome parked (parking time 60s), Az: 90.0 deg 05:45:31   Telescope Parked Telescope parked (parking time 42s total) 05:45:54   Telescope State Handbox reads 'Scope parked Turn scope off.' 05:47:03   Telescope Switched Off Telescope Power has been switched off via UPB Switch. 05:47:44   Services Stopped Night Services stopped 05:47:47 Session Finishing Session Finishing started (Create Fits Summary, Transfer Files) 05:48:04     Dome (Find Park) Find Park started (Search Az 88.0 to 92.0°, Step 0.2°, Narrow) 05:48:52     Dome Find Park found (Best Park Az 90.3°) 05:48:58     Dome Dome has been synced at park position (Az 90.0°, Adjustment: -0.3°) 05:49:00   Dome Parked Dome parked 05:52:02   Dome Charging Dome is parked and well charged (97%, 15.0v) 05:52:04 Session Finished Session Finished

Session Alerts & Alarms

Time     Type       Name Detail 01:03:00 Red Alert SBIG Camera Alert Take Image failed (Command timed-out) 01:22:20 Red Alert SBIG Camera Alert Take Image failed (Command timed-out) 01:24:00 Red Alert CcdCamera CcdCamera appears to be frozen (last cycle at 01:23:54) in section 'GetProperty / Status' 01:30:17 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:31:12 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:32:07 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:33:09 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:34:04 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:35:06 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:36:04 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:37:51 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:39:30 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:41:09 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:42:48 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:45:45 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:46:41 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:47:36 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:48:32 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:49:27 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:51:08 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:52:46 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:54:24 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:56:03 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:58:57 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 01:59:54 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 02:00:50 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 02:01:45 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 02:02:41 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 02:03:36 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 02:04:31 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 02:06:08 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 02:07:46 Red Alert CCDSoft Image file [0000] hasn't been saved to disk, possible CCDSoft issue 05:52:02 Yellow Alert Dome Charging Dome is parked and well charged (97%, 15.0v) 06:51:10 Green Clear Dome Charging Dome is parked and re-charging Ok (12mA)

Back to Top

Operational Issues (2026-09-27 S1456)

• Critical Issues (1)
• Major Issues (0)
• Minor Issues (3)
• Small Defects (8)
• Continuous Improvement (1)
• Figures (0)
  

[ Prev | Next ]

Critical Issues

• AllSky/Weather Computer has failed (2026-09-28) which means that no Observing Sessions can be run until issue is resolved. The AllSky/Weather Computer (Toshiba Dynabook Satellite Pro C50-E-102 Laptop, 8 GB, 512 GB, purchased in Aug 2020, see notes, 2020-08-23) failed on 2026-09-28. It had been running normally and was powered via its C Adapter, when it suddenly stopping sending files to Observatory website at around 18:10 and couldn't be connected to over a remote VNC connection. A visit to the Observatory showed that computer was off and its screen was black.  It couldn't be restarted by pressing its on-button - there was no sign or sound of any electrical/computer activity when pressing its on button for 30s+ and trying several times.  The AC Adapter was checked and shown to be supplying DC power at normal voltage (see AllSky/Weather Computer Failure, 2026-09-28) The AllSky/Weather Computer is critical to the operation of the Observatory, and has been taken to a local computer repair shop on 2026-09-29 for diagnosis and to see if it can be fixed, otherwise a new replacement computer will need to be identified and purchased (the current computer is 6 years old). It is likely that it will be some 5 - 25 days or more before Observatory Sessions can be recommenced,  and therefore the issue is rated as critical. If a new computer is necessary it is probable that one will be chosen with slightly higher spec (16 GB, 1 TB) but will still need to have an RJ-45 Ethernet Port (see Potential AllSky/Weather Computer Replacement, 2026-09-30). Changes were made to the Observatory setup to patch the CloudSensor through to the Observatory Computer on 2026-10-01 which together with changes to the AstroMain and AstroWeather programs allowed Observing Sessions to be successfully made on the nights of 2026-10-01 (S1457) and 2026-10-02 (S1458) despite the absence of the AllSky/Weather Computer.
   Being worked around  2026-10-01+ (AllSky/Weather Computer, Observatory)

Major Issues

• Multiple targets failed to acquire images as RestartCCDSoftCamera() method was unable to resolve underlying SBIG Camera issue.  Three targets, Target 5/19 (GCVS Z And), Target 6/19 (UGC 622 w/AT2026mjx) & Target 7/19 (WDS GRB 34) failed to acquire any CCD Images due to a CCDSoft Camera issue. Other targets would have likely also failed to acquire CCD images if session suspension hadn't occurred at 02:08, including Target 8/19 (M31 w/AT2026aabo).   Analysis shows that the RestartCCDSoftCamera() routine being used to fix the CcdCamera.TakeImage failures failed to resolve the underlying SBIG Camera Issue as it didn't resort to the more agressive fix involving a reset SBIG Camera operation using a Power Off/Power On sequence.   RestartCCDSoftCamera() was introduced in AstroMain 3.77.2 on 2025-07-25 (see Continuous Improvement ticket S1343A) as an improvement on existing RestartCCDSoft() routine. The routine is designed to call RepairUsbCamera() to fix a camera issue by making an initial Lite attempt at fixing an issue by resetting the USB Port to SBIG Camera, before making a more agressive attempt at fixing issue by resetting the SBIG Camera itself, however the RepairUsbCamera() operation is immediately exiting due to a condition check on the bRestartingCCDSoft flag being True, which it is inevitably True due to the routine being called from RestartCCDSoftCamera().
   Fixed 2026-10-01 (Session,  AstroMain 3.83.14, CCDSoft, SBIG Camera)

Minor Issues

• CCDSoft Alerts and Focus Frame Failures whilst performing Focus Profile (01:22 to 01:29). Whilst taking focus profile for Target 5/19 (GCVS Z And) there were CCDCamera alerts and failed focus frames.  Problems began on Focus Frame 9/14 at 01:22  The USB Port to SBIG Camera was automatically reset and camera connection initial reestabished, and 3 further focus frames were acquired (9/14*, 10/14, 11/14)  but problems reoccurred on frame 12/14 and CCDCamera was deemed to be frozen at 01:24:00.  There was then a further attempt to Restart CCDSoft Camera, but this didn't seem to include resetting power to SBIG Camera.  The focus profile was ultimately recorded as failed due to lost Focus Star (no focus star in 3 successive images),  but the failure was really due to lack of 3 successive images because of Focus Frame failures.  Analysis shows that the issue was due to there being an underlying CCDSoft/SBIG Camera issue and a failure of RestartCCDSoftCamera() & RepairUsbCamera() routines to agressively reset the SBIG Camera.  Whilst a temporary fix has been introduced on 2026-09-29 in AstroMain 3.83.14 Beta to make TakeFocusFrame() use the original RestartCCDSoft() routine instead of the newer RestartCCDSoftCamera() routine,  the longer term fix is the same as that required to resolve the Major Issue above.
   Issue understood 2026-09-30 (Session,  AstroMain 3.83.14, CCDSoft, SBIG Camera)
  
  Examining TakeFocusImage() shows that in event of a Frozen CcdCamera condition
     (bCcdImageAcquired = False Or bImageTakenOk = False ) and (CCDCamera.CycleIsPending Or bTakeImageTimedOut )
  the "Image failed    (Frozen CcdCamera)" message is reported and 'RestartCCDSoftCameraByThread(RestartCCDSoftMode.FrozenCcdCamera)' is called.  This runs RestartCCDSoftCamera(RestartMode) but is a code path that doesn't toggle the SBIG Camera's Power state, and therefore seemingling doesn't resolve the underlying hardware issue.  The alternate code path calling 'RestartCCDSoftByThread(RestartCCDSoftMode.FrozenCcdCamera, vcNull)' to run RestartCCDSoft(RestartMode, ) which will reset the SBIG Camera is only called  when 'bSbigDriverException=True.   Fixed in AstroMain 3.83.14 by modifying TakeFocusImage() routine to always use 'RestartCCDSoftByThread()' that will reset the SBIG Camera by toggling its power, instead of calling 'RestartCCDSoftCameraByThread()' which doesn't reset the SBIG Camera. [The RestartCCDSoftCameraByThread() & new RestartCCDSoftCamera() methods were added 2025-07-25 (CI S1343A, see notes ) .
   
• Multiple Red CCDSoft Alert were raised with message "Image file [0000] hasn't been saved to disk" (01:30 - 02:07). Between 01:30:17 & 02:07:46 there were 29 Red CCDSoft Alerts with the message "Image file [0000] hasn't been saved to disk, possible CCDSoft issue" . These were preceeded by a SBIG Camera red alerts at 01:30 and 01:22:20 with the message "Take Image failed (Command timed-out)" and a CCDCamera red alert at 01:24:00 with the message "CcdCamera appears to be frozen (last cycle at 01:23:54) in section 'GetProperty / Status".  Log file shows attempts to perform camera connection with errors "Exception in CCDCamera.Connect  - SBIG driver: Camera not found".  Problems began at 01:22:00 whilst taking Focus Frame 9/14 for Target 5/19 (GCVS Z And).  The USB to SBIG Camera was reset and camera connection reestabished, and 3 further focus frames were acquired, but problems reoccurred and CCDCamera was deemed to be frozen at 01:24:00.  There was then a further attempt to Restart CCDSoft Camera, but this didn't seem to include resetting power to SBIG Camera.  Session was suspended at 02:08 with the problem unresolved, but no longer giving any errors.  The problem seems SBIG USB Camera not listed in DeviceManager  to be that ObsOverseer kept diagnosing the issue as being due to the 'SBIG USB Camera not listed in DeviceManager'  which it was able to fix each time by resetting the USB Port, checking that power to SBIG camera was on and making an attempted connection to the camera. However this continuous sequence of attempted fixes, doesn't get to the route problem, which can only be resolved by turning off/turning on power to the SBIG Camera. An issue with TakeFocusImage has been fixed in AstroMain 3.83.14 which should help prevent/reduce the cascade of issues that follow on. The 'Image file [0000] hasn't been saved to disk' alerts are generated via calls to SignalUnsavedImageFile() which is called from CameraOps.TakeCam1LocateFrame(),  OB.TakeMainImage(), PlateSolve.ImageAndLink(), and TelescopeOps.MakeAutoMappingRun(). The multiple 'Image file [0000] hasn't been saved to disk' alerts in S1456 session are produced by OB.TakeMainImage() due to SignalUnsavedImageFile() not being encased within the 'If Flag.bRestartingCCDSoft = False' block.  Fixed in AstroMain 3.83.14
   Fixed 2026-09-29 (AstroMain 3.83.14)
   
• RestartCCDSoftCamera() and Job Executor() report messages are partly interlaced (01:29 to 02:08). Following earlier issue with CCDCamera whilst taking a Focus Profile for Target 5/19 (GCVS Z And) the report messages from successive RestartCCDSoftCamera operations and Job Executor operations became partly interlaced.  The issue seemed to begin at 01:29 following an abort at end of Focus Profile operation, when a Restart CCDSoft Camera operation was kicked off whilst Cam1 Focus Position was being restored, and Pre-Imaging Sky Conditions were being reported , and continued through the remainder of Z And imaging and tthrough the course of the locate & imaging operations for Targets 6/19,7/19,8/19, and only ended due to session suspension. Example of a sequence
     Taking 15s image (B)...    **        (Continued below)
 > Obs.Overseer               Warning   Task in TakeImage/Start is taking a long time? (01:30)
 **Taking 15s image (B)...        
   Restart CCDSoft Camera               2026-09-28 01:30  (Local, BST)                                          > Job Executor                Alert     2026-09-28 01:30  (Local, BST)
> Job Executor                Alert     CCD Image [0000] has not saved to disk. Restarting CCDSoft...   Restarting CCDSoft Camera   Info      Closing USB Port first due to unresponsive CCDSoft   Switch Off SBIG USB         Ok        USB Port to SBIG Camera is off (01:30:19)
  Apart from the failure of RestartCCDSoftCamera() to resolve the underlying hardware issue, the principal interlacing issue is that the two '> Job Executor' lines including the plan to Restart CCDSoft are written after the ReportSubTitle announcing the commencement of 'Restart CCDSoft Camera' operation.
   Fixed  2026-09-29 (AstroMain 3.83.14+)

Small Defects

• AstroMain falsely reporting 'Target Aborted' at end of target imaging (00:47).  After successfully completing the image for each of first 4 planned target AstroMain is reporting 'Target Aborted' with the message "Target has been aborted".  In each case the 'Target Aborted' report is invalid, as in each case the target is successfully acquirere and confirmed as such in the 'Result' section with messages like "Target finished   (5 / 5 frames completed)" . Looking back the issue has affected sessions as far back as S1401 (2026-03-06)  which corresponds to the introduction of AstroMain 3.80.21. The issue was not present in session S1400 (2026-03-04) which was running AstroMain 3.80.20.The  The 3.80.21 version incorporated a fix to issue "Ad-Hoc Target wasn't recorded in Session Observations table" issue and a reported fix to 'The target result and post-imaging conditions are also not recorded in the Report File' (see notes, 2026-03-04).  Examining current AstroMain code shows that the following lines, added on 2026-03-05 containing a flaw in the condition logic which is responsible for generating the 'Target has been aborted' message for every target that is completed normally.
    If jobAbort = False And jobAbortTarget = False Then ' removed abort=false conditions
       Report(Tab2 + "Target Aborted", "Info", "Target has been aborted") ' added 2026-03-05 (SD S1400)
  End If
  Issue fixed in AstroMain 3.83.14 by correcting the condition line as follows:
     If jobAbort or jobAbortTarget Then
       Report(Tab2 + "Target Aborted", "Info", "Target has been aborted") ' added 2026-03-05 (SD S1400)
  End If
   Fixed 2026-09-29 (AstroMain 3.83.14)
   
• Subsequent Focus Frame failures are being reported as "Image failed (Other reason)". During Target 5/19 (Z And) there were issues with CCDSoft/SBIG Camera (see Minor Issue above). Whilst first Focus Frame failure (9/14) was reported as "Image failed (Frozen CcdCamera)", subsequent failures (12/14, 12/14*, 13/14, 13/14*, 14/14, 14/14*) were reported as "Image failed (Other reason)".  The condition leadings the 'Other reason' branch will have been
    (CcdImageAcquired = False Or bImageTakenOk =False)
  and CCDCamera.CycleIsPending = False And bTakeImageTimedOut = False and bSbigDriverException =False and jobAbort = False
    Logs record the following for the 12/14 frame failure.
    01:23:12.51 | Start   TakeImageAsync Try   | Starting TakeAsync() routine
  01:23:13.24 | Call    TakeImage      Try   | Calling CCDCamera.TakeImage()
  01:23:20.47 | (error) GetProperty    Fail  | Get IsExposureComplete timed out after 2s
  01:23:20.54 | (warn)  CcdCamera      Info  | CcdCamera is Pending (6s) ' in section 'GetProperty / Status'
  01:23:24.31 | (ok)    CcdCamera      Info  | CcdCamera has resumed (cycle = 9.8s)
  01:23:30.42 | (error) GetProperty    Fail  | Get IsExposureComplete timed out after 2s
  01:23:30.56 | (warn)  CcdCamera      Info  | CcdCamera is Pending (6s) ' in section 'GetProperty / IsExposureComplete'
  01:23:45.59 | (warn)  CcdCamera      Info  | CcdCamera is Pending (21s) ' in section 'GetProperty / Status'
  01:23:50.59 | Check   JobQueue       Info  | Task in TakeFocusImage/TakeImage is taking a long time? (Camera.TakeImage)
  01:23:50.59 | (warn)  CcdCamera      Info  | CcdCamera is Pending (26s) ' in section 'GetProperty / Status'
  01:23:54.37 | (ok)    CcdCamera      Info  | CcdCamera has resumed (cycle = 30.1s)
  01:24:00.57 | (error) GetProperty    Fail  | Get IsExposureComplete timed out after 2s
  01:24:00.57 | (alert) CcdCamera      Alert | CcdCamera is frozen (30s) in section 'GetProperty / Status'
  01:24:00.58 | (fail)  TakeImageAsync Fail  | Image not acquired
  01:24:00.58 | (fail)  TakeFocusFrame Fail  | Image failed (Other reason)
  This shows that there wasn't an immediate failure in TakeASync, that CCDCamera.TakeImage was called and CCDCamera was frozen and Image was not acquired.  So why didn't call to TakeImageAsync() set bTakeImageTimedOut =True.  The reason is that the 'If Now() > TimeOutPoint' cod  block, that is intended to set it,  is skipped due entry it the earlier 'If CCDCamera.FrozenSecs > 30' block  . The 12/14 reporting case is fixed in AstroMain 3.83.14 by adding a 'bTakeImageTimedOut =True' line to the 'If CCDCamera.FrozenSecs > 30' code block. This will result in the expected "Image failed (Frozen CcdCamera)" report message.  For other failures (12/14*, 13/14, 13/14*, 14/14, 14/14*) the TakeImageAsync logs the failure is due to 'Camera is not connected' , and the "Image failed (Other reason)" report message is still deemed appropriate.
   Fixed 2026-09-29 (AstroMain 3.83.14)
   
• ObsOverseer is giving a false impression that CcdCamera has resumed when CCDSoft.Camera is likely still frozen or running at a impractically slow speed (01:23).  Currently in AstroMain 3.83.13 and earlier versions a pending or frozen CcdCamera thread is deemed to have resumed as soon as it the thread starts a new iteration of its functioning loop.  This may be a true resumption of the thread or just the release of a single COM call to CCDSoft.Camera. In the above case CCDCamera become pending at around 01:23:14 and indicates a possible freeze in CCDSoft.Camera.   At 01:23:24 the CcdCamera is logged as having resumed with the mesage "CcdCamera has resumed (cycle = 9.8s)". Whilst factually correct, semantically it is incorrect as the CcdCamera is immediately recorded to have problems, and again becomes pending from 01:23:25 onwards until the the CCDCamera is deemed frozen at 01:24 and upon reaching a timeout the image is deemed to have failed. It is proposed that when CcdCamera has been pending or frozen, a second iteration of the loop is required before declaring that CcdCamera has resumed.  A 'TentativelyResumed' flag and 'TentativelyResumedTimeStamp' shall be set on start of the 'first' iteration and only confirmed as a resumption if the start of a 'second' iteration occurs with 2s.  If not the 'TentativelyResumed' flag is reset, and ObsOverseer start waiting to see two iterations again. Fixed attempted in AstroMain 3.83.14
   Fix attempted 2026-10-01 (AstroMain 3.83.14 / ObsOverseer)
   
• Unable to install CloudSensor's Prolific USB-Serial Adapter on Observatory Computer (2026-10-01).  As part of a project to explore the possibility of running a live Observatory Session whilst the AllSky/Weather Computer is unavailable, an attempt was made to patch a USB connection between the CloudSensor's USB cable from the AllSky/Weather Computing Bay to the USB Hub attached to the Observatory Computer. A USB Extension couldn't be made to work (no COM Port appearing in DeviceManager) and instead the Cloud Sensor was connected via an intermediary small USB  Hub. This produced an entry in Device Manager/Ports called 'Please install corresponding PL2303 driver to support Windows 11'.  Clicking on Properties/Drivers/Update Driver/Search Automatically For Drivers', gives a dialog "Windows has determined that the best driver for this device is already installed' : Prolific USB-to-Serial Comm Port'.  Hardware IDs for the USB-Serial Adapter are :
       USB\VID_067B&PID_2303&REV_0400
       USB\VID_067B&PID_2303
  Copilot considered that the problem is that the Adapter's PL2303HXD chip is blocked by Windows 11 and stops the Device from being installed.  'PL2303 Legacy Update' program was downloaded  from GITHUB : johnstevenson/ pl2303-legacy and the legacy 3.3.111.152 driver version installed.  The entry changed to 'Prolific USB-to-serial Comm Port (COM 11)' and its Properties show Driver Date 2010-03-12, Version 3.3.11.152.  Serial Port was set to COM11 in the Cloud Sensor III program and the Cloud Sensor connected ok.  It is unclear how fragiile the setup is and whether there will be issues using the Device when the Computer is next restarted next. 
  Provisionally fixed attempted in AstroMain 3.83.14
   Provisionally fixed 2026-10-01 (Observatory Computer, Cloud Sensor III)
   
• AstroMain unable to access CloudSensor data (2026-10-01). As part of a project to explore the possibility of running a live Observatory Session whilst the AllSky/Weather Computer is unavailable, CloudSensor and AstroWeather were installed on the Observatory Computer. After resolving a driver issue associated with the CloudSensor's USB-Serial Adapter, the cloud sensor was connected to CloudSensor III software on COM11.  AstroWeather was able to see the Cloud Sensor data & display it in textboxes and seemingly write Cloud Sensor records.   However AstroMain failed to recieve and use CloudSensor records.  This is likely a TCP/IP port issue at either the AstroWeather or AstroMain end (or both). AstroWeather is normally expects that it is sittting on Laptop 7 and sending records to Laptop9 rather than sitting on Laptop9 and sending records to Laptop 9. There may be guards in place so that records can't be written to Laptop9 when AstroWeather isn't on Laptop7 to avoid interference with a live session, or the AstroWeather is sending cloud sensor records to a port that is different to the one that AstroMain expects.  Examining code shows that AstroMain in listening for records on Port 4005. Reviewing code shows that AstroWeather doesn't send out any CloudSensor (Cs) records when running on LAPTOP9. This is fixed in AstroWeather 1.30.5 using the modified condition :
   If Environment.MachineName = "LAPTOP7" Or Environment.MachineName = "LAPTOP9" Or
   (Environment.MachineName = "LAPTOP11" And .HostName <> "LAPTOP7" And .HostName <> "LAPTOP9") Then
   Fixed  2026-10-01 (Observatory Computer, AstroWeather 1.30.5)
   
• AstroMain unable to access CloudSensor data (2026-10-01). As part of a project to explore the possibility of running a live Observatory Session whilst the AllSky/Weather Computer is unavailable, CloudSensor and AstroWeather were installed on the Observatory Computer. After resolving a driver issue associated with the CloudSensor's USB-Serial Adapter, the cloud sensor was connected to CloudSensor III software on COM11.  AstroWeather was able to see the Cloud Sensor data & display it in textboxes and seemingly write Cloud Sensor records.   However AstroMain failed to recieve and use CloudSensor records.  This is likely a TCP/IP port issue at either the AstroWeather or AstroMain end (or both). AstroWeather is normally expects that it is sittting on Laptop 7 and sending records to Laptop9 rather than sitting on Laptop9 and sending records to Laptop 9. There may be guards in place so that records can't be written to Laptop9 when AstroWeather isn't on Laptop7 to avoid interference with a live session, or the AstroWeather is sending cloud sensor records to a port that is different to the one that AstroMain expects.  Examining code shows that AstroMain in listening for records on Port 4005. Reviewing code shows that AstroWeather doesn't send out any CloudSensor (Cs) records when running on LAPTOP9. This is fixed in AstroWeather 1.30.5 using the modified condition :
   If Environment.MachineName = "LAPTOP7" Or Environment.MachineName = "LAPTOP9" Or
   (Environment.MachineName = "LAPTOP11" And .HostName <> "LAPTOP7" And .HostName <> "LAPTOP9") Then
   Fixed  2026-10-01 (Observatory Computer, AstroWeather 1.30.5)
   
• CloudSensor values became unstable (2026-10-01). As part of a project to explore the possibility of running a live Observatory Session whilst the AllSky/Weather Computer is unavailable, CloudSensor III program were installed on the Observatory Computer and a connection established with the CloudSensor Head. After recording stable cloudsensor values for a 2 hour period, the values suddenly became unstable and jumped between good and bad or null values (see Fig 1).  Values became stable again after restarting CloudSensor III program.  Issue seemed to resolve itself after restarting computer.
   Resolved itself 2026-10-02 (Observatory Computer, CloudSensor / CloudSensor III )
   
• Unable to Open Observatory Dome due to Light Conditions (2026-10-01). As part of a project to explore the possibility of running a live Observatory Session whilst the AllSky/Weather Computer is unavailable, CloudSensor and AstroWeather were installed on the Observatory Computer and are feeding Light, Clairty and Rain values to AstroMain/Observatory.  Although Light values are 0 and Clarity values are 32-33, AstroMain guards wouldn't allow the Observatory Dome to be opened 'due to Light Condiions'. Running in debugger showed that the reason for returning MustClose=True was that Sun Altitude had the value 0.   Sun Altitude is normally provided by AstroAllSky Scorecard/Synopsis but as AstroAllSky is not running due to current non-availability of the AllSky/Weather Computer. In this situation AstroMain must supply Sun Altitude.  Fixed in AstroMain 3.83.14, using checkbox (cboxComputeSunAltLocally.checked=Tue) and checkbox (cboxUsingAllSkyComputer.checked=False) to control Sun Alt handling and suppress NoWeatherData guards.
   Fixed  2026-10-01 (Observatory Computer, AstroWeather 1.30.5)
   
• Check whether DomeCharging Follow-up /  Green AllClear alerts are operating as intended. AstroMain 3.83.xx introduced a new feature whereby after raising a Yellow or Red DomeCharging alert at the end of a session a followup Green all-clear Alert would be raised when charging was finally detected. Since introducing the feature its noticed that the Green AllClear is raised around 57-58 mins after the Yellow/Red Alert, rather than some number between say 5 and 45 mins, and there is a suspicion that there is a UT time/Local time issue in someway as the time gaps is close to 60 mins.   Tracing has been added to AstroMain 3.83.14 and logs from '2025-10-02 S1457' and '2025-10-02'  confirm that the green all clear are truely being raised around 57-58 mins after the Yellow/Red Alerts.  The Pulsar log suggests that the original Yellow Alert at 05:43:25 with message "Dome is parked and well charged (96%, 15.0v)" should have been a green alert with message saying that dome was parked and charging at 15 mA. and if not the post-session all-clear should have been issued a lot earlier than it did. (such as shortly after 05:44 green alert).  Why this is the case stilll needs some explanation.  Whilst ObsManager routine doesn't explicity have a UT/Local Time issue there might be an issue with parsing & using Pulsar Dome records.  Time stamps in the Pulsar Log File are Local Times. The logic condition in ObsManager's handleFinishingStage7 that indicates charging is ok is
     If DomeRecord.LastChargeTime > LastDomeParkTime Then
  Examining this:  LastDomeParkTime is a local time (  LastDomeParkTime = Now() ) but DomeRecord.LastChangeTime comes from DomeRecord.DateX which is a Universal Time
   ( .DateX = DateTime.UtcNow() ' changed from Now() to UtcNow() 2026-03-30 (MI S1412)).
  Fixed in AstroMain 3.84.2 by converting LastDomeParkTime to Universal Time
    If DomeRecord.LastChargeTime > LastDomeParkTime.ToUniversalTime Then
   Fixed 2026-10-02 (AstroMain 3.84.2)

Continuous Improvement

• Identify a means to run an Observing Session without the presence of the AllSky/Weather Computer.  Normally the execution of an observing session is critically dependant on the presence of a connected AllSky/Weather Computer with its suite of functioning software (including CloudSensor, CumulusMX, AstroWeather, AstroAllSky, AstroNorthCam, AstroObsCam). However with the recent failure of the computer and the possibility that a replacement may not be up and running for some 3 weeks,  it is proposed to look at the possibility of running an observatory session without the presence of the AllSky/Weather Computer.  This will include :
   - running a temporary USB Cable Extension to connect the CloudSensor to the Observatory Computer
 - installing CloudSensor III software on the Observatory Computer
 - installing AstroWeather on the Observatory Computer
 - modifying AstroMain and potentially AstroGuard to operate using the local CloudSensor data, and absence of AstroAllSky data.
 - dealing with various guard rails in AstroMain
  These items were addressed today (2026-10-01) and a trial Observing Session (S1457, 2026-10-01) was commenced in the same evening.
   Done  2026-10-01 (Observatory, AstroMain 3.83.14. CloudSensor, AstroWeather 1.30.5)

[ Prev | Next ]

Back to Top Issue,  Back to Top

[ Prev | Next ]

Back to Top Issue,  Back to Top

2026-09-28

CCDSoft Camera Issues in S1456

Analysis of 

RepairUsbCamera()

RepairUsbCamera() is a AstroMain routine that is called from 6 references and is designed to
  a) make an initial lite attempt to repair SBIG USB Camera by resetting the USB Port and if that fails
  b) make a more aggressive repair by reseting the SBIG Camera itself by using a PowerOff/Power On sequence

The routine contains a global condition guard that prevents it from making a Usb Camera repair when either the bRestartingCCDSoft flag or the bRestartingSbigCamera flag is raised.
This prevents the more aggressive camera repair from being made when called by RestartCCDSoftCamera() routine, as this explicity operates with a raised bRestartingCCDSoft flag.
and thus prevented the resolution of underlying SBIG Camera during multiple targets in Session S1456.

The obvious fix is to remove the guard, but it is unclear what the implications would be in removing the guard for the other 5 references that call the routine.

RepairUsbCamera() is called from the following 6 references:

• CheckCameraConnection()
  - itself called by 3 references:
   - CheckCameraTest() ,called by btnCodeTest_Click()
   - PerformTestStartupWithCamera() twice,  called by btnTestStartUpWithCamera_Click()
   
• ConnectCamera()
  -  itself called from 7 references
   
• ReconnectCCDSoftCamera()
  - itself called by  3 references
  - ExecuteQueue()
  - TakeAdhocTests()
  - RunPhd2Tests()
   
• EnsureSbigCameraIsOperational()
  -  itself called by 1 reference:
   - ConnectCamera()
   
• StartSbigCamera()
   - itself called by 2 references:
    - AutostartSession()
   - RestartCCDSoftCamera()
   
• RestartCCDSoftCamera()
   - itself called by 1 reference
   - RestartCCDSoftCameraByThread() which is called by 14 references

Back to Top

AllSky/Weather Computer Failure (2026-09-28)

The AllSky/Weather Computer has failed (2026-09-28) which means that no Observing Sessions can be run until the issue is resolved.

The AllSky/Weather Computer (Toshiba Dynabook Satellite Pro C50-E-102 Laptop, 8 GB, 512 GB, purchased in Aug 2020, see notes, 2020-08-23) is 6 years old.

It had been running normally and was powered via its C Adapter, when it suddenly stopping sending files to Observatory website at around 18:10 and couldn't be connected to over a remote VNC connection. A visit to the Observatory showed that the computer was off and its screen was black.  It couldn't be restarted by pressing its on-button - there was no sign or sound of any electrical/computer activity when pressing its on button for 30s+. Each attempt to start the computer failed.  The AC Adapter was checked and shown to be supplying DC power at normal voltage.

The AllSky/Weather Computer is critical to the operation of the Observatory, and has been taken to a local computer repair shop on 2026-09-29 for diagnosis and to see if it can be fixed, otherwise a new replacement computer will need to be identified and purchased (the current computer is 6 years old). It is likely that it will be some 10 days or more before Observatory Sessions can be recommenced.

 If a new computer is necessary it is probable that one will be chosen with slightly higher spec (16 GB, 1 TB) but will still need to have an RJ-45 Ethernet Port (see notes Potential AllSky/Weather Computer Replacement (2026-09-30)

Other notes on AllSky/Weather Computer

Update 2026-10-03
Changes were made to the Observatory setup to patch the CloudSensor through to the Observatory Computer on 2026-10-01 which together with changes to the AstroMain and AstroWeather programs allowed Observing Sessions to be successfully made on the nights of 2026-10-01 (S1457) and 2026-10-02 (S1458) despite the absence of the AllSky/Weather Computer.

Update 2026-10-05
Failed computer is still at local Computer Repair Shop for diagnosis/repair.

Back to Top

2026-09-30

Potential AllSky/Weather Computer Replacement (2026-09-30)

The observatory's AllSky/Weather Computer which is 6 years old failed on 2026-09-28 and has been taken to a local computer repair shop on 2026-09-29 for diagnosis and to see if it can be repaired. If it can't be fixed a new replacement computer will need to be identified and purchased.

Due to introduction of NorthCam operations and the associated realtime image processing including MetaFrame and Object Detection, the computer is somewhat under powered and there is always a shortage of disk space.  Therefore if a new computer is necessary one will be chosen with higher spec (Intel Core 5 210H instead of  16 GB RAM instead of 8 GB, 1 TB drive instead of 500 GB). It will still need to have an RJ-45 Ethernet Port instead of relying on a USB-Ethernet Adapter which demands USB resources placing it in competition with multiple USB devices used by the computer

Leading candidate replacement:

Lenova ThinkBook 16 Gen 9.
 - Intel Core 5 210H Processor (E-cores up to 3.60 GHz P-cores up to 4.80 GHz)
 - Windows Home 64,
 - 16 GB RAM (DDR5-5600MT/s (SODIMM) - 2 x 8 GB),
 - 1 TB SSD (M.2 2242 PCIe Gen4 QLC), 
 - 16" WUXGA (1920 x 1200)
 - USB-C (USB 10Gbps) with Power Delivery 3.0 & DisplayPort 2.1
 - USB-C (Thunderbolt 4, USB 40Gbps)
 - 2 x USB-A (USB 5Gbps) always on
 - Ethernet (RJ45)
 - HDMI 2.1
 - £1189.99  (Sept deal)

https://www.lenovo.com/gb/en/configurator/cto/?bundleId=21USCTO1WWGB3

Update 2026-10-06
Decision to be made on the purchase of replacement computer once repairability of old computer is finally determined.

Back to Top