PHD2 calibration successfully performed on the ZWO ASI ASCOM CAM  profile, comprising  ASI Camera (1) (ASCOM)  with POTH.Hub (ASCOM)   This is a neccessary step for mixing PHD2 autoguiding with AstroMain's access to ZWO ASI 178MC  camera for focusing and medium field shots.

Calibration for ZWO ASI ASCOM CAM  Profile - 2018-12-04

Earlier Calibration for ZWO ASI1878MC Profile - 2017-11-14

 

With temperatures down to -4 degC,  a heavy frost and with the dome open all night a frost developed on the inside of the Dome This included some quite nice frost patterns on the inside surface of the Shutter.  These patterns had melted slightly by the time I took a picture of them with a camera, but their main features can still be seen.

Frost Patterns on Dome Shutter (click on image to enlarge)

After parking the LX200 scope at 06:37 (following earlier computer carsh/restart) the AstroMain program was left running with connections to the Pulsar Dome (Parked) and LX200 Telescope (Parked) and the AstroGuard program was left running with connection to the Pulsar Dome

AstroMain		AstroGuard
Time	Report Log	Time	Report Log
06:36	ASCOM Dome (COM9):  Started	06:36	ASCOM Dome (COM9):  Started
09:11	"Dome has changed from COM9 to COM4"	09:11	Detected Dome had moved from COM9 to COM4
	An attempt will be made to restart the dome connection		An attempt will be made to restart the dome connection
	ASCOM Dome (COM4):  Started		ASCOM Dome (COM4):  Started
10:41	Dome Port lost		No message from AstroGuard at this time
	An attempt will be made to restart the dome connection
	ASCOM Dome (COM4):  Started
11:45	Dome Port lost		No message from AstroGuard at this time
	An attempt will be made to restart the dome connection
	ASCOM Dome (COM4):  Started
13:15	Dome Port lost
	An attempt will be made to restart the dome connection		No message from AstroGuard at this time
	ASCOM Dome (COM4):  Started
~ 14:40	Dome Connection noticed to not be working from POTH Hub
14:46	ASCOM Dome Stopped		ASCOM Dome Stopped
14:46	ASCOM Dome (COM4):  Started		ASCOM Dome (COM4):  Started

At some point (possibly in association with event at 09:11 but possibly later)  it was noticed that an ASCOM error message had popped up saying that the Meade LX200GPS/R Telescope Driver had stopped working. (going into debug implied a possible Out of Memory exception, this was without any source code however )

ASCOM Meade LX200GPS/R  Telescope Driver stopped working

There was no change to the Pulsar Dome's COM port associated with a momentary Power Grid outage at 14:06
(an event which has caused the COM Port for  Pegasus Ultimate Power Box to change)

At 2018-12-05 14:06 local time there was a a very small power grid outage and I noticed the house lights go off momentarily (<0.5s) and then come back on again. I looked back at my remote desktop connection to the Observatory Computer and noticed that the Pegasus Ultimate PowerBox software had put up a message  "Disconnected From Device".  Clicking the 'Reconnect'   button produced the message "Can't detect a UPB Controller".    Examining the Device Manager showed that the COM Port associated with the Power Box had shifted from its primary COM Port (COM6) to its secondary "switch-to" port (COM3). Port Monitoring logs confirm the change in COM Port at this time.

Perhaps I need to look into and invest in a UPS to prevent small power outages from having such an affect.  I have collected enough evidence to see that this would probably stop the UPB port changes, but I’m uncertain if it will stop the Dome port changes.   Crucially there was no change to the Pulsar Dome's COM port associated with the momentary Power Grid outage at 14:06.

Ultimate PowerBox disconnected and unable to reconnect again following a momentary Power Grid outage at 2018-12-05  14:06 GMT and associated change in its assigned Com Port

Disconnection from UPB Device (in direct/immediate response to momentary Power Grid Outage)

Can't detect a UPB controller (message when attempting to reconnect to PowerBox)

