David's Astronomy Pages Notes - Session 629  (2018-09-14)

Notes (S628)

Notes Main

Home Page

Notes (S630)

	Session Aims & Highlights
	- Observing Result  - Night Summary Plot
	Operational Issues
	- Critical Issues (0),  Major Issues (6),  Minor Issues (7),  Continuous Improvement (2)
	Sky Flats
	Autofocussing / HFD Profiles
	PowerShell - Renaming Files for Animation Shop
	Images from 2018-09-14  >>
	New Development Laptop (Windows 10)  - Software Installation  (2018-09-17)

Session Aims & Highlights (2018-09-14)

Main aims

1. Comet 21P. Acquire images of comet 21P/Giacobini-Zinner
2. Targets. Acquire images for a selection of variable stars, nearby stars, comets and deep sky targets
3. HFD Testing. Test new routine for measuring the Half Flux Diameter (HFD) of a star
   (this routine that might be used in future for automated focusing instead FWHM  like in FocusMax method)
4. Sky Flats. Acquire further Sky Flats
    (routine was manually initiated,  when sun was at -0.9 deg altitude. Six flat sets were successfully acquired) 
5. Stability. Continue checking stability of the Observatory System (hardware & software) 

Equipment & Software

• 12" LX200 and ST-10XME
•  80mm APO and ZWO ASI 178MC
•  CCDApp2, TheSky6, CCDSoft5, PHD2,  POTH Hub

Highlights

