David's Astronomy - Notes 2021-12-10 (S940)

David's Astronomy Pages
Notes - Session 940 (2021-12-10)

Notes
(S939)

Notes
Main

Home
Page

Notes
(S941)

	2021-12-12

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

	Operational Issues
	- Critical Issues (1), Major Issues (5), Minor Issues (11), Small Defects (1), Continuous Improvement (3)

	Images from 2021-12-10 >> [ Local Files >> ]

	First Session with new Observatory Computer
	Investigation - Guiding Runaway (SideOfPier Issue)

	Investigation - LX200 Tracking Rate Discrepency

Session Aims & Highlights (2021-12-10)

Main aims

Observatory Computer. Test out new observatory computer with freshly installed software and settings
Collate any teething issues or problems.
Targets. Acquire images of a selection of variable stars, nearby stars, comets & deep sky targets as allowed by time & conditions.
Wind Exclusion Zone. Continue to test new procedures that create and use a Azimuthal Exclusion Zone to avoid facing telescope into moderate/strong wind.
Shutter Operations. Test corrected code for managing shutter operations (AstroMain 3.48.2)
AstroMain 3.48.2 Test new feature and bug fixes in AstroMain 3.48.2

Equipment & Software

12" LX200 and ST-10XME
80mm APO and ZWO ASI 178MC
CCDApp2, TheSky6, CCDSoft5, DeviceHub 6.5.1.7, MeadeGeneric 1.3.2.367, UPB 1.5, ASCOM 6.5 SP1
Pegasus UPB & Motor Focus, TCF-S
SharpCap 3.2, PHD2 2.6.10
AstroMain 3.48.2, AstroPlan 1.29.1, AstroShCap 1.3.12, AstroGuard 1.6.3, AstroVOE 1.9, AstroSN 1.7.1, AstroProtect 1.6
(AstroWeather 1.15.2, AstroAllSky 3.14.1, AstroObsCam 1.8, AstroLaunch 1.8)

Highlights

Observatory Computer. summary.....
Targets. x Targets acquired in first part of the night
Wind Exclusion Zone. As per design hourly wind forecast data was used for defining exclusion zones for building the night's observing plan . The effect unfortunately couldn't be tested due to failure of the dome rotation/shutter system and due cloud in the second half of the night
Centering Performance. Guiding performance was fairly poor
Guiding Performance. Guiding performance was mixed.
Shutter Operations. Dome opening / closing operations were anomalous and in one case left the shutter the still partially open when it was meant to have closed.

Notes:

PHD2. Telescope was rebalanced in Dec/Altitude before the start of the session.
Short Mapping Job. Although telescope pointing of 'snap' images at commencement of session seemed very good following the necessary release of Dec Clutch during Tube Rebalaning, the Scope was resynced on a starfield and a short mapping run conducted. After which the scope was parked, powered off and then restarted.
Backlash. Dec Anti-Backlash setting in Scope at 85% for first 5 targets but then changed to 75% during Target 6 (M31 w/Transient).
Centering performance was poor and suggests and suggests that an anti-backlash setting of 90-95% would be better

(Whilst a lower value is potentially helpful to fix Dec jumps when changing Dec Guide Mode in PHD2, the lower values definately seem to lead to poorer centering.)

Summary Plots & Logs

Observing Plan

Observing Result

Dome & Scope Slewing Performance

Slew/Centering Performance
Poor centering performance in Dec. One rogue jog.

Guiding Performance
Reasons for poor guiding :

Black points (3 & 4)

RA Guiding Runaway due to calibration flip associated with inappropriate
setting of SideOfPier by telescope drivers