Device Manage listing directly after the event Shows COM3 instead of the Powerbox's usual COM6

Data from Port Monitoring Log (COM 6 used by PowerBox dropped out and replaced by COM3 at 14:06)

Given several events involving connection issues with the 12" LX200GPS/R  since installing the scope in the dome I looked into potential solutions to improve things and came across a new piece of technlogy which was a Pierro-Astro USB-RS232 cable with integrated interface for LX200 (Product Page at Pierro-Astro).   I bought one through www.astroshop.de (Product page at AstroShop)  and it arrived today.  The cable is 1.80m long and as a single piece it has the opportunity to replace the traditional 3 piece  solution (custom serial cable, serial-USB interface, usb cable).  

Pierro-Astro USB-RS232 Cable for LX200

The cable is too short to connect back to USB Hub attached to the Observatory Computer (at least without a USB extension cable),  but it can plug into a USB port on the recently acquired Ultimate PowerBox that is now attached to  LX200's right hand fork arm.  The cable does run the risk of being wrapped around the pier/wedge if the scope were to move clockwise beyond the North position, but this is the same risk already carried by the power and USB connection to the PowerBox. The cables are most 'happy' when operating in the NE, SE and SW quadrants.

There is a slight impediment to smooth movement of the cables due to the castellation on the cable retaining sleeve as it moves across the right hand arm of the wedge when the scope is moving in the NW quadrant but this is not enough to be a serious problem.     The retaining sleeve is used to provide a bit more rigidity to the cable ensuring that hang away from the adjustments knobs on the wedge which are hazards for catching an otherwise loose/wandering cable.

Of more concern is that the cables gets pulled across the front of the mount's base and becomes quite tight when the scope is just west of North. Until a better configuration is developed an azimuth exclusion zone will be introduced which will exclude targets lying between 340 and 360 degs, unless I'm in the observatory and watching the cables.  This will not be a significant issue for most observing targets.

One point of concern is that the integrated interface seems to use the same FDTI chip as in the Serial -USB interfaces used by the Pulsar Dome and Pegasus UPB controllers, for both of which  I have encountered issues with their COM Port changing during operation on my particular (Windows 7) system,  either apparently randomly or clearly in response to a momentary power interruption.

This concern was proved valid a few days later  when a test was carried out where the power switch on the USB Hub that is dedicated to the UPB PowerBox was flipped (flipping the power switch to the UPB itself would have the same effect based on past experience).    The COM Port's for both UPB PowerBox and the Pierro-Astro USB-RS232 interface both changed.

Data from Port Monitoring Log (COM 6 used by UPB PowerBox dropped out and replaced by COM3 at 15:50. At the same time COM7 used by Pierro-Astro USB-RS232 dropped out and replaced by COM8)

Following a proposed way foward that was set on 2018-12-05 and two further computer crashes on 2018-12-08 (02:30) and 2018-12-09 (06:11) a number of steps were then followed:

•  Run System File Checker    (2018-12-10)
     $ sfc /scannow
• Run Memory Checker  (2018-12-10 )
• Check /Repair Disk  (2018-12-11 01:37)
   $ chkdsk /r
• Run base systems only (for 24h+) then incrementally add in extra Services/Hardware  (from 2018-12-11 02:40 onwards)

The System File Checker and Memory Checker didn't show up any problems. However the results of the memory checker couldn't be found after computer resumed windows operations.     The Disk Checker (CHKDSK) showed up a couple of bad sectors (on none crictial files) which were automatically add to Bad Clusters File and discovered some free space that was marked as allocated in the master file table (MFT) and made corrections to the file system.

Results of the CHKDSK couldn't be viewed before Windows resumed its operations, but were accessed later by running the following command in PowerShell to place the results in a user accessible file.

get-winevent -FilterHashTable @{logname="Application"; id="1001"}| ?{$_.providername –match "wininit"} | fl timecreated, message | out-file C:\CHKDSKResults.txt

