• A new ASCOM Driver (6.3.10, dated 2023-06-27) was installed on the Observatory Computer today (2023-11-15)
  along with latest Pulsar Client Software (1.0.53.0 with Firmware 1.51, similarly dated 2023-06-27).
  
  Previous versions were "Pulsar Observatories Dome Drive Version: 6.3"  and Pulsar 1.0.38 (2021-03-03).
   
  
• Pulsar Client Update
  A screenshort of previous Pulsar Settings (1.0.38) was first captured for comparison and check against the Pulsar settings after update
  
  Upon installing new Pulsar Client Software (Pulsar_Client_Setup 1.0.53.0.msi), an  'Updating Devices' window was shown which seemed to successfully complete (100%)
  
  Opening the Pulsar Client Software the window seemed similar to before
  
  
  
  Opening the Settings window showed that previous Dome Settings (Home and Park Angles), Relay Settings (NO polarity, 30s delay)  and Shutter Settings (5 min timeout) had been preserved.during the update.  Firmware version shown in the Unit Information was now showing as 1.51 ~ B (vs 1.41 ~ B previously)
  
  
  The Pulsar Client program was then closed as operation of the dome is normally performed via ASCOM Client Programs.
   
• ASCOM Driver Update
  
  The new ASCOm driver (Pulsar Observatories ASCOM Driver 6-3-10-0.exe) was successfully installed.
  
  Checking ASCOM Profile Explorer showed that settings were unchanged
  
   
• Opening DeviceHub and making connection to dome connected to Pulsar Dome showed expected information from Dome.
   
  
• Opening the ASCOM Log still showed Driver Version as 6.3. The sub-version number ".10" is not shown. This may or may not be a limitation in ASCOM itself ?
  
  
    DriverInfo Get          Pulsar Observatories Dome Drive Version: 6.3
  DriverVersion Get       6.3
  
  Some of the inital Connection messages are different, suggesting that the Driver has been updated. New log message lines are
  
   Connected Syncing Syncing 0, RX: 0 ,Port: COM3
 Connected Syncing Syncing 1, RX: 1 ,Port: COM3
 Connected Syncing Syncing 2, RX: 2 ,Port: COM3
 Connected Syncing Syncing 3, RX: 3 ,Port: COM3
 Connected Syncing Syncing 4, RX: 4 ,Port: COM3
  and
   CommandString TX    VER
 CommandString RX    1.51
  
  It is also noticed that each "Volatile' message is preceeded with messages like
  
   CommandString TX    V 1
 CommandString RX    91.2 0 0.000000 0.0 0 1 970 14999 -2 -100 7504 2526 1 0
 CommandString TX    HOME ?
 CommandString RX    0
 CommandString TX    PARK ?
 CommandString RX    0
  
  
• Daytime Testing
  Dome Opening / Closing and Rotational Slewing were then tested.
  
  Rotational Slewing seemed normal with no issues.
  
  Dome Opening/Closing however showed anomalies . Whilst physically the Shutter Opened/Closed normally, the ascom driver continued reporting that the Shutter was still opening or closing for a significant time after the dome has physically become open or closed,  as determined by visual/audio observation of the shutter operation and by independant zigbee open/closed sensors on the shutter.  For a 40-43s opening the dome was noted to remain in ShutterState.Opening for 50s or more than it should have (i e 90s+ in total))., with a similar figures during closing.
  
  It would seem that the frequency of communication between the shutter and dome units is much too slow.   This wasn't a problem with the previous firmware version (1.41).
  
  Pulsar Dome Control Unit was power-cycled (rebooted) just to ensure that this wasn't a transitional problem after installing new software.  The problem persisted.
   
• Detailed Testing
  More tests were undertaken during which Open/Closing Times, and DeviceHub Dome Activity and Pulsar ASCOM Log data were collected and then compared
  
  
• Case 1 at 13:06
  
  In this case the system is behaving correctly.
  The Observatory's Zigbee Sensors record that the dome closed in 43s
  (which is the typical closing time for the shutter and was the same as visual observation of the shutter)
  
  
  > Observatory Shutter    Info   Shutter is closing   (13:06:48)
> Observatory Shutter    Info   Shutter has closed   (13:07:31, closing time 43s)
  
  and DeviceHub recorded that ShutterStatus took 45s to go from Open to Closed (basically the same time as zigbee sensors)
  DeviceHub's activity log shows CloseShutter command being made at 13:06:47.7 (whereupon the ShutterStatus changes from 'Open' to  'Closing' and Slewing changes from False to True.) The ShutterStatus continues as 'Closing' until 45s later at 13:07:32.8 (whereupon ShutterStatus changes to 'Closed' and Slewing state changes  to False
  
  
  13:06:43.428: Dome - Statuses: Get ShutterStatus: shutterOpen
