A new development version of MeadeGeneric driver was installed on the observatory computer today (2021-12-19).  This contains an updated version of the Get Tracking Property which now returns driveLunar for a wider range of Hz drive rates (57.3 to 58.9) and throws an ASCOM.InvalidValueException when the Hz rate is not one of the standard rates (driveSidereal, driveSolar, driveLunar).

The wider range in Lunar rates follows a review that I had undertaken on 2021-12-17:

Lunar Tracking rate probably varies with its distance from earth (ie where it is in its orbit) such that is is probably a range in rate (a view endorsed by some Nasa data).  Meade uses 59.9 Hz as Lunar Tracking rate, whilst ASCOM standard (DriveRate page) quotes a Lunar tracking rate of 14.685 arcseconds per second which would be equivalent to 58.74 Hz (4 * 14.685)

I’ve looked at a forum discussion this evening that discusses the lunar tracking rate
https://www.cloudynights.com/topic/624764-how-would-i-calculate-the-lunar-tracking-rate 

A number of people calculated rates for the moon from ‘first principles/ assumed orbital values”,  one person went as far as saying “I couldn't reconcile the ASCOM figure of 14.685 Asec/sec with any method of calculation that made astronomical or mathematical sense to me.”

Somebody else (james7Ca) worked out a range based on Nasa data from one month in 2018 which would place the ASCOM value towards the upper end of this range, with the Meade value close to the average.

Based on the numbers discussed in this posting it could asserted that returning driveLunar for anything in the range 57.3 to 58.9 Hz is a valid implementation of Get Tracking Rate

58.9 Hz (from 4 * 14.718 arcsec/sec, maximum value based on data from Nasa Horizon table for Jul 2018)
58.7 Hz (from 4 * 14.685 arcsec/sec, value in ASCOM standards driveRate page)
58.1 Hz (from 4 * 14.52 arcsec/sec, midpoint value based on data from Nasa Horizon table for Jul 2018)
58.0 Hz (from 4 * 14.492 arcsec/sec, calculated/proposed by JamesMStephens)
58.0 Hz (from 4 * 14.497 arcsec/sec, average value based on data from Nasa Horizon table for Jul 2018)
57.9 Hz (     = 4 * 14.475 arcsec/sec, Meade value)
57.8 Hz (from 4 * 14.451 arcsec/sec, calculated/proposed by DFEmery)
57.3 Hz (from 4 * 14.326 arcsec/sec, minimum value based on data from Nasa Horizon table for Jul 2018)

Results
MeadeGeneric driver 1.3.3.375 was used in a test run with live scope on 2021-12-19, which confirmed the updated bahaviour , but showed that the thrown exception is not reaching the telescope client and DeviceHub seems to intervene and send on driveSidereal to client when ASCOM.InvalidValueException is received from the MeadeGeneric driver.

>> MeadeGeneric Releases : https://bitbucket.org/cjdskunkworks/meadeautostar497/wiki/Release%20History