Sky Conditions (Locate Frames)
Sky Brightness measurements are invalid due to a SBIG camera bias level issue (eventually fixed 2022-01-02)

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
18:15:01	Camera1 Connected	SBIG Camera Connected (set point -15°C)
18:15:03	Session Created	Live Session Created (2021-12-10 S00940, ImageSaveNum: 940001)
18:15:17	Scope Switched On	Telescope Power has been switched on via UPB Powerbox.
18:16:54	Services Started	Observatory Services started
18:17:15	Telescope Connected	Telescope Connected (TheSky6)
18:19:39	Dome Opened	Dome opened (opening time 46s)
18:52:59	Observatory (Auto)	Observatory placed in Fully-Automated Mode
18:53:03	Session Pending	Session pending (2021-12-10)
18:53:05	Session Initiating	Session initiating (2021-12-10)
18:53:07	Plan Requested	Observing Plan requested from AstroPlan (1.29)
18:53:39	Plan Loaded	Observing Plan loaded to queue (, Plan ID: 693)
18:53:54	Camera1 Connected	SBIG Camera Connected (set point -25°C)
18:53:59	Telescope Connected	Telescope Connected (TheSky6)
18:54:18	Session Equilibration	Session ready for dome & camera equilibration
18:55:08	Session Running	Session running
18:55:11	Queue Started	Observing Queue started (40 targets selected)
18:55:14	Target Started (NrZen)	Target started (Focus Field 0, HIP 106)
18:56:49	Job Queue Frozen	Job Queue appears to have frozen at around 18:56 - 18:56
19:06:28	Obs.Monitor Frozen	Obs.Monitor appears to be frozen at around 19:06 in section Refresh Dome Picture
19:06:55	Session Suspended	Session suspended
19:07:45	Dome Closed	Dome closed (closing time 50s)
19:37:54	Session Resumed	Live Session Resumed (2021-12-10 S00940, ImageSaveNum: 940001)
19:38:22	Obs.Manager Started	Obs.Manager started
19:38:24	Obs.Overseer Started	Obs.Overseer started
19:38:28	Services Started	Observatory Services started
19:45:32	Services Stopped	Observatory Services stopped
19:45:37	Program Closed	Program closed by User
20:01:44	Session Resumed	Live Session Resumed (2021-12-10 S00940, ImageSaveNum: 940001)
20:07:40	Obs.Manager Started	Obs.Manager started
20:07:42	Obs.Overseer Started	Obs.Overseer started
20:07:45	Services Started	Observatory Services started
20:08:06	Camera1 Connected	SBIG Camera Connected (set point -25°C)
20:10:04	Scope Switched On	Telescope Power has been switched on via UPB Powerbox.
20:11:44	Services Started	Observatory Services started
20:12:03	Telescope Connected	Telescope Connected (TheSky6)
20:15:11	Dome Opened	Dome opened (opening time 45s)
20:15:31	Observatory (Auto)	Observatory placed in Fully-Automated Mode
20:15:33	Session Pending	Session pending (2021-12-10)
20:15:35	Session Initiating	Session initiating (2021-12-10)
20:15:39	Plan Loaded	Observing Plan loaded to queue (, Plan ID: 693)
20:15:52	Camera1 Connected	SBIG Camera Connected (set point -25°C)
20:15:57	Telescope Connected	Telescope Connected (TheSky6)
20:16:22	Session Equilibration	Session ready for dome & camera equilibration
20:16:24	Session Running	Session running
20:16:26	Queue Started	Observing Queue started (36 targets selected)
20:16:29	Target Started (NrZen)	Target started (Focus Field 1, HIP 4911)
20:17:38	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
20:19:50	Focusing Completed	Foc1 AutoFocus Completed (Profile No 1, wide)
20:21:57	Focusing Completed	Foc1 AutoFocus Completed (Profile No 1)
20:21:59	Focusing Started-Foc2	Foc2 Focusing Started (Secondary Scope, using ShCap)
20:24:09	Focusing Completed	Foc2 AutoFocus Completed (Profile No 2, wide)
20:25:55	Focusing Completed	Foc2 AutoFocus Completed (Profile No 2)
20:26:13	Target Completed	Target completed (Focus Field 1, HIP 4911)
20:26:15	Target Missed (5/40)	Target's time slot was missed (5/40, GCVS X TRI)
20:26:17	Target Started (6/40)	Target started (6/40, AT2021abed)
20:31:38	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
20:33:25	Focusing Completed	Foc1 AutoFocus Completed (Profile No 3)
20:47:39	Target Completed	Target partially completed (6/40, AT2021abed)
20:47:43	Target Started (7/40)	Target started (7/40, 10P/Tempel)
20:52:43	Focusing Skipped	Foc1 focusing skipped - star is lost (TCF-S)
21:02:34	Target Completed	Target completed (7/40, 10P/Tempel)
21:02:38	Target Started (8/40)	Target started (8/40, AT2021zkf)
21:06:13	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
21:08:53	Focusing Completed	Foc1 AutoFocus Completed (Profile No 4)
21:26:23	Target Completed	Target completed (8/40, AT2021zkf)
21:26:27	Target Started (9/40)	Target started (9/40, NGC 7446 w/SN2021agdd)
21:29:22	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
21:31:12	Focusing Failed	Foc1 focusing failed - star lost
21:47:43	Target Completed	Target completed (9/40, NGC 7446 w/SN2021agdd)
21:47:47	Target Started (10/40)	Target started (10/40, M31 w/AT2021aaxp)
21:50:21	Focusing Started-Foc1	Foc1 Focusing Started (TCF-S)
21:50:53	Focusing Aborted	Foc1 Focusing Aborted
21:50:55	Target Failed	Target failed due to aborted (10/40, M31 w/AT2021aaxp)
21:50:57	Queue Aborted	Job Queue aborted
23:56:49	Dome Closed	Dome closed (closing time 47s)
02:02:42	User Intervention	User request to close and finish session
02:02:44	Session Closing	Session closing
02:02:46	Dome Closed	Dome already closed (closed at 23:56, closing time 47s)
02:04:43	Dome Parked	Dome parked (parking time 113s), Az: 90.0 deg
02:05:59	Telescope Parked	Telescope parked (parking time 70s)
02:06:13	Telescope State	Scope parked Turn scope off. (Handbox)
02:06:34	Telescope Switched Off	Telescope Power has been switched off via UPB Switch.
02:07:29	Services Stopped	Night Services stopped
02:07:31	Session Housekeeping	Housekeeping Started (Cleanup FITS, Create Fits Summary, Transfer Files)
02:07:32	Session Finished	Session Finished

