A feature of PHD2 Guiding was tried out during the session for the first. This is comet tracking on a comet that is too dim to lock onto or has a centre which is to ill-defined to reliably guide upon. This is presented as Tool in PHD2 ( https://openphdguiding.org/man-dev/Tools.htm#Comet_Tracking ) in which the user fills in comet's forecast motion and then activates an 'Enable' button to begin the comet tracking. However this manual method isn't suitable for queue based automated observations where the user is generally not available for performing these manual tasks.

However it is possible to utilise the PHD2 server to perform the equivalent task. This was proven during a proof-of-concept exercise whilst imaging Comet C/2018 W2 (Africano).   

With two data fields containing the Ra and Dec motion of the comet in arcsec/hr, a button was tied to a new routine UsePhd2ShiftLock

Private Sub btnTestUsePhd2ShiftLock_Click(sender As Object, e As EventArgs) Handles btnTestUsePhd2ShiftLock.Click
'====================================
Dim RaRate As Double
Dim DecRate As Double

  RaRate = CDbl(txtRaMotionRate.Text)
  DecRate = CDbl(txtDecMotionRate.Text)

  UsePhd2ShiftLock(RaRate, DecRate)

End Sub

Sub UsePhd2ShiftLock(ByVal RaRate As Double, ByVal DecRate As Double)
'===============
Dim Response As String = ""
Dim Result As String = ""
Dim Params As String

' Set Lock Shift Params
' ----------------------
  Params = " ""params"": [{""rate"": [" + CStr(RaRate) + ", " + CStr(DecRate) + "] ""units"": ""arcsec/hr"", ""axes"": ""RA/Dec""}]"
  Phd2.SendRequest("{""method"": ""set_lock_shift_params"", " + Params + ", ""id"": #ID}", Response, "result", Result)
  WritePhd2LogFile(Response)

' Set Lock Shift Params
' ----------------------
  Phd2.SendRequest("{""method"": ""set_lock_shift_enabled"", ""params"": [true], ""id"": #ID}", Response, "result", Result)
  WritePhd2LogFile(Response)
End Sub

C/2018 W2 (Africano) was scheduled to be imaged at 2019-10-04 22:00 UT +/-. Ra/Dec rate was obtained from the Minor Planet Centre

C/2018 W2 (Africano)
Perturbed ephemeris below is based on elements from MPEC 2019-QD5.

    CK18W020
Date       UT      R.A. (J2000) Decl.    Delta     r     El.    Ph.   m1    Coord Motion       Object    Sun   Moon
            h m s                                                            "/hr     "/hr    Azi. Alt.  Alt.  Phase Dist. Alt.
2019 10 04 200000 23 04 13.2 -07 18 04   0.550   1.512  153.3  17.3  10.0 -224.04  -381.17    144  +25   -24   0.41   073  +07
2019 10 04 210000 23 03 58.3 -07 24 24   0.551   1.513  153.1  17.4  10.0 -223.89  -380.20    160  +29   -32   0.42   073  +01
2019 10 04 220000 23 03 43.4 -07 30 44   0.552   1.513  153.0  17.5  10.0 -223.58  -379.22    177  +31   -38   0.42   072  -07
2019 10 04 230000 23 03 28.5 -07 37 03   0.552   1.513  152.9  17.6  10.0 -223.08  -378.23    194  +30   -42   0.43   072  -15
2019 10 05 000000 23 03 13.6 -07 43 20   0.553   1.513  152.7  17.6  10.0 -222.40  -377.24    211  +26   -43   0.43   071  -24

and the values -223.58 & -379.22 entered into Ra, Dec rate fields in my program.

When the "TestUsePhd2ShiftLock"  button was applied it produced the following exchange with the PHD2 Server :

22:59:42.78 | >> Request={"method": "set_lock_shift_params", "params": 
                 [{"rate": [-223.58, -379.22] "units": "arcsec/hr", "axes": "RA/Dec"}], "id": 102}
22:59:43.30 | {"jsonrpc":"2.0","result":0,"id":102}

22:59:43.30 | >> Request={"method": "set_lock_shift_enabled", "params": [true], "id": 103}
22:59:43.81 | {"jsonrpc":"2.0","result":0,"id":103}

At the end of the process another button is used to send a request to 'set_lock_shift_enabled' to 'false' to stop the Lock Shift guiding method.

What  Lock Shifting does in PHD2 is to continuously adjust the Star Lock x,y position for the guide star at the same rate that the comet is moving.  By this means it generates an  image on the main camera where the comet appears stationary and the stars move between frames and/or are trailed  ( if exposure is longer enough and/or comet is moving faster enough or several frames are stacked together)

Stacking the resulting 9 x 45s frames taken whilst performing the Star Lock shift guiding produced the following image

C/2018 W2 (Africano) (passing through Aquarius) Sun Distance 1.51 AU Earth Distance 0.55 AU (82.5 million km)

CCD Image (70% size, log scale) 9 x 45s exposure (average combine), 3x3 binning, C Filter 2019-10-04 22:07 UT (#705094-102) 12" LX200R (at f/10.4) + ST-10XME Auto-guided using TS 80mm APO, ZWO ASI178MC & PHD2 with Lock Shift (RA rate -223.58 arcsec/hr, Dec rate -379.22 arcsec/hr)

Whilst the comet is well defined and stationary in the image as hoped, the quality of the guiding and the star trials is rather poor, with movements producing a jerky, zig-zag like trace rather than a nice straight trace.   It's not clear exactly why the guiding was performing this way. ? Declination backlash ?

Star Detail - Stacked Image

CCD Image (100% size, log scale, cropped) Image details as above

Star Detail - Video Animation

CCD Image (100% size, log scale, cropped) Image details as above

Next Steps
Next steps to automation the process would be as follows

a) find an online source that can accept command line/batch request for ephemerides data for a specified comet including Ra/Dec Motion rates
b) creating a routine to make request and recieve the response
c) creating a routine to parse the response and extract the required Ra/Dec Motion rates for a specified time
d) Create target /frame field to signal the use of Lock Shift guiding for comet / other targets
e) embedding calls to set_lock_shift_params and set_lock_shift_enabled within the ImageTargetT_QSO routine

