David's Astronomy Pages Notes - Session 782 (2020-05-13)

Notes (S781)

Notes Main

Home Page

Notes (S783)

	Session Aims & Highlights
	- Observing Result  - Night Summary Plot  - Session Event Log
	Operational Issues
	- Critical Issues (0),  Major Issues (0),  Minor Issues (9),  Continuous Improvement (19)
	Images from 2020-05-13 >>
	PHD2 - Version 2.6.8
	Dome Relay Testing
	2020-05-15
	Dome Relay Repair
	Pegasus UPB - v1.5.0
	GRB Alert Review

Session Aims & Highlights (2020-05-13)

Main aims

1. Software Testing: Test new 3.22.1 version of AstroMain which has had multiple changes since 3.21.6. Check for absence of introduced bugs / new issues. Check bug fixes and new features/enhancements
2. Targets: Acquire images of a number of targets if conditions allowed.   Weather conditions forecast to be marginal.

Equipment & Software

• 12" LX200 and ST-10XME
• 80mm APO and ZWO ASI 178MC
• CCDApp2, TheSky6, CCDSoft5, PHD2,  POTH Hub
• Pegasus UPB & Motor Focus, TCF-S
• SharpCap 3.2, PHD2  2.6.8
   
• AstroMain 3.22,  AstroGuard 1.2.11,   AstroPlan 1.14.4,  AstroShCap 1.2.22, AstroVOE 1.3.6, UPB 1.4.17 
  (AstroWeather 1.9, AstroAllSky 3.5.1)
  

Highlights

• Software Testing. Testing of new 3.22 version of AstroMain was largely successful.  No major issues were found and the majority of bug fixes/ new features in new version worked well.
• Rain Protection.  Weather Data Comms & Obs.Manager operated well and closed the observatory dome at 23:44 when rain threat & cloud developed ahead of a light rain shower that came through at 23:58 to 00:02.

Lowlights

• Cloud.  Skies were cloudy for most of night and only 1 target was successfully imaged

Summary Plots & Logs

Observing Plan

Observing Result

Dome & Scope Slewing Performance

Slew/Centering Performance

Guiding Performance

Sky Conditions (Locate Frames)

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

Pre-Session Weather Forecast (API data from darksky.net) Pre-Session Weather forecast showed variable skies range from 5 to 50% cloud cover,  light winds (wind 7mph) and a minimum temperature of 6°C. In the event conditions were clear and calm through the whole night, with a minimum temperature of around 4°C

Session Event Log

