A series of daytime tests using Telescope Drivers was conducted on 2021-04-22 & 2021-04-23.  The main conclusions were :

• MeadeLX200GPS driver was found to be capable of connection to the observatory's LX200 GPS/R scope but only if the 'Auto Set Time' option is turned off.
  Time/Date Prompts have to be manually entered.
   
  (MeadeLX200GPS driver continues to be unable to connect to scope with the Auto Set Time option turned on.   This issue developed during the course of session S887 (2021-04-16) and meant that attempt at an observing session the following night (S888A, 2021-04-17) had to be abandoned. This driver dates from 2005-2007 and is no longer supported.   This has prompted an effort to see if the MeadeGeneric ascom driver (written & supported by Colin Dawson) can be made capable for filling the role of the MeadeLX200GPS driver)
   
• New routine to set Telescope.UtcDate written to set Time/Date on Telescope.  But Time/Prompts still need to be acknowleged requiring access to the handbox.
   
• LX200 Scope shown to reset TimeZone for CLAIR ABZ site from GMT +00 from GMT +01 after connection / after date/time entry.    Why it does this is unclear,  but it does.  It was concluded that there was no point it setting the timezone to the correct zone (GMT +00) because the  LX200 simply changes it back to +01 once scope is initialised.
  
  (This issue was later resolved using Meade's by-pass Date Prompts command)

Update 2021-04-24

• A new button-initiated routine in AstroMain control program (called Scope.SetUtcDateWithByPass)  based on using Meade  ":hIyymmddhhmmss#"  command for by-passing date prompts and correctly setting scope's time/date without affecting its TimeZone setting was successfully tested. This makes it practical to again starting using the MeadeLX200GPS ascom telescope driver following the show-stopping issue that arose during sessions S887/S888A, when the driver was used with AutoSetTime Option being ON.
   
• For the session S890 (2021-04-24) it was initially proposed to drop back to the MeadeLX200GPS driver in order to avoid the ‘Unable to start the direct slew’ problem that badly interrupted the last two session when using the MeadeGeneric 1.0.0.296 driver. In the event MeadeGeneric driver was used for the session following successful fixing of issues in MeadeGeneric 1.0.1.32 Dev Build.

Update 2021-04-25

• New routine in AstroMain control program,  based on using Meade  ":hIyymmddhhmmss#"  command for by-passing date prompts and correctly setting scope's time/date without affecting its TimeZone setting was built it the program's automated telescope start-up routine.  The Meade ":ED#" command" is also used (via  Scope.CommandString(":ED#") )  to return the message currently shown on the scope's AutoStar II handbox.
   
• PEMProV2 shown to be capable of successful connection to scope when using MeadeLX200GPS driver via DeviceHub.Telescope
  
• Session S891 (2021-04-25) was successfully conducted using MeadeLX200GPS telescope driver with AstroMain providing new 'bypass date prompts' command,   This confirm successfully remediation of the show-stopping scope connection issue when using MeadeLX200GPS telescope driver with its native AutoSetTime option.

Update 2021-04-26

• Advanced settings for the Telescope's COM Port were examined :
  
  
  
  Can any of the Timeout settings alleviate the issue connecting to the telescope using MeadeLX200GPS driver with 'auto set time' set to on ?
  (or alleviate the issue connecting PemProV2 to the telescope using the MeadeGeneric driver ?)
  

Update 2021-05-22

• Unable to connect to telescope at start of session S898 (2021-05-22) using MeadeLX200GPS driver. 
  
  MeadeLX200GPS driver was used at start of session to get around an issue with the MeadeGeneric driver which currently makes it unable to effect a physical change to the telescope tracking state - preventing the telescope tracked to be turned off during a prolonged suspension.
  
  After developing workaround to allow MeadeLX200GPS driver to again connect to telescope (following issue with AutoSet Time) it was quite a surprise to again have telescope connection problems.  It was unclear why connection failed and why Date Field requests weren't by-passed using the special bypass/date setting command . Issue resolved in-session by switching over to use the MeadeGeneric driver (despite its ongoing Get/Set Tracking State issue). Connection occurred without further issue.    
   
• When trying to get Properties for MeadeLX200GPS driver the following day,  an ASCOM Chooser dialog popped up with message "Failed to load driver "MeadeLX200GPS.Telescope" System.RunTtime.InteropServices.COM Exception .. failed due to .. Class not registered".  Problem not fixed by reinstalling the Meade driver. Conformance Test on the MeaderLX200GPS driver showed following Driver Access ERROR  "Error creating driver object using late binding: System.Runtime.InteropServices.COMException (0x800A01A9): Creating an instance of the COM component with CLSID {E09E5EA3-18C9-4AAD-96C9-F474E4C374B3} from the IClassFactory failed"  
   
  Problem persisted after reinstalling the driver and rebooting the computer.  Problem occurs on both Observatory and Development Computers.  It is possible that Driver Properties can only be reached when the driver is connected to the scope, but the evidence is that driver access fails before the driver can connect.

A series of tests were conducted between 2021-04-22 to 2021-04-25 using the MeadeGeneric telescope driver (v1.0.0.296 to 1.0.1.328)

2021-04-22 / 23

• V1.0.1.312 of Meade Generic confirmed to have a working implementation of 'Auto Set Time' feature.
  This is a new feature in MeadeGeneric Driver that wasn't present in the earlier 1.0.0.296 version used in sessions S888 & S889.
   
   (V.1.0.1.310 was tested first but had a bug where the setting of current date/time and skipping of Date Prompts was performed in the wrong order, which resulted in telescope pointing to be off by several hours in RA)
   
• MeadeGeneric (1.0.0.296 to 1.0.1.312) shown to have an issue where, on my computer at least , most of its Driver Properties become blanked out or set to 0 after making a connection to the scope.   This means that properties have to be re-filled in each time the driver is used, making the driver in practical for regular use until fixed.
   
  (This was eventually fixed in the 1.0.1.322 DevBuild,  2021-04-24)
   
  
• Trace data was collected that confirned that MeadeGeneric (1.0.0.296 to 1.0.1.xxx) wasn't passing Slewing=True back to DeviceHub.Telescope (or other client) when the scope was slewing.
   
  Previously it was determined that the Meade.Generic.Telescope trace log was showing Slewing=False throughout S888 & S889 sessions and that the Slewing Property didn't ever seem to be set to True.   This is believed to behind a major new  issue in these sessions whereby TheSky6 would regularly to put up "Unable to start the direct slew!!" dialog box messages during Jog operations that held up AstroMain's automated job queue (requiring user intervention) and prevented the capture of curved slew path information in AstroMain.
   
• A fix to a) ‘Slewing Property not True whilst Slewing’ Issue and a resolution of b) ‘MeadeGeneric Properties become blanked’ issue are needed before it becomes practical to use MeadeGeneric for a new live observing session.
   
  (These key issue were fixed and there was sufficient confidence in the 1.0.1.327 Dev Build that is was using in live session S890 (2021-04-24) )
   
