David's Astronomy Pages Notes - Session 926 Attempt 3 (2021-10-19)

Notes (S926B)

Notes Main

Home Page

Notes (S926D)

	Session Aims & Highlights
	- Observing Result  - Night Summary Plot  - Session Event Log
	Operational Issues
	- Critical Issues (0),  Major Issues (1),  Minor Issues (10),  Small Defects (1), Continuous Improvement (3)
	No Images >>          [ Local Files >> ]
	TPoint Mapping Run

Session Aims & Highlights (2021-10-19)

Main aims

1. Resync Scope. Resync scope position and perform short mapping run in attempt to update TPoint Model . Failing that perform a new full sky mapping run to create a new TPoint Model.
2. Dec Motor. Make guiding runs to examine the performance of a new Dec Motor Unit that had been installed earlier in the day. 
3. Targets.  Acquire images of a selection of variable stars, nearby stars, comets & deep sky targets as allowed by time & conditions.
4. SkyQuality Chart.  Continue assessment of changes to appearance of new SkyQuality chart.
5. AstroMain. Check on fixes and new features added to AstroMain 3.44.4

Equipment & Software

• 12" LX200 and ST-10XME
• 80mm APO and ZWO ASI 178MC
• CCDApp2, TheSky6, CCDSoft5, PHD2 2.6.10,  DeviceHub 6.5.1.4,  MeadeGeneric 1.3.1.361, UPB 1.5, ASCOM 6.5 SP1
• Pegasus UPB & Motor Focus, TCF-S
• SharpCap 3.2, PHD2  2.6.10
   
• AstroMain 3.44.4  / 3.44.5,  AstroPlan 1.26  AstroShCap 1.3.2, AstroGuard 1.6.2,  AstroVOE 1.8,  AstroSN 1.6,  AstroProtect 1.6
  (AstroWeather 1.13, AstroAllSky 3.12.3, AstroObsCam 1.6.4, AstroLaunch 1.7)

Highlights

• TPoint Model.  A full sky mapping run was completed with a total of 179 mapped points from which a new TPoint Model was generated (Sky RMS of 59 arc sec)
•  SkyQuality Chart.  Data plotting and data legend, and upload to website all worked ok. Appearence was ok.
   
•  Dec Motor.  New Dec Motor Unit worked ok through the session but again there was no opportunity to examine/test its guiding performance.
   
•  Targets.   Maintainance operation prevented the acquisition of any targets during this session attempt.

Notes:

  Summary Plots & Logs

Dome & Scope Slewing 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

Session Alerts

Time     Alert Detail -- No Alerts                --

Back to Top

Operational Issues (2021-10-19, S926 Attempt 3)

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

[ Prev | Next ]

Critical Issues

• None

Major Issues

• Unable to get Map Points to map during Short Mapping Run.  Whilst images would link with pointing errors around 20-25 arc mins (with GSC catalog link after no link with UNCA-B) they would wouldn't map.  Tried with Image Size set to 25% of TheSky6's Virtual Sky instead of normal 80%, but still not mapping).  During last two session mapping worked ok in the cases where the image had successfully linked.    Eventually resolved iself once tube/fork flexure terms added to full sky mapping run.
  Resolved in session 2021-10-19 (Session, TPoint)   

Minor Issues

• TheSky6 behaving oddly at start of session.  After starting the LX200 Telescope and connecting to it from AstroMain, the scope was then connected to TheSky6.  The ConnectTheSky6Telescope routine reported that there was an 11.6° separation between ASCOM and TheSky6 coordinates.   TheSky6's Virtual Sky showed the telescope around 12 deg west of the scopes expected position at it start-up position which is at/close to the scope's normal Park Position (Az 180/Alt 3).  Scope was disconnected and reconnected to TheSky6. This time the scope appeared to be close to it expected position in TheSky's Virtual Sky.   Upon slewing the scope,  the scope moved to it requested coordinates, but the position of the telescope in TheSky's virtual sky didn't move.   Resolved in session by Parking Scope via DeviceHub's Telescope Tab and restarted the Observatory Software.  TheSky6 window was closed but TheSky was still showing as active in TaskManager and AstroLaunch's process to Kill Stranded Processes was run in order to force it close.  After restarting software TheSky6 showed the Telescope position correctly
  Resolved in-session (Session, TheSky6) 
   