Time     Event Detail 23:53:56 Session Created Live Session Created (2020-05-13 S00782, ImageSaveNum: 782001) 23:54:10   Obs.Manager Started Obs.Manager started 23:54:12   Obs.Overseer Started Obs.Overseer started 23:54:16   Services Started Observatory Services started 23:54:29   Scope Switched On Telescope Power has been switched on via UPB Powerbox. 23:56:16   Services Started Observatory Services started 00:01:45 Observatory (Auto) Observatory placed in Fully-Automated Mode 00:01:47 Session Pending Session pending (2020-05-13) 00:01:49 Session Initiating Session initiating (2020-05-13) 00:01:51   Plan Requested Observing Plan requested from AstroPlan (1.14.5) 00:02:12   Plan Loaded Observing Plan loaded to queue (2020-05-13 V1 BEST PLAN, Plan ID: 510) 00:02:26   Camera1 Connected SBIG Camera Connected (set point -20°C) 00:02:31   Telescope Connected Telescope Connected (TheSky6) 00:02:43 Session Equilibration Session ready for dome & camera equilibration 00:03:28   Shutter Opened Shutter opened (opening time 45s) 00:03:32   Equilibration Started Dome Equilibration started 00:05:49   Equilibration Ended Dome Equilibration ended (2.3 mins total) 00:05:51 Session Running Session running 00:05:53   Queue Started Observing Queue started (10 targets selected) 00:07:48     Target Started (1/10) Target started (1/10, NGC 3643) 00:10:29       Focusing Started Foc2 Focusing Started (Secondary Scope, using ShCap) 00:12:45       Focusing Completed Foc2 AutoFocus Completed (Profile No 1) 00:13:46       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 00:16:51       Focusing Completed Foc1 AutoFocus Completed (Profile No 2) 00:33:02     Target Completed Target completed (1/10, NGC 3643) 00:33:04     Target Started (2/10) Target started (2/10, M61) 00:36:28       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 00:39:34       Focusing Completed Foc1 AutoFocus Completed (Profile No 3) 00:55:26     Target Completed Target completed (2/10, M61) 00:55:29     Target Started (3/10) Target started (3/10, NGC 4277) 00:57:53       Focusing Started Foc2 Focusing Started (Secondary Scope, using ShCap) 00:59:58       Focusing Completed Foc2 AutoFocus Completed (Profile No 4) 01:00:44       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 01:03:45       Focusing Completed Foc1 AutoFocus Completed (Profile No 5) 01:19:23     Target Completed Target completed (3/10, NGC 4277) 01:19:25     Target Started (4/10) Target started (4/10, NGC 5157) 01:22:41       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 01:25:50       Focusing Completed Foc1 AutoFocus Completed (Profile No 6) 01:41:25     Target Completed Target completed (4/10, NGC 5157) 01:41:27     Target Started (5/10) Target started (5/10, UGC 9977) 01:44:15       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 01:47:02       Focusing Completed Foc1 AutoFocus Completed (Profile No 7) 02:02:47     Target Completed Target completed (5/10, UGC 9977) 02:02:49     Target Started (6/10) Target started (6/10, GCVS U Her) 02:05:35       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 02:09:02       Focusing Completed Foc1 AutoFocus Completed (Profile No 8) 02:16:35     Target Completed Target completed (6/10, GCVS U Her) 02:16:37     Target Started (7/10) Target started (7/10, UGC 10528) 02:18:40       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 02:21:24       Focusing Completed Foc1 AutoFocus Completed (Profile No 9) 02:37:05     Target Completed Target completed (7/10, UGC 10528) 02:37:07     Target Started (8/10) Target started (8/10, M92) 02:50:19     Target Completed Target partially completed (8/10, M92) 02:50:21     Target Started (9/10) Target started (9/10, HIP 87937) 02:53:03       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S) 02:55:51       Focusing Completed Foc1 AutoFocus Completed (Profile No 10) 02:58:55     Target Completed Target partially completed (9/10, HIP 87937) 02:59:12     Target Started (10/10) Target started (10/10, GCVS CY Lyr) 03:06:51 Critical Cloud Alert Critical Cloud Alert (Obs.Manager will close the Shutter) 03:06:53   HardSuspend Called Hard Suspend is called due to Critical Conditions (cloud) 03:07:38     Target Aborted (10/10) Target aborted (10/10, GCVS CY Lyr) due to cloud 03:07:40   Queue Paused Queue pausing for HardSuspend 03:07:58 Session Suspended Session suspended 03:08:48   Shutter Closed Shutter closed (closing time 50s) 03:12:35     Target Cancelled Target cancelled (10/10, GCVS CY Lyr) due to cloud 03:13:02   Queue Completed Job Queue completed 03:13:24 Session Closing Session closing 03:13:41   Shutter Closed Shutter already closed (closed at 03:08, closing time 50s) 03:14:17   Dome Parked Dome parked (parking time 36s) 03:14:54   Telescope Parked Telescope parked (parking time 9s) 03:15:24   Scope Switched Off Telescope Power has been switched off via UPB Powerbox. 03:22:58   Services Stopped Night Services stopped 03:23:00 Session Housekeeping Housekeeping Started (Cleanup FITS, Create Fits Summary, Transfer Files) 03:23:05 Session Finished Session Finished

Session Alerts

Time     Alert Detail -- No Alerts                --

Back to Top

Operational Issues (2020-05-13, S782)

• Critical Issues (0)
• Major Issues (0)
• Minor Issues (9)
• Continuous Improvement (19)

[ Prev | Next ]

Critical Issues

• None

Major Issues

• None

Minor Issues

