David's Astronomy Pages
Notes - Session 1261 Attempt (2024-10-28)

 
Bullet Session Aims & Highlights
 - Observing Result
 - Night Summary Plot
 - Session Event Log
Bullet Operational Issues
  - Critical Issues (0),  Major Issues (3),  Minor Issues (6),  Small Defects (7),  Continuous Improvement (15)
Bullet Images from 2024-10-28 >>         
2024-10-31
Bullet Notes: Experience, Issues and Adjustments to using DeviceHub 7.0
   
   

Session Aims & Highlights (2024-10-28)

Main aims

  1. Targets.  Acquire images of a selection of variable stars, nearby stars, comets & deep sky targets as allowed by sky conditions.
  2. AstroMain.  Check new 3.71.11 version of AstroMain
  3. C/2023 A3 (Tsuchinshan-ATLAS). Acquire images of comet C/2023 A3 (Tsuchinshan-ATLAS)

 Equipment & Software

Highlights

Notes

Summary Plots & Logs

Observing Plan
Image
  
Observing Result
Image
   
  
Night Sky Summary Plot
Top axis: Sky Brightness at Zenith (in ADU/s)
Lefthand axis: Local Time (hh LT). Righthand axis: Sun Altitude (degs)
The black 'spots on the keogram image are created by baby spiders which hatched earlier in the day (see Fig 2 & Fig 3)
Image   
  
  
Session Event Log
Time     Event Detail
00:09:55 Session Monitoring AutoStart monitoring for Live Session opportunity between 00:09 & 05:07
00:09:57   AutoStart Delayed Session delayed due to cloud
00:23:53 Session AutoStarting Session autostarting (00:23)
00:24:06   CCDSoft Restarting CCDSoft being restarted (to set AutoSave No.)
00:24:33   Camera1 Connected SBIG Camera connected (Set point -10°C)
00:24:35 Session Created Session Created (Live, 2024-10-28 S01261, ImageSaveNum: 1261001)
00:24:40   Scope Switched On Telescope Power has been switched on via UPB Powerbox.
00:26:38   Services Started Observatory Services started
00:26:46 Observatory (Auto) Observatory placed in Fully-Automated Mode
00:26:48   AutoStart Delayed Session delayed due to cloud
00:26:51 Session Pending Session pending (2024-10-28)
00:26:53 Session Initiating Session initiating (2024-10-28)
00:27:00   Camera1 Connected SBIG Camera connected (Set point -10°C)
00:27:07   Plan Requested Observing Plan requested from AstroPlan (1.42.4)
00:27:31   Plan Loaded Observing Plan loaded to queue (Plan ID: 1040)
00:28:14   Telescope Connected Telescope connected (TheSky6)
00:28:38 Session Equilibration Session ready to Open Dome
00:29:23   Dome Opened Dome opened (Opening time 45s, Zigbee 40s)
00:30:08 Session Running Session running
00:30:11   Queue Started Observing Queue started (18 targets selected)
00:30:14     Target Started (NrZen) Target started (Focus Field 3, HIP 14181)
00:30:30       Dome Unparked Dome unparked
00:34:12       Focusing Skipped Foc1 focusing skipped - unable to find a star (TCF-S)
00:34:38       Focusing Started-Foc2 Foc2 Focusing Started (Secondary Scope, using ShCap)
00:34:54     Target Completed (NrZen) Target completed (Focus Field 3, HIP 14181)
00:43:35     Target Started (1/18) Target started (1/18, GCVS UV Cet)
00:43:39     Target Failed (1/18) Target failed due to airmass limit (1/18, GCVS UV Cet)
00:54:47     Target Started (2/18) Target started (2/18, LEDA 2078778 w/SN2024xqe)
00:55:17     Target Failed (2/18) Target failed due to slew error (2/18, LEDA 2078778 w/SN2024xqe)
01:13:11 User Intervention User Intervention to abort job queue & switch back to Manual Mode
01:13:14   Queue Aborted Job Queue aborted
01:13:33   Services Stopped Observatory Services stopped
01:13:36 Session Closed Session closed by User
01:13:40 Program Closed Program closed by User
01:14:45 Program Opened Program Opened (AstroMain 3.71.11)
01:14:47 Session Resumed Session Resumed (Live, 2024-10-28 S01261, ImageSaveNum: 1261005)
01:14:52   Obs.Overseer Started Obs.Overseer started
01:15:01   Obs.Manager Started Obs.Manager started
01:15:10   Services Started Observatory Services started
01:15:32 Session Monitoring AutoStart monitoring for Live Session opportunity between 01:15 & 05:07
01:15:34 Observatory (AutoStart) Observatory placed in Auto-Start Mode
01:15:36   AutoStart Delayed Session delayed due to cloud
01:17:16   Dome Closed Dome closed (Closing time 47s, Zigbee 43s)
01:18:02   Services Started Observatory Services started
01:18:23 Observatory (Manual) Observatory placed in Manual Mode
01:20:38   Telescope Connected Telescope connected (TheSky6)
01:23:50   SBIG Camera Take Image failed (Command timed-out)
01:25:42   SBIG Camera Take Image command accepted (bSbigDriverException flag is reset)
01:26:13   SBIG Camera Take Image failed (Command timed-out)
01:28:12   SBIG Camera Take Image command accepted (bSbigDriverException flag is reset)
01:28:42   SBIG Camera Take Image failed (Command timed-out)
01:29:00 Session Monitoring AutoStart monitoring for Live Session opportunity between 01:28 & 05:07
01:29:02 Observatory (AutoStart) Observatory placed in Auto-Start Mode
01:29:05 Session AutoStarting Session autostarting (01:29)
01:29:14   Services Started Observatory Services started
01:29:20 Observatory (Auto) Observatory placed in Fully-Automated Mode
01:29:22 Session Pending Session pending (2024-10-28)
01:29:25 Session Initiating Session initiating (2024-10-28)
01:29:34   Camera1 Connected SBIG Camera connected (Set point -15°C)
01:29:37   Plan Loaded Observing Plan loaded to queue (Plan ID: 1040)
01:30:17   Telescope Connected Telescope connected (TheSky6)
01:30:42 Session Equilibration Session ready to Open Dome
01:31:27   Dome Opened Dome opened (Opening time 46s, Zigbee 40s)
01:31:30 Session Running Session running
01:31:33   Queue Started Observing Queue started (16 targets selected)
01:31:36     Target Started (NrZen) Target started (Focus Field 4, HIP 18637)
01:32:32   SBIG Camera Take Image command accepted (bSbigDriverException flag is reset)
01:34:53       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S)
01:35:04   CcdCamera Frozen CcdCamera appears to be frozen at around 01:35 in section 'GetCameraProperties / FilterIndexZeroBased'
01:35:36   CCDSoft Restarting CCDSoft being restarted (attempt to fix frozen CcdCamera)
01:35:43   SBIG Camera Reset SBIG Camera being power-cycled
01:36:37   Camera1 Connected SBIG Camera connected (Set point -15°C)
01:37:11   SBIG Camera Take Image failed (Command timed-out)
01:38:02   SBIG Camera Take Image command accepted (bSbigDriverException flag is reset)
01:38:32   SBIG Camera Take Image failed (Command timed-out)
01:38:49   CCDSoft Restarting CCDSoft being restarted (user action)
01:38:56   SBIG Camera Reset SBIG Camera being power-cycled
01:39:49   Camera1 Connected SBIG Camera connected (Set point -15°C)
01:39:52   SBIG Camera Take Image command accepted (bSbigDriverException flag is reset)
01:40:24   SBIG Camera Take Image failed (Command timed-out)
01:40:43 User Intervention User Intervention to abort job queue & switch back to Manual Mode
01:41:17   SBIG Camera Take Image command accepted (bSbigDriverException flag is reset)
01:41:23   CcdCamera Frozen CcdCamera appears to be frozen at around 01:41 in section 'GetCameraProperties / Disconnect/Direct'
01:41:30       Focusing Aborted Foc1 Focusing Aborted
01:41:32     Target Aborted (NrZen) Target aborted (Focus Field 4, HIP 18637) due to User Intervention
01:41:34   Queue Aborted Job Queue aborted
01:41:57   CCDSoft Restarting CCDSoft being restarted (attempt to fix frozen CcdCamera)
01:42:04   SBIG Camera Reset SBIG Camera being power-cycled
01:42:17   Services Stopped Observatory Services stopped
01:42:20 Session Closed Session closed by User
01:42:23 Program Closed Program closed by User
01:44:48 Program Opened Program Opened (AstroMain 3.71.11)
01:44:50   CCDSoft Restarting CCDSoft being restarted (to set AutoSave No.)
01:45:03 Session Resumed Session Resumed (Live, 2024-10-28 S01261, ImageSaveNum: 1261009)
01:45:09   Obs.Overseer Started Obs.Overseer started
01:45:19   Obs.Manager Started Obs.Manager started
01:45:27   Services Started Observatory Services started
01:45:48 Session Monitoring AutoStart monitoring for Live Session opportunity between 01:45 & 05:07
01:45:50 Observatory (AutoStart) Observatory placed in Auto-Start Mode
01:45:59 Session AutoStarting Session autostarting (01:45)
01:46:56   Services Started Observatory Services started
01:47:06 Observatory (Auto) Observatory placed in Fully-Automated Mode
01:47:09 Session Pending Session pending (2024-10-28)
01:47:11 Session Initiating Session initiating (2024-10-28)
01:47:21   Camera1 Connected SBIG Camera connected (Set point -15°C)
01:47:28   Plan Loaded Observing Plan loaded to queue (Plan ID: 1040)
01:47:39   Telescope Connected Telescope connected (TheSky6)
01:48:01 Session Running Session running
01:48:04   Queue Started Observing Queue started (14 targets selected)
01:48:07     Target Started (NrZen) Target started (Focus Field 4, HIP 18637)
01:54:58       Focusing Started-Foc1 Foc1 Focusing Started (TCF-S)
01:55:10   CcdCamera Frozen CcdCamera appears to be frozen at around 01:55 in section 'GetCameraProperties / Temperature'
01:55:43   CCDSoft Restarting CCDSoft being restarted (attempt to fix frozen CcdCamera)
01:55:50   SBIG Camera Reset SBIG Camera being power-cycled
01:56:43   Camera1 Connected SBIG Camera connected (Set point -15°C)
01:57:45   CcdCamera Frozen CcdCamera appears to be frozen at around 01:57 in section 'GetCameraProperties / FilterIndexZeroBased'
01:58:18   CCDSoft Restarting CCDSoft being restarted (attempt to fix frozen CcdCamera)
01:58:25   SBIG Camera Reset SBIG Camera being power-cycled
01:59:22   CCDSoft Restarting CCDSoft being restarted (user action)
01:59:29   SBIG Camera Reset SBIG Camera being power-cycled
02:02:16 User Intervention User Intervention to abort job queue & switch back to Manual Mode
02:02:35       Focusing Completed Foc1 AutoFocus Completed (Profile No 2, wide)
02:02:43       Focusing Aborted Foc1 Focusing Aborted
02:02:45     Target Aborted (NrZen) Target aborted (Focus Field 4, HIP 18637) due to User Intervention
02:02:47   Queue Aborted Job Queue aborted
02:03:23   CCDSoft Restarting CCDSoft being restarted (user action)
02:03:27   SBIG Camera Reset SBIG Camera being power-cycled
02:06:28   Critical Cloud Alert Critical Cloud Alert (Obs.Manager will close the Dome)
02:07:18   Dome Closed Dome closed (Closing time 50s, Zigbee 43s)
02:15:08 Program Opened Program Opened (AstroMain 3.71.11)
02:15:10 Session Resumed Session Resumed (Live, 2024-10-28 S01261, ImageSaveNum: 1261013)
02:15:14   Obs.Overseer Started Obs.Overseer started
02:15:32   Obs.Manager Started Obs.Manager started
02:15:40   Services Started Observatory Services started
02:16:22 Obs.Monitor Frozen Obs.Monitor appears to be frozen at around 02:16 in section 'Refresh Dome Picture/Refresh panelDome'
02:18:35   CCDSoft Restarting CCDSoft being restarted (user action)
02:18:39   SBIG Camera Reset SBIG Camera being power-cycled
02:19:45   CCDSoft Restarting CCDSoft being restarted (user action)
02:19:52   SBIG Camera Reset SBIG Camera being power-cycled
02:20:46   Camera1 Connected SBIG Camera connected (Set point -15°C)
02:22:07   Services Started Observatory Services started
02:25:38   CcdCamera Frozen CcdCamera appears to be frozen at around 02:25 in section 'GetCameraProperties / Status'
02:26:09   SBIG Camera Take Image failed (Command timed-out)
02:26:12   CCDSoft Restarting CCDSoft being restarted (attempt to fix frozen CcdCamera)
02:26:19   SBIG Camera Reset SBIG Camera being power-cycled
02:28:10   CCDSoft Restarting CCDSoft being restarted (user action)
02:28:14   SBIG Camera Reset SBIG Camera being power-cycled
02:29:20   Camera1 Connected SBIG Camera connected (Set point -15°C)
02:34:32 Program Opened Program Opened (AstroMain 3.71.11)
02:34:34 Session Resumed Session Resumed (Live, 2024-10-28 S01261, ImageSaveNum: 1261013)
02:34:39   Obs.Overseer Started Obs.Overseer started
02:35:02   Obs.Manager Started Obs.Manager started
02:35:10   Services Started Observatory Services started
02:36:24   Camera1 Connected SBIG Camera connected (Set point -15°C)
02:36:36 Obs.Monitor Frozen Obs.Monitor appears to be frozen at around 02:36 in section 'Refresh Dome Picture/Refresh panelDome'
02:36:37   CcdCamera Frozen CcdCamera appears to be frozen at around 02:36 in section 'GetCameraProperties / Disconnect/Direct'
02:37:11   CCDSoft Restarting CCDSoft being restarted (attempt to fix frozen CcdCamera)
02:37:18   SBIG Camera Reset SBIG Camera being power-cycled
02:39:02   Services Stopped Observatory Services stopped
02:39:08 Session Closed Session closed by User
02:39:11 Program Closed Program closed by User
02:41:36 Program Opened Program Opened (AstroMain 3.71.11)
02:41:38 Session Resumed Session Resumed (Live, 2024-10-28 S01261, ImageSaveNum: 1261013)
02:41:42   Obs.Overseer Started Obs.Overseer started
02:42:06   Obs.Manager Started Obs.Manager started
02:42:15   Services Started Observatory Services started
02:43:05   Services Started Observatory Services started
02:43:21   Telescope Connected Telescope connected (TheSky6)
02:43:52 User Intervention User request to close and finish session
02:43:54 Session Closing Session closing
02:43:56   Dome Closed Dome already closed (closed at 02:07, closing time 50s, zigbee 0s)
02:44:56   Dome Parked Dome parked (parking time 54s), Az: 90.0 deg
02:45:40   Telescope Parked Telescope parked (parking time 42s total)
02:45:55 Obs.Monitor Frozen Obs.Monitor appears to be frozen at around 02:45 in section 'Monitor ASCOM Scope'
02:46:15   Telescope State Handbox reads 'Scope parked Turn scope off.'
02:47:11   Telescope Switched Off Telescope Power has been switched off via UPB Switch.
02:49:36   Services Stopped Night Services stopped
02:49:41 Session Finishing Session Finishing started (Create Fits Summary, Transfer Files)
02:49:48     Dome (Find Park) Find Park started (Search Az 88.0 to 92.0°, Step 0.2°, Narrow)
02:50:32     Dome Find Park found (Best Park Az 90.0°)
02:52:21   Dome Charging Dome is parked and re-charging Ok (30mA)
02:52:23 Session Finished Session Finished

 
 