• Comet 21P. Images of comet 21P/Giacobini-Zinner were successfully acquired . Fine centering of targeting was performed manually due to the absence of an up to date ephemerides for 21P.  A current 'comets.cmt' file for importing comets to TheSky6 was not available. [ The IAU Minor Planet Center (https://minorplanetcenter.net/data) have recently changed the format of their Ephemerides files including the one for Observable Comets, leaving me unable to load the information into my TheSky6 Planetarium Software, until I build a program to convert the new format to the old format. or otherwise devise a method of importing the data. My old ephemerides showed the comet some 3 arc minutes away from its actual position, which stopped me from quickly auto-centering the comet ]
  
  Data collected comprised:
  
  60 x 30s Clear Filter images with LX200,auto-guided on a star that will nicely show the motion of comet against the background stars once I put them together in an animation.  I will also prepare a set of these images where I align them on the comet and stack them to maximise any detail in the comet, its coma and tail.   I will also take a selection of the images and put through rotational gradient algorithm to see if there are any emergent jets of activity.
   
  9 sets repeating C (15s), B (30s), V (20s), R (20s) sequence where I auto-guided on the comet itself, which will hopefully give me a colour image once processed (first time I’ve autoguided on a comet. Comet showed a SNR of 12 in PHD2 and most of the raw images looked fine, some looked a bit dodgy through.
   
  19 x 15s Clear Filter images with the comet positioned so I could maximise the length of tail that I could get in a single field of view
  
  Through my piggybacked 80mm APO  scope I also took:
    12 x 10s Colour Images with the comet centered in FOV
    12 x 10s Colour Images with the comet positioned near edge of FOV in order to show as much of M35 as I could see.
  
  
• Image Data.  Images for a further xx Targets were successfully acquired
  
• Sky Flats. Six flat sets (15 frames for 6 different filter/binning combinations) were successfully acquired before the sky become too dark
• HFD Testing.  HFD data was collected for 5 different focus profiles. 
         One of these datasets include supplementary data collected beyond the normal far focus and near focus regions
• Stability. Observatory Systems & Control Program somewhat unstable with several partial and full restarts

Summary Plots & Logs

Observing Result (2018-09-14, S629) Operations started at 19:04, Sky Flats started at 19:30, with first useful Flats at 19:57 Sky Flats ended at 20:13,  First HFD profile collected at  20:47, Automated Operations from 20:56, Job Queue started at 20:56,  Several software interruptions (to be listed) Manual Mode from 02:00 to image 21P/Giacobini-Zinner Further HFD Profiles at 04:33 Session Ended/Observatory Closed at 05:09

(Observation Status :  Green=Completed, Yellow= Partially Completed, Red= Failed)

Night Sky Summary Plot - 2018-09-14 Top axis: Sky Brightness at Zenith (in ADU/s) Lefthand axis: Local Time (hh LT). Righthand axis: Sun Altitude (degs) Data outages at 22:51 (0.25 hours), and 03:41 (10.6 hours)

Back to Top

Operational Issues (2018-09-14, S629)

• Critical Issues (0)
• Major Issues (6)
• Minor issues (7)
• Continuous Improvement (2)

[ Prev | Next ]

Critical Issues

• None

Major Issues

• AllSky Data and Weather Synopsis outages.  Outages in the generation of AllSky products (all sky images and Night Summary Plots) and the generation & delivery of weather synopsis/scorecard information occurred at 22:51. and 03:41 (outages lasted 0.25 and 10.6 hours respectively).  Reason: The outages occurred when a critical exception occurred in the main All Sky Routine (TakeFrameJobs / 'Take Image Series') which persisted even after attempts to automatically restart the routine 5 times.
  System.OverflowException: Arithmetic operation resulted in an overflow.
   at CCDApp3_AllSky.globals2.GetWeatherData() in C:\Users\David\Documents\Visual Studio 2017\Projects\CCDApp3_AllSky\CCDApp3_AllSky\globals.vb:line 71423
   at CCDApp3_AllSky.globals2.AllSkyTakeFrames() in C:\Users\David\Documents\Visual Studio 2017\Projects\CCDApp3_AllSky\CCDApp3_AllSky\globals.vb:line 60123
  Line 71423  (sitting within a "With WeatherData..End With" block) is     IV.AvWindDirection (integer) = .AvWindDirection (Double)
  This seems an unlikely exception point unless WeatherData.AvWindDirection is 'infinity' or some other very large number.
  The block has been placed within a 'Try..Catch.. End Try' block
  Fixed

•  Aurora Cloud Sensor producing error message "can't open data_plot.png" .    Cloud Sensor III produced two error message dialogs saying that it was unable to open 'data_plot.png' (the graph of Sky Clarity, Sky Temperature, Light and Rain) .   This has occasionally been seen before and generally ignored as it hasn't stop operations or data flow.   On this occasion there was a possible relationship (now dismissed) between two occurrences of this error message and two incidents where the Main AllSky Routine failed during the night.  Cause:  The probable reason of the error message is a very occasional conflict between Cloud Sensor III's access to the file and access to the file from a routine in my program that takes a copy of the file every 30s. The copying of the file is actually no longer required, since the functionality of showing a graphical representation of Cloud Sensor data is now taken on my a Graph Routine in my WeatherServer program.  Issue fixed. Program has been updated to no longer copy 'data_plot.png' file locally and no longer upload the copied version to the website.  Fixed
   
  
• CCDApp2 Program Freeze (ContextSwitchDeadlock).    Observatory Manager program locked up whilst executing Job Queue.  After 60 seconds the Visual Studio 2017 debugger entered Break Mode and showed the exception message 'ContextSwitchDeadlock'. Cause:  The precise underlying cause is not known.   The message give no information about the particular line or routines involved in the problem, so its' really hard to diagnose & resolve.  Resolving these program lock-ups is critical for successful automated operation of the observatory.   Resolved or no longer an issue
   
• Multiple ASCOM.Utility messages. 'Device does not recognize the command'.  Whilst investigating why the Observatory Computer desktop was suddenly unable to be display over remote (VNC) connection it was found that there were multiple (20+) TheSky6 dialog messages stating 'The Device does not recognize the command'.     After clearly all these messages (22:54) it was found the the Telescope was pointing in the wrong direction in TheSky6's virtual sky , POTH.Hub was showing '---' in the scope's LST field (rather than a time), the Scope couldn't be slewed via TheSky6. and PHD2 Program was showing a message that a 'PulseGuide command to the mount had failed'. Scope and Dome Shutter were both pointing west (Az 264 deg) whilst the scope in virtual sky was pointing SW (Az 136 deg). Similar incidents have occurred before occasionally (e.g . sessions on ,,,,) . The Observatory Software Suite (TheSky6, CCDSoft5, CCDApp2, POTH.Hub) were restarted and operations resumed.
  As per previous pattern, the COM port required for connecting the Pulsar Dome has switched (from COM9 to COM11 in this case . The underlying cause is not known.  With the telescope retaining it correct knowledge of its position and with problems in both TheSky6 and PHD2 would point to some issue in either POTH Hub or the LX200GPS/R driver.  Later analysis showed that the scope had slewed okay at 22:46  from EV Lac at Az 119 deg to Hickson 81 at Az 263  and then performed centering operations ok.  The 5 x 180s exposure scheduled each failed with errors during 'take image'  at 22:50. (presumably the TheSky6 / scope connection problems had a knock-on impact on CCDSoft5)
  Resolved   

  Multiple ASCOM.Utility messages 'The Device does not recognize the command'

  POTH Hub with missing LST value

  PHD2 Message: PulseGuide command to mount has failed

   
  
• Pulsar dome lost it's pointing direction  After successfully taking images of preceding target 37P/Forbes (01:03 to 01:13) the scope was slewed to RR Tau at 01:13.  The routine failed to center the target as all 4 locate images had 'too few stars' to produce a plate solution (none in fact) and autoguiding was unable to start as no star could be successfully locked onto. The same problem was suffered by the next two targets  (C/2016 R2 (PANSTARRS) & Hickson 25 ). Where images where taken they were devoid of stars. This was noticed when monitoring the operations remotely, even though the skies where known to be clear from AllSky camera image and Clarity measurements the targets lay moderately close to the horizon (altitude 22, 16 & 19 deg respectively) and it was thought there might be some thick haze that might be blocking starlight or perhaps dew on the telescope lens, or the dome shutter has closed for some reason.    A visit out to the observatory at 01:40 showed that telescope was pointing correctly in the right direction, but the dome shutter, whilst open,  was pointing in a completely different direction to the scope. The scope had thus been taking images of the dome interior (explaining the absence of any stars). Dome slaving was on (in POTH.Hub).  An attempt to move the scope to 090 deg (the dome's normal park direction) didn't move the dome's aperture to its expected position over the door, but to a different position.  After a couple of further tests it was evident the Dome Controller has completely lost it's correct pointing direction.  It's uncertain what had caused the Dome Controller to lose its pointing direction. The issue was fixed in the observatory by manually commanding the Dome to find 'home' using the keypad & screen on the Dome Controller.  The dome rotated round to its home position (due south) and having reset it's pointing direction the dome aperture then automatically rotated around to where the scope was pointing  (presumably because the Dome being still connected to POTH Hub and Dome Slaving was still on). There were no further problems with the Dome Pointing during the session. Extra code is required to output the Dome Azimuth after a slew, and check that it is consistent with the telescope's pointing direction.   This might not have identified the issue (the dome could have moved to an azimuth equal to the one commanded by the POTH.Hub, and correctly reported that azimuth back to Dome Driver / POTH.Hub, but for it still not be the dome's real azimuth if the dome has lost its reference point.   Extra code is required to raise a flag when an image or at least 3 images in a row are not showing any stars and especially when the sky is clear in that direction (data supplied by AllSky camera & Telecomm routines). Having a WebCam attached the telescope would be useful for checking that dome is open and in correct orientation or not.
  Resolved.   (Observatory).  A webcam was added in late 2020.
   
• CCDApp2 froze when closing down observatory. Close Shutter, Park Dome, Park Scope and Close Down Camera all completed, but execution failed to reach File Archiving & Other Admin tasks. Occasional issue. Eventually resolved in 2021.
  Resolved

Minor issues

• Unable to display Observatory Computer's desktop over remote (VNC) connection.  At one point in the night the VNC Connection to the Observatory Computer was lost and attempts to redisplay the remote desktop failed.  An ultravnc connection could be made and the remote computer would accept password ok, but it wouldn't show any more than a black desktop in the VNC viewer.  Folders could be accessed via Network indicating that the computer was still active.   Thinking that it was a problem with the Ultravnc server on the observatory computer, the observatory was visited.  Multiple ASCOM.Utility dialog box messages were showing on the screen. There didn't seem to be fundamental failure of the Ultravnc server as the desktop was able to be viewed remotely later on  without restarting the server at all., and the problem was more of a Windows Operating System or Computer Memory issue.
  Resolved
   
• Timings file not getting archived. The newly introduced '(timings).dat' file is not getting archived to the Session's _Logs folder with the other log and data files (Action: the 'ArchiveLogFiles' routine needs to be updated)
  Fixed
   
• 10s Locate Images for U Her leave star ghost on subsequent images intended for photometry. Look at Exposure time and adjust them if required
  On Hold (Session/Target DB/ AstroMain)
   
• Time scheduled for U Her overestimates the time actually required (too much time is given to taking Sub-Frames)
  Fixed
   
• CCDApp2 crashed with unhandled exception 'System.InvalidCastException 'conversion from string "Stopped" to type Double is not valid in 'StartPHD2Guiding' routine whilst Getting Exposure Setting (temporarily fixed by placing the non-critical code with a "Try..Catch.EndTry" block.
  Fixed
   
• 'Focus Star' lost whilst performing Automated Refocussing. Focus star lost between the 7th and 8th focuser step. Table showed null values for subsequent measurements . Later analysis showed this was due to the main star drifting/moving out of the box, leaving just a single faint star
  Profile run should have stopped itself (but didn't ) and I intervened to manually abort the routine. (Actions: a) Check the routine to see why the code hadn't stopped the routine when it was no longer getting valid star data, b) update the routine so the box area moves as the star moves (i.e. box coordinates chosen based on the star position in the preceding image)). Code Modified (but a further modification to stop and unwanted side effect needs to be checked)
  Resolved
    
• Too many targets are not being fully completed .  For several targets the Job Queue executor intervenes to cancel the final 1 to 3 images in order to keep the schedule on track. This is thought to be principally due to centering operations taking significantly longer than allowed for in the schedule building.  Current settings assume 80s for slewing and 240s for Centering.   From session logs the actual slewing times range up to 85s (range 23-85s, average 46s), whilst actual centering times range up to 306s (range 50-307s, average 173s).   The assumed times are not to far out.
  The schedule builder doesn't currently include any time allowance for starting PHD2 autoguiding.  This could take 5-30 seconds for those targets affected (>30s max exposure).  Examining specific cases:
   
  GSC 1224:29
  - only 5 out of 15 images taken (last 10 images cancelled)
  - Scheduled Start Time: 23:58,  Scheduled Duration:  472s
  - Actual StartTime : 23:58,   Actual Duration: 462s
  - Actual Times, Slew 33s, Centering   304s, Imaging 122s,  Other 3s.  Total 462s 
    (centering time is underestimated by 64s)
  - Looking at the scheduled time again:  
    Duration should comprise  : Slew 80s, Centering 240s,  Imaging 210s (15x(10s+4s)  = 530s
    This suggests the schedule builder has used a duration 58s shorter than it should
    (this might be time time for image downloads  ? (15 x 4 = 60s)
   
  37P/Forbes
  - only 3 out of 5 images taken (last 2 images cancelled)
  - Scheduled Start Time: 01:04,  Scheduled Duration:  572s
  - Actual StartTime : 01:03,   Actual Duration: 621s
  - Actual Times, Slew 55s, Centering   307s, Imaging 223s,  StartPhd2Guiding, 33s,  Other 3s.  Total 621s 
   
  - Looking at the scheduled time again:  
    Duration should comprise  : Slew 80s, Centering 240s,  Imaging 310s (5x(60s+2s)  = 630s
    The schedule builder has used a duration 58s shorter than it should have. 
    This is much longer than the download time (5 x 2 = 10s)
    Actual Centering took 67s longer than assumed and no time is included to start Phd2 Guiding (30s)
  Fixed

Continuous Improvement

• Observatory Viewer . It would be useful for diagnostics if the Obs.Viewer picture that is updated every 5s through the session could  be saved to file to create a picture archive showing the observatory's state throughout the session.  Feature Added
  Done (AstroMain)
   
• Log File doesn't contain sufficient information. Log files entries are vital tool for problem solving and diagnostics but they are not always sufficiently complete to spot things.  Look into putting in more information into the log file , particularly for routines where existing logging is pretty sparse
  Done (AstroMain) 

[ Prev | Next ]

Back to Top

Sky Flats

The Sky Flats routine was started off with sun at -0.9 deg altitude.  Six sets were successfully acquired before the sky became too dark to take flats that would meet ADU target (30,000 +/- 5,000) within 10s exposure (or 15,000 +/-5,000 for 1x1 binning).

Results

Set		Filter / Bin Set	Sun Altitude (deg)		Exposure (s)	Av. Count (ADU)		Target Count (ADU)		Total Time (incl Slew) (mins)		Result
1		Ha,  2x2	-1.06 to -1.57		3.26 to 4.40	30158		30000		5.7 mins		Successful Set (15 frames)
2		Nd,  1x1	-1.77 to -2.11		10.0 to 10.0	11415		15000		-		Sky too dark after 6 frames
3		Nd,  2x2	-2.31 to -2.65		8.80 to 10.0	28137		30000		-		Sky too dark after 8 frames
4		Nd,  3x3	-2.81 to -3.38		6.08 to 10.0	29184		30000		5.5 mins		Successful Set (15 frames)
5		Xo,  2x2	-4.05 to -4.49		1.02 to 1.72	29473		30000		8.3 mins		Successful Set (15 frames)
6		Xo,  3x3	-4.66 to -5.02		1.00 to 1.53	29628		30000		3.9 mins		Successful Set (15 frames)
7		S,  2x2	-5.19 to -5.69		3.78 to 7.47	29069		30000		5.3 mins		Successful Set (15 frames)
8		S,  3x3	-5.85 to -6.35		4.10 to 7.88	29147		30000		5.0 mins		Successful Set (15 frames)
9		C,  1x1	-6.49		10.0	4469		15000		-		Sky too dark to start frames

Notes:

a) Neutral Density (Moon) filter needs to be kicked off earlier
b) a shorter exposure trial (say 0.2s) could be used at the start to test for and limit/prevent over-saturation of the CCD
c) the optimal order of flats sets (by filter/binning) is probably best established by measuring ADU collection rates against the dusk sky, rather than guessing
d) Eventually the routine will be kicked off by the Observatory Manager itself at a more precisely defined sun altitude, but at this stage in its development it was again manually initiated and monitored). 

Pictures showing the Master Flats generated from the new sky flats from Session S629 (Flats).

Master Flat, Nd filter (3x3) (Average Median for 15 frames )

Master Flat, Xo filter (3x3) (Average Median for 15 frames )

Master Flat, S filter (3x3) (Average Median for 15 frames )

All Frames 50% original size (CCD Temp -15°C)

Back to Top

Autofocussing / HFD Profiles

A new subroutine has been written to calculate Half Flux Diameter (HFD) of a star, as an extension to my current Automated Focus Profile routine . In due to course I might switch to refocusing using HFD values if I can get I can make focusing quicker than my existing method based on FWHM measurements. For the moment it is just an initial exploratory look at HFD data and to test my HFD subroutine on live data.

HFD measurements are shown on following profile plots as small cyan circles,  the FHWM measurement are in orange. The best focus position automatically calculated from the FWHM data is in yellow.  Literature suggests that HFD profiles are V shaped with linear sections in the near focus and far focus regions with a short curved section in between, (ie through the critical focus area).

Whilst I can see linear sections either side the profile is not particularly V shaped, the middle curved section seems quite wide. It could be that I'm measuring a relatively narrow focus range close to the best focus. A wider focus range would presumably show longer linear sections making the curved section look a lot smaller.  

Focus Profiles,  including new HFD measurements

HFD Profile 5 (26 points) Including supplementary data taken beyond the normal step range The first 6 points and last 5 points are used to define linear sections of the profile

 

 The variation in HFD due to seeing was examined by taking 17 images at a single focus position (3850).   This dataset gave an average HFD value of 4.30 arc secs (range 3.93 to 5.40 arc secs).   17 images is clearly more than one would practically take at a single focuser position. Taking 3 successive sets of 5 images , showed average HFD values of 4.29, 3.98 and 4.7 arc secs. 

The time used to perform a single HFD calculation across all 5 profiles varied from 5 to 15 seconds (average 10.3s). This is significantly more than the exposure times of just 1 or 2 seconds used and significantly lengthens the time taken to measure an entire focus profile. 
(This is ok for an initial coding trial, but for practical application the calculation needs to be reduced to under 1 second). 

Earlier tests had shown that for 1x1 binning an outer radius value of 20 pixels (9 arc secs) was about the optimal size to use (a larger size increases uncertainty in the measurement, whilst a smaller size fails to capture all of the star data for moderately out of focus stars). For badly out of focus stars a much larger outer radius would be needed, but this larger radius would compromise HFD measurements of better focused stars.  (It would seem you need to know the HFD value in order to chose the right outer radius value to use in calculation of HFD (a 'chicken & egg' conundrum). A solution might be to use a two stage process, the first step using a standard size outer radius and then a second step with outer radius based on the approximate HFD value from the first step, but this would double the overall time for focusing).

HFD Sensitivity to Outer Radius Size HFD measurement of a star taken at two different focus positions using different outer radius sizes The optimal outer radius size appears to be around 20 pixels (9 arc secs) 1x1 binning, 12" LX200GPS/R operating at f/10.4

Back to Top

PowerShell - Renaming Files for Animation Shop

Back to Top

2018-09-17

New Development Laptop - Software Installation

Back to Top