Session Alerts

Time	Alert	Detail
19:06:54	Job Queue	Job Queue appears to be frozen (last IamAlive message at 18:56:16)
19:06:59	Obs.Monitor	Obs.Monitor appears to be frozen in section Refresh Dome Picture (last cycle at 19:06:28)
20:06:49	UPB.Switch	Restarting UPB Powerbox Software
20:06:56	UPB.Switch	UPB.Switch service hasn't been restored

Operational Issues (2021-12-10, S940)

Critical Issues (1)
Major Issues (5)
Minor Issues (11)
Small Defects (1)
Continuous Improvement (3)

[ Prev | Next ]

Critical Issues

Auto guiding was totally impossible for targets lying west of the Meridian. RA guide pulses having exactly the opposite effect to that required causing the telescope position to move further and further away from the guide star, producing badly trailed runied images. This is a different issue to the previously session poorer guiding performance for targets lying west of the meridian which is probably related to poor telescope balance). This is a new black/white issue that is due to MeadeGeneric ASCOM driver sending SideOfPier information through to DeviceHub with value 'SideOfPier - pierUnknown'. DeviceHub then calculates a SideOfPier value (East or West) from the telescope position and passes this onto PHD2 which uses the SideOfPier to flip the Guiding Calibration when the target lies on a different side of pier to the side when the Calibration was performed. Issue originated from a telescope driver change in Jun/Jul 2021 but has only become exposed because a new Calibration had to be performed as part of start-up task for using PHD2 on the new Observatory Computer. Colin Dawson author of MeadeGeneric driver has been contacted who will address the issue. In the event of a dealy the workaround would be to add a temporary setting in AstroPlan program to only include observing targets in the night's observing plan that lie east of the Meridian (West SideOfPier equivalent) and by performing initial PHD2 calibration on that side. A new driver version has been sent through from Colin this evening (2021-12-11) and installed on the Observatory Computer. Connecting to the observatory's LX200 showed the driver reports 'CanSetPierSide: False', 'CanSetRightAscensionRate: False' and Get SideOfPier: Exception' . These should allow it to function correctly with PHD2 and hopefully resolve the issue. Just waiting now for the next clear night to test the new Telescope Driver against PHD2 to confirm that the fix works. Issue confirmed to have been fixed by live testing during session S941 (2021-12-13). See Investigation - Guiding Runaway (SideOfPier Issue).
Fixed 2021-12-13 (MeadeGeneric 1.3.3.370)

Major Issues

Unable to connect the SBIG Camera (daytime testing). Attempts to connect to SBIG ST-10XME Camera from CCDSoft kept failing with 'Error code 1027. Camera Driver/Device not found.' After looking at previous problems with this issue in the past, the solution was found and reemployed. The issue was resolved by removing the USB cable to the SBIG Camera, removing SBIG Drivers in 'SbigDriverChecker64', then locating all SBIGuDrv.dll files on the computer & rename them as SBIGuDrv.dll_old, and finally update/install drivers again from SbigDriverChecker64. After reconnecting the USB cable the camera was able to be connected to from CCDSoft5. Problem is due to 'DLL hell' and is a typical issue seen when setting the SBIG Camera/ CCDSoft on a new computer or on a new installation.
Fixed in-session 2021-12-10 (SBIG drivers / DLL Hell / CCDSoft5)
Unable to connect 'ZWO ASI 178MC' camera in SharpCap from AstroMain (daytime testing). The 'AUTO' connect was causing the Monitored Folder 'camera' (camera ID 5) to open instead of ZWO ASI 178MC (camera ID 0). Whilst trying to resolve this using a manually entered Camera ID the computer WebCam was accidently selected which causing Kaspersky security to put up a blocking dialogue that couldn't be dismissed remotedly over VNC connection and required an observatory visit to dismiss it (wish Kaspersky didn't block me over the VNC control, but I can see why it would block). Problem was due to the connect routine not recognising 'AUTO' (needed 'Auto'). Fixed by installation of AstroMain 3.48.2
Fixed in-session 2021-12-10 (CCDSoft5 / CFW-10)
CCDSoft5 hanging whilst downloading images from SBIG Camera. A temporarily showstopping problem with SBIG driver / SBIG Camera device left little time for full CCDSoft5/SBIG Camera and PHD2/SBIG Camera testing in the afternoon. The camera seemed to be working but slow to download in PHD2 ?. In the first integrated test in the evening, CCDSoft hung whilst trying to down the first focus frame image of the session. This caused ObsMonitor/ObsPic to hang in AstroMain and eventually caused AstroMain itself to hang. After parking the scope and closing down/stopping observatory software.CCDSoft5 was started by itself and although the SBIG camera connected ok, CCDSoft5 would again freeze when downloading a 1s test exposure. The issue problem. Reinstalled Device Hub, but again same problem. The issue was finally resolved by power-cycling the SBIG camera (this was achieved remotely from an IPad in the house using Philips Hue / Smart Plug Control)
Fixed in-session 2021-12-10 (DeviceHub / Computer)
AstroPlan not uploading Session and Observatory Status files from Live Folder to website. This was due to AstroPlan 1.29 being used instead of 1.29.1. The 1.29 version is previous version that checked that machine name is 'LAPTOP9_CHILL' before uploading a file. This had been changed in 1.29.1 to checking that machine name is 'LAPTOP9' (the name of new observatory computer), but the executable wasn't uploaded to the Observatory Computer ahead of the session.
Fixed 2021-12-10 (Observatory Computer, AstroPlan 1.29.1)
DeviceHub GUI sometimes entering a state when it become a blank white window, with only title and the minimise,maximise, close (X) icons showing . The background process still seem to be working and clickin the non-visible buttons might still work if one could see them. It is impractical to continue with the GUI in this state. Closing and reopening DeviceHub doesn't solve the problem. Nor does reinstalling DeviceHub. Rebooting the computer resolves the issue (at least temporarily), but this is unsuitable workaround for a live observing session. Sometimes a different display problem occurs where the telescope tabl is visible, but opening the dome tab gives a blank black area (with the custom theme) or the refresh of the telescope display freezes. At end of session, all client telescope connections were closed, but the DH telescope tab was still showing 4 connected clients. DH was closed ok without any warning that there were clients still connected, which demonstrates the field with '4 clients' was a frozen display. Pulsar Dome software would also enter blank white window state. Clicking the position of invisble 'Accept' button allowed a dialog window to be dismissed, suggesting that this is a windows / graphics issue of some kind and not a specific program bug. The issue didn't occur previously when using Windows 7 on previous observatory computer, it has only appeared using the new Window10 Computer. Windows 10 was being operated with a 'Scale and layout' setting of 125% at the time, but has now been set to 100% in case the scaled layout was causing the problem. The next session will be monitored to see if this resolves the issue or not. Issue may be related to the same graphics issue that causes Microsoft Start Menu, Settings and Microsoft Visual Studio to not display correctly after the Computer Screen is automatically turned off after a set period. Workarounds include not turning the Screen off in Power Options / not Closing the Computer Laptop lid, or using an HDMI Dummy Plug Virtual Monitor Display Emulator.
Resolved (Observatory Computer)