• Mapping Table of Map Results showing 'age_Link_Information' as the Image number of first map point instead of 00926002. Routine to extract ImageNum couldn't handle the file's name for some reason '00926002.Image_Link_Information.FIT'   . Checking the GetImageNum() routine that is responsible for returning the image number to the aImNumber() array variable confimed that GetImageNum("C:\Data\CCD Imaging\New\2021-10-19 S00926\00926002.Image_Link_Information.FIT") was returning "age_Link_Information". Running this through debugger it could be seen that the code was looking for cases where filename might have text like  ".im926002" using a instr check for ".im" in order to extract 926002.  The routine is thrown-off by the detect of .Im from ".Image_Link_Information" that is contained in file name.   Code modified to only look for .im if the filename doesn't contain the string ".Image"
  Fixed 2021-10-20 (AstroMain 3.44.6)   
   
• Sky Quality Chart is missing data for various time intervals during the night.   Data is provided from AstroAllSky on AllSky/Weather computer, it is based on stats of the difference between AllSky images taken 3 minutes apart, on a rolling 30s cycle (the exposure time of images ).  AstroAllSky isn't producing a Sky/Image Difference Histogram chart at these times and reports "Rejecting DiffStats, Centre (10000) is outside of allowed range" for the affected time step.One such time interval was 02:44:25  to 03:07:10  (images 540828 to 540872). Problem seems to be associated with passage of very bright moonlit clouds across the sky resulting in extreme fluctuations in sky brightness and therefore extreme differences in images taken 3 minutes apart.  The current stats collects bins pixel data over a 20000 range (centered on zero, ie +10000 to -10000 of zero). Where the bulk of the data exceeds +/- 10000 the data is rejected and presumably vcNull values are forwarded during this time. When data returned at 04:07:41 initial imagedifference charts shows problem with there seem to be a problem with FWHM / C data values which are too small and are expressed on the Histogram chart as a very narrow gaussian curve which doesn't reflect the curve of actual data.  (eg 540873 - 540867, where C is 5.1).  Alternatively the C value is zero and the RMS values is NaA (eg 540874 - 540868) or where C is negative (eg  540875 - 540869). There were 6 steps affected by this in sequence (6 steps corresponds to 3 mins), so there might be a transition period where data isn't been rejected by it severely affecting the stats.
  Data for example interval copied to development computer for problem analysis.    When rerun later on developmen computer the 'transition' pictures (540873-79) aren't produced, they data is rejected as the Center Peak (-10000) is outside of allowed range. AstroAllSky routines modified to handle a +20000/-20000 range of difference values and use the best HM value  (based on half peak value derived from Moving Average Value).
    Fixed 2021-10-20 (AstroAllSky 3.12.4) 
   
• Exceptions occuring in AstroMain's SkyQualityChart.AddData() routine with the error 'Arithmetic operation resulted in an overflow'. There were 7 occurances of the exception through the session at following times 23:43:46, 23:44:31, 23:45:17, 23:46:02, 00:03:26, 00:51:00 & 04:10:21).
    Fixed 2021-10-20 (AstroAllSky 3.12.4) 
   
• Unable to run 'Build Local Jpg Page' on session files, process failing with the  message 'Could not find a part of the path 'C:\Data\CCD Imaging\Analysis\2021-10-19 S00926\_JPGS'. The 'BuildJpgPicturePage()' routine was developed as a way of presenting Target JPG pictures and Target Info data from a session and was later extended to show other graph, tables and logs from the session.  The routine 'expects' target JPG picture to always be present and exited when running against a session were no JPG images were created.  Modify routine so that routine can still build a slimmed down local  web page that is still useful. This is a similar to an earlier issue, no fixed,  when Build Local Jpg page failed when because there were no TargetInfo files)
  Fixed 2021-10-20 (AstroMain 3.44.6) 
   
• Link Image (UCAC) button routine from AstroMain/Analysis/Analysis tab is reporting certain image details twice .  The four lines that get repeated are as follows:
   Image/Object REDUCED Map Point 1
