David's Astronomy - Notes 2022-11-03 (S1053)

Issue
Planned images of Jupiter didn't contain the planet / Telescope didn't appear to slew to the commanded location
1) S1052, 2022-11-01 23:58).
2) S1053, 2022-11-03 22:14).

Description
Cam2 Reference image and AllSky Image shows that the sky was clear (or at least sufficiently clear for the bright planet to be visible). Cam2 Reference image shows that Jupiter was not within the 50' Cam2 field of view.

A similar problem occured in the last session (S1052) where the cause was initially put down to cloud.

Analysis
It was first though the telescope was being slewed to a prior Ra/Dec value stored in the database rather than calculating a correct position for the date/time of the new observation. Jupiter is marked as a non-sidereal target in the database, but AstroMain report clearly acknowledges that Jupiter is a non-sideral target.

1) Cam2 Reference image and AllSky Image shows that the sky was clear (or at least sufficiently clear for the bright planet to be visible). Cam2 Reference image shows that Jupiter was clearly not within the 50' Cam2 field of view. Report log shows that planned target coordinates of RA: 23 59 53.536 Dec -01 42 11.83 (J2000) (RA= 00 01 03.951 Dec= -01 34 33.39 (Current) ) which corresponds to the coordinates of Jupiter in TheSky6's virtual sky. MeadeGeneric logs shows scope being commanded to slew to RA= 00 01 19.32 Dec= -01 33 11.98 (Current), which corresponds to the correct target position allowing for TPoint adjustment. The plate solution on the 10s Cam2 Reference Image shows coordinates of RA: 23 59 10.685 Dec: -02 32 17.49 (J2000)

Plate Solved Coords: Ok RA: 23 59 10.685 Dec: -02 32 17.49 Linking Image (ASTAP).. Ok Solved in 2.8s (Stars 22, Scale 1.014, Angle 359.00°)

This reveals a telescope pointing error of 51' which is far larger than normal slew errors and is unexplained. The slew error is noted to be mostly in Dec position. This is unlikely to be a random glitch as it has occurred in two sessions running (S1052 & S1053) with the same target. With Jupiter lying 17' outside of the Cam2 FOV and 29' outside of the Cam1 FOV it can at least be understood why Jupiter didn't appear in either Cam1 or Cam2 images.

2) Report file reported proposed coordinates of Ra: 23 59 23.204, Dec -01 45 00.82 (J2000) at 2022-11-03 22:14 (Ra: 00 00 33.604, Dec= -01 37 22.53 (Curent) ). Checking TheSky6's virtual sky it reports 23h 59m 23s (Ra2000), -01°45'01" (Dec2000). So its hard to explain why the Jupiter didn't appear in the TS80/Cam2 FOV let alone the LX200/Cam1 FOV. ASTAP plate solution of the Cam2 Reference image reported coords of 23 59 03.529 (Ra2000), +23 59 03.53 (Dec2000). The Dec value looks suspicously like the Ra value (this was confirmed to be a reporting bug and is now fixed). MeadeGeneric log shows that the telescope was commanded to roughly the correct position : Ra = 00 01 09.36, Dec = -01 33 41.54 (Current). Slight differences in coords are due to TPoint adjustment. A subsequent plate solution on the 10s Cam2 Reference Image showed J2000 coordinates of RA: 23 59 03.529 Dec: -02 27 47.56

Plate Solved Coords: Ok RA: 23 59 03.529 Dec: -02 27 47.56 Linking Image (ASTAP).. Ok Solved in 3.1s (Stars 12, Scale 1.014, Angle 359.02°)

This reveals a telescope pointing error of 40.6' which is far larger than normal slew errors and is unexplained. The slew error is noted to be almost entirely an error in Dec position. This is unlikely to be a random glitch as it has occurred in two sessions running (S1052 & S1053) with the same target. With Jupiter lying 22' outside of the Cam2 FOV and 35' outside of the Cam1 FOV we can at least understand why Jupiter didn't appear in either Cam1 or Cam2 images. It seems unlikely that any Dec backlash (take up or correction) can be responsible as we don't see a problem with other any other targets. Jupiter lay at Az 222.9°/ Alt 23.5° in the S1052 case but lay at a rather different sky position (Az 196.9° / Alt 29.9°) in the S1053 case. It would seem that there the AutoStar II or the LX200 scope itself has a bug associated with the RA/Dec Coords that Jupiter lay on the two night. Propose a test to a separate target in same ra/dec region. (SlewTest). Results of test (S1055) was hampered by cloud / too few stars affecting Locate Images and Cam2 Reference, however looking at Log files showed a noticable discrepency between the inital logged Pre-Slew/Post Slew Dec coordinates and the latter Pre-Slew/Post Slew coordinates. A slewing discrepency of 37' was logged. Need to look closely at code & logs to see how the coordinates could have changed between initial set of coords and the later set.

Issue finally understood following a further occurance of the same issue in session S1057 (2022-11-07). Investigating the logfile from this incident in more detail shows

