Orbital Tracking error - RA motion is in the wrong direction

[Craig Anderson]

Hello,

I'm having problem where ACP is disabling orbital tracking in between subs in the midst of an imaging plan. The log I'm looking at now shows this happening when the filter changes from Red to Green. I believe I've also seen this happen when there is a refocus between plan observations with no filter change. Here's an example from a log captured last night where orbital tracking disabled at 5:33:49 (below). Note that there were three observations in the imaging plan, one each for Red, Green, and Blue. The plan shows orbital tracking on via the check box as seen in the schedule browser. When captured, Red had orbital tracking on, Green and Blue did not.

Any ideas on how I can resolve this? Mount is an AP1600 AE with GTOCP4.

Thanks!

-Craig

05:27:08 Imaging to CT C-2019 Y4-S001-Red-R005-300-2-20200324-052708
05:27:08 (taking 300 sec. exposure, Red filter, binning = 2)
05:27:08 (using 1 MHz (RBI Flood) readout mode)
05:27:08 (starting [RBI] + exposure)
05:33:09 (exposure complete)
05:33:28 (exposure complete and image downloaded)
05:33:28 Calibrating image...
05:33:30 Image finished
05:33:47 Plate-solve CT C-2019 Y4-S001-Red-R005-300-2-20200324-052708 final image.
05:33:47 1078 image stars found
05:33:48 553 catalog stars found
05:33:49 Solved! 197 stars matched.
05:33:49 Average residual is 0.42 arcsec.
05:33:49 Pointing error is 1.046 arcmin @ angle 72.03
05:33:49 True focal length is 2585.3 mm.
05:33:49 True binned plate scales (arcsec/pix): H = 1.43 V = 1.43
05:33:49 True image center (J2000): 08h 52m 41.6s 68� 07' 18.30"
05:33:49 Imager sky position angle is 179.1 deg.
05:33:49 Image FWHM is 4.6 arcsec (3.21 pixels)
05:33:49 (avg FWHM = 5.13 arcsec)
05:33:49 [flip check: Tn=0s HAc=5216s GW=T HAz=5219s DWz=T WF=no]
05:33:49 Re-slew to target.
05:33:49 (stop orbital tracking)
05:33:49 Start slew to CT C/2019 Y4...
05:33:50 (wait for slew to complete)
05:33:54 (slew complete)
05:33:55 [flip check: Tn=-300s HAc=5221s GW=T HAz=4925s DWz=T WF=no]
05:33:55 Imaging to CT C-2019 Y4-S001-Green-R001-300-2-20200324-053355
05:33:55 Switching from Red to Green filter for imaging
05:33:55 Focus change of -4 steps required
05:34:06 (taking 300 sec. exposure, Green filter, binning = 2)
05:34:06 (using 1 MHz (RBI Flood) readout mode)
05:34:06 (starting [RBI] + exposure)
05:40:06 (exposure complete)
05:40:30 (exposure complete and image downloaded)
05:40:30 Calibrating image...
05:40:33 Image finished

[Bob Denny]

I figured that comet ATLAS would reveal some other issues :-) :-) I'll look at this tomorrow.

[Bob Denny]

Please post the entire log. There is a lot I can tell from the startup and elsewhere. You can attach the log <- link to attaching instructions

[Craig Anderson]

Hi Bob,

Sorry for the delayed reply, but I've been doing more tests to try to narrow the orbital tracking issue I'm having down to the simplest possible case. Attached is a log from my run tonight with that test. You'll see that orbital tracking was initially enabled, for the first subframe, then disabled before the second subframe. A second mystery, equally important to me, is why I'm getting really poor tracking on C/2019 Y4 when orbital tracking is enabled. Basically the comet trails like crazy in a 600s sub. If I repeat that tracking test using APCC w/ Horizons, my scope tracks perfectly on the comet. So I wonder if there's something amiss somewhere between ACP, the AP V2 driver, and APCC. I'm on ACP and Scheduler 8.3, AP V2 v5.30.09, and APCC Pro v1.8.0.9. My mount is an AP1600 w/ encoders. Computer is Win7 64b Pro. I've updated MPCCOMET and verified that there are new orbital elements that get loaded.

If there are additional tests I can run to help narrow this down, please let me know.

Thanks!

-Craig

[Bob Denny]

Did APCC by chance log the velocity offsets? If so It might help. I need to double check my computations first. Also on the sequencing, can you please attach the ACP observing plan that you made for the multiple images? That info will allow me to possibly reproduce the problem.

[Craig Anderson]

Hi Bob, I've attached screen shots from APCC showing tracking offsets from last night- one with Horizons driving, which tracked perfectly, and the other with ACP driving, which trailed badly (on the comet). The filenames indicate which is which. I hope this helps!

Thanks,

-Craig

[Craig Anderson]

Additional info...attached is a screen shot of the AP V2 driver tonight on C/2019 Y4. APCC showed basically the same offsets as the picture of APCC I uploaded from last night. See the attached for what the AP V2 driver reported as coming from ACP.

Here is the RightAscensionRate sent from ACP to AP V2 via ASCOM as recorded in the AP V2 log for this run. It looks like the rate ACP sent to the AP V2 driver matches what the AP V2 driver displayed.

(from AP V2 log when orbital tracking was enabled on C/2-19 Y4) 047430 2020-03-30 20:07:47.385: ASCOM: Info : SET RightAscensionRate = -5.05685210903747E-03

The comet was badly trailed during a 600s exposure. That part seems very consistent unless I switch to Horizons to drive APCC then it tracks the comet perfectly, so I don't think it's the mount or alignment.

-Craig

[Craig Anderson]

Sorry for yet another update, but I think I may be on to something after more testing tonight. Could it be as simples as a sign error in the RA rate offset? Check out these two screen shots of the orbital tracking offsets for C/2019 Y4 I grabbed tonight. One is using ACP to do the orbital tracking. The other is using Horizons. ACP gave me a badly trailed comet. Horizons tracked the comet perfectly. Aside from some small differences in the offset absolute values, the sign on the RA offset is different between the two! Could it be as simple as a sign error in the number ACP sends to the AP V2 driver?

-Craig

[Dick Berg]

Hi Craig,

This is interesting.

I tabulated the coordinates of C/2019 Y4 at 24-hour intervals from today forward one day and backwards two days. The right ascension is decreasing (moving westward) at a rate (24-hour average) of about -0.00506 seconds per second. This is what your lefthand picture shows (that's ACP?)

That means the telescope drive rate has to move a bit faster than the sidereal rate in order to catch up to the comet that's moving westward. If those "Cust RA:" numbers are rate changes to apply directly to the sidereal drive, then the one on the left would be slowing the sidereal rate, and there is a sign error as you suspect. Unless in your telescope driver the rate change is subtracted from the sidereal rate.

Here's the table:
Now -2 RA 8:11:53 = 29513 seconds
Now -1 RA 8:04:31 = 29071 seconds
Now-- RA 7:57:13 = 28633 seconds
Now+1 RA 7:50:00 = 28200 seconds

The declination is also decreasing, so the sign for the Cust DEC: is correct.

[Craig Anderson]

Dick, I think you've found the issue! Your analysis leads me to believe that ACP is sending the correction in RA to AP V2 with the "wrong" sign. I say wrong in quotes because one could argue that the error is on either side, ACP or AP V2. But, I wonder, if ACP flipped the sign on the RA correction for orbital tracking, would the comet trails others have reported also be corrected? If there's such a thing as a beta fix that I could test, I'm available to install and test it. I'd sure like to use ACP on comets without those trails.

-Craig