Session Alerts & Alarms
Time     Type       Name Detail
01:18:32 Red Alert Program Hung AstroMain UI appears to have stopped responding at 01:18
01:18:37 Green Clear Program Resumed AstroMain UI has resumed again after 15s
01:22:04 Yellow Alert Anomalous Dome Slew Dome slew resumed at Az 133.3° (T+12.4s)
01:23:50 Red Alert SBIG Camera Alert Take Image failed (Command timed-out)
01:25:42 Green Clear SBIG Camera Take Image command accepted (bSbigDriverException flag is reset)
01:26:13 Red Alert SBIG Camera Alert Take Image failed (Command timed-out)
01:28:12 Green Clear SBIG Camera Take Image command accepted (bSbigDriverException flag is reset)
01:28:42 Red Alert SBIG Camera Alert Take Image failed (Command timed-out)
01:32:10 Yellow Alert Anomalous Dome Slew Dome slew resumed at Az 152.0° (T+28.8s)
01:32:32 Green Clear SBIG Camera Take Image command accepted (bSbigDriverException flag is reset)
01:35:34 Red Alert CcdCamera CcdCamera appears to be frozen (last cycle at 01:35:04) in section 'GetCameraProperties / FilterIndexZeroBased'
01:35:39 Green Clear CcdCamera CcdCamera has resumed again (01:35) after 35s
01:37:11 Red Alert SBIG Camera Alert Take Image failed (Command timed-out)
01:38:02 Green Clear SBIG Camera Take Image command accepted (bSbigDriverException flag is reset)
01:38:32 Red Alert SBIG Camera Alert Take Image failed (Command timed-out)
01:39:50 Green Clear SBIG Camera Take Image command accepted (bSbigDriverException flag is reset)
01:40:24 Red Alert SBIG Camera Alert Take Image failed (Command timed-out)
01:41:17 Green Clear SBIG Camera Take Image command accepted (bSbigDriverException flag is reset)
01:41:50 Red Alert Program Hung AstroMain UI appears to have stopped responding at 01:41
01:41:55 Red Alert CcdCamera CcdCamera appears to be frozen (last cycle at 01:41:23) in section 'GetCameraProperties / Disconnect/Direct'
01:42:00 Green Clear CcdCamera CcdCamera has resumed again (01:42) after 37s
01:42:05 Green Clear Program Resumed AstroMain UI has resumed again after 24s
01:55:41 Red Alert CcdCamera CcdCamera appears to be frozen (last cycle at 01:55:10) in section 'GetCameraProperties / Temperature'
01:55:46 Green Clear CcdCamera CcdCamera has resumed again (01:55) after 36s
01:58:16 Red Alert CcdCamera CcdCamera appears to be frozen (last cycle at 01:57:45) in section 'GetCameraProperties / FilterIndexZeroBased'
01:58:21 Green Clear CcdCamera CcdCamera has resumed again (01:58) after 36s
02:16:29 Red Alert Program Hung AstroMain UI appears to have stopped responding at 02:16
02:16:55 Red Alert Obs.Monitor Obs.Monitor appears to be frozen in section 'Refresh Dome Picture/Refresh panelDome' (last cycle at 02:16:22)
02:18:15 Green Clear Program Resumed AstroMain UI has resumed again after 113s
02:18:17 Green Clear Obs.Monitor Obs.Monitor has resumed again (02:18) after 1.8 mins
02:26:09 Red Alert SBIG Camera Alert Take Image failed (Command timed-out)
02:26:10 Red Alert CcdCamera CcdCamera appears to be frozen (last cycle at 02:25:38) in section 'GetCameraProperties / Status'
02:26:15 Green Clear CcdCamera CcdCamera has resumed again (02:26) after 38s
02:36:09 Red Alert Program Hung AstroMain UI appears to have stopped responding at 02:35
02:36:29 Green Clear Program Resumed AstroMain UI has resumed again after 30s
02:36:49 Red Alert Program Hung AstroMain UI appears to have stopped responding at 02:36
02:37:09 Red Alert Obs.Monitor Obs.Monitor appears to be frozen in section 'Refresh Dome Picture/Refresh panelDome' (last cycle at 02:36:36)
02:37:11 Red Alert CcdCamera CcdCamera appears to be frozen (last cycle at 02:36:37) in section 'GetCameraProperties / Disconnect/Direct'
02:37:14 Green Clear Obs.Monitor Obs.Monitor has resumed again (02:37) after 0.6 mins
02:37:16 Green Clear CcdCamera CcdCamera has resumed again (02:37) after 38s
02:37:19 Green Clear Program Resumed AstroMain UI has resumed again after 39s
02:46:28 Red Alert Obs.Monitor Obs.Monitor appears to be frozen in section 'Monitor ASCOM Scope' (last cycle at 02:45:55)
02:46:43 Green Clear Obs.Monitor Obs.Monitor has resumed again (02:46) after 0.8 mins
02:52:21 Green Clear Dome Charging Dome is parked and re-charging Ok (30mA)
 
 