13:06:43.428: Dome - Statuses: Get Slewing: False
13:06:47.753: Dome - Commands: CloseShutter: (done)
13:06:47.753: Dome - Statuses: Get ShutterStatus: shutterClosing
13:06:47.753: Dome - Statuses: Get Slewing: True
13:06:47.753: Dome - Statuses: Get ShutterStatus: shutterClosing
13:06:47.754: Dome - Statuses: Get Slewing: True
13:06:47.754: Dome - Commands: Started fast polling every 1000 ms.
... Intermediate messages (all shutterClosing) ...
13:07:30.806: Dome - Statuses: Get ShutterStatus: shutterClosing
13:07:30.806: Dome - Statuses: Get Slewing: True
13:07:31.804: Dome - Statuses: Get ShutterStatus: shutterClosing
13:07:31.804: Dome - Statuses: Get Slewing: True
13:07:32.810: Dome - Statuses: Get ShutterStatus: shutterClosed
13:07:32.810: Dome - Statuses: Get Slewing: False
13:07:33.806: Dome - Statuses: Get ShutterStatus: shutterClosed
13:07:33.806: Dome - Statuses: Get Slewing: False
13:07:34.805: Dome - Statuses: Get ShutterStatus: shutterClosed
13:07:34.805: Dome - Statuses: Get Slewing: False
13:07:35.821: Dome - Commands: Returning to normal polling every 5000 ms.
   
  Case 2 at 12:49
  
  In this case the system is behaving anomously.
  
  The Observatory's Zigbee Sensors again recorded that the dome closed in 43s.
  
  
  > Observatory Shutter   Info     Shutter is closing (12:49:38)