(from this article : https://www.download3k.com/articles/Chkdsk-Log-Location-in-Windows-7-8-10-01514 )

Computer resumed operations running AstroMain with basic services at 2018-12-11 02:40. Over the next 12-48 hours extra observatory services were progressively added without any new computer crashes.   The only item not yet brought on line in the observatory is the LX200 telescope.   (it can be noted that a lot of the earlier crashes happening without the LX200 Telescope being connected)

As at 2018-12-14 10:00  the computer has now be running 3.3 days since it was restarted following the System, Memory and Disk Checks.
Making a total of 5.1 days since the last crash  / unexpected restart.   Progress but

(When Services were briefly stopped at 2018-12-11 20:29, two services failed with exceptions. These are noted as they're the first time these errors have been seen with these devices. They're most likely to be unrelated to the earlier computer crash issue

Focuser1:         Fail   The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
PowerBox Switch:  Fail   The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

 

A number of day-time observatory tests were conducted as part of continued investigation of COM Port switching issues seen on the Observatory Computer (Laptop9) and to understand the behaviour of the Dome Shutter in the event of a prolonged power grid outage.

1. Observatory Computer (Laptop9, OS Windows7) running UPB Software and connected to UPB via USB Hub
   
   a)   Unplugged the USB Cable from the UPB PowerBox to the USB Hub
   
   Result: UPB (COM6)  and the connected Pierro-Astro USB-RS232 interface (COM7)  lost from Device Manager's  list of devices.
   UPB Software lost connection with the UPB PowerBox and produced the 'Disconnected from Device' dialog message.
   
   b) Replugged the USB Cable
   
   Result:   UPB and the connected Pierro-Astro USB-RS232 interface reappeared in Device Manager list of devices  but with Ports changed to COM3 and COM8 respectively.
   
   Notes: this is the same behaviour as shown in the test on 2018-12-11 when power to USB Hub was flipped off/on, and consistent with behaviour associated with a Power Outage Event on 2018-12-05 and earlier power disconnection & COM Port issues with UPB just after initial installation (2018-11-01 to 2018-11-09)
   
   Proposal :
   -  Repeat  Development Computer (Laptop10, OS Windows10) test but without the UPB Software running/connected
   
   -  Repeat  Development Computer (Laptop10, OS Windows10) test but without using an intervening USB Hub
    
   
2. Development Computer (Laptop10, OS Windows10) running UPB Software and connected to UPB via USB Port on Computer
   
   a)   Unplugged the USB Cable from the Compluter
   
   Result: UPB's USB Serial Port (COM6) and the connected Pierro-Astro RS232 USB Serial Port (COM5)  lost from Device Manager's  list of devices.
   UPB Software lost connection with the UPB PowerBox and produced the 'Disconnected from Device' dialog message.
   
   b) Replugged the USB Cable
   
   Result:   UPB and the connected Pierro-Astro USB-RS232 Serial Ports reappeared in the Device Manager list of devices with the same Port Numbers (i.e. COM6 and COM5 respectively)
   
   Notes: this is expected (hoped for) behaviour for the disconnection/reconnection of USB-Serial device using Virtual COM Ports, and differs from the behaviour seen on the Observatory Computer.  Is this a Windows 10 vs Window 7 difference, a specific anomalous behaviour of the Laptop9 computer, or is it related to use of an intervening USB Hub ?
   
   Proposal : Repeat  Development Computer (Laptop10, OS Windows10) test but using the intervening USB Hub
    
   