- FileName     Ok    00926020.REDUCED.FIT
- Exposure     15s   [00926020] (3x3 15s C -10.2°C)
- Date/Time    Ok    2021-10-20 00:14:04 UT
  LInes are repeated because 'AnalyseImageBasicData()' routine is called twice.  First call is from LinkActiveImageLong_UCAC(). Second call is from with LinkActiveImage().  Issue fixed by removing the first call to AnalyseImageBasicData().   Testing show the operation continues to work fine without the first call.
  Fixed 2021-10-20 (AstroMain 3.44.6) 
   
• Table of mapping results produced at end of mapping run is misrepresenting the results. The point numbers in the table don't correspond with the point numbers used during the map run and not all points are listed.  The main run of 122 points (of which 90 were successfully mapped), had a results table containing 115 points (ie 7 points were missing). The last point (122) is listed in table as point 115.  It would seem the routine would benefit from using a dedictaed results array rather than use the current 'fudged' solution using aIm() arrays and pointers.
  Fixed 2021-10-21 (AstroMain 3.44.6)   
   
• TheSky6 producing an error dialogue "ASCOM.DeviceHub  SlewToCoordinatesASync: set - '-0.00021' is an invalid value. The value range is: 0.00000 to 24.00000.'  DeviceHub.Telescope log file shows '-0.000208656760653065 is out of range from 0 to 24'.  Problem occurred twice, and seemed to hold up progress of operation until dialog box was accepted.   Screen capture of error message made at 00:09.   Based on a calculation for 00:09 to Map Point 2 (Az: 191.83, Alt: 54.81) would correspond to approx:  RA 00 24 54  Dec 22 26 09 which places in close to RA 0 / RA 24 boundary which is consistent with the lead hypothesis.  It is presumed that inside TheSky6 a TPoint call  had come up with a model corrected RA that was slightly less than 0 (but instead of adding 24 the negative RA was sent on to DeviceHub which then came back with an invalid value exception. The call Scope.SlewToAltAz () was made at 0:07:54.06.   Unclear why there was a User Request to Abort Job (Abort Scope.Slew & Abort.Dome Slew at 00:07:55.11. Resolved in Nov 2022 through the creation and installation of TeleLink (an ASCOM telescope 'driver' that sits between TheSky6/TeleAPI  and DeviceHub), whose job is to look for out of range RA values and wrap them to their corrected value.
  Fixed 2022-11-14 (TeleLink 1.0) 
   
• TheSky6 producing an error dialogue "ASCOM.DeviceHub  Unable to make direct slew.'  Problem occurred twice, and seemed to held up progress of operation until dialog box was accepted.  Problem seemed to occur when a Mapping Run was aborted during the process of slewing to a map point.   Problem a async/ AzAlt slew/ tracking issue ?  Slews are managed by SlewTheSkyScope(AzAlt) routine in which slew model is set to AzAlt,  Telescope set to Asynchronous operation , tracking is turned off and scope slewed using ASCOM call Scope.SlewToAltAzAsync. In case of Aborted Mapping Run at 00:01 , the call to Scope.SlewToAltAzAsync was made at 00:01:46 with the user abort being made at 00:01:47. Slew abort was as at 00:01:47.90, and at 00:01:47.95 the Scope was reset to Scope.Asynchronous = 0 and tracking turned on at 00:01:52.71.    It is probably best that a Job Abort allows a slew in progress to complete, before the abort is made effective ?
   To be investigated (Session, TheSky6, DeviceHub, AstroMain) 
   