Back to Top


Operational Issues (2024-10-28 S1261A)

[ Prev | Next ]

Critical Issues

Major Issues

Minor Issues

Small Defects

Continuous Improvement

[ Prev | Next ]


Fig 1.   TimeLine associated with CCDCamera Issue at 01:34

01:34:48.47   Called CCDCamera.TakeImage (1s)
01:34:52.37   Finished Camera.TakeImage

01:34:53.71   Starting Foc1 FocusProfile, wide
     ....     Prepare Focus Profile (Foc1, wide) 

01:34:53.93   Calling DrawFocusChange, MoveSteps = 2479
     ....     Get   CCDCamera.FilterIndexZeroBased
                       
     ....     Foc1 Focuser Moving

01:35:04.12   Get FilterIndexZeroBased call ( inferred time , CCDCamera is frozen)
01:35:06.12   Get FilterIndexZeroBased   timed out after 2s
01:35:06.96   Calling DrawFocusChange, MoveSteps = 500

01:35:10.31   Start FocusFrame 1/23   |  Start RunTakeQuickFocusShot()
01:35:14.31   CcdCamera is Pending (10s) ' in section 'GetCameraProperties / FilterIndexZeroBased'

Fig 2.   AllSky Image showing baby spider infestation (2024-10-28)

Image