Minor Issues

CCDSoft reporting it was taken a 'R' filter image when it was taking an image with C Filter (filter position 1). Problem was due to CFW10 still have default filter settings from the program installation. The issue was fixed by updating filter names in CFW10 settings (under CCDSoft Camera) to the actual filter names.
Fixed in-session 2021-12-10 (CCDSoft5 / CFW-10)
Pegasus UPB Software is trying to use COM6 to connect to the UPB powerbox instead of COM4. Although Pegasus UPB Software was connected to UPB Powerbox via COM4 in the afternoon testing in the evening it kept wanting to connect to COM6 in the evening testing, and when changed to COM4 it would sometime freeze or crash. Workaround used to fix the issue in-session, but it is possible that AstroLaunch is setting up UPB Software to start with COM6 (probably a carry over from the COM setting on the old observatory computer). Worked around issue during the session but this is annoying and needs to be fixed. Resolved after examining code which shows the AstroLaunch modifies the COM Port for UPB in registry before launching UPB Software, but the values was taken from that shown on the Settings Form which was COM6. This setting was manually changed to COM4 after which UPB Software launches with the correct COM Port (note that the setting is saved to a ini/setting file in between AstroLaunch sessions)
Fixed 2021-12-12 (AstroLaunch Settings)
Program windows are too large and take up to much desktop space. Issue resolved following the session by changing Windows10's 'Scale and layout' display setting to 100% (instead of 125%). This reduces program window sizes in a manner that makes them more suited a multi-application environment.
Resolved 2021-12-11
A 'News/Weather' Window keeps poping up when moving mouse along the task bar. This is a Windows 10 defaullt feature but is it is really annoying. It happens whenever the mouse accidently hovers over the 'News and Interests' toolbar. Resolved following the session by right-clicking on the toolbar, going to News And Interests menu item and unchecking the 'Open on Hover' option. There is also an option to 'Turn Off' the toolbar altogether
Resolved 2021-12-11
AstroLaunch is crashing when attempting to open DeviceManager. Problem occurs on both the Observatory Computer and Development Computer (it doesn't occur however on the AllSky/Weather Computer, where DeviceManager launches ok). Bug fixed (Path name to device manager had accidently become corrupted in code line)
Fixed 2021-12-11 (AstroLaunch 1.8.1)
Attempting to change a setting in Kaspersky over remote connection to the Observatory causes the remote desktop to lock up due to a 'Security dialog' which can't be either actioned or dismissed. This prevents further interaction with the Observatory Computer until the observatory is visited and the security dialog actioned or dismissed in person. Although the option 'Allow managing Kaspersky Internet Security settings via remote control applications' was enabled and the VNC server was listed as a Trusted Application, the blocking Security dialog would still occur. Fix made by going to Kaspersky's Application Control/Manage Applications and navigating to the Details/Rule for the VNC server application, then going to the Exclusions tab and enabling the option 'Allow interaction with the Kaspersky Intenet Security interface'. Fix applied to observatory computer (2021-12-11) and to AllSky/Weather computer (2021-12-13)
Fixed 2021-12-11 (Observatory Computer / Kaspersky)
Unable to use Start Menu application list, Windows Setting or use Visual Studio due to display and/or scrolling issue. Fixed by keeping the lid of the Observatory Computer laptop open so the the Monitor is open and by chnaging the Power Options settle so that the monitor doesn't turn off for several hours. This is something to do with how graphic/graphics cards and GL . As an alternative fix (one suggested by an online forum) a '4K HDMI Dummy Plug High Resolution Virtual Monitor Display Emulator' had been ordered https://www.amazon.co.uk/dp/B096XQWYHQ/ref=pe_27063361_485629781_TE_item
Fixed 2021-12-11 (Observatory Computer / Kaspersky)
JPG Pictures (SBIG & 178MC Images) not available on current session web page. This was due to JPG picture creation (locate frames, focus frames, reference frames, main frames) not happening due to a missing ImageMagicK application. Fixed by installing ImageMagicK onto Observtaory Computer.
Fixed 2021-12-12 (Observatory Computer / ImageMagicK)
After restarting telescope and reconnecting again without closing DeviceHub application, slewing to a target would fail with the error dialog “SlewToCoordinatesAsync not allowed when the telescope is AtPark”. Error occurs even though Telescope driver report AtPark = False. This was reported to Rick Burke (author of DeviceHub) who corrected the bug in Device Hub's telescope park behaviour and issued a new version (v6.5.1.8). This was tested and confirmed to fix the issue (2021-12-13).
Fixed 2021-12-13 (DeviceHub 6.5.1.8)
Difficulty in accessing and launching DeviceHub (from outside of AstroMain), Pulsar Dome, UPB Software, PaintShopPro. Very difficult to use the Windows10 StartMenu over a VNC connection (list of apps won't scroll or it resizes or scroll bar isn't accessible) and having to navigate to the program's folder. Fixed by adding PaintShop Pro to QuickLaunch bar, by adding PaintShop Pro & DeviceHub to AstroLaunch Support Apps tab and resolving issue with seeing/manipulating Start Menu over VNC connection.
Fixed 2021-12-20 (AstroLaunch 1.8.2, Observatory Computer)
Get AllSky Camera measurements isn't working . Error message 'Data unavailable (AllSky Camera measurements are unavailable). Finally fixed in AstroMain 3.48.10.
Fixed 2021-12-26 (AstroMain 3.48.10)

Small Defects

The Get Current Sky Meas routine in AstroMain (part of Conditions section) is failing with the message 'TP2.DateTime=Nothing? (String was not recognized as a valid DateTime). Also multiple exceptions being logged for 'Exception in GetCloudInformation'. Fixed around 2021-12-26.
Fixed 2021-12-26 (AstroWeather/AstroAllSky, AstroMain)

Continuous Improvement

Create a Bad-Pixel Map in PHD2 for the 178MC camera. Bad Pixel map created in PHD2 for the 'TS80/178MC' profile using 'Darks/Bad-Pixel Map' menu option and 21 x 10s dark frame and the standard 75% agression settings'. TS80 telescope was covered during the operation, and uncovered again at the end.
Done 2021-12-13 (PHD2, Observatory, 178MC)
Update TheSky6 connection routine to also report scope's current Tracking Rate. This can be accessed by sending a CommandString ("GT") command to the scope.
Done 2021-12-14 (AstroMain 3.48.4)
Add routines in AstroMain and accompanying user button options for setting the Tracking Rate on the observatory's main telescope (LX200GPS/R) LX200's. Options should be Sidereal, Solar, Lunar & Custom. Testing will be required in view of the telescope's firmware x10 finer tracking and custom tracking rate used and saved at end of session. Buttons added by there are some discrepencies with how LX200 deals with/interprets tracking rate setting / tracking rate Hz rate.
Done 2021-12-15 (AstroMain 3.48.4)

[ Prev | Next ]

First Session with new Observatory Computer

Following a total failure of old Observatory Computer (2021-12-05) a replacement computer has been acquired (2021-12-09) and software including multiple pieces of observatory software installed (2021-12-09 to 10). This included ASCOM 6.5 SP1,Software Bisque software (TheSky6, CCDSoft5 and TPoint), Pegasus Power Box, and ASCOM drivers (UPB, PulsarDome, TCF-S focuser, MeadeGeneric, SBIG, ZWO ASI) and AstroSuite/Observatory Control software (AstroMain, AstroPlan, AstroGuard, AstroLaunch, AstroShCap) and support programs (PHD2, SharpCap 3.2). Various settings were taken from setting recovered from old observatory computer's SSD drive (using an mSata to USB adapter) or recreated where necessary.

- Issues discovered during installation and resolved are described here.

Pre-Session Issues (Daytime Testing)

The following issues were found during the daytime testing in the observatory and resolved prior to the nightime session.

Unable to connect the SBIG Camera
Unable to connect 'ZWO ASI 178MC' camera in SharpCap from AstroMain

(see Operational Issues for more details and current status)

Session Issues (Night-time Testing)

The following issues arose setting up and conducting a nightime session

CCDSoft reporting it was taken a 'R' filter image when it was taking an image with C Filter
CCDSoft5 hanging whilst downloading image from SBIG Camera
DeviceHub GUI sometimes entering a state when it become a blank white window, with only title and the minimise,maximise, close (X) icons showing.
Pegasus UPB Software is trying to use COM6 to connect to the UPB powerbox instead of COM4.
JPG Pictures (SBIG & 178MC Images) not available on current session web page.
Program windows are too large and take up to much desktop space
AstroLaunch crashing when attempting to open DeviceManager on Observatory Computer and Development Computer
Difficulty in accessing and launching DeviceHub (from outside of AstroMain), Pulsar Dome, UPB Software, PaintShopPro
A 'News/Weather' Window keeps poping up when moving mouse along the task bar
(see Operational Issues for more details and current status)

Com Ports

Device	Primary Com Port	Secondary Com Port
Pulsar Dome	COM3	unknown (n/a)
UPB Powerbox	COM4	unknown (n/a)
TCF-S Focuser	COM5	unknown (n/a)
LX200 Telescope	COM6	unknown (n/a)

Whilst primary COM Port numbers are identified for the key observatory equipment that use Serial ports, and recorded in the necessary program settings (AstroMain and later in AstroLaunch) it hasn't been possible to determine secondary ports. These are port numbers that device can potentially jump to if inserting USB cables into different ports on the USB hub/computer or for some other hardware, software or Windows OS glitch. This was seen on the old observatory computer (Windows 7) but it is not yet known if this behaviour will be seen on the new observatory computer (Windows 10). Rebooting the computer always results in devices returning to their respective primary COM Port.

AstroMain has routines that automatically update ASCOM profiles to use the primary/secondary COM port dependant on which Port is active, and monitor sessions in progress to see if Com Port has switched and automatically restart the connection to the respective device on the new port. Until secondary ports are identified these routines won't be able to perform the task of automatically resetting the driver COM port setting if the device jumps to a secondary port.

Update 2022-06-21: During the first 6 months / 80 sessions since installation of a new observatory computer on 2021-12-10 the attached devices have continuously remained locked-on their original COM Port settings.. This would seem to be associated with either new computer hardware / USB controller or with the use of Windows 10 operating system (instead of Windows 7).

Investigation - Guiding Runaway (SideOfPier Issue)

Issue : Guiding Runaway occuring in RA after performing PHD2 Calibration on new observatory computer

Description
After the failure of the previous Observatory Computer after session S939 (2021-12-05) a new Calibration had to be performed on the new replacement computer. This was performed at the start of session S940 (2021-12-10) using a starfield close to Dec 0 and just east of the celestrial meridian. Calibration data was checked and satisfied with its quality, the observing session was begun

Guiding performance on the first two targets was good. Both target lays east of Meridian, i.e on the same side as where the Calibration was performed.

Guiding performance on the next 3 targets (AT2021zkf, NGC_7446 & M31) was terrible with immediate runaway in RA guiding. It appeared that each RA guide pulses was pushing the star further and further away from star lock position. Quickly the RA guide pulses reached the Maximum RA guide pulse setting of 2500 ms. Over the course of a 180s exposure telescope was being shifted some 9 arc minutes in cases where the guide star was followed and not lost. Often the guide star would eventually became lost.

180s exposure, C Filter, #940017

The 3 targets with terrible guiding all lay on the west side of the Meridian, i.e. on the opposite to where the calibration was performed.

Whilst guiding on the observatory telescope is generally poorer on the west side of the Meridian (due usually to Dec guiding / possibly balance issue), the guiding character is nothing like these new cases which are clearly suffering from RA guding runaway.

Investigation
The observing objectives for the session was placed on hold, whilst investigation was carried out.   This began with guiding test on starfields just west of and just of the Meridian.   The starfield just west of the Meridian suffered from the same terrible guiding whilst the starfield just east of the Meridian had normal guiding.
The tests were repeated with same result. A test was performed where guiding started east of the Meridian and kept running whilst the starfield crossed the Meridian, this has normal guiding throughout. The pointing position (the SideOfPier) when the guiding started was a key factor, not the pointing position (SideOfPier) later on.

This indicated a 'SideOfPier' related issue, and seemed to try up somehow with the appearence in July 2021 onwards, with warning messages from PHD2 saying that 'SideOfPier had changed but the Calibration doesn't have SideOfPier information'. The Calibration that was being used on the old Observatory Computer was made prior to June 2021. With the making of a new Calibration (for the new Computer) it suddenly had SideOfPier information and it was evident that PHD2 was performing a Calibration flip when starting to guide on target starfields lying on the opposite of the Meridian.

Analysis
A calibration flip is the appropriate action for a GEM Mounted scope when guiding on targets lying on the opposite side of the Meridian to where the Calibration was performed.   RA pulses (and for some designs Dec pulses) have to be inverted to produce the neccessary guiding effect.

However for my Fork & Wedge Mounted LX200 Scope, RA and Dec Pulses shoudn't be inverted when crossing the Meridian (It doesn't really have a SideOfPier so to speak).   There is a way to turn off Calibration Flipping in PHD2. All that can be done is to toggle a setting so that a new calibration is automatically performed on each and every target, which would interfer with observing and could possibly give rise to a hold-up to automated operations if the calibration fails and user involvement is required.