3. Observatory Computer (Laptop9, OS Windows7) running AstroMain and connected to Pulsar Dome via USB Hub
   
   a)   Unplugged the USB Cable from the Pulsar Dome to the USB Hub
   
   Result: Pulsar Dome (COM9)  lost from Device Manager's  list of devices.
   
   b) Replugged the USB Cable
   
   Result:   Pulsar Dome's USB Serial Port  (COM9)  reappeared in Device Manager list of devices with the same Port Numbers (i.e. COM9)
   
   Notes: this is the expected behaviour for the disconnection/reconnection of USB-Serial device using Virtual COM Ports, and differs from the behaviour shown by the UPB PowerBox .    The result shown by the Pulsar Dome is consistent with the observation that its COM Port didn't change during the momentary Power Outage event on 2018-12-05 whereas the COM Port for the UPB did change.  The expected behaviour seen in this test doesn't offer an explanation of the random changes in Pulsar Dome USB Serial Port that have been recorded during 24x7 port monitoring. (2018-11-26, 2018-11-27)
    
   
4. Observatory Computer (Laptop9, OS Windows7) running AstroMain and connected to Pulsar Dome via USB Hub
   
   a)   Pulsar Dome Shuttter Settings checked using Dome Controller Interface - timer value  changed from 10 min to 5 mins
   
   b)   Dome Shutter opened via AstroMain / POTH.Dome
   
   c)  Power to Dome Controller turned off
   
   d)  Waited
   
   Result:   After 5 minutes the Dome Shutter automatically closed itself
   
   Notes: Provided the shutter has been opened via Dome Controller or Computer Connection (rather than the Red Button on the Shutter Drive Unit), the Shutter Controller will close itself if it hasn't heard from main Dome Controller for more more than the timer setting.   Five minutes appears to be the shortest possible setting. 

Discussion:

Previous observations have shown the UPB Software is unable to connect to UPB after COM Port has changed. The Observatory Laptop has to be rebooted in order to reconnect to UPB (unless the recently developed workaround is used whereby the UPB Software Process is killed and  UPB's COM Port set to the new Port using ASCOM.Profile, before relaunching the UPB Software ).

In case of test 2 where the COM Port doesn't change , the user can dismiss the Disconnected from Device dialog message and click on the Connect Button to resume the connection.     But should   UPB Software previously assist  automonous operation by automatically resuming the connection to the UPB if the UPB's COM Port comes back online ?   Two schools of thought on this : -

It can be argued that UPB Software behaviour is the right one.  It has spotted that it has become disconnected from the device and has flagged this up for the user to decide what to do next. Perfectly reasonable ?

However having previously set Auto-Connect to on, it could be argued that the a user might expect that the UPB software monitors the situation and if the Device's USB-Serial Port reappears and becomes potentially reconnectable and the user hasn't intervened then the UPB software should reconnect by itself.

Test 4 shows that in the event of a power cut during an observing session the Dome will automatically close itself. This is especially important for unattended operation.    With the current setting this will occur after 5 minutes.  There is a residual risk that rain could commence before the 5 minute period timeouts, however rain radar forecast from 'darksky.net' and monitored by the AstroWeather program (running on Laptop7) and communicated to the AstroMain Program (running on Laptop9) would hopefully catch the imminent rain threat and have commanded a closure of the shutter before the power cut occurs.

Other Items and Issues

• AstroMain's UPB Com Port Monitoring (part of Observatory Manager main loop) is outputting an inappropriate blank line for every loop of the Observatory Manager (ie every 5s) after the USB-Serial Port to UPB is lost and not yet changed to a new COM Port number
  
• AstroMain's UPB Com Port Monitoring should only be active when using PowerBox Services (i.e. it should be deactivated when Power Services are not being used
  
• AstroMain's UPB Com Port Monitoring & Response should be extended to attempt a restart of the UPB connection when it detects the UPB has gone offline (noticeable by the ASCOM UPB dreivers starting to send invalid data  (eg. Env.Temperature, Env.Humidity & Env.Dew Point all returning 0.0).
  
• AstroMain's ObsEnv sending service and/or AstroWeather's ObsEnv recieving service should set UPB Sensor Values to null (-99) when Env.Temperature, Env.Humidity and Env.Dew Point values are showing 0.0 due UPB Software loosing its connection with UPB PowerBox or AstroMain's ASCOM UPB clients loosing connection with the UPB software/server