2019-10-06

The Minor Planet Centers' Ephemerides Service ( https://cgi.minorplanetcenter.net/iau/MPEph/MPEph.html  ) appears to only accept manual form based data entry  and it is seems too difficult to find a way of sending batch commands to the Form Action CGI  (https://cgi.minorplanetcenter.net/cgi-bin/mpeph2.cgi) in a way that would work. 

The JPL Solar System Dynamics provides accesss to JPL's HORIZONS system which can be used to generate ephemerides for solar-system bodies  (https://ssd.jpl.nasa.gov/?horizons).  This includes a web based batch mode interface to the system . This is accessed at https://ssd.jpl.nasa.gov/horizons_batch.cgi 

User Manual at https://ssd.jpl.nasa.gov/?horizons_doc

The example batch command given at this site is following.

https://ssd.jpl.nasa.gov/horizons_batch.cgi?batch=1&COMMAND='499'&MAKE_EPHEM='YES'&TABLE_TYPE='OBSERVER'&START_TIME='2000-01-01'&
STOP_TIME='2000-12-31'&STEP_SIZE='15%20d'&QUANTITIES='1,9,20,23,24'&CSV_FORMAT='YES'

The command https://ssd.jpl.nasa.gov/horizons_batch.cgi?batch=1&COMMAND='C/2018%20W2'&MAKE_EPHEM='YES'&TABLE_TYPE='OBSERVER'&START_TIME='2019-10-04'&
STOP_TIME='2019-10-05'&STEP_SIZE='1%20h'&QUANTITIES='1,3,9'&CSV_FORMAT='YES'

produced the following data for

**************************************************************************************************
 Date__(UT)__HR:MN, , ,R.A._(ICRF/J2000.0), DEC_(ICRF/J2000.0), dRA*cosD,d(DEC)/dt,  T-mag, N-mag,