The problem is due to ASCOM telescope sending SideOfPier (pierEast or pierWest) through to PHD2.
     SideOfPier = pierEast, or
     SideOfPier = pierWest

Whilst the issue only became exposed in my system just now when it became necessary to do a new Calibration in PHD2 (because of a new computer)
looking back at earlier logs on my system it can see that the issue inherently dated back to the June 2021 version of MeadeGeneric telescope driver (v1.2.0) when it implemented the SideOfPier property and on my system it began returning.
    SideOfPier = pierUnknown

This would probably have been ok for PHD2 except that a previous change in DeviceHub made earlier in Oct 2020 (v 6.5.0.1) caused DeviceHub to step in upon seeing 'pierUnknown' from the telescope driver and calculated a SideOfPier value ( 'pierEast' or 'pierWest') based on the telescope position.
    SideOfPier = pierEast, or
    SideOfPier = pierWest

The pierWest/pierEast became used by PHD2 and resulted in the showstopping RA guiding runaway issue on my system.
It also now explains the frequent PHD2 warnings that began to appear in July 2021, saying

Prior to June 2021 MeadeGeneric was throwing an exception on my system
SideOfPier = Not implemented

Fix (2021-12-11)
Colin Dawson and Rick Burke (authors of MeadeGeneric Driver and of DeviceHub respectively) were contacted regarding the issue with result that a fix was made in MeadeGeneric development version 1.3.3.370. This was tested (2021-12-11) and for my system the original behaviour of throwing a 'Not Implemented' exception is restored :