Fig 3.   AllSky Camera showing baby spiders & funnel-like spiders web (2024-10-29)
.
Image

Image

[ Prev | Next ]

Back to Top


2024-10-31


Notes: Experience, Issues and Adjustments to using DeviceHub 7.0 (2024-10-31)

Following on problem with using the Observatory during first part of the S1259 session (2024-10-24) and subsequent investigations (see Investigation - Issues caused by installation of DeviceHub 7.0.1 ),  the cause of the problem and solutions were eventually determined.  Based on my experience I posted a summary on the ASCOMTalk Group under the post at this addreess https://ascomtalk.groups.io/g/Help/message/47596

The elements of the posting (including two follow-up posts) are presented here:


Experience, Issues and Adjustments to using DeviceHub 7.0

This note describes some initial issues I had using DeviceHub (DH) 7.0 - part of the ASCOM 7 Platform - and the solutions/adjustments that I've had to make to my particular environment and client program.
 
If you are not aware DH 7.0 makes a significant change to how it serves clients with Telescope and Dome Properties, like Slewing, Azimuth, Altitude, RightAscension, Declination etc, compared to the former DH 6.6 version.

DeviceHub 6.6
In DH 6.6 a call to Get Telescope Property (or Get Dome Property) would be served up from DeviceHub's internal cache of the values it obtained from the Telescope & Dome when it last polled them (every 1s or so during fast polling, or every 3s (? 5s) during normal polling). 

