David's Astronomy Pages Notes - Session 1095 (2023-02-04)

Notes (S1094)

Notes Main

Home Page

Notes (S1096)

	Session Aims & Highlights
	- Observing Result  - Night Summary Plot  - Session Event Log
	Operational Issues
	- Critical Issues (0),  Major Issues (2),  Minor Issues (6)  Small Defects (22),  Continuous Improvement (7)
	Images from 2023-02-04 >>
	2023-02-09
	Guiding for Comets
	Lymax SCT Cooler

Session Aims & Highlights (2023-02-04)

Main aims

1. Camera Rotation.  Rotate ST-10 camera to 180.0 +/- 0.1 deg following its reattachment to telescope. Rotate ZWO 178MC camera on secondary scope to 0 deg + /- 0.2 deg, following identification that it currently sits at 358.5 deg (1.5 deg off).
2. Comet C/2022 E3 (ZTF).  Acquire images of C/2022 E3 (ZTF) after its transit across the north celestrial pole area (not readily observable with my fork mounted scope) on its way to its closest approach to earth and its travel into southen celestrial skies (where it will no longer be visible from my latitude)
3. AstroMain. Test new AstroMain version (3.61) several changes and additions.
4. Targets.  Acquire images of a selection of variable stars, nearby stars, comets & deep sky targets as allowed by sky conditions.
5. Secondary Scope Imaging/Stacking.  Continue testing of secondary scope imaging with automated in-session stacking of ZWO 178MC frames using and AstroMain's StackCam2Frames() routine, Siril-cli and a Siril script (OSC_stackframes.ssf).

 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.11dev4, Siril 1.0.6, deCONZ 1.18.2, ASCOM 6.6 SP1
   