SideOfPier = Not implemented

DeviceHub see this exception and reports SideOfPier as 'Unknown' on its Telescope Control tab and doesn't attempt to set a pierEast or pierWest but simply passes on the exception. PHD2 reports the SideOfPier as 'N/A'.

Testing (2021-12-13)
Testing confirm that the fix in MeadeGenric 1.3.3.370 has resolved the earlier Guiding Runaway/SideOfPier issue
(The fix will no doubt be ruled up into a official MeadeGeneric release in due course).

Update (2021-12-14)
A new version 6.5.1.9 version of DeviceHub was released today (2021-12-14) with a fix to 'Ensure that a telescope side-of-pier is only calculated for a German Equatorial mount'.

Actions
SideOfPier : Update 'TheSky6 connection' routine in AstroMain to report the scope's SideOfPier to check that pierEast/pierWest doesn't start to appear again following future releases of DeviceHub/MeadeGeneric.

2021-12-12

Investigation - LX200 Tracking Rate Discrepency (2021-12-12)

Issue : Telescope Tracking isn't at Sidereal Rate (contrary to the running assumption that is was on sidereal rate)

Description
Whilst looking at the telescope logs in connection with a separate ( SideOf Pier) issue it was noticed that there were TrackingRate messages like

13:40:56.199 TrackingRate Get 60.0 driveLunar