Whilst testing the set tracking command (:STtt.t#) and several occasions it gives rise to a rogue Azimuth Value.  

In following example before using the ST command the scope was positioned at Az 189.8°,  Alt 32.9°
Directly after the command was received and completed,  the Azmiuth was reported being Az 1189.8° (Alt was still at 32.9°)

This value is passed to the AstroMain (Observatory Control Program) via DeviceHub.Telescope, where the  Obs.Manger upon seeing that the scope has moved beyond 349 (which is an defined exclusion zone where cables could wrap around the pier if the scope goes close to or beyond 360 ) intervenes and commands the scope to slew back to a 'safe' position at Az 245.5°, Alt 9.8°

It can be seen the rogue azimuth "1189.8" value is "1" & "189.8"    (ie a "1" is put in front of the scopes actual Azimuth value).

01:19:35.642 Altitude       32.8894444444444
01:19:35.674 Azimuth Get    189.784722222222

01:19:35.866 CommandString  raw: False command GT
01:19:35.898 CommandString  Completed: +59.3

01:19:38.504 CommandBlind   raw: True command :ST60.020#
01:19:38.633 CommandBlind   Completed

01:19:38.633 Altitude       32.8891666666667
01:19:38.697 Azimuth Get    1189.79166666667

01:19:39.844 SlewToAltAzAsync Az=245 Alt=10


Problem repeated at 01:22:   
In this case rogue azimuth "1190.7" value is "1" & "190.7"    ( a "1" is again put in front of the scopes actual Azimuth value).

01:22:35.441 Altitude      32.8272222222222
01:22:35.490 Azimuth Get   190.682777777778

01:22:38.174 CommandBlind  raw: True command :ST60.060#

01:22:38.385 Altitude      32.8258333333333
01:22:38.387 CommandBlind  Completed
01:22:38.481 Azimuth Get   1190.70055555556

Problem previously occurred in sessions S941 (2021-12-16)  & S942 (2021-12-17) and again when sending a ST command.

The problem does not occur on every use of the ST command, it happens in around 1 in 4 times or so.

It is unclear if the issue is related to
 - using the ST command
 
-  using the ST command in the format  :STtt.ttt#  instead of the documented format :STtt.t#
   (the extra decimal places modify the x10 finer Custom Tracking rate in AutoStar II and is therefore believed to be valid)
 
-  using the ST command with a CommandBlind, rather than a CommandString
   (the ST command is due to return:  0 – Invalid,  1 - Valid, but when CommandString was tried it was found to give
   Exception: Timed out waiting for received data, and is why CommandBlind was used)
  

It it hypothesed that the rogue "1" that is prefixed in front of the correct Azimuth value is the "1" that was the (valid) response  from the ST command that wasn't waited for

Is this a bug in the LX200 code, 'user error' (due to the STtt.ttt command format used) or a bug in the driver ?

CommandBlind should be legitimate call to the scope.  The ASCOM standard states the method "Transmits an arbitrary string to the device and does not wait for a response."

Other observation

When sending a ST command the result of the tracking rate change takes some to appear.

MeadeGeneric

00:41:23.224 CommandBlind raw: True command :ST60.600#
00:41:23.469 CommandBlind Completed

00:41:23.469 Altitude 33.2333333333333
00:41:23.533 Azimuth Get 1178.44805555556

00:41:23.742 CommandString raw: False command GT
00:41:23.773 CommandString Completed: +60.5
00:41:23.775 Connected Get True

00:41:24.982 CommandString raw: True command :GT#
00:41:25.005 CommandString Completed: +60.5

No  "TrackingRate Get" line because exception has been thrown.

DeviceHub

00:41:23.470 CommandBlind: Command :ST60.600#, Raw True (done)
00:41:24.162 Get Azimuth: 1178[B0] 26' 53" (done)
00:41:24.163 Get Altitude: 33[B0] 14' 00" (done)

00:41:25.005 CommandString: Command :GT#, Raw True, Returned +60.5 (done).
00:41:25.005 Get TrackingRate: driveSidereal (done)

1) An examination of PHD2 and MeadeGeneric logs was made see whether all the PulseGuides were actually being made by the Telescope driver or whether some of intended pulses were being dropped.   (if this this was happening then it might provide some explaination of why the PHD2 guiding seems to be sometimes ineffective at bringing a guide start back to the lock position.

A particular 60s time interval was examined (2021-12-17 18:43:00 to 18:44:00) were guiding in Dec is not fully effective.

PHD2 shows 31 PulseGuide calls in the 60s interval,  each call is accompanied by a 
   Get IsPulseGuiding:  False
   Get Slewing: False

During the same 60s interval, the MeadeGeneric log records 31 occurance of the row

   PulseGuide      Using new pulse guiding technique

with 30 occurances of    PulseGuide      pulse guide direction.....
and 30 occurances of    PulseGuide      Complete Before....
and 31 occurances of    PulseGuide Complete After

It therefore seems that all Guiding calls are getting through and none are being dropped / lost.

During this time there are 20 occurances of
   MovingAxis

of which 4 occurances of    MovingAxis     Result = false (guiding is true)

and 16 occurances of         MovingAxis     Result = False Primary=False Secondary=False


 
2) Blocking ?

There was some concern that PulseGuide being synchronous in DeviceHub might block all other telescope communications.
I wasn’t sure if this applied to all PulseGuides or just those using Old Method (where the NewMethod commands can’t be used or where the guide duration was >= 10000 ms)

I was worried in case Pulse Guides to move the scope up to 2 arc min (which would take around 8.5s to complete on my system using x0.90 guide rate) would block other threads and other clients from getting routine telescope information (coordinates, tracking state, etc).

But looking at MeadeGeneric Logs and a particular 7720ms Pulse Guide I am reassured that it hasn't blocked other activity which reads telescope coords/status etc. Between the start and completion of the pulse guide there were a total of 168 intervening log messages  :

02:10:54.422 Pulse Guide Started (guideNorth duration 7720)
02:10:54.422 PulseGuide Using new pulse guiding technique

  { 168 log messages including }

02:10:54.648 Connected Get True
02:10:54.648 AtPark Get - False
02:10:54.742 SiteLongitude Get -02[B0] 00' 32"
02:10:54.742 SiderealTime Get - 7.77665793998855
02:10:54.742 Connected Get True
02:10:54.743 MovingAxis Result = false (guiding is true)
02:10:54.743 GetSlewing Result = False
02:10:54.743 Slewing Result = False
02:10:54.744 TargetDeclination Get 4.03104166666667
02:10:54.744 Connected Get True
02:10:54.745 TargetRightAscension Get 5.49018333333333
02:10:54.745 Tracking Get
02:10:54.745 GetScopeAlignmentStatus Started
02:10:54.745 CommandString raw: False command GW
02:10:54.781 CommandString Completed: PTP
02:10:54.790 GetScopeAlignmentStatus Result AlignmentStatus AlignmentMode=algPolar;Tracking=True;Status=ScopeWasParked
02:10:54.790 Tracking Get = True

  { other intervening log messages aren’t shown here }

02:11:02.261 PulseGuide Complete Before RA: 05:29:25 Dec:04[B0] 01' 56"
02:11:02.261 PulseGuide Complete After RA: 05:29:25 Dec:04[B0] 03' 22"