• AstroMain 3.61, AstroPlan 1.36,   AstroShCap 1.3.14, AstroGuard 1.10.2
  AstroVOE 1.13  AstroSN 1.10,  AstroProtect 1.7,  AstroMove 1.9.8
  (AstroWeather 1.19.9, AstroAllSky 3.18,  AstroObsCam 1.11.4, AstroLaunch 1.10.7

Highlights

• C/2022 E3 (ZTF). Images of comet C/2022 E3 (ZTF) were successfully acquired using the secondary scope.
• AstroMain. There were no new signficant issues introduced by the new AstroMain version (3.61), through some gaps in recently added code to automate realtime stacking of images were revealed that require sorting out.
• PHD2 ST-10 (2x2). First session using ST-10 camera in PHD2 at 2x2 binning (faster performance & smaller file sizes compared with 1x1 binning and adequate of autoguiding the secondary scope with its smaller focal length.  Guiding performance seems ok no issues usually manually modified calibration.
• Dome Slews.  No hold-ups during any of the nights dome slews (Hold Up Stats: 0/60 slews affected, 0%, 0.0 minutes total hold-up time).
• Targets. It was not feasible to use the ST-10 CCD Camera for imaging with the LX200 primary scope due to the significantly reduced light capture because of condensation on the inside surface of the scope's corrector lens and primary mirror.
• Secondary Scope Imaging/Stacking.  Secondary Scope Image was conducted on a couple of targets including comet C/2022 E3 (ZTF). Whilst dataseys were acquired a number of issues were revealed when working with comets.
• Camera Rotation. It proved very slow and tedious to get the ST-10 camera rotated to the required angle. Whilst the rotation tweak for the ZWO 178MC camera on secondary scope was a lot quicker, both efforts were undone by an incident later in the session when Filter Wheel/ST10-Camera assembly slipped 40 deg, knocking the 178 MC camera off in the process.
• ST-10 Imaging. Dew/condensation inside the telescope meant that it was not feasible to collect any decent images through the LX200 and also made it difficult to realign the scope and perform a short mapping job following earlier reattachment of the ST10 camera.

Notes:

• Using Hair-Dryer at 21:20 temporarily cleared dew/condensation from inside surface of LX200's corrector lens, taking tube temperature from 3°C to 7°C,  but condensation moved to the primary mirror and then later on, back the corrector lens again.
   
• Using Hair-Dryer at 00:00 again temporarily cleared dew/condensation from inside surface of LX200's corrector lens, taking tube temperature from 3°C to 8.5°C,  but condensation moved to the primary mirror and then quite quickly back to the corrector lens again. 
  
  (In each case tube temperature took about 1 hour to fall back from peak to a background (steady state) temperature.
  

Summary Plots & Logs

Observing Plan

No plan created for the session (Manual Based Observing)

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)

Actual Weather vs Pre-Session Weather Forecast

Session Event Log

Time     Event Detail 19:32:55   CCDSoft Restarting CCDSoft being restarted (to set AutoSave No.) 19:33:08 Session Created Session Created (Live, 2023-02-04 S01095, ImageSaveNum: 1095001) 19:37:38   Scope Switched On Telescope Power has been switched on via UPB Powerbox. 19:39:21   Services Started Observatory Services started 19:39:44   Telescope Connected Telescope connected (TheSky6) 19:41:01       Dome Unparked Dome unparked 19:41:49   Dome Opened Dome opened (opening time 47s) 19:42:05   SBIG Camera Take Image failed, Error Code xxx 19:42:32   Camera1 Connected SBIG Camera connected (set point -20°C) 19:42:50   SBIG Camera Take Image command accepted (bSbigDriverException flag is reset) 19:46:58   Observatory Door Observatory Door has opened 19:47:08   Observatory Door Observatory Door has closed (open time 10 sec) 20:16:33   Automapping Started Automapping started (12 points planned) 20:16:50   Observatory Door Observatory Door has opened 20:16:58   Observatory Door Observatory Door has closed (open time 8 sec) 20:32:04 Program Opened Program Opened (AstroMain 3.61) 20:32:06 Session Resumed Session Resumed (Live, 2023-02-04 S01095, ImageSaveNum: 1095017) 20:32:17   Obs.Overseer Started Obs.Overseer started 20:32:42   Obs.Manager Started Obs.Manager started 20:32:50   Services Started Observatory Services started 20:33:59   Services Started Observatory Services started 20:34:16   Telescope Connected Telescope connected (TheSky6) 20:34:38   Camera1 Connected SBIG Camera connected (set point -20°C) 20:38:37   Automapping Started Automapping started (12 points planned) 20:49:12   Automapping Completed Automapping completed (6 points mapped out of 12 points) 20:49:51   Automapping Started Automapping started (12 points planned) 21:00:05   Automapping Completed Automapping completed (3 points mapped out of 12 points) 21:02:39   Telescope Parked Telescope parked (parking time 65s) 21:02:53   Telescope State Handbox reads 'Scope parked Turn scope off.' 21:03:16   Telescope Switched Off Telescope Power has been switched off via UPB Switch. 21:08:27   Scope Switched On Telescope Power has been switched on via UPB Powerbox. 21:10:19   Telescope Connected Telescope connected (TheSky6) 21:11:59   Observatory Door Observatory Door has opened 21:12:03   Observatory Door Observatory Door has closed (open time 4 sec) 21:21:32   Observatory Door Observatory Door has opened 21:21:40   Observatory Door Observatory Door has closed (open time 8 sec) 21:26:20     Target Started (NrZen) Target started (Focus Field 7, HIP 34070) 21:28:11       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 21:30:09       Focusing Completed Foc1 AutoFocus Completed (Profile No 1) 21:30:10       Focusing Started-Foc2 Foc2 Focusing Started (Secondary Scope, using ShCap) 21:32:09       Focusing Completed Foc2 AutoFocus Completed (Profile No 2, wide) 21:33:52       Focusing Completed Foc2 AutoFocus Completed (Profile No 2) 21:34:09     Target Completed (NrZen) Target completed (Focus Field 7, HIP 34070) 21:35:20     Target Started (1/1) Target started (1/1, C/2022 E3 (ZTF)). Using SharpCap 21:56:27   Camera1 Connected SBIG Camera connected (set point -20°C) 21:56:30     Target Completed Target completed (1/1, C/2022 E3 (ZTF)) 21:57:55     Target Started (1/1) Target started (1/1, C/2022 E3 (ZTF)). Using SharpCap 22:13:15   Camera1 Connected SBIG Camera connected (set point -20°C) 22:13:17     Target Completed Target completed (1/1, C/2022 E3 (ZTF)) 22:16:56     Target Started (1/1) Target started (1/1, C/2022 E3 (ZTF)). Using SharpCap 22:20:51   Camera1 Connected SBIG Camera connected (set point -20°C) 22:20:53     Target Completed Target completed (1/1, C/2022 E3 (ZTF)) 22:22:42     Target Started (1/1) Target started (1/1, C/2022 E3 (ZTF)). Using SharpCap 22:25:39   Camera1 Connected SBIG Camera connected (set point -20°C) 22:25:41     Target Completed Target partially completed (1/1, C/2022 E3 (ZTF)) 22:32:56     Target Started (1/1) Target started (1/1, C/2022 E3 (ZTF)). Using SharpCap 23:04:23   Camera1 Connected SBIG Camera connected (set point -20°C) 23:04:26     Target Completed Target completed (1/1, C/2022 E3 (ZTF)) 23:06:12     Target Started (1/1) Target started (1/1, NGC 1501). Using SharpCap 23:10:10   PHD2 Communication PHD2 is potentially stalled ('LoopingExposures' Events not detected) 23:10:32   PHD2 Restarted PHD2 service restarted 23:23:04   Camera1 Connected SBIG Camera connected (set point -20°C) 23:23:06     Target Completed Target completed (1/1, NGC 1501) 23:29:27   Camera1 Connected SBIG Camera connected (set point -20°C) 00:01:21   Observatory Door Observatory Door has opened 00:01:27   Observatory Door Observatory Door has closed (open time 6 sec) 00:01:29   Observatory Door Observatory Door has opened 00:01:31   Observatory Door Observatory Door has closed (open time 0 sec) 00:08:27   Observatory Door Observatory Door has opened 00:08:32   Observatory Door Observatory Door has closed (open time 5 sec) 00:08:35   Observatory Door Observatory Door has opened 00:08:37   Observatory Door Observatory Door has closed (open time 1 sec) 00:08:44 Obs.Monitor Frozen Obs.Monitor appears to be frozen at around 00:08 in section 'Refresh Dome Picture/Label Dome Azimuth' 00:10:54     Target Started (NrZen) Target started (Focus Field 10, HIP 49253) 00:11:26       Dome Unparked Dome unparked 00:15:36       Focusing Skipped Foc1 focusing skipped - unable to find a star (TCF-S) 00:15:37     Target Completed (NrZen) Target completed (Focus Field 10, HIP 49253) 00:20:03   Observatory Door Observatory Door has opened 00:20:07   Observatory Door Observatory Door has closed (open time 4 sec) 00:27:07   Camera1 Connected SBIG Camera connected (set point -25°C) 00:28:52   CCDSoft Restarting CCDSoft being restarted (user action) 00:29:00 Program Hung AstroMain Program Hung 00:29:39 Program Opened Program Opened (AstroMain 3.61) 00:29:41 Session Resumed Session Resumed (Live, 2023-02-04 S01095, ImageSaveNum: 1095056) 00:29:43   Obs.Overseer Started Obs.Overseer started 00:31:18   Obs.Manager Started Obs.Manager started 00:31:21   Services Started Observatory Services started 00:31:35 Foc1FieldsUpdater Frozen Foc1FieldsUpdater appears to be frozen at around 00:31 in section 'Update Foc1Fields' 00:38:00 Program Hung AstroMain Program or Crashed 00:39:17 Program Opened Program Opened (AstroMain 3.61) 00:39:19 Session Resumed Session Resumed (Live, 2023-02-04 S01095, ImageSaveNum: 1095056) 00:39:31   Obs.Overseer Started Obs.Overseer started 00:39:53   Obs.Manager Started Obs.Manager started 00:40:02   Services Started Observatory Services started 00:41:12   Services Started Observatory Services started 00:41:29   Telescope Connected Telescope connected (TheSky6) 00:42:02   Camera1 Connected SBIG Camera connected (set point -20°C) 00:45:08 Telescope Running 'ResetScopePointing' under user supervision 00:46:18   Telescope Telescope pointing successfully synced 00:46:21   Telescope Pointing Mapping run started 00:46:28   Automapping Started Automapping started (12 points planned) 00:59:17 Program Opened Program Opened (AstroMain 3.61) 00:59:19 Session Resumed Session Resumed (Live, 2023-02-04 S01095, ImageSaveNum: 1095060) 00:59:30   Obs.Overseer Started Obs.Overseer started 01:00:12   CCDSoft Restarting CCDSoft being restarted (user action) 01:00:19   SBIG Camera Reset SBIG Camera being power-cycled 01:01:09   Obs.Manager Started Obs.Manager started 01:01:17   Services Started Observatory Services started 01:02:00   Services Started Observatory Services started 01:02:29   Telescope Connected Telescope connected (TheSky6) 01:04:03   SBIG Camera Take Image failed, Error Code xxx 01:04:19   Camera1 Connected SBIG Camera connected (set point -20°C) 01:04:27   SBIG Camera Take Image command accepted (bSbigDriverException flag is reset) 01:05:22 Telescope Running 'ResetScopePointing' under user supervision 01:06:32 Telescope Running 'ResetScopePointing' under user supervision 01:09:11 Telescope Running 'ResetScopePointing' under user supervision 01:10:09   Telescope Telescope pointing successfully synced 01:10:12   Telescope Pointing Mapping run started 01:10:17   Automapping Started Automapping started (12 points planned) 01:21:12   Automapping Completed Automapping completed (2 points mapped out of 12 points) 01:21:38   Telescope Pointing Mapping run finished (Mapped 2 / 12) 01:22:19   Automapping Started Automapping started (12 points planned) 01:30:54   Automapping Aborted Automapping aborted (2 points mapped out of 12 points) 01:35:10   Telescope Parked Telescope parked (parking time 41s) 01:35:25   Telescope State Handbox reads 'Scope parked Turn scope off.' 01:35:47   Telescope Switched Off Telescope Power has been switched off via UPB Switch. 01:36:08 User Intervention User request to close and finish session 01:36:10 Session Closing Session closing 01:36:58   Dome Closed Dome closed (closing time 50s) 01:37:35   Dome Parked Dome parked (parking time 30s), Az: 90.0 deg 01:39:05   Services Stopped Night Services stopped 01:39:08 Session Housekeeping Session Housekeeping started (Create Fits Summary, Transfer Files) 01:39:18 Session Finished Session Finished

Session Alerts & Alarms

Time     Type       Name Detail 19:42:05 Red Alert SBIG Camera Alert Take Image failed, Error Code xxx 19:42:50 Green Clear SBIG Camera Take Image command accepted (bSbigDriverException flag is reset) 00:09:15 Red Alert Obs.Monitor Obs.Monitor appears to be frozen in section 'Refresh Dome Picture/Label Dome Azimuth' (last cycle at 00:08:44) 00:09:35 Green Clear Obs.Monitor Obs.Monitor has resumed again (00:09) after 0.8 mins 00:33:19 Red Alert Foc1Fields Updater Foc1FieldsUpdater appears to be frozen (last cycle at 00:31:35) in section 'Update Foc1Fields' 00:40:01 Red Alert Program Hung AstroMain UI appears to have stopped responding at 00:39 01:01:16 Red Alert Program Hung AstroMain UI appears to have stopped responding at 01:01 01:04:03 Red Alert SBIG Camera Alert Take Image failed, Error Code xxx 01:04:27 Green Clear SBIG Camera Take Image command accepted (bSbigDriverException flag is reset)

Back to Top

Operational Issues (2023-02-04, S1095)

• Critical Issues (0)
• Major Issues (2)
• Minor Issues (6)
• Small Defects (20)
• Continuous Improvement (7)
  

[ Prev | Next ]

Critical Issues

• None

Major Issues

• Unable to achieve the required number of mapped points from a 'short' mapping job (01:10 to 01:30). Following a camera reattachment and rotation adjustment, the telescope position was resynced in TheSky6 (which was itself difficult), a Short Mapping Job was then attempted in order to give the best tie into existing TPoint Model. Very few points would successfully map (success rate very low).  This was generally associated with images containing too few stars or fail to link. This was caused by significant reduction in the light coming through the telescope's optical path due to heavy condensation on the inside surface of the LX200's corrector lens and to some degree also on the primary mirror (see separate issue regarding condensation inside the telescope). Issue was not helped by sky being very bright due to the near full moon and light scattter from the condensation being lit by moonlight.  In the final attempt to perform a Short Mapping Job the operation had to be given up before getting the minimum number of 6 mapped points, and the telescope had to be parked without precise alignment.   This needs to be corrected at the next session once telescope's consensation issue has been resolved. Issue understood and closed after review 2023-02-05.
  Issue understood and closed 2023-02-05 (LX200, SBIG Camera Images)  
   
• Heavy condensation forming inside of LX200's corrector lens leading to a significant reduction in the light passing through telescope. This preventing using the telescope for target imaging and ended up preventing a resync of telescope position and preventing a Small Mapping Job from being successfully achieved. The condensation could be temporarily cleared with a hairdryer directed at front of scope, but this simply caused the condensation to move onto the primary mirror, but after a short period this would move again to the corrector lens.  There was no condensation/dew on the outside surface of corrector lens. Dew heater were in place at the front and back of the scope.  Issue is a continuation / new escalation of problems that have affected the telescope following an incident during session S1088 (2023-01-18) when snow slid off the observatory dome's shutter onto front of LX200 onto front of telescope when shutter was opening, leading to some water and humidity entering the telescope tube. (notes).  Several attempts to reduce the dampness / humidity but none of the following attempts have worked i) blowing (hot) air into tube with hairdryer, ii) sucking air out of the tube with a vacuum cleaner, iii) running dewheaters at max, iv) placing desicator in a muslin back at the visual back.  Further attempt is being made today (2023-02-05).  A CAT Coolor like the Lymax CosmicOne SCT Cooler R3 is being looked into as a way of circumlating lower humidity air into the telescope to displace the humid air from inside, however the the price (£139) is pretty high.  The corrrector lens could be removed to dry out the interior but I'd rather not attempt this if at all possible.   Update:  A Lymax SCT Cooler for 12" SCT was ordered today (2023-02-06) due for arrival in 2-3 days, and arrived 2023-02-09 and straightaway employed to help dry out the inside of the telescope.  A hair dryer was initially used to lift the dew/condensation by warming the front of the LX200 corrector lens, the rear cell area and my directing warm air into the SCT Cooler to warm the inside of the scope.   The SCT cooler was then left to run for 16-18 hours. Telescope was successfully used in session S1096 (2023-02-10),  SBIG Camera Images were normal.
  Fixed 2023-02-10 (LX200, SBIG Camera Images)  