That was considered odd, because :

1) A rate of 60.0 Hz would be Solar Tracking rate (driveSolar), Lunar Tracking Rate is 57.9 Hz
2) I thought I was using a Sidereal Tracking rate (60.1 Hz) driveSidereal

What’s going on, I expected to see "60.1 driveSidereal' being reported !

Confirmation of Discrepency
Scope was powered up, connected and the the Tracking Rate setting in AutoStar II examined using Virtual Handbox . It shows that the scope is set to "Sidereal" tracking

Setting was confirmed and the MeadeGeneric log reexamined but is still shows "60.0 driveLunar"

13:44:12.360 TrackingRate Get 60.0 driveLunar

Analysis (Problem 1)
Problem 1 was determined to be a bug/limitation of the MeadeGeneric code which only considers Sidereal and Lunar options

In the Get Tracking Rate function it can be see that the following code line leads to the function returning driveLunar whenever the scope tracking rate is not 60.1, regardless of what the rate actually is.
DriveRates result = rate == "60.1" ? DriveRates.driveSidereal : DriveRates.driveLunar.

Bug has been reported to author of MeadeGeneric driver for his examination/fix.

Analysis (Problem 2)
Problem 2 was harder to explain: Why was the value returned by a GT (Get Tracking) command 60.0 , rather than the expected sidereal rate (60.1) which should be associated with the scope’s current Tracking Rate setting (“Sidereal”).

Eventually this was determined to be a misunderstanding / forgotten awareness of exactly how the observatory scope is configured after its firmware was upgraded from 4.2g to a 4.2G patch back in 2013, and also an apparently undocumented feature of the Custom Tracking Rate in AutoStar (or at least its behaviour in 4.2G Patch)

In 2013 I updated the scope’s firmware to 4.2G in order to access two (at the time critical) enhancements.

10x finer tracking rate
Tracking Rate can be specified to a x10 finer rate than the default (4.2g) firmware

The 10x finer Custom Tracking Rate adjustment to 0.01% of sidereal allows adjusting custom tracking rates to greater precision
Save tracking rate
The Custom Tracking Rate is restored at Power Up