From a client program's point of view (POV) the access to Telescope/Dome properties was near-instantaneous (c. 1 ms), but the property values might be out-of-date (compared to the Hardware Driver/Hardware value) by around 1s (fast polling) or 3s (normal polling).

DeviceHub 7.0
In DH 7.0 a call to Get Telescope or Dome Property is passed on to the relevant Hardware Driver and is not served from DeviceHub's own cache.

From a client program's POV the values returned by a Get Property call will or should be the current property value as delivered by the Telescope or Dome Hardware/Driver.   However it takes a not insignificant amount of the time to return the property values.

Tests in my observatory environment shows the client waiting an average of 267ms to Get Telescope.RightAscension (with a range of 46-675ms).   So reading a pair of properties like RightAscension and Declination could take 530ms and reading a complete set of properties (Slewing, Tracking, Az,Alt, Ra,Dec, At Park) could take 1800-2100ms if there is a high load on the driver.

In future as Telescope Drivers move to the new ITelescope V4 and Dome Drivers move to the new IDome V3, the process will possibly be speeded up by some amount through the use of the new DeviceState property which retrieves all the main operational properties in one go. However for time being many of us will still be using drivers using older Interface Versions, and/or Clients using older Interface Versions and therefore not have this capability at hand.

New Design Philosophy
During Slewing, for example,  it is somewhat a moot point whether getting properties near-instantaneously in DH 6.6, which could be out of date by 1s or so (but with an opportunity to get a new set of properties near-instantaneously 1s or so later)  is better or worse than waiting 0.5 - 2s to get an up-to-date set of properties in DH 7.0 which may then require another 0.5-2s to get the next set of up-to-date properties.
 