• AstroMain UI Not Responding from 02:57 onwards.   Problem began whilst taking images frames for Target 9/10 (HIP 87937) and significantly didn't occur when user was making any input to AstroMain or the computer. This issue has often noticed before when user clicked on AstroMain form and it was ambiguous what the exact cause was.   In this case messages reporting that Obs.Worker Thread had become frozen appeared around  30s after the first frozen UI message. Whilst the UI and Obs.Worker remained frozen under the end of the session the execution of the Job Queue and Obs.Manager tasks continued without incident and importantly the Observatory was closed down normally at the end of the planned session (i.e. shutter closed and dome & telescope parked etc).  The UI not responding & frozen Obs.Worker messages stopped when the Observatory returned back to a general session at 03:23.  The UI was responding entirely normally when AstroMain was examined in morning over a remote connection.    Investigating shows the start of the problem began at the same time that there was a failure to acquire the 9th image frame for HIP 87937. The report file shows:
      Taking 2s image (C)... Failed ()
  and log file shows
      Camera.TakeImage      Fail    |  Error during TakeImage
  It's not possible to say whether a problem taking the Image via CCDSoft prompted the non-responsive UI & frozen Obs.Worker thread or whether the camera problem was a consequence of the frozen UI/Obs.Worker, or whether both were caused for some other hidden problem.  A little later whilst trying to take a locate frame for Target 10/10 (GCVS CY Lyr) the Obs.Overseer service reported a problem with the operation > Obs.Overseer                Warning   Camera.TakeImage task in TakeImage/TakeImage is taking a long time? (03:03)
  Other possible sideffects/consequences of the problem appear to have been
  a) a repeat attempt at final target (10/10, GCVS CY Lyr) - not sure if this was related or was an independant problem
  b) a flat lining of CCD Temp & Cooling Power curves on CCD Temperature chart for 25  minutes between 02:57 and 03:22 (end of Monitor file) data didn't capture the CCD camera cooling being turned off at 03:16.
  b) an unexplained gap of around 6 minutes at the end of Session Closing, between turning of CCD Camera and the point that Night Services where recorded as being stopped (normally this is less than 30s). This suggests there was a problem in stopping one of the Observatory Services (presumably the Obs.Worker Service which was frozen).  Issue closed on 2021-01-04 following a review that showed that the AstroMain was essentially stable (following a series of improvements and fixes), with an absence of any unexplained program hangs or crashes during the 35 sessions between  2020-09-18 & 2021-01-03.
  Closed 2021-01-04 (AstroMain)
   
• Final Target appeared to repeat itself.  After starting the final Target (Target 10/10 GCVS CY Lyr) at 02:59 and whilst make failed attempt to centre the target (due to failed Camera operations) a Critical Cloud Alert was sent at 03:06:51 following by Hard Suspend request at 03:06:53.  This led to the Target 10/10 aborting at 03:07:38, the session moving to Suspended State at 03:07:58 and the shutter fully closed at 03:08:48. Rather than finish the session at that point, suspension continued and Job queue switched to a second attempt at Target 10/10 which was held waiting due to the continued state of suspension due to Cloud. Finally at 03:12:35 Target 10/10 (take 2) was cancelled due to Cloud and the Queue terminated at 03:13:02.  Reflecting on the operations:  whilst it was confusing to see Target 10/10's aborted event at 03:07 followed 5 minutes later by Target 10/10's cancelled event at 03:12, the behaviour is actually as per design:   in the event of a suspension rather than fully abort a target the Job Queue manager tries to retain the ability to continue or restart the target in case weather conditions clear and there is still time to acquire data from the target before its time slot ends.   This logic was introduced as there had previously been cases where the telescope & camera where left idle for 15+ minutes after a short suspension because there was a time left  to the start time for the next target.
  Closed 2020-05-14 (AstroMain)
   
• 'Take Auto Flats' appears to cause AstroMain to hang.  Whilst testing AstroMain's flat frame acquistion on development computer, the AstroMain UI become non-responsive immediately after clicking the 'Take Auto Flats' button .   After killing the program and trying again it was found that the same problem happened again. Investigating this time it was found that the UI stopped responding whilst it took a 1s, 2s, 4s, 8s & 16s trial flats before finally putting up a dialog box requiring user confirmation to continue or cancel. which may not be noticed or become hidden behind the main window.  In a live session a 1s or 2s image would normally be sufficient to check the flat field strength and quickly return the dialog box to the user.  In test environment the Camera Simulator returned a completely black frame and this is why the routine tried longer and longer exposures.  The routine clearly needs to be run as a threaded operation, so that UI remains responsive throughout.
  Fixed 2020-05-14 (AstroMain 3.22.2) 
   
