David's Astronomy Pages Notes - Session 1329 Attempt (2025-05-18)

Notes (S1328)

Notes Main

Home Page

Notes (S1329)

	Session Aims & Highlights
	- Observing Result  - Night Summary Plot  - Session Event Log
	Operational Issues
	- Critical Issues (1),  Major Issues (1),  Minor Issues (7),  Small Defects (8),  Continuous Improvement (10)
	- Figures (7)
	No Images from Session  >>
	Investigation - USB / COM Port Failures (S1329A)

Session Aims & Highlights (2025-05-18)

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, CCDSoft5, DeviceHub 7.0.3 RC3.4694, MeadeGeneric 1.3.12.522 , UPB 1.5,  Pulsar Dome Firmware 1.51 & Driver 6.3.10
• Pegasus UPB & Motor Focus, TCF-S 6.0.6
• SharpCap 3.2, PHD2  2.6.13, Siril 1.0.6, deCONZ 1.18.2, ASCOM 7.0.3 RC3
• [ DomeLink 1.0 / 1.1 - not used ]
   
• AstroMain 3.74.17,  AstroPlan 1.43.9,  AstroShCap 1.3.15, AstroGuard 1.10.6   (any new items or versions in bold)
  AstroMag 1.4.13, AstroVOE 1.15.1,  AstroSN 1.14,  AstroProtect 1.10.6,  AstroMove 1.16
  AstroWeather 1.27.9, AstroAllSky 3.23.5,  AstroObsCam 1.11.4 (not 1.11.5), AstroNorthCam 1.3.1, AstroLaunch 1.13.1

Highlights

• Targets.  0/12 planned target observations were completed due to early termination of session following series of issues including SBIG Camera Issue / Telescope Port Loss / & UPB Connection Loss.
• CCD Camera. There was issues with the CCDCamera freezing and SBIG Driver not found issues, that were difficult to resolve.
•   Dome. There was no issues opening/closing the shutter during the session. Dome closed and parked at end of session ok.

Notes

• Job Queue aborted by user at 23:47:08 after series of problems with Camera, UPB Powerbox, Telescope Com Port.
  and session finished early with acquiring any target images.
  

Summary Plots & Logs

Observing Plan

Observing Result

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

Session Event Log