This is in contrast to the default operation of the Autostar which is to reset the Tracking Rate to Sidereal upon power-up

(At the time I found the scope tracking rate wasn’t close enough to sidereal rate and I could correct this with my own custom rate,
but didn’t want to have to reenter the value every time the scope was powered up)

This firmware behavior might explain why the GT command is returning 60.0 since if I might still have ‘60.0’ in the custom setting in the scope from when the custom setting was last used for Solar Observing more than 12 months ago and my 4.G patched scope might use the custom value even though the Autostar II implies that I’m using Sidereal.

Custom Rate is specified by entering a signed value that adjusts the 'standard' tracking rate. In 4.2g the adjustment is 'signed value * 0.1%'. In 4.2G the adjustment is 'signed value * 0.01%'

It was thought that the standard tracking rate reference would be sidereal rate (60.1), but it now seems that the standard tracking rate reference is in fact 60.0

The LX200GPS/R manual states:

Custom Tracking Rate allows you to enter values from -999 (stands for -99.9%) to 999 (stands for +99.9%). The lower the number, the slower the rate. If you enter -999 the telescope will move so slow as to appear to be stopped. If you enter 999, the telescope will be moving at approximately twice the tracking rate.

but doesn't explicity say what the reference tracking rate (what does 0 exactly stand for ?)

The Sun tracks at 99.7270% of sidereal rate. I original though that this would be entered in Autostar II's Custom Tracking as -3, representing 0.3% slower than sidereal (-999 would stand for 99.9% slower). However for my LX200 which has firmware updated to 4.2G v19 and uses 10x finer tracking rate I originally thought the Custom Tracking should be set as -27, representing 0.27% slower than sidereal, -999 would stand for 9.99% slower) .
( I believe that I have subsequently show that this is probably wrong and Solar Rate should be entered as +0 on my scope (i.e. 60 Hz + 0.00%) )

However the discrepancy doesn’t end there :

- I’ve gone into Scope Tracking Rate setting and went to ‘Custom’ expecting to see –27 (for Solar Rate equivalent) but it doesn’t , instead it has the value 0 (I suppose it’s possible that it was –27 but going into custom from a previous position of Sidereal being previously selected might set the displayed custom value to 0 upon entry)

- If I enter a custom value of 0, and Save it , I find ‘Sidereal’ is still the selected Tracking Rate after going up to Telescope Setup and then going back down into Tracking rate.

- I then entered a custom rate of +1 (which I originally understood to be Sidereal Rate + 0.01% on my scope, ie 60.10601 Hz
But after saving this the drivers log file still reports “60.0 driveLunar”

- I then restarted the scope thinking that it needed to go through a reboot stage to pick up the new value. The TrackingRate in the scope is still showing as “Custom” with a value of +1 which would be equal 60.10601 Hz but the driver log file still reports “60.0 driveLunar”

Eventually I concluded that the % adjustment in ‘Custom’ isn’t a +/- % adjustment to sidereal rate (60.1) but a +/- % adjustment to a standard 60.0 Hz rate .

- Putting in a custom rate of +17 (from (1 - (60.1/60.0) *100 *100), leads to the driver log reporting “TrackingRate Get 60.1 driveSidereal”

So after a lot of investigation I think that’s the second half of the discrepancy is explained.

Scope will be left with this custom rate of +17 and the tracking/guiding behaviour of the scope monitored during the next live session.

Actions

Communicate driveLunar Tracking Rate bug to Colin Dawson (author of MeadeGeneric driver)

Change Custom Tracking Rate in scope to +17 (ie 60.1 Hz equivalent)

Monitor the tracking/guiding behaviour of the scope during the next live session (S941 session)

Update TheSky6 connection routine in AstroMain to report scope's current Tracking Rate

Add routines in AstroMain and accompanying user button options for setting the Tracking Rate on the observatory's main telescope (LX200GPS/R)

Update 2021-12-14
Using :STtt.t# method of setting tracking rate on LX200 (via btnSetTrackingRate.Click) shows some anomalies

:ST60.2# puts LX200 Tracking Rate to "Custom" , +16 (4.2G) [ ~ +2 (4.2g) ]
but GT command returns +60.1 (ie Sidereal Tracking Rate)

:ST60.1# (intended Sidereal Tracking Rate) puts LX200 Tracking Rate to "Sidereal"
but GT command returns +60.0 (ie Solar Tracking Rate)

:ST57.9# (intended Lunar Tracking) puts Tracking Rate to Custom, -365 (4.2G) [ ~ 37 (4.2g) ]
but GT command returns 57.8

:ST58.0# puts Tracking Rate to Custom
but GT command returned 57.9 (i.e. Lunar Tracking Rate)

Send GT command... Info Tracking Rate is unknown
GT Command : Fail Timed out waiting for received data

Send GT command
17:01:07.395 CommandString raw: False command GT
17:01:07.426 CommandString Completed: +60.1

This Web Page:	Notes - Session 940 (2021-12-13)
Last Updated :	2024-09-28
Site Owner :	David Richards
Home Page :	David's Astronomy Web Site