> Observatory Shutter   Info     Shutter has closed (12:50:20, closing time 43s)
  
  However DeviceHub records that the Pulsar ShutterStatus took 92s to go from Open to Closed.  
  
  Activity log below shows CloseShutter command being made at 12:49:36.98 (whereupon the ShutterStatus changes from 'Open' to  'Closing' and Slewing changes from False to True.) The ShutterStatus continues as 'Closing' until 92s later at 12:51:09.0  (whereupon ShutterStatus changes to 'Closed' and Slewing state changes  to False.
  
  
  12:49:36.621: Dome - Statuses: Get ShutterStatus: shutterOpen
12:49:36.621: Dome - Statuses: Get Slewing: False
12:49:36.980: Dome - Commands: CloseShutter: (done)
12:49:36.980: Dome - Statuses: Get ShutterStatus: shutterClosing
12:49:36.980: Dome - Statuses: Get Slewing: True
12:49:36.980: Dome - Statuses: Get ShutterStatus: shutterClosing
12:49:36.981: Dome - Statuses: Get Slewing: True
12:49:36.981: Dome - Commands: Started fast polling every 1000 ms.
  Intermediate messages (all shutterClosing)
12:51:07.098: Dome - Statuses: Get ShutterStatus: shutterClosing
12:51:07.098: Dome - Statuses: Get Slewing: True
12:51:08.097: Dome - Statuses: Get ShutterStatus: shutterClosing
12:51:08.098: Dome - Statuses: Get Slewing: True
12:51:09.084: Dome - Statuses: Get ShutterStatus: shutterClosed
12:51:09.084: Dome - Statuses: Get Slewing: False
12:51:10.083: Dome - Statuses: Get ShutterStatus: shutterClosed
12:51:10.083: Dome - Statuses: Get Slewing: False
12:51:12.100: Dome - Commands: Returning to normal polling every 5000 ms.
   
  Just to check lets look at the Pulsar Log it shows CloseShutter Request at 12:49:36.98 (whereupon ShutterStatus changes to 3 (Closing) )
  The ShutterStatus continues as 3 (Closing) until  12:51:08.99. The confirms that the ShutterStatus remained to Closing state for 92s, which is 49s longer than the physical time to close the shutter.
  
  
  12:49:35.797 Volatile 100.0 0 0.000000 100.0 0 0 960 14959 -3 516 8251 2510 0 0       (0 = Open)
12:49:36.621 Slewing Get True    ( Actually this is a continuing logging bug  - Slewing is False)
12:49:36.621 ShutterStatus 0   (ie Open)
12:49:36.974 CommandString TX CLOSE
12:49:36.980 CommandString RX A
12:49:36.980 CloseShutter Request sent
12:49:36.980 ShutterStatus 3  (ie Closing)
12:49:36.980 Slewing Get True   (this seems to indeed mean Slewing is True)
12:49:37.764 Volatile 100.0 0 0.000000 100.0 0 3 960 14971 -2 516 8251 2510 0 0  
12:49:37.991 ShutterStatus 3  (ie Closing)
  Intermediate messages (all ShutterStatus 3  ie Closing)
12:51:07.098 ShutterStatus 3  (ie Closing)
12:51:08.020 CommandString RX 100.0 0 0.000000 100.0 0 3 880 14684 -350 516 9247 2491 0 0
12:51:08.052 Volatile 100.0 0 0.000000 100.0 0 3 880 14684 -350 516 9247 2491 0 0        (3 = Closing)
12:51:08.097 ShutterStatus 3  (ie Closing)
12:51:08.996 CommandString RX 100.0 0 0.000000 100.0 0 1 950 14936 -2 516 8500 2491 0 0  (1 = Closed)
12:51:09.028 Volatile 100.0 0 0.000000 100.0 0 1 950 14936 -2 516 8500 2491 0 0          (1= Closed)
12:51:09.084 ShutterStatus 1  (ie Closed)
   
  
• Case 3 (Open at 13:24, Close at 13:26)
  
  In this Case Dome Opening was normal but Dome Closing was anomalous
  
  ZigBee Sensors record that Shutter Opening took 40s with Shutter Closing took 43s  (both typical times)
  
  
  Open Dome                               2023-11-15 13:24  (Local, GMT)
> Observatory Shutter         Info      Shutter is opening(13:24:57
  Open Dome...                Ok        Dome is opening   (Clarity: 42.5, Stars: 0, Rain: -1.2, Wind: 3.2) > Observatory Shutter         Info      Shutter is open   (13:25:36, opening time 40s)   Open Dome...                Ok        Dome is open      (Opening time 43s)

Close Dome                              2023-11-15 13:26  (Local, GMT)
> Observatory Shutter         Info      Shutter is closing (13:26:04, open time 28s)   
  Close Dome...               Ok        Dome is closing    (Clarity: 42.9, Stars: 0, Rain: -1.2, Wind: 3.3) > Observatory Shutter         Info      Shutter has closed (13:26:47, closing time 43s)   Dome Safety                 Error     Dome closure hasn't finished after 90s   Check Shutter               Ok        Hub reports dome is Closing (3), PulsarLog reports Closing (3)
  
  The Pulsar Log for Closure shows CloseShutter Request at 13:26:03 (whereupon ShutterStatus changes from 0 (Open) to 3 (Closing), and then remaining on ShutterStatus 3 (Closing) until 13:27:54 when ShutterStatus changes to 1 (Closed).   This shows that the Pulsar ShutterStatus remained in the Closing state for 111s, which is 68s longer than the physical time to close the shutter.
  
  
  13:26:01.218 ShutterStatus 0   (Open)
13:26:02.832 Volatile 110.0 0 0.000000 0.0 0 0 870 14646 -4 1 8998 2441 0 0   (0= Opening)
13:26:03.186 CommandString TX CLOSE
13:26:03.279 CommandString RX A
13:26:03.279 CloseShutter Request sent
13:26:03.279 ShutterStatus 3   (Closing)
13:26:03.838 Volatile 110.0 0 0.000000 0.0 0 3 870 14903 -3 1 8749 2441 0 0   (3= Closing)
13:26:05.287 ShutterStatus 3   (Closing)
   Intermediate messages (all ShutterStatus 3  ie Closing)

13:27:54.102 CommandString RX 110.0 0 0.000000 0.0 0 1 940 14878 -2 1 8749 2422 0 0   (1 = Closed)
13:27:54.134 Volatile 110.0 0 0.000000 0.0 0 1 940 14878 -2 1 8749 2422 0 0                         (1 = Closed)
13:27:54.403 Connected Get True
13:27:54.403 Connected Get True
13:27:54.403 ShutterStatus 1
   
  
• Case 4 (Open at 16:30)
  
  Whilst the previous Open Dome at 13:24 was normal this later Open Dome case at  16:30 was anomalous
  
  
  Open Dome                               2023-11-15 16:30  (Local, GMT)
> Observatory Shutter         Info      Shutter is opening            (16:30:40, close time 3.1 hour)   Open Dome...                Ok        Dome is opening   (Clarity: 39.4, Stars: 0, Rain: -0.9, Wind: 2.0) > Observatory Shutter         Info      Shutter is open               (16:31:20, opening time 40s)   Open Dome                   Warning   Dome opening hasn't finished after 60s   Open Dome                   Fail      Dome opening hasn't finished after 90s
   
  The Pulsar Log for Dome Opening shows CloseShutter Request at 16:30:39 (whereupon ShutterStatus changes from 1 (Closing) to 2 (Opening), and then remaining on ShutterStatus 2 (Opening) until 16:32:24  when ShutterStatus changes to 0 (Open).   This shows that the Pulsar ShutterStatus remained in the Opening state for 105s, which is 65s longer than the physical time to close the shutter.
  
  
  16:30:36.551 ShutterStatus 1  (Closed)
16:30:39.221 Volatile 91.2 0 0.000000 91.2 0 1 950 14920 -2 -1315 3519 2404 0 0   (1= Closed)
16:30:39.335 CommandString TX OPEN
16:30:39.348 CommandString RX A
16:30:39.348 OpenShutter Request sent
16:30:39.348 ShutterStatus 2  (Opening)
16:30:39.350 ShutterStatus 2  (Opening)
16:30:40.228 Volatile 91.2 0 0.000000 91.2 0 2 950 14920 -2 -1315 3519 2404 0 0   (2= Opening)
16:30:40.349 ShutterStatus 2  (Opening)
   Intermediate messages (all ShutterStatus 2  ie Opening)
16:32:23.452 ShutterStatus 2  (Opening)
16:32:23.452 Volatile 91.2 0 0.000000 91.2 0 2 840 14582 -348 -1315 4266 2390 0 0     (2= Opening)
16:32:24.396 CommandString RX 91.2 0 0.000000 91.2 0 0 940 14873 -3 -1315 3768 2390 0 0  (0 =Open)
16:32:24.428 Volatile 91.2 0 0.000000 91.2 0 0 940 14873 -3 -1315 3768 2390 0 0     (0 =Open)
16:32:24.460 ShutterStatus 0  (Open)
16:32:25.388 Volatile 91.2 0 0.000000 91.2 0 0 940 14873 -3 -1315 3768 2390 0 0 0  (0 =Open)
16:32:25.468 ShutterStatus 0  (Open)

Update 2023-11-16

At the end of session S1167, the dome closing operation was also anomalous with the shutter taking 44s to physically close, but with ShutterStatus remaining in the 'Closing' state for 85s (ie for 41s after the shutter was actually closed).

A test was made the following morning (2023-11-16) in which the shutter was opened and closed   directly from the Pulsar Client Program (so no DeviceHub / ASCOM involvement). Results were similar for both opening and closing tests and the cases the previous day. The Shutter took 41s and 44s to physically open & close respectively, but the Pulsar Client showed the shutter state to be 'Shutter opening' and 'Shutter closing' for some 90-120s range.

This would seem to point to the problem being with the new 1.51 firmware, or a comms incompatibility between the new Dome firmware (1.51) and the Shutter firmware (1.25).

SlewToAzimuth 190 (Test at 13:31)
Logs from yesterday's Slewing Tests were examined today

Device Hub activity logs records SlewToAzimuth 190 request at 13:31:27. Because slewing doesn't immediately become true, and the property returns False  DeviceHub thinks the SlewToAzimuth has been achieved, and changes polling to standard rate. I pick this up as an anomalous slew and I can see parts of the ASCOM Dome Compliance run are not completed.    Only at 5s after the request does DeviceHub pick up that the Dome is slewing.  (Early time Az changes are lost to my client program, Az is seen to suddenly jump from Az 110 to Az 119.8). 

13:31:22.439: Dome - Statuses: Get Azimuth: 110   (Starting Az: 110)
13:31:22.439: Dome - Statuses: Get Slewing: False
13:31:27.047: Dome - Commands: SlewToAzimuth (190.00000°): (slew started)
13:31:27.049: Dome - Statuses: Get Slewing: False (this should immediately go to True but doesn't
13:31:27.049: Dome - Statuses: Get Azimuth: 110
13:31:27.049: Dome - Statuses: Get Slewing: False
13:31:27.049: Dome - Commands: Started fast polling every 1000 ms.
13:31:27.049: Dome - Statuses: Get Azimuth: 110
13:31:27.050: Dome - Statuses: Get Slewing: False (slewing still returning as False)
13:31:27.050: Dome - Commands: Returning to normal polling every 5000 ms.
13:31:32.064: Dome - Statuses: Get Azimuth: 119.8 
13:31:32.065: Dome - Statuses: Get Slewing: True  (Slewing only recognised as True, 5s after Slew request)
13:31:33.065: Dome - Statuses: Get Azimuth: 121.9 
13:31:33.065: Dome - Statuses: Get Slewing: True
13:31:34.060: Dome - Statuses: Get Azimuth: 124.3
13:31:34.060: Dome - Statuses: Get Slewing: True
 Immediate Messages  (Slewing = True, Azimuth gradually increasing)
13:32:04.090: Dome - Statuses: Get Azimuth: 188.9
13:32:04.090: Dome - Statuses: Get Slewing: True
13:32:05.090: Dome - Statuses: Get Azimuth: 189.8
13:32:05.090: Dome - Statuses: Get Slewing: True
13:32:06.090: Dome - Statuses: Get Azimuth: 190    (Destination Az: 190 )
13:32:06.091: Dome - Statuses: Get Slewing: False  (Slewing Stopped)
13:32:07.104: Dome - Statuses: Get Azimuth: 190
13:32:07.105: Dome - Statuses: Get Slewing: False

Pulsar Log records SlewToAzimuth request at 13:31:27

13:31:21.643 Volatile 110.0 0 0.000000 0.0 0 1 940 14907 -2 1 8500 2422 0 0
13:31:22.439 Azimuth Get Azimuth = 110
13:31:22.439 Slewing Get True      (Slewing state in log is completely reliable as it is always reported as True here though Dome is not slewing)
13:31:22.666 Volatile 110.0 0 0.000000 0.0 0 1 940 14907 -2 1 8500 2422 0 0
13:31:23.674 Volatile 110.0 0 0.000000 0.0 0 1 940 14907 -2 1 8500 2422 0 0
13:31:24.697 Volatile 110.0 0 0.000000 0.0 0 1 940 14907 -2 1 8500 2422 0 0
13:31:25.705 Volatile 110.0 0 0.000000 0.0 0 1 940 14907 -2 1 8500 2422 0 0
13:31:26.729 Volatile 110.0 0 0.000000 0.0 0 1 940 14907 -2 1 8500 2422 0 0
13:31:27.030 SlewToAzimuth Start 190   (SlewToAzimuth request received)
13:31:27.030 CommandString TX GO 190
13:31:27.047 CommandString RX A
13:31:27.047 SlewToAzimuth Request sent
13:31:27.049 Azimuth Get Azimuth = 110 (Dome hasn't physically / measurable started to move but Client expects to see Slewing=True at this point)
13:31:27.049 Slewing Get True          (Client is sent False at this point though reported as True in this Pulsar Log)
13:31:27.049 Azimuth Get Azimuth = 110
13:31:27.049 Slewing Get True          (Client is sent False at this point though reported as True in this Pulsar Log)
13:31:27.049 Azimuth Get Azimuth = 110
13:31:27.050 Slewing Get True          (Client is sent False at this point though reported as True in this Pulsar Log)
13:31:27.049 Azimuth Get Azimuth = 110
13:31:27.049 Slewing Get True          (Client is sent False at this point though reported as True in this Pulsar Log)
13:31:27.050 Slewing Get True          (Slewing state in log is unreliable as it is always reported as True even when Dome is definately not slewing)
13:31:27.704 CommandString RX 110.9 1 0.000000 190.0 1 1 940 14907 -2 60 8500 2422 0 0    (Dome is moving at this point)
13:31:27.927 Volatile 110.9 1 0.000000 190.0 1 1 940 14907 -2 60 8500 2422 0 0
13:31:28.936 Volatile 113.3 1 0.000000 190.0 1 1 940 14907 -2 227 8500 2422 0 0
13:31:29.911 Volatile 115.6 1 0.000000 190.0 1 1 940 14907 -2 390 8500 2422 0 0    (Early Time Az changes not available to end Client)
13:31:30.871 Volatile 117.6 1 0.000000 190.0 1 1 940 14907 -2 531 8500 2422 0 0
13:31:31.846 Volatile 119.8 1 0.000000 190.0 1 1 940 14907 -2 687 8500 2422 0 0
13:31:32.064 Azimuth Get Azimuth = 119.8
13:31:32.065 Slewing Get False    (Log reports Slewing False even though Dome is Slewing and the Client is sent Slewing=True)
13:31:32.838 Volatile 121.9 1 0.000000 190.0 1 1 940 14907 -2 830 8500 2422 0 0
13:31:33.065 Azimuth Get Azimuth = 121.9
13:31:33.065 Slewing Get False    (Log reports Slewing False even though Dome is Slewing and the Client is sent Slewing=True)
13:31:33.814 CommandString RX 124.3 1 0.000000 190.0 1 1 940 14907 -2 999 8500 2422 0 0

ASCOM Driver 6.3.10

A comparison between new ASCOM Driver 6.3.10 and previous 6.3.x version.

	Required ASCOM Behaviour	Previous Version (6.3.x), 2021		Version 6.3.10, 2023	Notes
1)	Dome.Slewing property should be True if any part of the dome is currently moving or False if no part is currently moving	Slewing stayed False when Shutter was Opening or Closing		Slewing now correctly becomes True when the Shutter is Opening or Closing	Confirmed fixed.
2)	Dome.Slewing property should become True immediately upon receiving SlewToAzimuth, OpenShutter or CloseShutter
	Things associated with the Pulsar ASCOM log
3)	Logfile should report the full version details	Log reports : DriverInfo Get      Pulsar Observatories Dome Drive Version: 6.3 (spelling: Drive should be Driver)		Log reports : DriverInfo Get      Pulsar Observatories Dome Drive Version: 6.3 (spelling: Drive should be Driver)	Still an issue. I'd expect to see Version 6.3.10 for the current driver  (this may be an ASCOM limitation ?)
4)	Logfile should report the same Slewing state that it is sending to the Client	Log reports Slewing False when Dome is Slewing and reports Slewing True when the Dome is not slewing (even though correct values are sent to client)		Log reports Slewing True when Dome is Slewing and reports Slewing True when the Dome is not slewing (even though correct values are sent to client at all times)	Issue partly fixed but still a half-defect

Update 2024-01-05
A new version of Pulsar Software and new version of ASCOM driver were supplied by Pulsar Observatories and installed onto the Observatory Computer today (2024-01-05).  (See Pulsar Dome - Software Update (Firmware 1.52 & ASCOM Driver 6.4), 2024-01-05 )

Condensation & dew inside the Observatory's AllSky Camera's Hemisphere has been an outgoing issue in past 2-3 years and a source of much frustration, sometimes degrading the quality of Aurora Imaging/Monitoring and/or leading to the unreliablity in the AllSky Star Count provided to the Observatory Control Program undertaking automated observing/imaging.

After re-reading a 2019 conversation about "Oculus All Sky Camera and Dome - Condensation Problem" on the Stargazers Lounge forum (https://stargazerslounge.com/topic/325447-oculus-all-sky-camera-and-dome-condensation-problem/) it was noticed that a follow-up post from PhotoGav covered a 'solution' that had been supplied to him by Terry (Platt) of Starlight Xpress.  

Original post from PhotoGav,  2018-11-11

"As you can clearly see from this image, I have a condensation problem inside the dome of my Oculus All Sky Camera. After a particularly rainy period it invariably has condensation inside the acrylic dome. I cleaned the inside of the dome only two days ago, it poured yesterday and overnight and now I have condensation. I have the internal dew heater on a timer to come on at nighttime only every night. The camera lens is fine. The dome is not fine! It does evaporate eventually, but takes quite a while and obscures a clear view for the start of a night and beyond."

Later post/reply from PhotoGav, 2019-02-08

"I thought I would update this thread as I am delighted to report a successful solution has been supplied by Starlight Xpress. Terry at SX was very helpful and after discussion and various failed experiments he sent me a new base plate that has two 1 cm holes drilled in it. I swapped out the base plate and for once I was happy that it rained. The good news is that the dome no longer mists up inside. I’ve run it for the last few nights and it continues to work perfectly. So, ventilation was indeed the issue. .." .   

PhotoGav's issue sounds very similar to the issue I experience with my own Oculus AllSky Camera and the mention of a solution provided by Starlight Xpress (the makers of the Oculus AllSky Camera) suggests this is something I should probably consider myself.

So today (2023-11-15) I decided to bit the bullet and have a go at implementing the same fix to my Observatory's Oculus Camera, and drilled two 1cm diameter holes in the base plate of the camera to increase ventilation in the manner described by PhotoGav's posting.

Secondary aims for bringing the camera down from its mounting was to see if there was an way of retrofitting a small computer fan inside the casing to further increase ventilation and to also check the camera's dew heating system. As it turned out things didn't go completely to plan, but the two 1 cm diameter did get drilled and the camera has been returned to its mounting again.

AllSky Camera with internal dew - Side View Camera lens is clear of condensation, problem is the camera's dome/hemisphere		AllSky Camera with internal dew - Top View Adjacent to AllSky Camera is the Observatory's CloudSensor
Hemisphere/Dome after wiping dry  but before screwing back its retainer Vent holes inside dome around fish-eye lens, small drain holes outside of dome, white powder inside dome is to kill earwigs which somehow find their way into the camera		Existing Base Plate of Camera View from below
Existing Base Plate of Camera  (camera removed from its mounting)		Failed attempt to unscrew the two retaining bolts Both bolts were completely stuck and both snapped off when applying force making the base plate unremovable
Bottom Plate after drilling two 1cm diameter holes Being unable to remove the base plate, two pilot holes were drilled first to check there wasn't anything important behind the plater		AllSky Camera re-attached to its mount View from below showing the two new ventilation holes

An update will be added later to with information about whether these ventilation holes improve the condensation/dew issue or not.

There is a slight concern that the two new holes provide an easy route for more critters to enter the camera/dome. On the other hand it might allow adult earwigs (which originally entered the camera as small young earwigs) a way of getting out instead of clambering all over the fish eye lens as they sometimes have.  

The sheared bolts unfortunately mean there is no way to get into the camera body (unless the broken bolt ends are drilled out). This prevented an examination as to whether the addition of a computer fan in future was a feasible retrofit.

There is one school of thought that says there should be a gap around the bottom edges of the hemisphere/dome to allow ventilation but in my case I suspect that original small patches of velcro to allow this have worn away or lost over the years (only one partial section remains). This might explain why the condensation/dewing seems to have been worse in the last 2-3 years than during the first few years of using the camera.

Supply of 12v power to the AllSky Camera's dew heater was checked at the socket end using a desk-lamp temporarily plugged into the Zigbee Smart Plug that is used for controlling the dew heater and turned on/off using Zigbee, and at the plug end using a voltmeter which indicated 12-13v.  Of concern is that during visits to the Camera to wipe hemisphere dry, I have being having any sensation of warmth around the top of the camera. Last time I remember feeling it warm was back in the spring. Have the dew heaters failed ?

Issue:  Target Circle for BL Lac is mis-positioned on JPG Pictures (S1167, 01:19)

Description
Target Circle for BL Lac is mispositioned on  Main Frame JPG pictures (but correct on Locate and Focus Pictures).  The circle is mispositioned by around 35".  In other sessions BL Lac target circle has been correctly drawn.  Replaying the target in AstroMain On-the-Fly Observing at a later time (2023-11-17) showed that the issue was repeatable.

Images below shows Realtime JPG pictures for the Locate 3 image (left) and for 1st Main Image (right), with BL Lac Target Circles (in blue)
The blue circle in the lefthand picture shows the position of BL Lac object. The blue circle is right-hand image is clearly mispositioned.

 

The Target Circle & Host Ellipse for AT 2023uhx/ NGC 3893 were also mispositioned in JPG pictures and is probably a further example of the same issue (S1167, 00:59).

Analysis
Replaying the BL Lac target in AstroMain OnTheFly Observing (using Target ID 17 & Images 1167249-54) showed that the bug was repeatable (a pleasant surprise as , replays typically fail to replicate ConvertFitsToJpg() bugs).  
 
The replay produced the following error for each main frames (the error wasn't reported during live session- is the error a sideeffect of image substitution used for the replay or is the report of this error one that is specifically withheld during live sessions ?

   ImageShift : Fail     Not enough stars (nStars 8, n 0)  

Examining log files showed that both test session and the live session contain messages like

   23:18:15.82 | GCVS BL Lac    Calc ImageShift(WrtLoc)   Fail | Not enough stars (nStars 8, n 0)

indicating that the report message is intentionally withheld during the live session. 

Comparing the Locate 3 Picture with the Picture from the first Main Frame shows that the BL Lac Target Circle is positioned in exactly the same XY location.   In the Locate 3 Picture the Circle honors the position of the BL Lac object,  but it doesn't in the Main Frame picture.  Stars shift noticeably between the two pictures and with the Calc ImageShift failing it explains why, without an Image Shift correction,  the Target Circle is mis-positioned in the  Main Frame pictures.   The Locate Frame and Main Frame pictures have plenty of stars and the method of finding stars and calculating ImageShift should have been successful. Examing raw FITS images the BL Lac object shifts 25.7 px (36.0") between Locate 3 and Focus Frame,  or 25.4 px (35.6" ) between Locate 3 and 1st Main Frame. Even though the physical shift is similar in both cases the shift calculation is successfully performed for the Focus Frame Image but fails for the Main Frame Image.  One hypothesis might be that the brightest stars in Main Frame picture are different because it is taken with R filter, instead of the C filter using by Locate 3 and Focus Frame Images. Another hypothesis is that due to the relatively large image shift (35-36"), there is greater risk of a dimmer star interferring with star offset determinations in the longer 60s exposures used by Main Frames.

Examining MatchBrightestStar results for 1st Main Frame in AstroMain 3.64.8 (which fixes 'duplicated Star 1 and Star 2' bug) we see the following :

  1 , X: 102.5, Y:  92.7, ClosestOffset: 25.6, OffsetX:  25.6, OffsetY:   0.7
  2 , X: 165.0, Y: 128.4, ClosestOffset: 25.6, OffsetX:  25.6, OffsetY:   0.6
  3 , X: 357.2, Y: 279.8, ClosestOffset: 24.5, OffsetX: -16.9, OffsetY:  17.8
  4 , X: 590.8, Y: 465.2, ClosestOffset: 10.5, OffsetX:  -8.0, OffsetY:  -6.8
  5 , X:  37.0, Y: 293.3, ClosestOffset: 24.3, OffsetX:   3.3, OffsetY: -24.1
  6 , X: 446.7, Y:  91.9, ClosestOffset: 19.0, OffsetX:  -8.6, OffsetY: -17.0
  7 , X: 658.8, Y: 213.7, ClosestOffset: 25.4, OffsetX:  25.4, OffsetY:   0.7
  8 , X: 362.9, Y: 303.5, ClosestOffset: 23.0, OffsetX:   6.9, OffsetY:  22.0

Of these matches only 3 matches (stars 1,2, 7) with Offsets of 25.4-25.6 pixels reflect 'correctly matched' stars. The other 5 rows are mismatches.

The Median offset is calculated to be 5.2 (X: 5.1, Y: 0.6) and none of the stars have an offset anywhere close to 5.2 and hence the routine's judges that there are not enough stars to determine a shift. 

Code was modified to show which particular Star in the new image was being matching and where it ranked in term of brightest to dimmest star in the image, and the target replayed with the following results for Main Image Frame 1

  1 , X: 102.5, Y:  92.7, ClosestOffset: 25.6, OffsetX:  25.6, OffsetY:   0.7, MatchedStar: 0/95
  2 , X: 165.0, Y: 128.4, ClosestOffset: 25.6, OffsetX:  25.6, OffsetY:   0.6, MatchedStar: 1/95
  3 , X: 357.2, Y: 279.8, ClosestOffset: 24.5, OffsetX: -16.9, OffsetY:  17.8, MatchedStar: 29/95
  4 , X: 590.8, Y: 465.2, ClosestOffset: 10.5, OffsetX:  -8.0, OffsetY:  -6.8, MatchedStar: 93/95
  5 , X:  37.0, Y: 293.3, ClosestOffset: 24.3, OffsetX:   3.3, OffsetY: -24.1, MatchedStar: 35/95
  6 , X: 446.7, Y:  91.9, ClosestOffset: 19.0, OffsetX:  -8.6, OffsetY: -17.0, MatchedStar: 79/95
  7 , X: 658.8, Y: 213.7, ClosestOffset: 25.4, OffsetX:  25.4, OffsetY:   0.7, MatchedStar: 7/95
  8 , X: 362.9, Y: 303.5, ClosestOffset: 23.0, OffsetX:   6.9, OffsetY:  22.0, MatchedStar: 32/95

Looking at the new revised table listing that shows the relative brightness of the matched star (based on its position within the inventory list) we can see for example that the 3rd brightest star in reference image was matched to the 29th brightest star in the new image, the 4th brightest star if matched with the 93rd brightest star etc.

The findings confirm that what the source of the problem is.

Conclusion

• Where the image shift between the reference image and new images is fairly large, the section of the existing CalcImageShift() routine that is meant to associate each of the 8 or so brightest stars in Reference Image with the corresponding star in the new images (thereby lead to an Averaged Shift) will frequently fail to ind the correct corresponding star.  This happens because with the routine simply looks for star in the new image that is closest to a bright star in the reference image, and with a relatively dense starfield the star in the new field that is closest to a reference star position will frequently be dim star, rather than a brighter star that we are really looking for.
• Tthe code that finds the position of star that corresponds with each of the brightest reference image stars needs to be updated.

Fix 

Issue is fixed in AstroMain 3.64.8 on 2023-11-18 by modifying the CalcImageShift() routine to preferentially look for the closest star to each reference star position that is one of the top 12 brightest stars in the new image.  

Running the new AstroMain version and again replying the BL Lac target from the S1167 session produces JPG Pictures for the Main Image Frames that are correct:

The blue target circle in right hand picture showing the 1st Main Image frame is now correctly positioned.

 

The table of matched stars for the 1st Main Image frame shows that stars have been correctly match and show consistent shifts in the narrrow range 25.4 to 25.6 pixels.

1 , X: 102.5, Y:  92.7, ClosestOffset: 25.6, OffsetX: 25.6, OffsetY: 0.7, MatchedStar: 0/95
2 , X: 165.0, Y: 128.4, ClosestOffset: 25.6, OffsetX: 25.6, OffsetY: 0.6, MatchedStar: 1/95
3 , X: 357.2, Y: 279.8, ClosestOffset: 25.6, OffsetX: 25.6, OffsetY: 0.8, MatchedStar: 2/95
4 , X: 590.8, Y: 465.2, ClosestOffset: 25.5, OffsetX: 25.5, OffsetY: 0.9, MatchedStar: 3/95
5 , X:  37.0, Y: 293.3, ClosestOffset: 25.5, OffsetX: 25.5, OffsetY: 0.8, MatchedStar: 5/95
6 , X: 446.7, Y:  91.9, ClosestOffset: 25.5, OffsetX: 25.5, OffsetY: 0.6, MatchedStar: 6/95
7 , X: 658.8, Y: 213.7, ClosestOffset: 25.4, OffsetX: 25.4, OffsetY: 0.7, MatchedStar: 7/95
8 , X: 362.9, Y: 303.5, ClosestOffset: 25.6, OffsetX: 25.6, OffsetY: 0.9, MatchedStar: 8/95

A replay of NGC 3893 w/AT 2023uhx  confirms that the fix has also worked with this target set.