But anyway the serving of properties direct from the Hardware via its respective Driver is the new behaviour in DeviceHub 7.0.

Peter Simpson explained it to me like this

"The caching mechanic in DH (6.6) broke a fundamental principle that ASCOM clients must receive accurate information from ASCOM devices. Causing the information to be up to 3 seconds out of date breaks that principle. Conform, our “standard application” reports multiple issues when the Platform 6.6 device hub hosts drivers that pass 100% on their own.

Fixing the DH problem was really about implementing ASCOM’s expected “device” behaviour (in DH 7.0) in regard to accuracy of information."

However it is important to be aware that the new behaviour in DH 7.0 does almost certainly increase of the number of requests/load going to the Telescope/Dome Driver. This may may or may not cause a problem, dependant on the design of the driver and the frequency of requests going to the driver.  Equally it is important to be aware that the extra delay in getting property values when using DH 7.0 could cause a problem to client applications. This is dependant on the frequency of their Get Property call,  the load on the Telescope/Dome driver from Get Property calls from all clients (which can further delay the serving of property values) and the particular design of the client applications involved.

Issues experienced with DH 7.0.1 installed
In my case I had show-stopping issue(s) when initial trying to use DH 7.0.1 in my observatory environment, which comprises Windows 11, LX200GPS/R Telescope & Pulsar Dome and  which is shown in the picture below (thanks to Peter Simpson for drawing this up)
 
I persevered for 2-3 hours with DH 7.0.1 during its first live session. One problem was there were delays of up to 14s when requesting a telescope slew before the hardware (telescope and dome) began moving. But the more serious matter was that after slewing to a target and taking a Locate Frame, CCDSoft5/TheSky6 would both freeze up whilst trying to Image Link/Plate Solve the locate frames as part of my usual centering operation.  This forced me to make multiple program kills and restarts / retries.    As I wasn't getting anywhere with my list of planned observing targets  I eventually installed my former DH version (6.6.1.1) at which point things worked fine for the remainder of the night.

Whilst my self-written Client Application (VB.Net) does have its own connection to DeviceHub.Telescope  (link not shown on figure above), it initiates slews via TheSky6 application, in order to pick up T-Point modified coordinates which are then communicated to the Telescope via TeleAPI Plugin & DeviceHub.Telescope.   I have a SlewMonitor in my client applications that builds a table of paths/times for the scope & dome slews, and creates charts showing slew path and speeds which is useful for spotting any issues in the observatory. 