Time     Event Detail 23:21:28 Session Monitoring AutoStart monitoring for Live Session opportunity between 23:21 & 01:46 23:21:32 Session AutoStarting Session autostarting (23:21) 23:21:53   CCDSoft Restarting CCDSoft being restarted (to set AutoSave No.) 23:22:20   Camera1 Connected SBIG Camera connected (Set point -15°C) 23:22:22 Session Created Session Created (Live, 2025-05-18 S01329, ImageSaveNum: 1329001) 23:22:27   Scope Switched On Telescope Power has been switched on via UPB Powerbox. 23:24:13   Services Started Observatory Services started 23:24:21 Observatory (Auto) Observatory placed in Fully-Automated Mode 23:24:24 Session Pending Session pending (2025-05-18) 23:24:26 Session Initiating Session initiating (2025-05-18) 23:24:34   Camera1 Connected SBIG Camera connected (Set point -15°C) 23:24:41   Plan Requested Observing Plan requested from AstroPlan (1.43.9) 23:25:06   Plan Loaded Observing Plan loaded to queue (Plan ID: 1114) 23:25:48   Telescope Connected Telescope connected (TheSky6) 23:26:12 Session Equilibration Session ready to Open Dome 23:26:57   Dome Opened Dome opened (Opening time 45s, Zigbee 40s) 23:27:42 Session Running Session running 23:27:45   Queue Started Observing Queue started (12 targets selected) 23:27:47     Target Started (NrZen) Target started (Focus Field 14, HIP 69068) 23:28:02       Dome Unparked Dome unparked 23:33:19       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 23:36:19   SBIG Camera Take Image failed (Command timed-out) 23:36:23   CCDSoft Restarting CCDSoft being restarted (attempt to fix frozen CcdCamera) 23:36:30   SBIG Camera Reset SBIG Camera being power-cycled 23:38:49   CCDSoft Restarting CCDSoft being restarted (attempt to fix frozen CcdCamera) 23:38:56   SBIG Camera Reset SBIG Camera being power-cycled 23:39:18   UPB Connection Powerbox Connection appears to have failed 23:39:33   TCF-S Switched Off TCF-S Power has been switched off via UPB Powerbox. 23:39:37   TCF-S Switched On TCF-S Power has been switched on via UPB Powerbox. 23:40:42   CCDSoft Restarting CCDSoft being restarted (user action) 23:40:49   SBIG Camera Reset SBIG Camera being power-cycled 23:41:53   Camera1 Connected SBIG Camera connected (Set point -15°C) 23:41:56   CCDSoft Restarting CCDSoft being restarted (attempt to fix frozen CcdCamera) 23:42:03   SBIG Camera Reset SBIG Camera being power-cycled 23:43:06   Camera1 Connected SBIG Camera connected (Set point -15°C) 23:43:40   CCDSoft Restarting CCDSoft being restarted (attempt to fix frozen CcdCamera) 23:43:48   SBIG Camera Reset SBIG Camera being power-cycled 23:44:03   TheSky6 Restarting TheSky6 being restarted (resolve unresponsive TheSky6) 23:44:28   Telescope Connected Telescope connected (TheSky6) 23:45:14       SoftSuspend Called Soft Suspend called due to Deteriorating Conditions (reducing clarity) 23:45:16   Critical Cloud Alert Critical Cloud Alert (Obs.Manager will close the Dome) 23:45:18   HardSuspend Called Hard Suspend called due to Critical Conditions (cloud) 23:45:24       SoftSuspend Cancelled Soft Suspend is cancelled due to improved conditions 23:45:29       SoftSuspend Called Soft Suspend called due to Deteriorating Conditions (reducing clarity) 23:45:39       Focusing Aborted Foc1 Focusing Aborted due to HardSuspend 23:45:41     Target Aborted (NrZen) Target aborted (Focus Field 14, HIP 69068) due to cloud 23:45:43     Target Aborted (1/12) Target aborted (1/12, NGC 2744 w/SN2025oq) due to Unknown Reason 23:45:45   Queue Paused Queue paused for Session Suspension 23:45:47 Session Suspending Session suspending 23:46:34   Dome Closed Dome closed (Closing time 50s, Zigbee 43s) 23:46:36 Session Suspended Session suspended 23:47:08 User Intervention User Intervention to abort job queue & switch back to Manual Mode 23:47:10   Queue Aborted Job Queue aborted 23:50:25   TCF-S Switched Off TCF-S Power has been switched off via UPB Powerbox. 23:50:29   TCF-S Switched On TCF-S Power has been switched on via UPB Powerbox. 23:53:08   Telescope Connected Telescope connected (TheSky6) 23:54:50   CCDSoft Restarting CCDSoft being restarted (user action) 23:54:57   SBIG Camera Reset SBIG Camera being power-cycled 23:56:01   Camera1 Connected SBIG Camera connected (Set point -15°C) 23:57:45 User Intervention User request to close and finish session 23:57:47 Session Closing Session closing 23:57:49   Dome Closed Dome already closed (closed at 23:46, closing time 50s, zigbee 43s) 23:58:39   Dome Parked Dome parked (parking time 45s), Az: 90.0 deg 23:59:25   Telescope Parked Telescope parked (parking time 43s total) 23:59:49   Telescope State Handbox reads 'Scope parked Turn scope off.' 00:00:39   Telescope Switched Off Telescope Power has been switched off via UPB Switch. 00:02:02   Services Stopped Night Services stopped 00:02:05 Session Finishing Session Finishing started (Create Fits Summary, Transfer Files) 00:02:12     Dome (Find Park) Find Park started (Search Az 88.0 to 92.0°, Step 0.2°, Narrow) 00:02:56     Dome Find Park found (Best Park Az 90.0°) 00:04:41   Dome Charging Dome is parked and re-charging Ok (45mA) 00:04:43 Session Finished Session Finished

Session Alerts & Alarms

Time     Type       Name Detail 23:36:19 Red Alert SBIG Camera Alert Take Image failed (Command timed-out) 23:39:21 Yellow Alert UPB.Switch Restarting UPB Powerbox Software 23:39:28 Green Clear UPB.Switch UPB.Switch service has been restored 23:44:37 Red Alert Scope Alert TheSky6's scope is reporting a RA=0/Dec=0 position 23:50:14 Yellow Alert UPB.Switch Restarting UPB Powerbox Software 23:50:21 Green Clear UPB.Switch UPB.Switch service has been restored 00:04:41 Green Clear Dome Charging Dome is parked and re-charging Ok (45mA)

Back to Top

Operational Issues (2025-05-18, S1329A)

• Critical Issues (1)
• Major Issues (1)
• Minor Issues (7)
• Small Defects (9)
• Continuous Improvement (10)
  

[ Prev | Next ]

Critical Issues