• Night Summary Plot are showing gaps in the Dome and Telescope tracks were there should be a line as the Dome & Scope are both at least semi-active.  Fixes have been recently made to ensure than mapping time is recorded as active time however that fix seems to have exposed this secondary issue.  For Telescope 'line' to be drawn requires the following condition to be met  {  Now().Subtract(TP2.DateX).TotalMinutes < 5 And TP2.ScopeMode <> ScopeMode.Undefined }, this means that if there are no new TCP/IP messages for TP2 for 5 minutes  then a line gap will be started.   Similary absence of new TCP/IP messages will cause a line gap to be started in the Dome track.  Looking at the gap at around 02:00 which lasted 15 mins or so. Trace lines added for another purpose reveal an absence of TP2 communications between  01:49:11 &  02:07:13 which is a gap of 18 mins.  At this time AstroMain was conducting a 10 point mapping run (01:50 to 02:03). Program was then closed at 02:05 (which closed the TelePosition (TP) sender) and reopened at 02:06 (which restarted the TelePosition Sender).  Main mapping run  was attempted between 02:10 and 02:26 (aborted after 8 points).  After a series of short (12 point) mapping runs, the main mapping run of 122 points was finally conducted between 03:46 and 05:57.   During this later period there was a 25 min gap in apparent communcation around 04:40 to 05:05.   ObsCam plots which also receive TP2 messages via TCP/IP on the same computer as AstroAllSky don't show any data issues , TP2 details are changing throughout this time.  TeleCommsReceiver in AstroAllSky monitors TCP/IP Port 4006 whilst AstroObsCam monitors TCP/IP Port 4015.  This means the issue can't be due to 'conflicts/races' to read data from the Port,  but can explain why  AstroAllSky might be have problems whilst AstroObsCam wasn't having problems at the same time.   TeleComms.MainServerLoop was running continously through the period (as shown by regular records coming through to the AstroObsCam client) and would have been sending a TP record to AstroAllSky every 2s or so.  AstroAllSky client receiver looks for new data from the server every 0.2s or so and parses the any new  data to TP2 record . If there isn't a pending connection on the specified Port the existing TP2 record are marked as invalid (.Valid = False). Extra trace lines added to AstroAllSky 3.12.5 (2021-10-22). 
    To be resolved 2021-10-22  (AstroMain 3.44.6, AstroAllSky 3.12.4+) 

Small Defects

• Mapping Run report FWHM -99.0 (vcNull) instead of '--' when image links couldn't be obtained.  Fixed AnalyseFWHM() routine to so that vcNull Fwhm values are reported as "--"
  Fixed 2021-10-20 (AstroMain 3.44.6) 

Continuous Improvement

• PowerBox's 'Started already' report lines for 'PowerBox Env:' needs to show the ASCOM driver id rather than its name/description.  Report is showing '(Pegasus Astro Environment)' but needs to show '(Astro.pegasus_upb.ObservingConditions)'
  Done 2021-10-20 (AstroMain 3.44.5)   
   
• Query. Will 'Make Mapping Run' avoid points which are close to the Moon ? Need assurance that Mapping Run wouldn't take 15s exposures (C Filter) whilst being pointed directly at the moon. Moon is too bright for camera CCD to deal with exposures of this duration. Points close to moon will also suffer a lot of glare and make image linking difficult.   Code checked and found that it doesn't currently make a separation from moon.  Call to CheckMoonSeparation(RaDec(0), RaDec(1), MoonAngSep)  added to MakeAutoMappingRun () routine and the point cancelled if the angular separation from moon is < 15 degs. AstroMain 3.44.5 used during second half of session during which 5 map points were cancelled due to proximity to moon. These points had angular separation from the moon in the range 5 to 11 deg. Routine can probably be improved but excluding points were moon is below horizon from being cancelled, or make the tolerance a function of moon phase.
  Done 2021-10-20 (AstroMain 3.44.5)   
   
• Add NightSummary Plot to Session's Local Jpg Page
  Done 2021-10-20 (AstroMain 3.44.6)   

[ Prev | Next ]

Back to Top

TPoint Mapping Run (2021-10-19)

Following issues where Telescope ReSync & Short Mapping was unable to reduce pointing errors below 15-20 arc mins in sessions S926A, S926B and first part of S926C it was decided to forgoe any observing in the rest of the S926C session and instead run a  full sky mapping run in order to create a new TPoint Model.   Since the sky was very bright due to a nearly full moon it was as a good a time as any.

Mapping Run
With the old model deleted and a new TPoint model object added to TheSky6 an initial telescope sync & map was performed near the interesection of the Meridian and Dec 10. and was following by 3 clusters of Short Mapping runs, but the pointing error didn't seem to come down very quickly (being in range 20-45 arc mins) and a first attempt to make a full sky mapping was aborted after initial 6 points failed to map.    After a couple more short mapping points in the E & W part of sky and after reaching a total of 74 mapped points it was decided that the realtime TPoint Model wasn't pulling the mapped points into the centre of the 'circular' error chart and an intervention was necessary.  TPoint was opened and Fork Flexure & Tube Flexure terms added to the model.   This had a big effect in decreasing the model's error value. 