(The TeleLink driver is simply a 'pass-through' driver that I wrote to workaround a bug in the no-longer supported TheSky6 program whereby targets close to RA 0/ RA 24 can be given a T-Point Modified RA value slightly less than 0 or slightly greater than 24, which fail checks in DeviceHub's SlewToCoordsAsync method.  The TeleLink driver intercepts any 'bad' values and wraps them appropriately, adding or subtracting 24.0 as appropriate). 

TheSky6 
Investigating showed that calls to slew the scope were being held up for an extra 10s such that hardware (scope and dome) didn't begin moving to around 14s after the call was sent by my client application.  This compared with the performance using DH 6.6.1.1 where it was taking just 0.8s for the call from my client application to reach DH with the hardware (scope and dome) starting to physically move only 3s or so after the call was sent (the dome actually moves slightly before the scope starts moving).  Extra tracing/logging put into a 7.0.2 beta version of DH by Peter Simpson logged the time of entry into DeviceHub's SlewToCoordsAsync Method which then showed me definitively that call to slew was getting delayed BEFORE reaching DH.

It was deemed that most-probably it was TheSky6 program that was the causing the delay rather than DeviceHub or the Meade Driver (MeadeGeneric 1.3.5). This hypothesis was supported by the observation that TheSky6's GUI (its response to mouse/mouse button actions) was a lot slower when using DH 7.0.1 than when using DH 6.6.1.1 and that TheSky6 is one of the pair of programs that was associated with Plate Solving/ Freeze issue when using DH 7.0,1 but not DH 6.6.1.1.

The issue was eventually resolved by relaxing the 'update cross-hair frequency' in TheSky6 from former figure of 500ms to a new figure of 2000ms  (this was after tests using update frequency of 1500, 2000 & 2500ms which found that 2000ms was the most optimal setting).  This allows slews to be initiated in DH 7.0.1 as fast as they were under DH 6.6.1.1. i.e there was no longer a 8-10s delay in the process.  (1500ms was a lot better than 500ms but still imparted some delay),  More importantly Locate Frames could be plate-solved as normal for centering targets without TheSky6/CCDSoft5 programs freezing.  

Under DH 6.6.1.1 TheSky6 could get Ra/Dec values from DeviceHub.Telescope almost instantaneously and with 500ms update frequency it could keep in reasonable step with the latest coordinates that DH had,  even if they were 1s behind the Telescope itself, and the virtual experience of telescope slewing was reasonable.    But under DH 7.0.1 it takes TheSky6 some 530ms to get RA/Dec values (say a range  of 100-1200ms), and with probable poor thread design it causes knock-on issue for the program's GUI and its ability to meet image-linking (plate-solving) requests from CCDSoft5.   
(TheSkyX, which I've never upgraded to (due to high cost for full package incl T-Point), may or may not perform better than TheSky6 in this regard.)

With a update frequency changed to 2000ms TheSky6 seems able to meet demands of GUI and requests from client or CCDSoft imaging program, but the virtual experience is less smooth, but not critical for my normally automated observing operations.
(Access to up-to-date property values does not guarantee regular/or rapid access to up-to-date values !)

Telescope & Dome Drivers
Analysis of MeadeGeneric Telescope Driver Logs showed me when using TheSky's with original Update Frequency of 500ms, the number of Get RightAscension calls during a normal (non-slewing) part of a session  increased from 6 in a 15s period when using DH 6.6.1.1 to 56 in a 15s period when using DH 7.0.1,  ie from 1 call every 2.5s (DH 6.6.1.1)  to 1 call every 0.25s (DH 7.0.1), a 10 fold increase.   Surprisingly during slewing the increase in calls with DH 7.0.1 was only two-times higher than with DH 6.6.1.1.   These numbers are of course dependant on the client programs being used and various settings, but they give an idea of the impact of DH 7.0
 
As far as I can tell The MeadeGeneric driver I use for my LX200GPS/R telescope seems to manage the additional load than is imposed on it under DH 7.0 compared to DH 6.6.   Similarly the Pulsar Observatories driver than I use for my Pulsar Dome also seems to manage the higher loads under DH 7.0 ( the dome has less clients using it so its extra load when using DH 7.0 is likely less than for the telescope driver).

Client Application / Observatory Control Program
With the insights gained I have been modifying my Client Application (AstroMain) to perform better in the DH 7.0 environment, not just to benefit itself, but by reducing its load on the Telescope driver may help the driver serve data to TheSky6 program with a faster turnaround. ?  These are examples of actions I've taken.

1) With DH 6.6 environment where my SlewMonitor needed to get fresh telescope property values as soon as possible after DH polled the Telescope it was has been making property set requests to DH.Telescope ever 0.2s so that it shouldn't be more than 1.2s behind the Telescope's actual values, if it polled DH every 1s it might be up to 2s behind the Telescope's actual values).  This was optimal in the DH 6.6 environment, as the property value were returned to the SlewMonitor nearly instantaneously and there was no extra loading on the Telescope Driver itself.   

With DH 7.0 environment,   the polling of telescope properties every 0.2s by my SlewMonitor clearly places a significant amount of extra load on the Telescope Driver (and may end up slowing the Telescope Driver's response to TheSky6 ?).  Polling at such rates (even if possible) is also wasted as experience suggests that the Telescope Driver is likely refreshing its own values every 1.5s or so.   However there is still a need to get fresh data as soon as it could become available, so I'm electing to use a cycle time of 0.5s to achieve this (cycles may take longer than this as timings are ultimately controlled by the sum of the individual times in getting the required properties, these are mainly Slewing, Az & Alt (since I can calculate Ra,Dec them from Az/Alt quicker than I can get them from the scope, accuracy is sufficient for my needs during slewing ).

2) Besides the SlewMonitor that is used during slewing operations, I have a general monitor that runs every 2.5s and collects a variety of observatory information, including telescope coordinates Az,Alt, Ra,Dec and states like Slewing, At park, Tracking.

Under DH 6.6 where access to telescope properties by the client are near-instantaneous and have no impact on the Telescope Driver, there was no problem in having both the SlewMonitor and the General Monitor's Scope Reading  running at the 'same' time (though in different threads).  Under DH 7.0  having these two threads Getting Telescope properties places extra load on the telescope driver, and probably delay each other.

Therefore I've changed my application design to pass-over the General Monitor's Scope Reading section when a Slewing Operation is taking place and extend my SlewMonitor to do tasks that the General Monitor would be doing if it wasn't passed.

Putting together these two improvements with the change to TheSky6's telescope update frequency, should give me a system/environment that works with DH 7.0

General Lessons
So whilst the particular issue I had related to TheSky6 and I have/will arrive at a solution that works for me, the general lesson is that there can be unexpected consequences of moving to DH 7.0 due to its different design philosophy, which may require changing application settings, modifying client applications and possibly in some cases modifying drivers in order to handle /work with the higher work load and with the extra delays in getting property values. 

One could stay with Device 6.6 (by re-installing a prior DeviceHub version, replacing DH 7.0.1 that is installed with ASCOM 7 Update 1) , at least as an interim solution whilst working any issues raised.
 
In my case I reinstalled my formerly used DH 6.6.1.1 version after installing ASCOM 7 Update 1 and then finding issues using DH 7.0.1 in my existing client environment.  Using DH 6.6.1.1 with ASCOM 7 Platform worked ok for me and provided me a way of continuing my Telescope Observing/Imaging whilst figuring out how I could make adjustments to work with DH 7.0.1).

Moving to DH 7.0 is the preferred route in my view because of it's better logging capabilities and continued support/development moving forward. 

Another lesson is that working with Simulators can only get you so far.   The problems experienced in the Observatory couldn't be replicated using Simulators as they don't delay the return of property values in the way that real hardware/drivers do.

Additional note, added 2024-10-31

Another adjustment that can be made to reduce load on Telescope/Dome ASCOM Driver in DH 7.0 environment and that is the fast polling rate in DH’s telescope and dome setups.  

Since the client programs no longer receive operational properties from DH’s cache in DH 7.0, they can no longer derive any benefit in having DH poll the Telescope/Dome with higher frequency during Fast Polling.  I had Telescope Fast Polling set at the minimum setting of 0.5s, and have changed this to 1.0s. Subject to any further problems across the entire client set I might even set it to the maximum setting of 1.5s.



Reply to post from Peter Simpson (2024-10-31)
"I would just like to add that a fundamental, and often unspoken ASCOM principle is that drivers must always provide current, up-to-date, information to clients. By extension, this also applies to hubs.
 
The Platform 6 version of Device Hub did not implement this principle and could return stale values that were up to three seconds old, we do not recommend its use for this reason. 
 
The Platform 7.0.1 version of Device Hub abides by the timeliness principle and is a good tool, particularly for those who want to use it's dome slaving capability. David has found a behavioural change that was unintentionally introduced in the 7.0.1 release and this will be fixed in Platform 7.0 update 2

Back to Top