• LX200 Telescope was operating unknowingly and was in danger of critical damage (2025-05-24).  Whilst examining a separate matter on the AllSky/Weather Computer at around 23:00  it was noticed from the current ObsCam image that that the Observatory's LX200 Telescope was not in its parked position.   Examining the Observatory Computer showed that whilst the Telescope was not connected in AstroMain, it was powered up (as shown by Pegasus UPB Software) and was active (as shown by DeviceHub).  The Telescope was connected to via AstroMain and TheSky6 and after checking that telescope coordinates matched and were consistent with the ObsCam view, the Telescope was parked using AstroMain's 'Park Scope' button.  Examining AstroMain's report file showed that the Telescope power-up and connection occurred at 18:42. Telescope Connection from AstroMain was stopped at 19:59 from all Services were stopped and AstroMain closed in order to install a new AstroMain version (3.74.19), and later on it shows the telescope being connected to at 23:09 and successfully parked at 23:10 - 23:11 and turned-off.  Day Summary Plot shows the telescope was active between 18:42 and 23:09. (likely active between 18:42 and 19:59, and then not changed till turnoff at 23:11.   Issue was due to the user who was conducting tests on the Development Computer at th time, unintentionally and unknowingly starting the telescope service on the Observatory's Computer in a VNC Window which was active at the time.   Issue is entirely down to the user error.  User needs to be more aware and should probably close the VNC Window if conducting Telescope related testing on the Development Computer to prevent such an issue from occuring.  The issue is serious since if the issue hadn't been noticed, the telescope would have continued tracking and at some point overnight telescope cables would have likely wrapped themselves around the pier causing damage to telescope equipment. It is for this reason that the issue is ranked as 'Critical'.  As the telescope was not connected in AstroMain it was not in a position to monitor and stop the telescope from entering the telescope from entering the no-go area (near to Az 340-360.   AstroGuard which was not running / not connected was likewise not in a position to monitor and guard the telescope.  A separate Continuous Improvement ticket is raised to passively monitor the state of LX200 Power & MeadeGeneric Driver and raise a red alert / alarm to the the potential danager. This would provides some extra chance of the user becoming aware of the issue, but wouldn't be enough to stop a critical incident occuring.  After a further period of time and provided that DeviceHub and MeadeGeneric telescope driver are running,  AstroMain should automatically connect to the telescope and then either turn off telescope tracking or even proceed to park the telescope.
   Fortuitously resolved by user before damage occured  2025-05-24 (User, Telescope/Software Testing,  Observatory, LX200 Telescope)

Major Issues

• COM Port to Telescope unexpectedly closed (23:39).   Whilst Near Zenith Focusing was being conducted and whilst trying to resolve issue with SBIG Camera/CCDCamera, COM Port 6 (the com port to Telescope) unexpectedly closed. This was reported in AstroMain with the message "Scope Port Check.. Alert Port has closed (Closed at 23:39:09)"., in log file as "ScopePort Fail - Scope Port closed at 23:39:09" and "Get Scope.RaDec - Fail - The port is closed".  MeadeGeneric log records CommandString Error: "The port is closed" from "23:39:08.65 until 23:48:46 when MeadeGeneric Driver was closed (The first MeadeGeneric error was at 23:39:08.65 with message "The I/O operation has been aborted because of either a thread exit or an application request.[0D][0A] ".  DeviceHub Activity log also records the issue at 23:39:09.026 with the message  "Telescope : Get Altitude Exception: The port is closed".  TheSky6 produced multiple error dialogs with messages like  "Port has closed".  The DeviceHub-TheSky6 Telescope message log records nineteen "Get RightAscension  (failed) - The port is closed" messages from 23:39:08 to 23:43:23. TheSky6 was restarted using AstroMain's backdoor facility at 23:44:03.  Upon reconnecting the TheSky6.Telescope it gave messages that telescope was at Ra 0 Dec 0. and not where it was expected to be. AstroMain reported the following
      Telescope Coords (ASCOM)    Ok        RA   0-99 00 00.000, Dec: -99 00 00.00 (Current Epoch) ASCOM   
    Telescope Coords (TheSky6)  Ok        RA   00 00 00.000, Dec: +00 00 00.00 (Current Epoch) TheSky6   
    Telescope Coords (TheSky6)  Alert     TheSky6's scope is reporting a RA=0/Dec=0 position
  DeviceHub was observed to be showing "Not available" against all the telescope property fields on the Telescope Tab.
  DeviceHub was eventually killed/restarted (23:51:44). and Telescope reconnected (23:52:04), before Telescope was successfully parked (during session shutdown/finish).
  The lost of the COM Port seemed to coincide with the failure of the Powerbox Connection.   Logs records "Powerbox port seems to have been lost at 23:39:13". However the actual time that the Powerbox Port was lost could be up to 5s before this (ie as early as 23:39:08 or 23:39:09).   The Telescope Port was reported to have reopened as COM6 at 23:39:17. It is notable that this appears to have happened before the RestartPowerBox was initiated.  Issue is being investigated (see Investigation - USB / COM Port Failures (S1329A)  ).   Issue understood.  Issue closed after review 2025-05-23. A separate continuous improvement has been added to create a new or modified automated routine to restore telescope operability in the event of a COM Port outage.
   Closed after review 2025-05-23 (Session, UPB Powerbox, Com Ports, DeviceHub, TheSky6, AstroMain)

Minor Issues

• Continuation of CCDSoft.Camera issues (23:35). After successfully acquiring Locate Frames for Near Zenith Focus Field, and completing first 16 focus frames during Foc1 Wide Focus Profile there was an image failure for focus point 17/23, and the subsequent RestartCCDSoft encountered a "SBIG driver: Device not found" exception at 23:37:20. This was nearly 95s before the loss of communication to Telescope & UPB Powerbox at 23:39:09. .
   To monitor & fix  2025-05-19+ (SBIG Camera, CCDSoft, Com Ports)
   