A full sky mapping run was then made with 123 points, following by an infill run that picked up 13 of 21 points that had failed the first attempt.

As per design change in AstroMain 3.44.5 map points within 15 arc deg of the moon were delibrately cancelled.

In total 179 points were successfully mapped during the night session.   An interim TPoint model was created using 11 terms (6 Equatorial Terms, Fork Flexure, Tube Flexure & 3 harmonic terms) which had a Sky RMS of 106 arc sec (1.8 arc min)  before the telescope was parked.

TPoint Model
Post session analysis (TPoint 1.00.511) showed that without any model terms the raw Sky RMS was 1536 arc sec (25.6 arc min).  
(one point, pt 120 ( at Star RA 02 20 48.77, Star Dec 43 19 54.5),  was a long way off all the others and was marked as an error)

[ The raw Sky RMS of 1536 arc sec  (25.6 arc min) compares with values of 1258 arc sec (21 arc mins) from previous 2020 TPoint run (2020-01-17) and 409 arc sec from 2018 TPoint run (2018-05-17).  It is has been suggested previously that that the larger RMS in 2020 might be due to a poorer polar alignment  compared to 2018 mapping run ?  ]

A model with 6 equatorial terms shows a Sky RMS of 879 arc sec (14.6 arc min).  This decreased to 601 arc sec after the addition of a Tube flexure term, and then decreased to 493 arc sec with the futher addition of the Fork flexure term.

[ Whilst the Tube Flexure(tan) term was used in the 2020 Model, the regular Tube Flexure term seems to give a better RMS reduction in the 2021 TPoint Run ]

Addition of ACES term (Azimuth centering error (Sin) ) brought  the Sky RMS down to 276 arc sec (4.6 arc min). Adding successive harmonic terms brought the Sky RMS further still

Best Model   The 'Best' TPoint Model generated from the mapping run incorporates 16 terms (6 equatorial terms, Fork Flexure, Tube Flexure, ECEC and 7 harmonic terms) and reduces the Sky RMS error down to 59 arc secs (0.98 arc mins). 

[ This is a worse result than the 2020 TPoint Run (39 arc secs (= 0.65 arc mins) ) and 2018 TPoint Run (47 arc secs  (= 0.8 arc mins)).  
It is conjectured that the concentration of 40% of the points into a series of clusters limits the ability to get a good all-sky model. ]

New Mapping Run - 179 data points (2021-10-19) Scatter Plot. No Terms Modelled		New Mapping Run - 179 data points (2021-10-19) Scatter Plot. Best Determined TPoint Model  - 16 terms
Orthographic Plot. No Terms Modelled Initial clusters of mapped points can be seen (whilst initially useful, they probably overly-bias the later TPoint model to the southern sky ?)		Orthographic Plot. Best Determined TPoint Model  - 16 terms (Model fit is worst in the NW sky. However it is  best in the SW, S & SE sky were the majority of observing is conducted)

Comparison of new TPoint model with the previous 2020 model

New Mapping Run - 179 data points (2021-10-19) Scatter Plot with Best Determined TPoint Model  - 16 terms (6 equatorial terms, Fork Flexure, Tube Flexure, ACES & 7 harmonic terms)		Earlier Mapping - 155 data points (2020-01-17) Scatter Plot with Best Determined TPoint Model  - 16 terms (6 equatorial terms, Fork Flexure, Tube Flexure(tan), ACES, ECEC & 6 harmonic terms)
New Mapping Run - 179 data points (2021-10-19) Scatter Plot. No Terms Modelled		Earlier Mapping - 155 data points (2020-01-17) Scatter Plot . No Terms Modelled

Polar Alignment

Comparison of Polar Alignment Information from new mapping run (2021) with that from previous runs (2020) shows there has been no significant change in polar alignment between the two dates.   The moun's polar axis is fairly well aligned in azimuth (1.2 min error only), but has a misalignment in altitude of 19.5 mins.  

Polar Alignment Information from New Mapping Run (2021-10-19) 179 data points.  Best TPoint Model 16 terms
Polar Alignment Information from Earlier Mapping (2020-01-17) 155 data points.  Best TPoint Model  - 16 terms
Polar Alignment Information from Earlier Mapping  (2018-05-17) 121 data points.  Alternate TPoint Model 8 terms

 

Back to Top