20:20:46.51 | Jupiter Check RA Value Info | dRa (23.99317658) is very close to RA 0 / RA 24 20:20:46.51 | Jupiter Check RA Value Info | This could lead to RA falling outside of 0 to 24 range after applying TPoint corrections 20:20:46.51 | Jupiter Check RA Value Info | TPoint won't be used for this slew to avoid a potential RA range exception 20:20:46.51 | Jupiter Call Scope.SlewToCoordsAsOk | Calling objScope.SlewToCoordinatesAsync

Because the following condition dRa < (0.04) Or dRa > (24 - 0.04) is true the SlewTheSkyScope() routine employs protection routine to avoid TheSky6 sending a TPoint modified Ra value onto DeviceHub, and steps in by requesting Telescope slew to the basic Ra/Dec coordinates (unmodified by TPoint) using direct call via DeviceHub.Telescope.SlewToCoordinatesAsync() thus passing usual call TheSky6.Telescope.SlewToRaDec()

This was code that added in response to a Major Issue experienced in Session S827 (2020-11-05) during a slew to Target 22/49 (SS Cyg) which caused TheSky6 to produce a modal error dialog which blocked further session progress until the dialog was manually acknowledged. A modal error dialog is a showstopper for automated operation. Since TheSky6 is no longer supported the bug that can causes a RA value to be sent to the scope that is outside the 0.0 to 24.0 range or the behaviour of TheSky when it recieves an exception from the scope are not fixable.

A fix has been attempted in AstroMain 3.57.1 which adds a custom 41' adjustment to dDec value when using DeviceHub.Telescope.SlewToCoordinatesAsync() to slew to Jupiter. This is replace the correction that would otherwise be applied by TheSky6/TPoint (current model). This is not perfect since the amount of adjustment is a function of az/alt, side of meridian etc. and may not be appropriate if the telescope's polar alignment was changed & a new TPoint model built.

Ideal solution would be to access TPoint's calculator in someway and get the Ra/Dec correction for a given sky position & time, recreate its calculator using the same TPoint Model values, or develop an empherical solution in someway. The first method doesn't seem possible (TPoint is not exposed via a COM object) and the second method would seem to be very difficult to build. The third method would involve slewing to lots of points across the sky, and recording the difference between the requested position and the telescope's apparent position and create an empirical model that can return the necessary correction for any sky position. This emphirical model probably doesn't require the actual scope but could use as a simulation scope.

Another potential solution would be to build a ASCOM telescope 'driver' that sits between TeleAPI and DeviceHub.Telescope that does nothing more than pass communication to and fro, except for checking the dRA parameter in SlewToCoordinatesAsync() calls , adding 24 if dRa is < 0 or subtracting 24 if dRA is > 24. This would be an interesting project when time allows.

Conclusion
A temporary fix has been added to AstroMain 3.57.1(2022-11-12) which was successful used in session S1058 (2022-11-12) where it allowed Jupiter to be finally centered & imaged again.

This is just a temporary fix and a decision was taken to try to build an ASCOM Telescope 'driver' to sit between TeleAPI and DeviceHub.Telescope, that would check the dRA parameter in calls to SlewToCoordinatesAsync() , adding 24 if dRa is < 0 or subtracting 24 if dRA is > 24. This would deliver a final workaround for the bug in TheSky6 where Ra values slightly less than 0 or slightly greated that 24 can be generated and sent to DeviceHub.Telescope when the target RA is very close to either RA 0 or RA 24. This is because TheSky6 doesn't check and wrap the TPoint modified RA value when it is less than 0 or greater than 24.

Update 2022-11-13
A working first version of TeleLink driver was developed in a matter of a few hours and successfully tested with a TheSky6, DeviceHub and the ASCOM Telescope Simulator (see TeleLink 1.0, 2022-11-13) . The TeleLink driver was successfully used during a 13 hour live session on 2022-11-20 (S1059).


	Session Aims & Highlights
	- Observing Result - Night Summary Plot - Session Event Log

	Operational Issues
	- Critical Issues (0), Major Issues (0), Minor Issues (5), Small Defects (1), Continuous Improvement (8)

	Images from 2022-11-03 >> [ Local Files >> ]

	Investigation - Slewing Discrepency (Jupiter)

This Web Page:	Notes - Session 1053 (2022-11-03)
Last Updated :	2024-09-25
Site Owner :	David Richards
Home Page :	David's Astronomy Web Site

David's Astronomy Pages
Notes - Session 1053 (2022-11-03)

Session Aims & Highlights (2022-11-03)

Operational Issues (2022-11-03, S1053)

Investigation - Slewing Discrepency (Jupiter)

David's Astronomy Pages Notes - Session 1053 (2022-11-03)

Session Aims & Highlights (2022-11-03)

Operational Issues (2022-11-03, S1053)

Investigation - Slewing Discrepency (Jupiter)

David's Astronomy Pages
Notes - Session 1053 (2022-11-03)