• Uploading of files to Observatory WebSite failing with the message "Copying files to remote side failed - Disk full - please upload later" (Post-Session).  Uploading of files from Developement, Observator and AllSky/Weather computers using WinSCP failing with message "Error transferring file  - Copying files to remote side failed - Disk full - please upload later". There was a 40 minute outage at 2025-06-19 12:44, followed by a 60min+ outage" later in the day at 18:01.  JustHost (now BlueHost) contacted, no issue with account or disk space allowance (using 2.77 GB used of unlimited - 0%, using 37470 used of 1000000 - 4%). Transfer by C-Panel/File Manager works ok. The issue may be elevated to a Major Issue if it persists for more than 24h or otherwise keeps occuring.  Interaction reference id : I-20816825 for call.  Resolved by JustHost engineers at 2025-05-20 06:10:10 (giving an outage duration of around 12.1 hours).
   Resolved 2025-05-20 (Website)
   
• SAM III readings (X, Y & Z axes) shifted in value for around one hour (2025-05-25). At 2025-05-24 15:51 UT all three axis dropped by around 60-70 nT  before returning to close to their original values at 2025-05-24 17:11 (See Fig 2)  This was identified as being due to an outage in Observatory Temperature data than meant that temperatures corrections weren't being made.  Issue closed after review.
   Issue understood 2025-05-24 (SAM III,  Observatory Computer)
   
• SAM III readings (Y Axis) making large jumps in value (2025-05-23 08:34 & 2025-05-24 02:50). After working well since the LC Low Pass Filter was added to the SAM III system on 2025-05-10 the system has been showing anomalies during the last 30 hours.  At 2025-05-23 08:34 UT the Y Axis reading jumped by +1425 nT.   (See Fig 1) A number of small step like decreases occurred during following couple of hours as the reading stablished on a new base level. At 2025-05-24 02:58 UT the Y Axis reading jumped by -95 nT.
   To monitor 2025-05-24 (SAM III)
   
• SAM III readings (X and Y Axis) making unexpected increase (2025-05-25).  Beginning at around 2025-05-25 03:00 UT  X and Y magnetometer readings began and unexpected increase in value (See Fig 2) that wasn't observed in Comparison stations (Fig 3). The increase was gradual is not marked by a sharp shift at all.  The Y axis readings are unaffected. A temperature related affect is suspected,  but the increase around 100 nT, would imply a 10°C cooling in the SAM III box at surface (but there is no evidence of this)  or a 1°C cooling of the buired magnetometers, however there is no evidence of any temperature decrease of these sizes (see Fig 4).   Temperatures were somewhat anomalous with a very warm late afternoon until 18:00 UT and a long period of overnight cooling which didn't begin to rewarm until overnight last evening until 09:30 UT (10:30 LT).  The increase in readings is noted to potentially correspond with a rain event beginning at 01:00 UT (02:00 LT) reaching its heaviest point at around 02:30 UT (03:30 LT (see Fig 5).  Even if the rain was cooler than the ambient temperature (12 - 13°C) at the time,  and soaked into ground to the depth of the magnetometers it would be expected to have warmed up passing through the shallower soil layers (which had been up to 18°C the previous day) and upon reaching the magnetometer depth (0.8 - 1.2 m below ground surface) the water wouldn't be expected to be any cooler than the temperature already being experienced by the magnetometers (which was 11.0°C based on the co-located Temperature Sensor Probe).  Although the Z Axis magnetometer is the deepest sensor and would be the least likely to experience any temperature change, it does have the highest temperature coefficient of all 3 magnetometers but doesn't see any increase in magnetometer readings at this time. Examination of the data on the Development Computer using AstroMag showed that the increase in readings was present regardless of whether using temperature correction or not.  So what else could explain the unexpected increase in X & Y readings - were the 2 magnetometers drifting due to some interaction ?.   or could water have entered the sensor unit and caused the anomalies ?.   Readings became normal again (ie semi-parallel to comparison stations at around 10:00 UT. (ie giving a total anomalous period of around 7 hours) but even then didn't return to their pre-anomaly values (see Fig 6).   The  increase in X/Y reading is still unexplained at the time of review (2025-05-25 pm).  The data is suggestive of cold rain having led to cooling of the magnetometers and surrounding soil, but the colocated temperature sensor doesn't support a subsurface cooling (Fig 4). It is proposed to monitor the situation for any future anomalies that can help explain the observations.
   To monitor 2025-05-25 (SAM III, AstroMag).
   
• Certain First Frame Poster Picture and Prior Day videos are out of date (2025-05-25).  The first frame DayVideo poster image, the first frame PriorDayVideo, the first frame PriorNightVideo and the PriorDayVideo and PriorNightVideo seen in browser windows are out of date by as much as 3 days in the case of PriorVideos. Problem is confirmed by direct examination of files on Observatory Website using WinSCP. Examination of files on the AllSky/Weather Computers Server (Live) folder confirm that the correct files are present, which implies there has been an issue in uploading the respective files to Website by AstroAllSky's webuploader, which is responsible for the uploading.
  Logs from 2025-05-24 show files being queued but not uploaded.
  2025-05-24 18:43:24.36 | 1880.54 s : Queuing NorthCam.PriorNightVideo.mp4 for upload (id 111)
  2025-05-24 18:43:24.36 | 1880.54 s : Queuing NorthCam.FirstFramePriorNightVideo.jpg for upload (id 112)
  2025-05-24 18:43:24.36 | 1880.54 s : Queuing NorthCam.PriorDayVideo.mp4 for upload (id 115)
  2025-05-24 18:43:24.36 | 1880.54 s : Queuing NorthCam.FirstFramePriorDayVideo.jpg for upload (id 116)
  FtpQueueMax is set to 150 in AstroAllSky 1.23.6 and therefore this isn't the reason for failure to upload files.  Extra logging added to AstroNorthSky 1.4.1 to log copying of Night/Day files to PriorDay / PriorNight files within the server folder and the copying of new Night/Day files to the server folder.  AstroAllSky 1.23.6 examined but couldn't immediately find any reason for the problem.   Examining AstroAllSky's log file after the creation of the DayVideo at 2025-05-25 21:58 shows that at 21:58:36 the upload of the queued file 'NorthCam.LatestDayVideo.mp4' failed with the error message "File Size (39.0 MB) is larger than size limit in settings (30 MB)" .  The associated file 'NorthCam.FirstFrameDayVideo.jpg' wasn't even queued for upload. Adding extra logging to trace the initial cycle through the listening loop in the NorthCamListener() routine. Size limit for uploaded files increased from 30 MB to 45 MB.   A 60s delay has been added at the start of NorthCamListener in AstroAllSky 1.23.8  to allow FtpQueue to settle down before submitting the first cycle of NorthCam files.
   To investigate 2025-05-27 (Website, AstroNorthCam 1.4.1,  AstroAllSky 1.23.8).
   
• AstroAllSky is logging multiple exceptions associated with the upload of 'NorthCam.Latest3hVideo.mp4' file to website (2025-05-25). Each time there is a new  NorthCam.Latest3hVideo.mp4 file the file is queued for upload, each of the 3 upload attempts fails with an exception message like  "The process cannot access the file ...  because it is being used by another process". This cycle is repeated 1-2 further times over the next 30s before the file is eventually uploaded.
     1) Latest3hVideo queued at 04:49:58  (exceptions at 04:50:00)
   2) Latest3hVideo queued at 04:50:08  (exceptions at 04:50:08) 
   3) Latest3hVideo queuded at 04:50:19 (finally uploaded at 04:50:24)