• For the next session it is proposed to drop back to the MeadeLX200GPS driver in order to avoid the ‘Unable to start the direct slew’ problem that badly affected/interrupted the last two session when using the MeadeGeneric 1.0.0.296 driver.
  
  (As it turned out the was sufficient confidence in the fixes included MeadeGeneric 1.0.1.327 Dev Build that it was using in live session S890, 2021-04-24.

Update 2021-04-24

• MeadeGeneric 1.0.1.322 confirmed to have fixed issue where driver settings were being blanked or set to 0
   
  
• MeadeGeneric 1.0.1.322 shown to have a critical bug where scope UTC Date/Time was 12 hours off when connecting after midday.
  (This was bug was a date formatting error where 'hh'  (hour on 12-hour clock) had incorrectly been used instead of 'HH' (hour on 24 hour clock)
   
  
• MeadeGeneric 1.0.1.327 confirmed to have corrected UTC Date/Time bug
  (bug fixed by using 'HH' format to specify hour on 24-hour clock)
   
  
• For the session S890 (2021-04-24) it was initially proposed to drop back to the MeadeLX200GPS driver in order to avoid the ‘Unable to start the direct slew’ problem that badly interrupted the last two session when using the MeadeGeneric 1.0.0.296 driver. In the event MeadeGeneric driver was used for the session following successful fixing of issues in MeadeGeneric 1.0.1.32 Dev Build.

Update 2021-04-25

• MeadeGeneric 1.0.1.328 DevBuild confirmed to return the expected Az/Alt position when the 'Report Coordinates As' option is used.
  (This is one of the three Parked Behaviour options that was introduced in 1.0.1.327, but wasn't initially working correctly until 1.0.1.328)
  
  One issue arose during testing but it is a very much a TheSky6/TPoint issue and not a MeadeGeneric driver issue. It’s a behaviour that I’ve seen in TheSky6 before but never understood till now. When scope is reported to be at Alt 0 (as would if the driver reports Parked Coordinates as Az 180 / Alt 0) and a TPoint Model is active (or at least the particular TPoint model that is generated for my scope) TheSky6 shows a scope position on its virtual sky that gradually moves from 30 deg below horizon to some 70 deg above horizon and then repeat. I saw a not dissimilar effect when I attempted to slew the scope to Az 180 / Alt 1 at start of session S890. The moving virtual scope is confusing but intrinsically its not a problem if the option prevents a blocking dialog message from appearing. The problem doesn’t occur if TheSky6 document has no TPoint model (which is why I believe that TPoint calculated position when close to horizon is somehow involved) . I normally use a TPoint model and its been shown that the issue is easier enough to remedy by setting the Telescope driver to report Parked coordinates as Az 180 / Alt 3.  (ie a position that is off the horizon)
  
• An issue prevents PEMProV2 from successful connection to LX200GPS telescope when using MeadeGeneric driver (1.0.1.327) either directly or via DeviceHub.Telescope.  A ‘Timed out waiting for received data’ error dialog pops up. It's unclear what is upsetting PEMProV2 but something evidently is.
  (In contrast Connection from PemProV2 is possible when using the MeadeLX200GPS driver)
  (this issue was fixed in v.1.1.0.336)

Update 2021-04-27

• MeadeGeneric 1.1.0.336 version confirmed to have fixed an issue where PEMProV2 wasn't previously able to connect to scope using MeadeGeneric
   
• MeadeGeneric 1.1.0.336 version confirmed to return the expected Az/Alt position when the 'Last Good Position' Parked Behaviour option is used.
   
• Attempts to speed up processing of positional data in MeadeGeneric driver by reducing the number of Get Azimiuth/Get Altitude calls from AstroMain (3.39.4) failed to give any improvement. The average time befween scope position changes during slewing remains at 2.3s . This remains as being 70% slower than when use MeadeLX200GPS driver.  Prior test (2021-04-24) show that path for 80 deg slew to Near Zenith Focus Field was defined by 16 unique Az/Alt points (25 points when using MeadeLX200GPS) .  In new test path for 77 deg slew to Near Zenith Focus Field was defined by 12 unique Az/Alt points.  
   
• Demonstrated that display message on AutoStar II handbox can be obtained using  Scope.Action(‘'handbox”,”readdisplay”) command. Beside "handbox",  “site” is the other action that is supported by the MeadeGeneric driver. Repository code will be examined in due course to to see what parameters are applicable to use with these actions. 
  In the previous day's testing it was demonstrated that Scope.CommandString(“:ED#”,True) could be used to obtain the handbox display message.
  
• MeadeGeneric 1.1.0.337 version is confirmed to show improved performance.
  
  For LX200GPS scope Az/Alt values are now taken directly from the scope. This eliminates the retrieval of UTCDate, SiteLongitude, SiteLatitude, RightAscension and Declination from scope that are necessary for maths calculation to workaround a firmware bug in 44Eg (older Meade scopes/Autostar versions) where
   :GA# was returning the Dec, not the Altitude!)
  
  For an 80 arc deg slew the associated Az/Alt slew path now has 22 points constructed along it compared to only 12-14 points previously for an equivalent slew. The average time between positional changes now comes in as 1.6s compared to 2.4s earlier. This new result (1.6s) is not too far off previous results using the MeadeLX200GPS driver (1.3s)

Update 2021-04-28

• MeadeGeneric 1.1.0.337 version is confirmed to show a performance that is similar to MeadeLX200GPS Driver
  
  For an 85 arc deg slew the associated Az/Alt slew path now has 26 points (average 1.38s between points) with MeadeGeneric 1.1.0.327. This new result was very similar to a similar 83 deg slew using the MeadeLX200GPS driver which had an Az/Alt slew path with 24 points (average 1.32s between points).
   
• Test conducted trying to connect  to the scope using baud rate of 38400 (read somewhere that might be possible). Changed setting in driver setting and in USB-Serial Port Properties noth to 38400. But the connection attempt failed.   Dropped the baud rate back to 9600 again.
  
  
• Data collected about the values returned by Get Scope.UTCDate. 
  
  Looking at MeadeGeneric Log it seem that was a real (or apparent) computer to telescope time difference of around 2s  (probably a time delay getting date/time into telescope during connection + delay in LX200 whilst it set the clock + a time delay getting date/time back out from the telescope)
  
  Values returned to client program (AstroMain) indicate an apparent difference of between 2 and 6s between Telescope UTCDate and Computer UTCDate. It seems that in addition to the basic 2s difference observed in the telescope driver a further 0 to 3s delay is probably attributable to DeviceHub with it returning either a freshly obtained UTC value or a slightly less fresh UTC value depending on whereabouts it is in its slow polling rate cycle.  
  
  A bit later I saw that the time difference jump to a larger value (with the time difference typically being up to 12 to 18s).  This was initially harder to explain - but is now explained as being data collected after the telescope was parked but before the telescope/driver was disconnected on the computer. MeadeGeneric log does not shown any completed Get UTCDates messages after scope is parked. It seems that scope simply can’t/didn’t return a UTCDate/Time when it was parked, or the driver chooses not to fetch it when the scope is parked,  and after some timeout period a time (but not the current UT time) is somehow returned.
  
  This ‘UTC date whilst parked’ issue is not a significant problem in practice.
  
  

Opportunity was taken to re-balance the OTA on the observatory' LX200 telescope today (2021-04-23).  This was an overdue task since OTA became unbalanced when secondary scope was removed and then re-attached at a different position on the dovetail  (see motor focus repair, 2020-10-02) . Since then louder than normal sounds began coming from the Dec drive when the scope was slewing at certain locations with greatest load.

Rebalancing was achieved by releasing the Declination clutch and adjusting the positions of the two weight sets suspended on the bottom of the OTA.  After this the scope was deemed to be very well balanced when the OTA was lying horizontal  and moderately well balanced when pointing vertically up.   As the RA position remained in the locked position,and scope repositioned close to the Park Position, the scope will be ok to resume from Park Position (subject to a resync & short mapping run).

Driving the scope from the handbox showed that loud sounds from the Dec Drive when slewing have reduced  following the rebalancing but had not totally disappeared.
(sounds are overall much more normal)