• Obs.Manager picture on Current Session & Observatory Status webpages is missing data and is displayed as a gray rectangle.  There is a problem with the generation of Session.ObsManagerTab.png  during general session 2020-05-15 (using AstroMain 3.22.2 beta).   Opening the Obs.Manager Tab in AstroMain on Observatory Computer fixed the problem.  Normally the Tab would always be opened in a normal live session, but in this case this didn't happen after AstroMain was restarted with a new version. It would seem that the opening code needs to automatically display the Obs.Manager tab for a moment to 'initialise' it for display.  Issue has occurred in Aug-Sept sessions and is deemed to be resolved and can be closed.
  Closed 2020-09-18 (AstroMain)
   
• Observatory Shutter Health Charts show flat data lines where temperature, voltage, current go flat and show the same values for up to several hours at a time. This has been noticed previously but has not been previously resolved.  There are two aspects to the problem a) fixing the data source so that flat data isn't produced, or output with vcNull values and b) recognising that data has become flat in AstroWeather charts routine and showing a gap instead of flat lines. This ticket refers to fixing the Charts routine to recognise and suppress the display of flat line data. A separate ticket refers to resolving the occurance of flat line data read from Pulsar Dome ASCOM trace files.
  Fixed 2020-05-15 (AstroWeather 1.9.2) 
   