It's unclear what process is 'holding' onto the file before 'releasing' it.  A fix has been added to AstroAllSky 1.23.7 so that a delay of 60s is applied before this particular file is submitted for upload.
   Fix attempted 2025-05-25 (AstroAllSky 1.23.7).
   
• AllSky/Weather Computer crashed due to a critical Kernal Power event (2025-05-24, 18:00). On occassional ongoing issue on the AllSky/Weather Computer is that it will unexpectedly crash, as it did today at around 18:00.  Event Viewer records there to have been a crictial kernal power event.  This is understood to be due to a window kernal believing that to has no battery power even though computer in plugged in and running with battery at 100%. Continue investigating/researching this issue.. .
   To monitor 2025-05-24 (AllSky/Weather Computer)

Small Defects

• AstroMain's log files contains a series of ScopeMode(Waiting) & ShowScope messages (23:47).  After aborting the Job Queue in order to terminate the session early, the log file contains a series of Observatory Manager message   "Set ScopeMode(Waiting) Info | ObsManager setting ScopeMode=Waiting and bFollowScope=True" and
  "Set ShowScope Info | TP.ShowScope (Scope Waiting)". Messages occurred between 23:47:09 and 23:48:44 (a c. 1.5 minute period) .
    23:47:14.43 | Set ScopeMode(Waiting) Info | ObsManager setting ScopeMode=Waiting and bFollowScope=True
  23:47:14.43 | Set ShowScope          Info | TP.ShowScope (Scope Waiting)
  23:47:19.44 | Set ScopeMode(Waiting) Info | ObsManager setting ScopeMode=Waiting and bFollowScope=True
  23:47:19.44 | Set ShowScope          Info | TP.ShowScope (Scope Waiting)
  23:47:24.44 | Set ScopeMode(Waiting) Info | ObsManager setting ScopeMode=Waiting and bFollowScope=True
  23:47:24.44 | Set ShowScope          Info | TP.ShowScope (Scope Waiting)
  The code that produces these message is as follows
 If gObservatoryMode = omManual And bRunningParkScope = False Then ' added bRunningParkScope condition 2024-11-19 (SD S1172)
   If ScopeUse.ScopeMode <> ScopeMode.Parked AndAlso ' add ScopeUse.ScopeMode condition 2024-11-16 (SD S1269)
    Scope.Connected AndAlso Scope.TrackingIsOn = False And
    Scope.SlewInProgress = False Then ' added Scope.SlewInProgress = False condition 2024-11-08 (MI S1264A)

      If TP.bFollowScope = False Or ScopeUse.ScopeMode <> ScopeMode.Waiting Then

         WriteLogFileRecord(szTargetName + " (ObsManger)", "Info", "Set", "ScopeMode(Waiting)",
                "ObsManager setting ScopeMode=Waiting and bFollowScope=True")

         SetScopeMode(ScopeMode.Waiting)
         TP.FollowScope("Scope Waiting")
      End If
    End If
  End If
  The 'SetScopeMode(ScopeMode.Waiting)' code line isn't leading to any change to 'ScopeUse.ScopeMode' since its 'SetScopeMode' log message isn't present and show that there isn't a race conditon going on with some other process that is separately changing the 'ScopeUse.ScopeMode value. The 'TP.FollowScope("Scope Waiting") ' code line is responsible for the "TP.ShowScope (Scope Waiting)" message.  This both sets bFollowScope = False  (in TP.ShowScope() and then follow this by setting bFollowScope = True. 
  which should block the code block being reentered on the next cycle of the ObsManager Main Loop. Something would seem to be setting 'bFollowScope = False'.   This can happen by a call to TP.ShowScope (TargetName, Ra2000, Dec2000),    TP.ShowScope(TargetName), HideScope().  It is believed that the problem occurred on this occasion as Job Queue was aborted using 'Abort Job' button which led to SwitchToManualMode() being called which then calls SetScopeMode(ScopeMode.Waiting)  - a trial added 2021-10-19 (CI, S926B). Issue likely fixed by a change to Abort Job process which now calls  ObsManager.SetMode_Manual() instead of calling 'SwitchToManualMode()', which skips the SetScopeMode calls.
   Fixed 2025-05-23 (AstroMain 3.74.18)
   
• AstroMain's log files contains "Exception In ..." messages in which "In" which should be in lowercase format. Fixed in AstroMain 3.74.18. Log messages now appear as "Exception in ..."
   Fixed 2025-05-21 (AstroMain 3.74.18)
   
• Log file doesn't show an explicit message recording that Session State has changed to Manual (23:47) .  At 23:47 user clicked the set mode 'Manual' button that after user confirmation to abort job queue' changed the Observatory Mode from Automated/Suspended to Manual.  This is recorded in Report File with the message "Setting Mode ...   Ok        Manual     (New Observatory Mode) " . Whilst the log file contains messages "User request to Abort Job",  "Job queue is aborting" & "Job Queue has been aborted" there is no explicit message recording the change in Observatory Mode or Session State.  Examining the 'SetMode_Manual()' routine indicates that a "Set ManualMode  Ok | Observatory set to 'Manual' mode" message should have been written to the log file, but it isn't present.  Similar the routine should have recorded a yellow session event with the message "Observatory placed in Manual Mode" , but instead there is a session event with the message "User Intervention to abort job queue & switch back to Manual Mode".     This session event is logged when user clicks the 'Manual' mode button (with Job Queue running) or clicks the 'Abort Job' button (btnAbortJob) (with job queue running.   In the former case it leads to SetMode_Manual() being called, but not in the latter case which calls PerformAbort() which calls 'SwitchToManualMode()'.   Fixed in AstroMain 3.74.18 PerformAbort() modified to call ObsManager.SetMode_Manual() instead of calling 'SwitchToManualMode()'.
   Fixed 2025-05-23 (AstroMain 3.74.18)
   
• AstroNorthCam failing to save Object (Bird) Images after beginning a new session.  After a new night date/new session was started, new 'Object (Bird)' Images stopped be saved, due to exception that is caused by the absence of a new datestamped subfolder.  Issue fixed in AstroNorthCam 1.4.  The appropriately named folder is now created when a new session is started.  Also the presence of required folder is checked before saving an 'Object' Image.
   Fixed 2025-05-23 (AstroNorthCam 1.4)
   
• AstroMain is reporting an anomlous RA value "0-99" when RA's value is vcNull (23:44).  Due to lost of telescope port at 23:39 and resulting exception getting Ra/Dec value the ASCOM Telescope RA property was given the value vcNull (-99.0), which was unexpectedly reported as "0-99 00 00.00" where the leading 0 is unexpected.
     Telescope Coords (ASCOM)    Ok        RA   0-99 00 00.000, Dec: -99 00 00.00 (Current Epoch) ASCOM
  Bug fixed in GetFullRA(dRa) routine in AstroMain 3.74.18.
   Fixed 2025-05-23 (AstroMain 3.74.18)
   
• A 'Scope Port closed at 23:39:09' message at 23:39:17 is incorrect. (23:39). After the Telescope Port unexpectedly closed at 23:39:09, the Port appears to be opened again at 23:39:17 based on report line  "Scope Port Check..    Info      COM6 has opened   (Opened at 23:39:17)".  This incorrectly logged as 'fail'  when it should have bee logged as 'Info  Telescope Port has reopened'. Fixed in  AstroMain 3.74.18.
   Fixed 2025-05-23 (AstroMain 3.74.18)
   
• Outage time for Powerbox / Powerbox Port Connection is incorrect (23:39).  After the lost of Powerbox Port at 23:39:13, the Powerbox Connection was deemed to have failed leading to the ObsManager initiating action to restart UPB Software & Services at 23:39:19.  This action was successful and the message "Powerbox port (COM4) is connected again. Outage was 1,202s"  was logged  at 23:39:28.  The stated outage time  (1202s)  is incorrect.  The outage time that is evident from the timeline is just 15s.  The time given (1202s) corresponds to 20 minutes and would imply that the outage began at 23:19:26 which is around 2 minutes before the session was created.  The 'connected again' message is produced from the  "Monitor for Change in PowerBox Port"  ObsManagerSection of the ObsManager Main Loop in which Outage Time is calculated using 'SecondsSince(PowerboxPortChangedTime)' .  However PowerboxPortChangedTime was set to Now() when powerbox port is lost 23:39:13 and was is used in log message "Powerbox port seems to have been lost at 23:39:13".  Investigating further the Powerbox.Connect (routine), that was called as part of the Powerbox recovery process, contains the line PowerboxPortChangedTime = Now().AddMinutes(-20) which explains where the 1202s (~20 mins) comes from.  Fixed attempted in AstroMain 3.74.19.
   Fixed 2025-05-23 (AstroMain 3.74.19)
   
• AstroLauch isn't automatically updating active programs & versions when running on AllSky/Weather Computer. AstroLaunch 1.13.1 should update active programs and version numbers when the focus in moved back to AstroLaunch from another application.  For some reason it is working on the AllSky/Weather Computer. Previous attempt to fix this isn't working. Fixed attempted in AstroLaunch 1.13.2.
   Fixed 2025-05-24 (AstroLaunch 1.13.2)
   
• AstroAllSky is logging exceptions associated with the upload of 'NorthCam.Latest3hVideo.mp4' file to website (2025-05-25). AstroAllSky is logging exception messages
  as follows
    2025-05-25 21:30:16.69 | Parameter must be positive and < Height.
   Parameter name: y
  2025-05-25 21:30:16.69 | System.ArgumentOutOfRangeException: Parameter must be positive and < Height.
   Parameter name: y
  at System.Drawing.Bitmap.SetPixel(Int32 x, Int32 y, Color color)
  at AstroAllSky.ImageViewer.DrawNightSummaryPlotLine(Int32 LineOffset, String Hour, String OddImageHour,
  Int32 bStarFrame, Boolean bSunAltMark, Int32 SunAltMarkNo)
  in C:\Users\david\Documents\Visual Studio 2022\Projects\AstroAllSky\ImageViewer.vb:line 4019
  The exception occurs in the DrawNightSummaryPlotLine () routine in the middle of the following code block
    For i = 0 To HeightSm - 1
    bm_ImageNightSummary1.SetPixel(TopMargin + i, iColumn, bm_Column.GetPixel(0, i))
  Next
The exception is caught at a latter point in the DrawNightSummaryPlotLine () routine and likely leads to useful code being passed over when the exception occurs.  Fix implemented in AstroAllSky 1.23.8 - conditons have been added to the SetPixel line and for further assurance a Try..Catch..EndTry block is placed around the conditions check/setpixel lines.
   Fixed 2025-05-26 (AstroAllSky 1.23.8)
   
• New Object/Bird detection algorithm in AstroNorthCam is producing to many False-Positives due to Cloud Edges. Daytime object/bird detection algorithm has been added to AstroNorthCam 1.3.2 - 1.4. Whilst the algorithm is very successful at detecting birds, it produces to many false positives associated with edges of certain clouds having a very dark edge in the Tapo/ ISpy originated JPG images (see Fig 7). Whilst the algorithm uses a method that helps guarentee picking up the whole of bird (eg both wings) or a group of birds, it picks up multiple 'dark' spots along the edge of a cloud (generally the top edge) and considers that it has a positive detection. Whilst the algorthm check that it has more than a certain number of dark fixes, may be it should ensuring that it has more that a certain number of dark pixels in direct contact with each other.  Fixed in AstroNorthCam 1.4.2, the number of false positive are significantly reduced and are now at an acceptable level.
   Fixed 2025-05-26  (AstroNorthCam 1.4.2)

Continuous Improvement

• Modify Charts in AstroMag to so they have a consistent width and therefore a consistent alignment on Observatory Website Pages.  Implemented in AstroMag 1.4.14.
   Done 2025-05-19 (AstroMag 1.4.14)
   
• Ensure AstroMain's TakeImageAsync checks bCameraConnected flag before trying to take an image. Implemented in AstroMain 3.74.18.
   Done 2025-05-19 (AstroMain 3.74.18)
   
• Modify AstroMain to raise Red Alerts if Telescope Port closed, with later Yellow/Green Alert if port is subsequently reopened.  Implemented in AstroMain 3.74.18.
   Done 2025-05-20 (AstroMain 3.74.18)
   
• Modify AstroMain to raise Red Alerts if the Powerbox Port closes, with later Green Alert if port is subsequently reopened.  Implemented in AstroMain 3.74.18.
   Done 2025-05-20 (AstroMain 3.74.18)
   
• Modify AstroMain to make improved message when Telescope Port is closes or re-opens.  Implemented in AstroMain 3.74.20.
   Done 2025-05-24 (AstroMain 3.74.20)
   
• Create a 'Test Focus Frames' routine that tests the behaviour of TakeFocusFrames/ TakeImageAsync/ CCDCamera/ SBIG Camera/ RestartCCDSoft etc under near-real conditions.  This tests the system for the presence of CCDCamera/SBIG Camera freezes and if an issue/freeze occurs to test the behaviour of TakeFocusFrames/ TakeImageAsync routines. Implemented in AstroMain 3.74.18.  Routine runs a loop with 90 focus frames unless Abort.  Used in a general session 2025-05-20 (telescope not running), but no problems surfaced.
    Done 2025-05-20 (AstroMain 3.74.18)
   
• Save new NorthCam 'Object (Bird)' images to Server (Live) Folder for upload to website.  AstroNorthCam 1.3.2/1.3.3 contains a new feature that auto-detects objects such as birds in daytime images, that are typically silhouetted against a brighter sky background. It is proposed to copy the annotated 'object' image to server (live) folder as  "NorthCam.LatestDayObject.jpg"  for upload to theObservatory WebSite.  Implemented in AstroNorthCam 1.4.   AstroAllSky 3.23.6 modified to upload the LatestDayObject image to the website.
    Done 2025-05-23 (AstroNorthCam 1.4, AstroAllSky 3.23.6, Website)
   
• Add extra protection to AstroMain to monitor for and respond to situation where LX200 Telescope is unknowing operating and in danger of critical damage.  Whilst conducting telescope testing on the Development Computer the Observatory Telescope was unintentionally and unknowing turned on  (via a VNC Window which was active at the time)  and then left running without any AstroMain monitoring in place.  Issue and any damage to equipment would have been entirely due to the user error.  User needs to be more aware and should probably close the VNC Window if conducting Telescope related testing on the Development Computer to prevent such an issue from occuring.  The issue is serious since if the issue hadn't been noticed, the telescope would have continued tracking and at some point overnight telescope cables would have likely wrapped themselves around the pier causing damage to telescope equipment.   As Telescope was not connected in AstroMain it was not in a position to monitor and stop the telescope from entering the telescope from entering the no-go area (near to Az 340-360.   AstroGuard which was not running / not connected was likewise not in a position to monitor and guard the telescope.  It is proposed to extend AstroMain monitoring by looking out for a situation where the LX200 Power is unexpectedly on and after a period of time (1 hour) to raise a Red Alert to hopefully warn the user of the situation.  This would provides some extra chance of the user becoming aware of the issue, but wouldn't be enough to stop a critical incident occuring.  After a further period of time (say 3 hours) and provided that DeviceHub and MeadeGeneric telescope driver are running,  AstroMain should automatically connect to the telescope and then either turn off telescope tracking or even proceed to park the telescope. Extra message box warning should be added to AstroMain if the user attempts to close the program when the telescope power is on.  Warning message on exit and red alert after 1 hour added to AstroMain 3.74.20.   Automated reconnection to telescope is placed on hold, but extra alert raised as reminder.  The new code was tested during S1329 Session (2025-05-25) and shown to have teething issues, which required a remedial fix to be included in AstroMain 3.74.21
    Done 2025-05-25 (AstroMain 3.74.20)
   
• Create a new or modified automated routine to restore telescope operability in the event of a COM Port outage. During S1329A session there was an event that saw the loss of communication with UPB Powerbox and Telescope, which was restored manually by the user who was in attendance at the time.  It is unclear if existing automated routines would have been able respond to the situation or not.  Restoration is not a simple task, as it needs to ensure that communication with Power Box is restarted, that TheSky is restarted and that DeviceHub is restarted, and other applications are notified and waited for before reconnecting to telescope. It would also likely required the Session to be suspended including closure of the Dome's Shutter since the Restart DeviceHub operation will mean that the Dome is not connected for a period of time. There is already a 'Resolve Scope Port' button on the More/Backdoor Tab that runs ResolveScopePortIssue() as a threaded operation  All it does at present is to call RestartDeviceHub() and reset certain flags (bResolveScopePortIssueIsRequired & bResolvingScopePortIssue).  The routine isn't currently accessed by any automated processes such as ObsManager or ObsOverseer.  Instead ObsManager calls RestartDeviceHub() if bResolveScopePortIssueIsRequired = True.  Solution will be modify the existing ResolveScopePortIssue() routine with additional code blocks in ObsManager.   New read-only property added in AstroMain 3.74.18 called  'Scope.IsPortClosed() as boolean' which returns True if objscope.Altitude produces an exception message containing "port is closed".
    Done 2025-05-24 (AstroMain 3.74.19)
   
• Create a process whereby meteor, satellite flashes and unidentified objects can be automatically identified in night time Tapo NorthCam Images. AstroNorthCam 1.3.2 has been recently extended to automatically detect birds/insects and other unidentified objects in day time images.  It is proposed to extend AstroNorthCam to automatically detect meteor, satellite flashes and unidentified objects in night time images.
   To do 2025-05-23+ (AstroNorthCam 1.4+ )

[ Prev | Next ]

[ Prev | Next ]

Back to Top

Investigation - USB / COM Port Failures (S1329A)

Back to Top