**************************************************************************************************
 2019-Oct-04 20:00, , ,23 04 13.03,-07 17 46.7, -219.869, -381.135,  10.88, 13.32,
 2019-Oct-04 21:00, , ,23 03 58.26,-07 24 07.3, -219.381, -380.242,  10.88, 13.33,
 2019-Oct-04 22:00, , ,23 03 43.51,-07 30 26.9, -218.893, -379.347,  10.89, 13.33,
 2019-Oct-04 23:00, , ,23 03 28.80,-07 36 45.7, -218.404, -378.450,  10.89, 13.34,
 2019-Oct-05 00:00, , ,23 03 14.11,-07 43 03.6, -217.916, -377.553,  10.89, 13.34,

alternate run with slightly differ 

  2019-Oct-04 20:00  m  23 04 13.39 -07 18 00.1 -222.074  -381.312  10.88  13.32
 2019-Oct-04 21:00  m  23 03 58.46 -07 24 20.8 -221.879  -380.344  10.88  13.33
 2019-Oct-04 22:00     23 03 43.54 -07 30 40.5 -221.511  -379.364  10.89  13.33
 2019-Oct-04 23:00     23 03 28.65 -07 36 59.3 -220.961  -378.378  10.89  13.34
 2019-Oct-05 00:00     23 03 13.80 -07 43 17.0 -220.235  -377.392  10.89  13.34

The Ra/Dec motions produced from Horizons system using the "Rates; RA & DEC" option (3)   (-218.893, -379.347 (Earth Centre) and -221.511  -379.364 (Greenwich 000 )  differ from the ones produced from the Minor Planet Centre using the "Separate R.A. and Decl. coordinate motions" option & Greenwich 000 (-223.58  -379.22) , but are similar to the ones produced from the Minor Planet Centre when using the Separate R.A. and Decl. sky motions option & Greenwich (-221.66  -379.22 ) 

2019-10-07

After having some problems getting the Batch Interface to accept Site Coordinates I had some help from the JPL webmaster and included
CENTER=COORD  and COORD_TYPE=GEODETIC included in the command string .

https://ssd.jpl.nasa.gov/horizons_batch.cgi?batch=1&COMMAND='C/2018%20W2'&MAKE_EPHEM='YES'&TABLE_TYPE='OBSERVER'&CENTER=COORD&
COORD_TYPE=GEODETIC&SITE_COORD='-2.20000,+57.20000,0'&START_TIME='2019-10-04'&
STOP_TIME='2019-10-05'&STEP_SIZE='1%20h'&QUANTITIES='1,3,9'&CSV_FORMAT='YES'

More details about the email /  batch interface commands at ftp://ssd.jpl.nasa.gov/pub/ssd/horizons_batch_example.long

I've notice however that RA/Dec rates can also be obtained directly from the TheSky6.  At 2019-10-04 22:00 UT the motion rates for C/2018 W2 (Africano) obtained from TheSky6 are Ra -0.0614 arc sec/sec, Dec -0.1054 arc sec/sec. These are equivalent to -221.04, -379.44 arc sec/hr which are comparable with the values from Minor Planet Center & JPL Horizons.

The revsed forward plan is simplified to

a) create routine to get RA/Dec motion rates from TheSky6 and multiple by 3600 to get rates in arc sec/hr.
b) Create target /frame field to signal the use of Lock Shift guiding for comet / other targets
c) embedding calls to set_lock_shift_params and set_lock_shift_enabled within the ImageTargetT_QSO routine

The RA / Dec motion rates can be obtained from reading
  ObjectInformation.Property (skObjInfoProp_RA_RATE_ASPERSEC (=77) ),     and
  ObjectInformation.Property (skObjInfoProp_DEC_RATE_ASPERSEC (=78) )

 

Potential issues
At some point whilst guiding with Lock Shift Enabled the guide star will begin to approach the edge of the guiding FOV, at which the guiding will become unreliable.
Ideally one would choose a guide star that would stay in the FOV for as long as possible. Unfortunately but one doesn't have a choice on the most suitable star when auto-select star is used, which is the normal (only) method when using fully automated (unmanned) operations.  The best option would probably be to have the AutoGuiding Manager to monitor the proximity of the guide star to the edge of the FOV (if possible) and once it is close to the edge and 'no longer acceptable to auto-selection' to then pause guiding,quickly auto-select another star and guide on it. Ideally the switch over could be made to happen between frames without overly affecting the comet tracking.