Minor Issues

• Very slow / tedious to rotate ST-10 Camera to give the required camera angle 180.0 +/- 0.1 deg.   After re-attaching the SBIG camera onto the back of LX200 scope and rotating it by eye to roughly the 180 deg position that is used (this to avoid lead hitting the base of the fork / telescope control panel ).  An iterative process was them carried out. Ttaking a 5s-10s image and plate solving it  the camera angle could be obtained which would indicate the amount and direction to rotate the camera, so a camera angle of 180.4 meant than camera need to be rotated clockwise by 0.6 degs, whilst a camera angle of 178.6 meant that camera needed to be rotated anticlockwise by 0.4 deg, with rotation being made by loosing 1 or 2 of the screw knobs and rotating the camera by hand, then tightening the screw knobs again, and then remeasuring the camera angle again.   Problem was that it was a very prolonged process to make the required rotation (with rotations being too much and overshooting or not enough, procedure was much quicker when used in S1089 session attempt on 2023-01-24. The process was in part hindered by reduced number of stars in the locate frames (due to condensation issue above) and an issue with a newly built routine to report camera rotation angle measurement (necessiating the reverted back to an older method).  The sequence of measured Camera Angles went as follows :
  180.7, 179.7, 179.7, 180.5, 179.6, 179.7, 180.6, 179.5, 179.5, 180.4, 180.1, 179.95, 179.9, 180.4, 180.3, 180.2, 179.5, 179.6, 180.9, 180.6, 179.2, 179.3, 180.8, 178.4, 178.9, 180.6, 180.6, 180.4, 179.2, 179.9,
  At one stage the camera angle was acceptable (ie within +/- 0.1 deg range) and process should have stopped at that stage. A field rotator would be helpful in such a situation but cost of these (eg (Pegasus Falcon Rotator at £565) is too high to warrent what would be very occasional usage.  Eventually got the camera rotated to a final acceptable angle of 179.9 deg but the process of rotating the camera for one of the adjustments made was probably made against insufficiently loosened screw knobs and the rotation seems to have accidentally loosened the 2" nose that is screwed into the front of CFW-10 Filter Wheel. Unknown at the time this lead later on to a 40 deg rotation of the filter-wheel/camera assembly during a telescope slew, undoing the earlier adjustments and necessiating a further visit to the observatory.  A new re-adjustment of the camera is required at the next session once the telescope's consensation issue has been resolved. The 'Measure Cam1 Rotation'  routine has been optimised to given better performance.
  Issue understood and closed 2023-02-05 (LX200, SBIG Camera Images, AstroMain )  
   
• Filter Wheel/Camera assembly slipped by 40 deg during a telescope slew. A plate solution on an image late into session was rejected. ALthough image link was rejected and examination of the image link in TheSky6 showed that it linked ok but the impled camera angle () was too far from expected angle of 180 deg, that that the plate solution was rejected.  A visit to the observatory showed that the filter wheel/camera has slipped by some 40 degs.  Although the 3 screw knobs held the 2" nosepiece tightly in the TCF-S focuser the nose piece that should normally be tightly screwed into the CFW-10 filter wheel  (which then attachs to the  ST-10 camera) had loosened.  It is highly probably that this happened when a particular rotation of the camera during earlier adjustement had most-likely be done against insufficiently loosened screw knobs and it had caused the 2" nose screw thread to rotate/loosen instead. The slippage of the filter wheel/camera assembly had a secondary affect of pulling on the USB3 leading to the ZWO 178 MC camera attached to secondary scope, causing that camera to also rotate. The 2" nose piece was tighly screwed back onto the filter wheel/camera assembly and both cameras were roughly adjusted back to approximately their usual camera angle positions, pending more accurate adjustment at the next session once the telescope's consensation issue has been resolved.
  Issue understood and closed 2023-02-05 (LX200, SBIG Camera & Filter Wheel)  
   
• Image linking failed on many SBIG Camera images through the session (23:07+). Problem affected by manually initiated Locate Image operations and automated Maping and Centering operations.  An example of the problem was shown by the locate frames (#1095048-51) for the manually initiated target NGC 1501.  Four locate frames were taken with exposures 5s, 20s, 30s and 60s. They are all failed to image link with the message "Too few stars" and with SmartStarCount numbers of 2, 3, 3 & 4 stars respectivily (all had less than the 5 or 6 minimum stars required for image linking).  Later image linking attempts on these images on Development Computer after Dark/Flat reduction also failed with 'too few stars' (star count again 2-4).  Problem was primarily caused by dew on the inside surface of the scope's Corrector Lens (ie condensation inside the LX200's telescope tube) that spread and suppressed the light coming from stars to the CCD Camera.  Although the locate frames from NGC 1501 visually appear to contain around 8 GSC stars, which should be adequate for image linking, the CCDSoft Image Inventory is only able to find say 2-4 stars and the InsertWCS / link attempt is reported as a failure. It is hypothesised that the condensation suppresses the peak of the star so that SExtractor simply doesn't recognise them as objects using normal settings against the bright moonlit sky background.  Later investigation proved that the images could be linked within the TheSky environment by pasting the images into the virtual sky and running the Link Wizard.   Whilst the issue will resolve itself once humidity can be removed from inside the telescope tube.   It would be useful to have a specific mode that would allow Simple Image link attempt to still be tried even if the number of stars is conventionally 'too few'. A separate continuous improvement ticket has been raised for this.
  Issue understood and closed 2023-02-05 (Session, AstroMain, CCDSoft/TheSky6)  
   
• Telescope Position not correctly shown in TheSky6 (01:22 to 01:33). Towards the end ofthe  session TheSky6 program began to show an issue where it starting displaying an incorrect (not expected) telescope position. When a sky position or target was selected in TheSky's virtual display and the telescope commanded to go to that position, the telescope was appear to initially move to or towards the target , but then continuing display at its original position.  Actual scope did move to the commanded sky position based on the movement of the scope in Device Hub and AstroMain's ObsViewer picture. It is unclear if this has any associations with issue related to resynchronising the scope positions and performing a short mapping run.  Because of this issue the attempt to press on with the Short Mapping Run (already problematic because of imaging issue) was abandoned. The final Park Scope operation at end of session (01:34) was carried out using AstroMain 'Park Scope' button routine through a direct Park command without using TheSky6 to slew first to the 'Near Park' position. Investigating ASCOM log files shows that during normal slews like one at 00:27:45   TheSky6 comands Telescope.SlewToCoordinatesAsync: RA  9.50961, Dec  -1.19335.    which is followed by pairs of Ra, Dec messages that show TheSky6 receiving telescope coordinates that show the progress of the scope towards the target. Slews at 01:31:36,  01:32:19, 01:33:35 are anomalous. After the Telescope.SlewToCoordinatesAsync command there are a series of Get Slewing = True messages (messages not normally seen), but the usual series of RA, Dec messages pairs are absent. Eventually after say 14s or so an RA, Dec message pair are logged and seem to indicate the Telescope having reached the target.   The ASCOM Log would explain the behaviour seen in the Virtual Model but not explain why TheSky6 wasnt getting the Ra.Dec information from TheSky6. Other clients such as AstroMain recieved coords information ok during the slew. TeleLink shows RA Dec pairs every 500ms before the slew at 01:31:36 but after this time the frequency of RA Dec Pairs is significantly reduced with no values during the slew. Issue is put down as a glitch of unknown cause and the ticket is closed.   Future sessions should be need to be monitored in case of future instances of this problem.
  Closed after review  2023-02-05 (TheSky6, DeviceHub)  
   
• DeviceHub not giving up its connection to the MeadeGeneric Telescope driver when the final telescope client has disconnected (01:37).   Device Hub GUI doesn't show any connected clients (no Telescope Clients: 1+ field).  A white 'Disconnect Telescope' button is showing, but clicking on the Disconnect Telescope doesn't stop the connection.   Fields like Az, Alt show default parked coordinates from the driver  Problem is believed to have been previously reported to DeviceHub author (Rick Burke). Same issue ooccured in session S1098. It is possible that the problem is caused by PHD2 still having a connection open at the time that scope is powered off.  A fix has been attempted in AstroMain 3.61.6 to command PHD2 equipment to be disconnected when Scope.ParkScope2_Manual() is called from the "Park Scope" button routine.  Later review (2023-10-08) concluded that fix in Feb 2023 has been successful in eliminating this issue and closed the ticket.
  Fixed 2023-02-14 (AstroMain 3.61.6, DeviceHub)
   
• AstroMain crashed whilst carrying out a CCDSoft.Camera operation (00:50 to 00:54) . Whilst attempting to carry out an operation in AstroMain, the program crashed due to an unhandled exception "TargetInvocationException: 'COM target does not implment IDispatch' " at codeline 'Camera.Subframe = False' in 'RunClearSubframe() routine.  Problem related to SBIG Camera / driver issue (stalled or something), most likely associated with earlier program hung that neccessiated killing Observatory software suite (including TheSky6 & CCDSoft etc).   It is probably prudent in future to power cycle the SBIG camera in such a situation.  Such exceptions need to be caught in order to prevent an issue with SBIG Camera/CCDSoft from bringing down the AstroMain program.   Try Catch End Try block placed around the particular code producing the exception, but other CCDSoft.Camera code needs to have try-catch-end try type handling to prevent unhandled exceptions from causing the AstroMain program to crash. Closed after review 2024-03-27, as AstroMain 3.66 no longer crashes due to issue with CCDSoft.Camera. In general any issues are handled & logged, and CCDSoft/SBIG Camera automatically restarted.
  Resolved/Closed 2024-03-27 (AstroMain 3.62 to 3.66) 

Small Defects

• New 'Measure Cam1 Rotation' routine using link methods that sometime fails for images where Simple Link works ok.  The new RunMeasureCam1CameraAngle() routine added in AstroMain 3.61 calls TakeLocateImageAndLocate() routine but this sometimes failed to produce a Rotation Result as the Image Link fails. Performing a simple link on the image however linked ok and produced the required Camera Rotation result.   Fix made in AstroMain 3.61.1   The RunMeasureCam1CameraAngle() now calls a new routine RunTakeCam1LocateFrame() to take a 10s locate frame.  If successful the routine then calls LinkActiveImage() routine to perform a Simple Link.
  Fixed 2023-02-05 (AstroMain 3.61.1)  
   
• Job executor operations waiting for Siril Stacking to finish timed-out (21:56 & 23:03). After secondary scope imaging is completed the job executor prepares and submits a bat file that calls siril-cli to align and stack the frames and created result .FIT and .PNG files, whilst it waits in a loop at the end of which it renames the result files and ConvertsPngToJpg()  routine to created annotated JPG files and copy then to the 'live' folder for their upload to website and display on the Current Session web page. For a particular target run of 50 full frames images for C/2022 E3 (ZTF) Siril's stacking and image generation script took 2m 12s to finish whilst the time out in TakeSecondaryScopeImages() routine timed out after 2 minutes.  A consequence of the time out was the the process folder from the 3 runs affected was not cleaned up at the end (these folders totalled 18 GB which had to be cleaned up post-session. The wait loop could be modified to monitor the size of the siril log file or final .png file and use that as an indicator that job has been completed or not.  Time out can be moved out to say 5 minutes.  Job executor should say when .bat file is submitted.  Fixed in AstroMain 3.61.1 with modifications to StackCam2Frames() routine.
  Fixed 2023-02-04 (AstroMain 3.61.1)  
   
• ASCOM Log Folder contains multiple TeleLink logs. (20:18 to 21:02 & 01:12 to 01:34).  Folder contains 36 TeleLink logs between 20:18 and 21:02 with particularly small file sizes (between 2 and 77 KB)., with a further 21 such files between 01:12 and 01:34. Before these logs there were 'normal' log created at 19:39 (626 KB, last modified 20:17) and 21:10 (2726 KB, last modified 00:33). Folder contains 51 DeviceHubTelescope logs with particularly small file sizes (2 - 84 KB)  associated with the 20:17 to 21:02 and 21:34 to 23:29 time intervals. with a further 19 small logs files between 01:13 and 01:34.   Problem hasn't been noticed before.  The DeviceHubTelescope Logs show pairs of 'Get RightAscension' & 'Get Declination' messages which are diagnostic of communications with TheSky6 and end in the message "Setting Connected to False (disconnecting from ASCOM.MeadeGeneric.Telescope)"  . The times of these disconnections correspond to the moments that theTheSky6 Telescope is disconnected in preparation for mapping a point. After mapping each point (actual mapping or attempted mapping) the TheSky6 Telescope is connected again, which results in a new TeleLink log and a new DeviceHubTelescope log. Issue understood and closed after review 2023-02-05.
  Issue understood and closed 2023-02-05 (TheSky6, TeleLink, AstroMain)  
   
• Failed to use 'Check/Reset Scope Pointing' facility when resyncing telescope pointing (20:37). Whilst it is feasible to image link an image, and manually click on the Sync button on Telescope tab associated with the 'Image Link (Object) Information' dialog in TheSky6 (which was what was done near the start of the session after reattaching the SBIG Camera assembly and adjusting its camera angle)  it is preferable if AstroMain's 'Check/Reset Scope Pointing' facility is used as this provides a Wizard that takes the use through the process including running Short Mapping Job afterwards., provides better documented reporting and records a Session Event "Telescope.   Running 'ResetScopePointing' under user supervision".   The facility was used later in the session, so this is a simple case of user forgetting to use the preferred method.
  Closed 2023-02-06 (User Awareness, AstroMain, LX200) 
   
• The TCF-S Focuser went off line and stayed off-line for some 36 hours until noticed.  In particular the service stopped providing fresh OTA temperature data which prevented automated dew heater management.  This ticket deals with the issue that the TCF-S focuser went offline.  A separate continuous improvement ticket is raised to automatically monitor the TCF-S service and restart it if it has gone offline and the 'Use TCF-S Service' is checked.   Investigating shows the the TCF-S Focuser service stopping providing data around midday on 2023-02-05. This is believed to corrospond with the time that the power supply plug to UPB Powerbox was accidently disconnected.  Even though UPB power was quickly reconnected, it had the effect of stalling the communications between the TCF-S Focuser and its driver. 
  Issue understood 2023-02-07 (Session, AstroMain 3.61.1, TCF-S Focuser)  
   
• Log file is showing multiple "Conversion from string" exceptions when UPB PowerBox was accidentally turned off (2023-02-05). During daytime changes to dew heater leads the power supply plug to the UPB Powerbox was accidently disconnected at around 13:05 (2023-02-05). A message "Powerbox port seems to have been lost at 00:00:00" (in which the reporting of 00:00:00 is a bug ), was written to log file at 13:05:39  and the UPB Monitor proceeded to make an attempt to Restart UPB.Switch. Although the power was quickly restored to the Powerbox, it may have been too late for the Restart UPB Switch operation to be successful. At 13:06:00 an interventation was made to stop and the restart the three UPB based services (Switch, Focuser and Observing Conditions).   Beginning earlier at 13:05:49 and continuing every 5s until noticed some 50 hours later there are log messages "Exception in MainLoop (Monitor For Change in PowerBox Port)" with  the exception message "Conversion from string "Powerbox port (COM4) is connecte" to type 'Double' is not valid."   Using the 'List COM Ports' facility show that UPB Powerbox is on Port 4 (as per normal).  All Services were stopped and then restarted.   This resolved the problem of multiple exception message reporting, but there is clearly a bug.  Examining the 'Monitor for Change in PowerBox Port' (2023-02-07) it wasn't immediately clear why the particular exception occurred based on the exception message.  However the bug was found and fixed the following day (2023-02-08, SecondsSince() - a double value wasn't placed in FormatNumber() to convert it to a string) . Code changed anyway so that log messages describing an exception are only written if it is more than 30 minutes since the last exception or the exception message is different.  The bug where the time of Port lost  is reported as 00:00:00 has also been fixed (2023-02-07).
  Fixed 2023-02-08 (Session, AstroMain 3.61.1, TCF-S Focuser)  
   
• Rain Viewer maps in the Radar Section of the Current Weather & Conditions Web page are not longer respecting the Lat/Long coordinates for NE Scotland area or the zoom level that are set as part of iframe url.  When the page opens the two RainViewer Maps both have a FOV centered on the USA.   It is also noticed that if one of the two maps is panned or its zoom level is changed, and the page is refreshed both maps adopt that new FOV rather than remaining independant maps.  When either URL is used directly the browser shows radar map centered on NE Scotland at the zoom level specified, however the expected map isn't shown correctly when the URL is used from an iframe. Embed code check and corresponds to the 'embed code' (including iframe) that are currently reported on the RainViewer site. No solution (RainViewer embeds not working any more, DarkSky maps no longer available).   Web page modified to shows a link to Rain Radar+Wind Map on Zoom Earth.   Unfortunately this is not available as an IFrame embed. 
  Closed after investigation and part fix  2023-02-05 (RainViewer Applet, Web page)  
   
• Manually initiated ad-hoc targets are not being listed in the contents section of the session's Report file.  This makes it difficult to move directly to the section for each manually initiated target observation or observation attempt. The report title for each of these target observations should use the special form of ReportTitle() called ReportLineTitle() (as used by the Job Queue in the form ReportLineTitle(szTargetName, szTargetName, TitleType.Target, L2, True) ) to order to include a href bookmark with the title and include a hyperlink in the contents.htm file than is included at the top of the finalised session report.  This is an obmission (gap) in the current design rather than a bug, the issue is dealt as a Small Defect rather than a continuous ticket. Either way a fix has been added to AstroMain 3.61.1.
  Fixed 2023-02-06 (AstroMain 3.61.1)  
   
• AstroMain Reduction failing to open up session S1095 due to "IndexOutOfRange Exception" (post-session reduction).   Running AstroMain in Visual Studio's debugger revealed that exception was occuring in code line 'Return FPath(nFiles)'  in the routine 'GetSharpCapSettingsFile(FolderPath).   Folder path was "C:\Data\ZWO Imaging\SharpCap\2023-02-04 S01095\C2022 E3 (ZTF)\21_37_40"  and the number of Camera.Setting files counted (nFiles) was 87. FIlename and path details are assigned to a local variable array created  as  'Dim FPath(20) As String'. Whilst exceptions that try to assign to FPath(21) to FPath(87) are caught, an exception is produced at end of routine when it tries to return the FPath value for the final file (FPath(87).  Bug only exposed because ShCap Imaging uses more than 20 frames in this session (normally only 20 frames have been used in recent sessions). Fixed in AstroMain 3.61.1.
  Fixed 2023-02-06 (AstroMain 3.61.1)  
   
• ShCap Imaging for C/2022 E3 (ZTF), Set 3 wasn't corrected reported by AstroMain, and was ended earlier by AstroMain disconnecting the ShCap Camera.  ShCap imaging run for the prior observation ( C/2022 E3 (ZTF),  Set 2, 50 x 20s planned frames, started at 22:02:06 ) was aborted by the user at 22:12:54 during frame 32. This was a user decision based on reviewing the quality and value of the images being collected against the observing aim.   During the next observation (C/2022 E3 (ZTF),  Set 3, 50 x 20s planned frames, started at 22:16 ) the job executor reported the planned ShCap Imaging and submitted the request to AstroShCap for the collection of a fresh image set (expected to be Set 3), and then entered a listening loop to monitor the SharpCap operation.  Instead of hearing a ShCap event indicating the completion of Frame 1, a ShCap event was heard concerning Frame 32, followed by message "Aborted after 32 frames" and a FrameSet description indicating Set 3.  It would seem that AstroMain was hearing events from the end of the previous image set. It was initially through that the earlier ShCap take_image_set thread hadn't been closed and was somehow still active, but this later disproved by ShCap log & report messages and a review of the python code used for AstroShCap. This showed that ShCap successfully completed the first 5 frames for Set 3 but was stopped in taking further frames by a 'Disconnect Camera' operation.  As a result of investigations it was concluded that AstroShCap & its TakeImageSet() routine respond correctly to an 'abort' request from AstroMain and that the problem is due to an event handling issue in AstroMain.   TakeSecondaryScopeFrames() routine modified to call  ShCap.ClearEventQueue() to clear the event queue before starting a new Target  or new Frame Set.  This will prevent any events associated with the last Image Set being being confused with new events associated with the new Image Set.
  Fix attempted  2023-02-07 (AstroMain 3.61.1)  
   
• Observing Result chart is drawn with a 'Scheduled End' line & text when there is no observing plan.   The line/text for 'Scheduled End' shouldn't have been drawn for session S1095 and there was no observing plan.   The SBIG Camera wasn't producing good images (due condensation inside LX200 Telescope Tube Optics issue) and operations were all manually initiated, so there was no concept of a 'Scheduled End' for the session - it would end when the user decided.   Examining code for creating chart, the inclusion of 'Scheduled' End event is peforrmed by SessionEventsForm.LoadResultEvents() routine where a 'Scheduled End' event is given the date value Night.NightEndTime.ToUniversalTime.  However this controlled by a flag called bIncludeNightEndTime   (with a ' Trial'  comment beside it) but is currently hard-coded as True. It is proposed that this is only set to true if the table of Session Events includes a 'Plan Loaded' event, otherwise the flag is set to false.  Implemented in AstroPlan 1.36.1.
  Fixed  2023-02-08 (AstroMain 3.61.1)
   
• During guiding for C/2022 E3 (ZTF) a LockPositionShiftLimitReached condition arose but a new guide star wasn't picked.   Set2 ShCap Imaging of comet C/2022 E3 (ZTF) was initiated with automated guiding with 'Comet Tracking' whereby PHD2 guides on a star but continuously adjusts the lock position based on comet's expected rate of RA and Dec motion.  In theory this keeps the comet positioned at a fixed point in the image frames whilst the background stars move without having to explicity guide on the comet itself . During guiding at around  Frame 27 the following message was reported:
     > PHD2 Event     Ok      LockPositionShiftLimitReached (new Guide Star will be selected
  This event is raised by PHD2 because the guide star itself has approached or reached the edge of the FOV of the guide camera and happened because of the comet's relatively high rate of motion (Ra -390.93 arcsec/hr, Dec -852.64 arcsec/hr), the Guide Camera relatively small field of view (Cam1 (ST-10) being used instead of usually used larger FOV Cam2 (178MC) ).  The time to this event will also depend on how close to the edge of Guide Camera's FOV or ROI  that the guide star was when it was initially selected.  In this case with comet moving in Dec at 14.2'/hour and the half height of the guide camera FOV being only 5.7' this was a likely event at some stage.  This is known potential situation (though not one previously encountered during a live session) and the guide manager is designed in respond to the event by stopping and restarting the guiding so that a new guide star can be auto-selected by PHD2, and the observation of the comet or asteroid can continue.  On this occasion the logs show 'LockPositionShiftLimitReached' event being received from PHD2 at 22:11:03.36, and this is followed quickly by a requests from AstroMain to 'stop_capture'  and to 'guide' at 22:11:03.98.   PHD2 issued a SettleBegin response indicating that PHD2 had received and was acting upon the new guide request.  
    22:11:03.36 | Event << {"Event":"LockPositionShiftLimitReached","Timestamp":1675548663.366,"Host":"LAPTOP9","Inst":1}
  22:11:03.55 | Stopping PHD2 Looping/Guiding
  22:11:03.55 | 274 REQUEST >> {"method": "stop_capture", "id": 274}
  22:11:03.62 | Event << {"Event":"Alert","Timestamp":1675548663.609,"Host":"LAPTOP9","Inst":1,
                "Msg":"Shifted lock position outside allowable area. Lock Position Shift disabled.","Type":"warning"}
  22:11:03.66 | 274 Response << {"jsonrpc":"2.0","result":0,"id":274}
  22:11:03.98 |
  22:11:03.98 | 275 REQUEST >> {"method": "guide", "params": [{"pixels": 2.0, "time": 6, "timeout": 10}, false], "id": 275}
  22:11:04.01 | 275 Response << {"jsonrpc":"2.0","result":0,"id":275}
  22:11:04.01 | Event << {"Event":"SettleBegin","Timestamp":1675548663.999,"Host":"LAPTOP9","Inst":1}
  22:11:05.28 | Event << {"Event":"GuideStep","Timestamp":1675548665.281,"Host":"LAPTOP9","Inst":1,"Frame":125,"Time": ..}
  22:11:05.29 | Event << {"Event":"GuidingStopped","Timestamp":1675548665.291,"Host":"LAPTOP9","Inst":1}
  22:11:05.31 | Event << {"Event":"SettleDone","Timestamp":1675548665.297,"Host":"LAPTOP9","Inst":1,  ..}
  22:11:05.32 | Event << {"Event":"LoopingExposuresStopped","Timestamp":1675548665.322,"Host":"LAPTOP9","Inst":1}
  22:11:05.32 | Event << {"Event":"LockPositionLost","Timestamp":1675548665.324,"Host":"LAPTOP9","Inst":1}
  22:13:02.01 | Stop PHD2 Guiding (2023-02-04 22:13:02 LT)
It is not possible to understand precise course of events/actions after the stop guiding & start new guide requests went to PHD2 and whether the required action to begin guiding with a freshly picked guide star was fully carried out. It is possible that user might have made a premature action using the PHD2 Program window.  Frames 28 to 31 went unguided and then on Frame 32 the user aborted the observation.  It would seem prudent to add a 2s delay between the 'stop_capture' and restart 'guide' requests (Implemented in AstroMain 3.61.1, delay of 200ms increased to 2s in Guider.SelectNewGuideStar).  Ticket is closed after review 2023-02-08
  Closed after review 2023-02-08 (Session, AstroMain 3.61.1, PHD2)  
   
• AstroMain's (PHD) Log began repeating messges multiple times (22:11:04 to uring guiding for C/2022 E3 (ZTF) . Issue identified whilst investigating AstroMain response to a 'LockPositionShiftLimitReached' event that was received from PHD2 at 22:11:03.36.  After sending a 'guide' request to PHD2 at 22:11:03.98 (id 275),  the log file then contains a vast numbers of lines (~131,000) which repeat PHD2's response to the guide request (id 275) between 22:11:04.09 & 22:11:05.
    22:11:03.98 | 275 REQUEST >> {"method": "guide", "params": [{"pixels": 2.0, "time": 6, "timeout": 10}, false], "id": 275}
  22:11:04.01 | 275 Response << {"jsonrpc":"2.0","result":0,"id":275}
  22:11:04.09 | {"jsonrpc":"2.0","result":0,"id":275}
  22:11:04.09 | {"jsonrpc":"2.0","result":0,"id":275}
   ..    131,000 repeated lines (not shown)
  22:11:04.09 | {"jsonrpc":"2.0","result":0,"id":275}
  22:11:05.28 | {"jsonrpc":"2.0","result":0,"id":275}
  At 22:11:05.28 there is a GuideStep Event,  this is recognised as an Event  ( Event << {"Event":.... )  but unexplainably the Event message is repeated 94 times between 22:11:05.28 and 22:11:05.29, until a GuidingStopped Event is received and recognised, but again unexplainably the new event message is repeated 994 times between 22:11:05.29 and 22:11:05.31.    Problem might relate to the absence of CRLF character in response of 275,  which is where the repeated messages began.  However review of code shows that the problem lies in AstroMain's Guider.SelectNewGuideStar() routine which writes the current value of Response to logfile for each passage through a 'Do While' loop.  Issue fixed in AstroMain 3.61.1  (SelectNewGuideStar() routine's Do loop no longer writes the value of Response to the (phd2) log file and is now optimsed to only run the loop's main code block when Response <> LastResponse)
  Fixed 2023-02-04 (AstroMain 3.61.1)  
   
• AstroMain UI running slowly whilst job executor operations waiting for Siril Stacking to finish. After Siril-cli began an operation to debayer, align and stack 50 images of C/2022 E3 (ZTF).   This operation is very CPU intensive and might have caused AstroMain to run slowly.   Alternatively the wait loop wasn't optimised and was taking up too much program CPU. Wait loop changed from a 200ms cycle to a 1000 ms cycle, and number of File.Exists() checks reduced.  Issue to be monitored. It is possible that the number of thread used by Siril should be reduced from current number of 12, however Siril warns that reduced the number of processes can degrade performance. Closed after review 2023-02-08.
  Closed but continue to monitor 2023-02-08 (AstroMain 3.61.1)  
   
• Some of the graphs on Current Weather and Conditions Web Page are displayed too small. Three of the graphs on the page are displayed too small. This is due to the accidental addition of incorrect width & height values on these particular graphs, following recent work to explicitly declare images sizes in order to improve page loading performance and behaviour. Fixed 2023-02-07 & 2023-02-08.
  Fixed 2023-02-08 (Website, Current Weather & Conditions page)  
   
• Current/Latest Session web page scripts stopping, leaving page without Observing Plan & Observing Result pictures and without Link to session's Notes page (2023-02-09). Unclear if this problem was present during / at end of session or is a follow-up problem. Opening the page in Edge using Inspect shows up a couple of errors
  1) HEAD 'https://www.astro-richweb.net/astro/notes-2023-02-04.htm' net::ERR_CONTENT_DECODING_FAILED 200
  2) Uncaught DOMException: Failed to execute 'send' on 'XMLHttpRequest: Failed to load.
  (main.js , 'https://www.astro-richweb.net/astro/notes-2023-02-04.htm' , but also
  Problem comes from use of doesFileExist() routine to ascertain if the notes-2023-02-04.htm page exist before creating a link to it or not.
  Unclear why this happens, no definate pattern. Tried a few things but could get something that would firmly and consistently work.  Finally employed a try catch block to at least cause the "network error" to not block execution of the rest of the page scripts.
  Workaround added 2023-02-10 (Website, Current/Latest Session Web Page)
   
• Red Alert "Program Hung,  AstroMain UI appears to have stopped responding (2023-02-09 13:54).  Alert raised during General Session on 2023-02-09 at 13:54:58.  This was 25s after program start and 20s of ObsServices start, and occured whilst Focuser1 (TCF-S) service wasbeing started. The alert is likely to be transient / start-up bug rather than an actual UI hang.  UT was certainly working ok at 17:13 and 19:50. Regardless of the reason for the alert, there should have at some stage been a green all-clear issued at some point  and there wasn't. Issue happened whilst running a prelininary build of AstroMain 3.61.1.  Change made to ObsOverseer so that alert won't be raised with 60s of starting the GUIchecker, and show now report All Clear if previously hung UI starts responding again.
  Fix attempted 2023-02-09 (AstroMain 3.61.1)
   
• Temperature graph (16h) doesn't show  temperatures graphs centered in Y range (2023-02-10).  The 16h temperature graph (vwsGraph23) shows all the temperature lines (temperatures values 5 to 7.5°C) bunched up at top of graph (with -4 to 8°C range). May be due to the OTA Temperature data having vcNull (-99) values through the 16h time period of the graph due to the TCF-S Focuser being offline.   GraphID 23 uses a special routine, 'SpecialGraph23SetUp()', to setup the Y range of the graph.  No obvious flaws in the code.   Running in debugger and stepping through code shows that the
  OTA.Temperature has value .  Looking at the ObsEnv data file show field had value -274 at 2023-02-10T00:44:41Z (straddled by values of -99.0 & -99.0).
  Some other anomalies  Issue mitigated by modifying SpecialGraph23SetUp() to ignoring datavalues <-15 for setting the Y axis range.  But what has caused the anomalous value of -274 ? Correlating the time of the anomaly with activity in AstroMain, it seems that it occurred during a period when attempts were being made by ObsServices to restart the Focuser1 (TCF-S) and a time when ObsOverseer reported that the ObsManager was temporarily frozen. So likely a random glitch / rare timing issue.
  Fixed  2023-02-10 (AstroWeather 1.19.10 )  
  
  (Note: A value of -274 in field 12 (.DomeMilliAmps) of ObsEnv file at 2022-11-23T23:31:12Z  and other points with value -298 and -267 proved to be a red- herring).
   
• Program entered a loop state trying to "Restart Focuser 1"  (2023-02-10).  The AstroMain program was restarted after installing a new development build of 3.61.1.  Day Services were started including Focuser 1 (TCF-S).  At this time as the focuser was disconnected from its handbox (due to temporary removal from visual back in oder to use new Lynax SCTCooler to dry out the inside of the LX200 telescope tube) and the TCF-S focuser couldn't be connected.  AstroMain recognised a problem and attempted to Restart Focuser 1 (TCF-S) as per design including a power reset .  However as the TCF-S focuser was not physically connected it the 'percieved issue'  couldn't be solved by the 'RestartFocuser1() routine.  Faced with failed connection  AstroMain went into a loop trying in vain to restart the Focuser. The program was halted after the AstroMain had made its third attempt to Restart Focuser1. AstroMain was restarted again and the Focuser1 (TCF-S) service turned off before starting Services.   It should be possible to stop the looped attempts to Restart Focuser 1 by unchecking the Focuser1 Service , but this didn't work. During this process the ObsOverseer reported that Obs.Manager is pending in 'Monitor For Change in TCF-S Monitor' section. 
  Obs.Manager, Foc1Port:  Fail   Foc1 Port has changed at 2023-02-10 00:41:54
Obs.Manager, Foc1Port:  Fail   Foc1 Port has changed from to COM5
  When the Power to Focuser1 is reset, this cause the Foc1 Port to change, which causes a secondary Check to come into play which probably should be overlooked whilst RestartFocuser1 is in operation.  Repeated "TCF-S Focuser hasn't been successfully restarted" message may indicate two restart operations happening in parallel ?  Some other messages "ObsManager still running at 20s timeout" and  "Obs.Manager has resumed again at 00:43:14 after 1.4 min"
  Fixed 2023-02-09 (AstroMain 3.61.2)
   
• ObsManager froze for 1.4 minutes  (2023-02-10 00:43).  Whilst  ObsService entered a loop trying in vain to Restart Focuser1( TCF) Service program,  ObsOverseer reported that Obs.Manager is pending in 'Monitor For Change in TCF-S Monitor' section.  and log message indicate that ObsManager is frozen.  (e.g. Obs.Manager is frozen (74s) in 'Monitor For Change in TCF-S Monitor' &  "ObsManager still running at 20s timeout". Later on it was reported that  "Obs.Manager has resumed again at 00:43:14 after 1.4 min" .  Issue is most-likely a sideeffect of  loop that calls RestartTcfFocuser().  Issue is probably resolved by fix that stops repeated calls to RestartTcfFocuser(). is Focuser1 Power is off.
  Believed resolved 2023-02-09 (AstroMain 3.61.2)
   
• ObsViewer not showing Focuser1 as Red Flag & Power Is Off , when power was off.  ObsViewer showing Yellow Flag when power was off. Issue was due to ObsViewer using MonitorFoc1PowerState when it wasn't getting set by ObsMonitor as objFocuser1 wasn't connected, which hide the assignment of MonitorFoc1PowerState. Issue fixed in AstroMain 3.61.2 by not using MonitorFoc1PowerState (variable removed) and using Focuser1.PowerState instead (much more direct).
  Fixed 2023-02-09 (AstroMain 3.61.2)
   
• ObsWorker putting out multiple log messages 'Tube Temperature is vcNull (2023-02-10).  Focuser1 is not connected as Powerble removed) and using Focuser1.PowerState instead (much more direct).
  Fixed 2023-02-09 (AstroMain 3.61.2)

• Add 'Zwo' buttons to AstroMove's Session Tab that will open sessions Zwo/SharpCap folder.
  Done 2023-02-05 (AstroMove 1.10)  
   
• Add assisted image linking facility to AstroMain's existing set of manual directed image linking. In event of a condensation/dew issue with the LX200 images that are focussed and visually seem to contain enough stars, fail to image link via CCDSoft.  Problem is that CCDSoft Image Inventory is only able to find say 2-4 stars which is then reported as a failure, the condensation suppresses the peak of the star and SExtractor simply doesnt recognise them as objects using normal settings. However it is feasible to Image Link such images manually in TheSky6 after pasting image into the Virtual Sky.  AstroMain should either go ahead with a Simple Link operation anyway (when using this new facility), or after the CCDSoft.Image.InsertWCS operation, which puts the image into the virtual sky,   cntl-D keys can be sent to TheSky6 to trigger the Link Wizard, the required information (dObjectRa, dObjectDec, dScreenRotation) can then probably be accessed via TheSky.RASCOM.TheSky object. Calling TheSky.ImageLink (dImageScale, dRa2000, dDec2000) might do the same.  Solution implemented in AstroMain 3.61.1 with the use of a new checkbox 'Disable Star Check' on Scope/ Sync & Align tab.  If checked the requirement for a minimum of 5 stars is disabled & images with only 2-4 Inventory Objects can proceed to further linking attempts.  It does this by allowing the ValidateStarCount() function to return True.
  Solution implenented 2023-02-06+ (AstroMain 3.61.1+)  
   
• Provide facility to allow scale bar to be drawn of correct size on annotated image where the original FIT image isn't available for linking or won't link for some reason. With a task to create an annotated picture of NGC 1501 where the source image was a 50% scaled, processed picture in .png format the image's base file name was set in Image Sets/Image tab and the file imported from the Store folder ok.  PIcture was created with a scale bar that was based on plate scale of a 3x3 binned SBIG picture and wasn't correct for the picture created. Drawing the scale bar in ImageBuilder.DrawScaleBar requires two things: PlateScale (scale of source image in "/px and the Image Scale (the factor that image is scaled by ).
  PlateScale comes from objConsole.txtObjImagePlateScale.Text field and can thus be set by the user. 
  Closed 2023-02-06+ (AstroMain 3.61.1)  
   
• Get AstroShCap to send the SetNo to AstroMain when starting an image set.  Although the set no is sent at the completion of the image set it would be useful to send the set no. at any earlier stage for information/reporting in AstroMain (this is useful for the case that the Image Run is aborted part way through). Implemented via a new ShCap Event called SetNoSelected
  Done 2023-02-07 (AstroMain 3.61.1, AstroShCap 1.3.15)  
   
• DecMode set for imaging C/2022 E3 (ZTF) wasn't appropriate because of the rate and direction in which the comet was moving. Bi-directional Dec guiding isn't used due to the relatively high Dec backlash on the LX200 Scope and therefore unidirectional Dec guiding is used instead.  AstroMain's Guide Manager selects to guide either North or South dependant on which side of the Meridian the telescope is pointing and the known drift tendancy of the mount associated with its current small Polar Alignment error. This works well for normal sidereal targets, but in the case of C/2022 E3 (ZTF) which is presently moving particularly fast across the sky the direction of movement was opposite to and much bigger than the polar alignmen error related drift.   Resolved in session by flipping the Dec Guide mode from 'North' to 'South'. In such a situation it is appropriate that AstroMain examines the comet's expected direction of movement and make appropriate call to adjust the Dec Guide mode accordingly. The need for such assessment has been previously recognised for objects like comets and meteors, but this is the first case where the discrepency between the comets rate of movement and the Dec Guide mode has been so noticeable. First pass solution implemented in AstroMain 3.61.1 where Guider.StartGuider()  and Guider.StartPHD2Guiding() changed to include RateOfDecMotion as a parameter and a new routine is  SetDecModeFromScopePositionAndObjectMotion(RateOfDecMotion)  is used to select and set DecMode.
  Done 2023-02-09 (AstroMain 3.61.1)  
   
• Adjust Guide ROI to minimise chance of guide star drifting out of field view when using lock shift set by comet motion. Depending on direction and rate of comet motion a guide star might move out of field of view if selected in a suboptimal position.  So for a fast northward moving comet we don't want a guide star in the southern part of the Guide Cam's FOV, equally for a fast southward moving comet we don't want a guide star in the northern part of the Guide Cam's FOV.  Changes made to StartPHD2Guiding() routine to achieve this. Additonal changes needed to provide the routine with RateofRaMotion.  The new routine was successfully tested out in session S1098  (see Fig 1 showing the chosen Guide ROI, and position of selected Guide Start (F1 picture), and position of Guide Star at end of guiding period (F2 picture)
  Done 2023-02-09 (AstroMain 3.61.1)  
   
• If the Use 'TCF-S Focuser' service is checked the ObsOverseer/ObsManager should respond to the TCF-S focuser going offline by restarting the service. A backdoor facility is available to the user to 'Restart TCF-S Service' but the user will only respond by using it if the outage is noticed by the user via an alert or by noticing an outage in OTA temperature data in one of the Observatory Conditions charts on website The ObsManager is in a better position to respond quickly to an outage. A new code section 'Check Focuser1 TCF-S' has been added to ObsManager Main Loop which reports and records any outages of the Focuser1 (based on MonitorLastValidFoc1TemperatureTime,  set when Focuser1.PreciseTemperature <> vcNull (ie objFocuser.Temperature doesn't produce an exception) )
  Solution attempted, need to monitor for issues  2023-02-08  (AstroMain 3.61.1)  

[ Prev | Next ]

Back to Top

2023-02-09

Guiding for Comets

Back to Top

Lymax SCT Cooler

A Lymax SCT Cooler for 12" SCT (Lymax CosmicOne SCT Cooler R3) arrived today 2023-02-09 and was straightaway employed to help dry out the inside of the LX200 telescope.

The acqusition of the SCT Cooler follows from an incident during session S1088 (2023-01-18) when snow slid off the observatory dome's shutter onto front of LX200 telescope when the shutter was opened following a heavy snow shower, leading to some water and humidity entering the telescope tube (See notes). This led to significant problems with condensation/dew forming on the inside surface of the LX200s corrector lens and on the primary mirror, suppressing the light transmission through to the SBIG CCD Camera, and effecting the quality of collected images and in some cases preventing the use of the main scope for target imaging.  Problem was particularly bad during session S1095 session (2023-02-04).

Several attempts to reduce the dampness / humidity were tried but none of the following attempts have worked i) blowing (hot) air into tube with hairdryer, ii) sucking air out of the tube with a vacuum cleaner, iii) running dewheaters at max, iv) placing desicator in a muslin back at the visual back.  Further attempt was made 2023-02-05 but this always failed to get rid of the condensation.  Warming the front of the telescope with dew heater is insufficient to fully lift the condensation on the inside of the corrector lens. Using a hair dryer lifts the dew/condensation but it merely recondenses on the primary mirror.  After the corrector lens cools down the condensatton move back to the corrector lens.  Opening the virtual back is uanle able to let the humid air to be expelled /replace.

Removal of the corrector lens to allow the humid air to be fully expelled from the telescope tube was considered but rejected out of concern about damaging the lens or upsetting secondary mirror alignment. 

In the end it was decided that despite the quite high expense a Lymax SCT Cooler would be purchased as online posting had indicated that it might be useful for the purpose required (to expell humid air and replace by lower humidity air) even it wasn't the advertised purpose of the Lymax which is to quickly cool a warm telescope.

The TCF-S focuser was removed from the virtual back and the Lymax SCT cooler plugged into a 5V USB Power Supply, and after testing it the long end of the cooler was inserted into the telescope, ensuing that the end didn't hit the secondary mirror. It was found that the Lymax Cooler had to be pulled slightly out in order to allow internal air to be expelled through the 4 vents it has (when the Lymax was fully inserted these vents where block, the virtual back adapter (used for TCF-S adaptor) has a larger opening than the 2" size expected by the Lymax). This proved not to be a problem with the telescope tube lying in a horizontal position.

A hair dryer was initially used to lift the dew/condensation by warming the front of the LX200 corrector lens, the rear cell area and by directing warm air into the SCT Cooler's Air Intake in order to warm the inside of the scope.  The SCT cooler was then left to run for 16-18 hours. All condensation disappeared.

The Telescope was successfully used in session S1096 (2023-02-10) with no signs of any condensation.   Transmissibility through to SBIG Camera returned to normal levels.   The Lymax SCT Cooler proved itself as a total success (price is still a judged to be bit high but it did resolve the significant issue that was affecting observations in the past 2-3 weeks.

Photo showing snow /ice on front of telescope optics (photo 2023-01-17)		Photo showing condensation still present inside telescope at end of following session  (2023-01-19)
Photo showing condensation still present inside telescope  following session S1095 (2023-02-04)		Photo showing condensation still present inside telescope  before using Lymx SCT Cooler (2023-02-09)
Lymax SCT Cooler (end view)		Lymax SCT Cooler (side view)
LX200 Visual Back (TCF-S Focuser disconnected and removed)		Lymax SCT Cooler inserted into Visual Back (Lymax's long tube inserted into Baffle Tube & into interior of LX200)
Lymax SCT Cooler fully inserted 'exhaust ports blocked')		Lymax SCT Cooler pulled slightly out to expose the exhaust ports

Back to Top