• After starting Job Queue Execution the Scope slewed to a Near Zenith Focus Field but no focusing was undertaken and instead the scope immediately went off to start Target 1/10 (NGC 3643).  The session was projected to start running at 00:03 ahead of commencing the Target 1/10 at around 00:10 (2 minutes before the Plan's scheduled start time at 00:12), providing 7 minutes in which to complete main scope (Foc1) and secondary scope (Foc2) focusing.    In the event the session left the 'Equilibration' state and entered the 'Running' state at 00:05, whereupon the scope slewed to the selected Near Zenith Focus Field.   Instead of performing the expected focusing at the Near Zenith Focus Field location, execution went directly on to 'start' Target 1/10 at 00:06, reporting target information and then waiting  for 1.3 minutes until earliest start time for target at 00:07 (5 min before Scheduled Start Time) afterwhich the scope was slewed to Target 1/10 to begin the target observations.    [ Code uses a boolean variable 'ActivatedAutoFocussing' which is set to either true or false at several points in the code, but doesn't appear to be used - it doesn't appear in any ' IF' statements,  another boolean variable 'bScopeIsFocused' is used to indicate if scope has been focused or not ].  Problem fixed - a 'Exit Sub' statement had been accidently left in place from earlier code testing and hadn't been removed prior to release of version 3.22.2 onto Observatory Computer.
  Fixed 2020-05-16 (AstroMain 3.22.3) 
   
• Session entered 'Running' state 2 minutes later than had been expected from the time listed during preceeding 'Equilibration' State. The session was projected to start running at 00:03 ahead of commencing the Target 1/10 at around 00:10 (2 minutes before the Plan's scheduled start time at 00:12), providing 7 minutes in which to complete main scope (Foc1) and secondary scope (Foc2) focusing.    In the event the session left the 'Equilibration' state and entered the 'Running' state at 00:05, whereupon the scope slewed to the selected Near Zenith Focus Field.  Assuming 7 minutes for Foc1+Foc2 focusing Target 1/10 would have started at its schedulued start time, but not 2 minutes earlier which is the designed bias to always begin targets slightly ahead of time.  Examining the current code (AstroMain 3.22.2) shows that if < 4 minutes of equilibration time have occurred (where dome is open & rotated into direction of the wind), the Starting Run Time will be pushed out but not by such much that the Plan Start Time will be delayed.   Since the Plan was generated after the Scheduled Sun Alt start,  the schedule builder sets just a minimum amount of time between the moment the plan is created and the Plan Start Time. Decision made to close the issue following introduction of new code in AstroMain 3.29.4 in late Sept 2020 to set the plan start time according to the required pre-queue tasks (near zenith focusing etc)
  Closed 2020-09-29 (AstroMain 3.29.4) 
   
• Main Image ( #782072 ) was saved as Locate Frame style picture. JPG images from image #782072  (frame 8/15 from Target 9/10 (HIP 87937)) was annotated with the locate name 'Locate 2'.  Furthermore the Small Size Picture (loaded to website) had a white centre cross drawn on it. Again this is an indication that it had produced in the ConvertFitsToJpg routine with SaveType 1, rather than SaveType 2 or SaveType4.   This happened around the time of a problem taking images with CCDSoft.   The 9th frame failed as did 1st and 2nd locate frame attempts for Target 10/10 (GCVS CY Lyr). It would seem that for each of these attempted targets the ConvertFitsToJpg was called, but the process reused the #782072 Fits Image overwriting the prior JPG file in turn, until reaching the Locate 2 attempt from CY Lyr when the session effectively ended (this was 'suspension' due to cloud following by 'closing' after  CY Lyr's timeslot ended).   Ideally the code should recognise that Image capture had failed and not call the SaveImageToJpg/ConvertFitsToJpg routines.
   Closed 2021-02-07 (AstroMain)
   
• When starting Powerbox and Telescope Services at the same time at start of session the connection to POTH.Telescope fails.   The telescope service checks don't get  give a expected message box asking user if Scope Power can be turned on' and the routine proceeds to attempt connecttion to POTH.Telescope but fails (as scope power is off). Problem happens on Observatory Computer during a Test Session but not the Development Computer.  Initial guess was that in the case of the observatory which is dealing with physical devices the PowerBox connection isn't perhaps fully up and running in time and an inappropriate reply is given to the check on whether scope power was on or not, a problem which doesn't happen on development computer which is using Simulated Devices which fire up almost instantanously in comparison. Checking Report Logs shows that PowerBox connection is automatical started when opening the Observatory Program and is thus already deemed as running by the time the user toggles the 'Use' Telescope Service option and then clicks on 'Start Services' .Examining the code for 'StartPowerBoxServices()' shows the a potential cause of the fault.  When routine is running it initial sets several flags including setting 'Obs.bPowerboxConnected' to False, but after establishing in this case that PowerBox Switch service is Already Running and 'Obs.bPowerboxConnected' is set to True at the end of the routine, before the ' Scope.Connect("POTH.Telescope") routine is run.  Examining the code for Scope.Connect shows for Obsrevatory Computer (i.e. not Laptop10) the Scope.Power state is only checked and the power turned on if a 'Live' session is being run; Power State is not checked for a 'Test' session.   If testing using a simulated telescope, one wouldn't want to turn on the power to live scope, but when testing using real scope one would (but would have to do it using a separate 'Turn On Scope Power' button .   This is a current design limitation . Issue is deemed as closed (potential to open a continuous improvement ticket regarding design logic when running a Test Session)
  Closed (AstroMain)

Continuous Improvement

• Add 'Sun Alt' to the Obs.Viewer picture. Add sun alt value and associated traffic light flag to Obs.Pic and reposition Star's value and flag
  Done 2020-05-13 (AstroMain 3.22.1) 
   
• Increase number of TargetInfo Charts displayed on Current Session Webpage. Number of TargetInfo Charts displayed on website to be increased from 2 to 4. Requires changes to AstroMain, AstroPlan and Website (session_current.htm)
  Done 2020-05-15 (AstroMain 3.22.2, AstroPlan 1.14.6, Website) 
   
• Add Legend  for Curves on Wind Graphs.  Add legend for Wind Speed and Av Wind Speed (GraphID, 4, 9, 49)
  Done 2020-05-15 (AstroWeather 1.9.2) 
   
• Adjust position of Curve Key Legend for DPD &Temp Difference Charts. Move legend from Top to Bottom so that it is less commonly overposted by the curves themselves (Graph ID, 8, 37, 38)
  Done 2020-05-15 (AstroWeather 1.9.2) 
   
• Make further refinement in the position of Curve Key Legend for DPD, Humidity, Temp Difference & Dew Heater Charts to best avoid grid lines and data curves.  (Graph ID, 16, 17, 18, 31, 50, 51)
  Done 2020-05-16 (AstroWeather 1.9.3) 
   
• Filter out OTA.Temp points which have flat-lined before plotting Charts and before being used for calculating OTA.Temp differences etc
  Done 2020-05-16 (AstroWeather 1.9.3) 
   
• Deprecate use of 15 min wind graph and wind meter graph on website. Graphs vws1325 and vws1472 are no longer use and computer performance / bandwith use can be improved by removing them from vws
  Done 2020-05-16 (VWS & Website) 
   
• Change Dome Speeds to deg/sec instead of deg/min in order to be easier to compare with telescope slew speeds.  Change effects calculation of Dome Speed,  and the Speed units reported in Report File, Log File, SlewTable & Dome Chart
  Done 2020-05-16 (AstroMain 3.22.3)  
   
• After clicking 'Open in AstoPlan'  it would be helfpul if AstroPlan's TargetForm appears as the topmost windows form.   Whilst the specific object/target opens up in the form, it may be buried below other windows, requiring extra navigation by the user.
  Done 2020-05-18 (AstroMain 3.22.3)  
   
• Create new system / process for bringing attention to critical session alerts. Critical alerts are ones that affect the safety of the observatory and the productivity of the current session. At a minimum the critical session alerts should be posted to current _session web page, but may include other means such as Text Messages etc in future.   The recording of critical alerts in the SQL Database (like the recording of Session Events) shows one means by which this can be achieved.  Table 'sessionalerts' and AstroPlan Form 'Session Alerts' have been created. A new routine 'StoreSessionAlert' has been added to AstroMain to allow Alerts to be saved back to the database.  Alerts can be saved to an .htm table.(like Session  Events report). An 'Alert' flag needs to be passed to AstroPlan to tell it to regenerate the Alerts.htm file and the AstroPlan's web-uploader routines needs to be able to recognise a new Alerts.htm file and upload it to website.  Webpage needs to be modified to show the table of Alerts.
  Done 2020-05-18 (AstroMain 3.22.3, AstroPlan 1.15, Database 1.7,  Website)  
   
• Widen the Y range on DPD Charts  from -2 to 6, to a new range of -2 to -8 (GraphID 37 &  38)
  Done 2020-05-18 (AstroWeather 1.9.4)  
   
• Add '+' sign  to positive values on UPB Env Temp Difference box. (GraphID 43)
  Done 2020-05-18 (AstroWeather 1.9.4)  
   
• Add Outdoor Temperature to Temperature Difference from Outside Chart chart as a white ibe'+' sign  to positive values on UPB Env Temp Difference box. (GraphID 43)
  Done 2020-05-18 (AstroWeather 1.9.4)  
   
• Perform a Dome Relay test to confirm how Relay Changes are used by the Dome Control System: With Relay Safe, Shutter Open & 30s Relay Delay,  adjust Cloud Sensor Thresholds to make Relay Unsafe for 10s (ensure Changes Applied) then make re-adjust Threshold to make Relay Safe again.   Confirm that Shutter remains open and doesn't close. (for results see Dome Relay Follow-Up Testing 2020-05-19)
  Done 2020-05-19 (Observatory, Cloud Sensor) 
   
• Create new graphs showing Guiding Summary information for Ra and Dec. Current Guiding Summary chart shows total guiding RMS (ie Dec & RA errors combined). New graphs can use the parent GuidingGraph Type quite easily. New Chart  'Session.GuideSummChart2'  added for showing Guiding Summary by Ra & Dec   (Av RMS Ra& Av RMS Dec).  Uses the object GuideSummChart2 As New TGuideSummChart and is opened using GuideSummChart2.OpenChart(2).  (Note: the earlier GuideSummChart chart object is renamed as GuideSummChart1)
  Done 2020-05-23 (AstroMain 3.23)
   
• Create web page(s) showing Supernova observations by year. This will be a better way of appreciating SN image & graph data. and simplify the tasks of maintainance/duplication of earlier images on Session pages and size of Session Page. SN targets on session pages will have a link back to the appropriate  collection of images on the relevant SN by page (like is done with Comets).   Pages created for 2018-2021.  Decision made to close improvement item (2021-02-14) even though pages for 2017 (and before) have still to be created. Key thing is that these SN_by year pages are established practice for 2020/2021 and moving forward
  Largely done 2021-02-14 (Website) 
    
• Add new critical session alerts to relevant sections in AstroMain's observatory operation and monitoring . Critical alerts are ones that affect the safety of the observatory and the productivity of the current session.
  Largely done 2021-02-14 (AstroMain)
    
• Create new AstroSN application that monitors online resources/feeds for Supernova data and prepares suitable targets for automated scheduling Application will be a bit like AstroVOE which monitors of GRB Alerts.  Proof of concept application has been built and tools in place to allow backup of application and installation of application onto observatory computer.  Tool developed during Nov 2020.   Issue closed 202012-03 following released of AstroSN 1.1.
  Done 2020-12-03 (AstroSN 1.1) 
   
• Create new routines & code for protecting observatory in event of outage of key information (clarity, stars, rain data). This might include use of a Weather Risk for the session (input from data field) to indicate how uncertain or how risky use of observatory is without data, how much tolerance to an outage, 10mins, 1 hour etc.
  In Progress(AstroMain) 

[ Prev | Next ]

Back to Top

PHD2 - Version 2.6.8 (2020-05-13)

A new version of PHD2 Software (v2.6.8, dated 2020-05-03) has been installed onto the Development and Observatory Computers.

[ PHD2 Downloads (incl Change Log) :  https://openphdguiding.org/development-snapshots/ ]

Dome Relay Testing (2020-05-13)

A critical issue was posted on 2020-05-04 (S778) entitled Dome Relay Protection apparently not working.  During a day time test was being conducted involving the opening of the shutter from AstroMain.  It was light and the CloudSensor reported an Unsafe Relay condition.  It had been expected that the Relay condition would have triggered the Pulsar Dome Control unit to intervene to close the shutter after 30s of the start of shutter opening. However this didn't happen and the shutter remained open until it was closed from AstroMain. Having a reliable working Relay control system is a critical component to the safe operation of the Observatory, and hence this issue is deemed critical.

Following up on this critical issue a system test was carried on 2020-05-13. Test setup, results & conclusions  are given below along with proposed way forward

Set Up

• All ASCOM connections to the Pulsar Dome such as from AstroMain were closed (this is to stop any programmed operational of the dome)
• Pulsar Dome Software was used for accessing Dome Relay Settings and for Opening & Closing the shutter
• On the Settings Tab the Relay Delay was temporarily changed  to a value of 5s from the normal operational value of 30s. 
  (this was to allow the behaviour of the shutter opening /closing in response to Relay changes to be more quickly seen)
• On the Settings Tab Relay operation was changed between NC ( Normally Closed) and NO (Normally Open) monitoring states
• Cloud Sensor III software was used to change the Relay Thresholds in the Cloud Sensor Head to various achieve Safe and UnSafe Relays states
  
  An issue with the Cloud Sensor system meant that the Threshold Values couldn't initially be changed, but this was resolved by restarting the AllSky/Weather computer (Laptop7)

Results

• Testing with Relay Polarity set to NC (Normally Closed), produced a consistent result where
  - the Shutter would begin to automatically close 5s after initiating a Open Shutter operation 
  - this happened regardless of whether the Cloud Sensor Software was showing a Safe or Unsafe condition.
  
    NC Setting means the system expects  'relay closed' when it is not raining (ie normal conditons) and 'relay open' when it is raining
    Since the Dome responded by closing the shutter with the NC setting, the dome unit must have being seeing a continuously open relay,
    one that was 'open' regardless of the Cloud Sensor's view of the conditions being safe or unsafe.
  
• Testing with Relay Polarity set to NO (Normally Open) produced a consistent but opposite result where
  - the Shutter would fully open after initiating a Open Shutter operation
  - this happened regardless of whether the Cloud Sensor Software was showing a Safe or Unsafe condition.
  
     NC Setting means the system expects  'relay open' when it is not raining (ie normal conditons) and 'relay closed' when it is raining
     Since the Dome responded by allowing the shutter to fully open with the NO setting, the dome unit must have being seeing a continuously open relay,
     one that was 'open' regardless of the Cloud Sensor's view of the conditions being safe or unsafe.

Conclusion

•  The Dome Unit appears to be working correctly, responding entirely appropriately to an 'open relay' dependant on whether it a NC or NO Polarity setting was in operation
  
• The Cloud Sensor unit doesn't appear to be able to Open/Close the relay according to whether it viewed the conditions as Safe or UnSafe.  
  
• It is concluded that there is either a fault in the Cloud Sensor unit such that the relay remains permanently open
  or there is a break in the relay wiring or connections making the circuit permanently open (unable able to closed even if Cloud Sensor is closing its part of the circuit)

Way Forward

• Examine check/wiring from Cloud Sensor.   The circuit should be using the orange wire (common) and either the brown wire (normally open) or the white wire (normally close)
  
• Examine/check  connections
  
• Test circuit with meter
  
• Check Relay operation by manually closing the circuit

Back to Top

2019-05-15

Dome Relay Repair  (2020-05-15)

Following on from a 2020-05-04 critical alert and 2020-05-13 testing that demonstrated that the Dome Relay Protection system was not working investigatory checks were made today on the connections and wiring between the Cloud Sensor Unit and the Dome Control Unit.

The investigations seemed to show an issue with the wiring connections to the connector that plugs into Relay port on the Dome Control Unit, and  fresh wiring connections were made. 

Investigations were complicated by ambiguous Power Meter readings.  WIthout the connector in place there was a clear 12.8v  supply coming from the Dome Control. However with the connector in place and connected to the Cloud Sensor Unit there seemed to be no voltage reading when measuring voltage in parallel between the two leads entering the middle connector block or in parallel between the two leads entering the connector going to the Dome Unit.  However if one lead was disconnected from the middle connector block thus breaking the circut to the Cloud Sensor Unit,  a 12.8v reading could be obtained.   When measuring the voltage in series I can understand that a 12.8v or 0v  would depend on whether the relay circuit was open or closed.  But when taking a reading in parallel (bypassing the relay in the Cloud Sensor Unit I don't understand why I see a 0v reading

Anyway with the new wiring connections in place the Dome Relay Protection was retested with the same setup used for 2020-05-13 testing.

New Results

Tests conducted in daylight & overcast skies with a 5s Relay Delay and 'NO' Relay Polarity
(Note: Normally Open 'NO' is the polarity that my selected wiring is designed to work with)

Conclusion

• The Dome's Relay Protection is safely working again
  
  It is unclear if there definately was a wiring problem which caused the failures in the system (which have now been fixed)
  or there was some glitch in the Cloud Sensor Unit (which was somehow fixed when the Cloud Sensor unit happened to be rebooted)
  
  
• Above tests should be repeated at regular intervals to check that Relay Protection is working
  (see Dome Relay  Follow Up Testing (2020-05-19) )

Back to Top

Pegasus UPB - v1.5.0 (2020-05-15)

A new version of UPB Software (v 1.5.0) has just been released (May 2020) by Pegasus Astro.  The new version has been loaded onto Development Computer (2020-05-06) and Observatory Computer (2020-05-15). Changes in v.1.5.0 according to its change log are:

* Bug: Fix report of motor run during ASCOM UDP requests
* UI: New UI release fixes input boxes handling
* UI: Change colour in labels for night vision view
* Code cleanup and debug information added
* Graphs display refactoring

It will be interesting to see if new version fixes the earlier problem where the UPB Env Humidity values fall back to a constant value of 90% when the sensor humidity exceeds 97%. An AstroSuite software workaround is already used to overcome this issue.
(update: the Humidity Issue was fixed in the following v1.6.0 version installed on 2020-05-25, see notes)

[ Pegasus Astro Support Page:  https://pegasusastro.com/support/ ]

Back to Top

GRB Alert Review (2020-05-15)

'FastReact' is a variable used in AstroSuite to indicate a special target like a GRB that requires the highest priority fast reaction in order to observe it as soon as possible, immediately aborting any current target and immediately slewing the scope to the GRB target.

Whilst working with code in AstroMain it was noted that the variable is defined as integer type in ToO class objects but is defined as boolean type in  T Class objects . This is far from  ideal and there are cases where ToO.FastReact (integer) is used in statements like
   ' if ToO.FastReact then '  where FastReact integer variable is treated as boolean.

At first sight it looks like the variable should be boolean - the target either is or is not tagged as one that fast reaction actions should be taken.
Now its possible that in future there may be various types of FastReact object. This could prehaps be handle using an associated new FastReactType variable or by using one of the other existing variables, such as ToO Priority or TargetType.

Changing FastReact to boolean type everywhere will requires changes to 3 programs (AstroMain, AstroVOE and AstroPlan) whilst changing it to integer type every requires changes to just 1 program (AstroMain)

After consideration the code will be changed to FastReact to integer type. (ie changes only to AstroMain).

Back to Top