1. Topics
  2. Custom Tracking Rate woes

Custom Tracking Rate woes

Ray Gralak
 

The calculation looks correct, but just to set your expectations, this does not guarantee accurate tracking of your target. You will need a sky model to do that (APCC Pro).

-Ray
wbelhaven
 

Thanks, that helps. The Custom RA rate is 1/3600'th of an hour of Right Ascension per Sidereal second (as an offset to the 'normal' Sidereal tracking rate), and not 1/3600th of a degree of Right Ascension per Sidereal second.

So, if an object has RA1 (in hrs) at time T1 (in seconds), and moves to RA2 (in hrs) at time T2 (in seconds), then the rate I should enter is:

Cust RA = (RA2 - RA1) hr × (3600.0 sec / hr) × (0.9972695677 sec / Sidereal second) / (T2 - T1) sec = xxxx sec / Sidereal second

Right?
Ray Gralak
 

@Ray: I've read the help guide and the link, but I still don't understand what the "seconds" (numerator) refers to:
I assume you mean right ascension "seconds"? That's the distance in RA a star would travel in a sidereal second. A sidereal second is 1/(24*60*60) of a sidereal day, which is about 23 hours and 56 minutes.

You can see that if you enter a 1.000 in both RA and Dec that the RA and Dec coordinates update about 1 unit per second. This makes a Dec=1.000 about 1/15x of the RA=1.000 rate, as per the ASCOM specification.

One reason an application may not work is that the Dec direction is not defined in ASCOM, so what one mount manufacturer defines as a positive Dec move might be a negative Dec move for another manufacturer. Thus, an application may need to discover the Dec direction if not pre-configured with the correct Dec directions for a particular mount (btw, the Dec direction can change sign after a German equatorial mount pier flips).

-Ray
Brian Valente
 

>>> the whole point of setting a shift rate in the mount itself is to accomplish the opposite (less corrections by the guiding system). The way it is working now is substantially worse than leaving the mount at Sidereal.

yes, more specifically the whole idea is to set the shift rate of both the mount and PHD so they work in tandem together rather than fighting each other. I'm really surprised that your results, i've found the opposite is true for me and it works as expected (non-AP mount). A possibility there could be differences in settings in NINA when Orbitals retrieves values/sets rates. I don't know for sure

On Tue, Aug 9, 2022 at 2:50 PM wbelhaven via groups.io <wbelhaven=yahoo.com@groups.io> wrote:
Thanks all ...

@Ray: I've read the help guide and the link, but I still don't understand what the "seconds" (numerator) refers to: in one possible interpretation it's 15x the value of another possible interpretation. Can you please show me the answer for that hypothetical example I stated?  That will resolve all ambiguity for me. Sorry if I'm being dense.  I'm guessing the answer is 1.0 × 0.9972695677 and not 15 × 0.9972695677 but I'm not positive about that.

@Brian: Yes, I've experimented with Orbitals, but the numbers it's populating into the ASCOM panel and therefore into the mount are not consistent with the comet's actual apparent movement. (I'm polar aligned to within a few arc-seconds of the pole according to SharpCap.) Conversely, the numbers it's sending to PHD2 for guiding seem pretty close to the "right" answer. But if I let it populate only the AP ASCOM panel/mount, and turn off guiding, the comet "drifts" in the camera field substantially, so much so that when enabling guiding, PHD2 has to work very hard to keep the guide star "shifting at the right rate", whereas (I think) the whole point of setting a shift rate in the mount itself is to accomplish the opposite (less corrections by the guiding system). The way it is working now is substantially worse than leaving the mount at Sidereal.

This is why I'm trying to understand precisely what the AP ASCOM panel is expecting and how that number is being interpreted.

@Todd: Interesting, thanks for the tip.



--

wbelhaven
 

Thanks all ...

@Ray: I've read the help guide and the link, but I still don't understand what the "seconds" (numerator) refers to: in one possible interpretation it's 15x the value of another possible interpretation. Can you please show me the answer for that hypothetical example I stated?  That will resolve all ambiguity for me. Sorry if I'm being dense.  I'm guessing the answer is 1.0 × 0.9972695677 and not 15 × 0.9972695677 but I'm not positive about that.

@Brian: Yes, I've experimented with Orbitals, but the numbers it's populating into the ASCOM panel and therefore into the mount are not consistent with the comet's actual apparent movement. (I'm polar aligned to within a few arc-seconds of the pole according to SharpCap.) Conversely, the numbers it's sending to PHD2 for guiding seem pretty close to the "right" answer. But if I let it populate only the AP ASCOM panel/mount, and turn off guiding, the comet "drifts" in the camera field substantially, so much so that when enabling guiding, PHD2 has to work very hard to keep the guide star "shifting at the right rate", whereas (I think) the whole point of setting a shift rate in the mount itself is to accomplish the opposite (less corrections by the guiding system). The way it is working now is substantially worse than leaving the mount at Sidereal.

This is why I'm trying to understand precisely what the AP ASCOM panel is expecting and how that number is being interpreted.

@Todd: Interesting, thanks for the tip.
midmoastro
 

I also use Horizons for tracking comets. It works great!
Todd
Brian Valente
 

WB

You could also try NINA's Orbitals plug-in to program your mount for custom tracking rate on a specific comet, I assume you will see the resulting values in the AP UI



On Mon, Aug 8, 2022 at 10:21 PM wbelhaven via groups.io <wbelhaven=yahoo.com@groups.io> wrote:

Hi, can someone please confirm the units of the Cust RA and Cust DEC rates in the AP v2 ASCOM Driver? I've read the help file but can't seem to make the mount move in the way I'm expecting it to move based upon the values I type into the panel.

Let's do this by way of example. Imagine a comet at RA = 12:00:00 (hours), DEC = +60 00 00 (degrees) moves to RA = 12:00:01, DEC = +60 00 01 exactly one second later.

Is the RA rate to type into the panel: (a) 1.0000, (b) 1 x 15 = 15.0000, or (c) 1 x 15 x cos(60) = 7.5000?

I'm pretty sure the DEC rate for this example would be 1.0000, but please confirm.

Thanks,
WB



--

Ray Gralak
 

Hi WB,

Hi, can someone please confirm the units of the Cust RA and Cust DEC rates in the AP v2 ASCOM Driver? I've
read the help file but can't seem to make the mount move in the way I'm expecting it to move based upon the
values I type into the panel.
The units are defined by ASCOM and also defined in the help file. They

The right ascension tracking rate offset is relative to the sidereal rate, in seconds per sidereal second. There is no compensation for declination, so the apparent tracking rate will appear slower at declinations other than zero.

https://ascom-standards.org/Help/Platform/html/P_ASCOM_DeviceInterface_ITelescopeV3_RightAscensionRate.htm

The declination tracking rate is in arcseconds per SI (atomic) second.

https://ascom-standards.org/Help/Platform/html/P_ASCOM_DeviceInterface_ITelescopeV3_DeclinationRate.htm

-Ray
wbelhaven
 

Hi, can someone please confirm the units of the Cust RA and Cust DEC rates in the AP v2 ASCOM Driver? I've read the help file but can't seem to make the mount move in the way I'm expecting it to move based upon the values I type into the panel.

Let's do this by way of example. Imagine a comet at RA = 12:00:00 (hours), DEC = +60 00 00 (degrees) moves to RA = 12:00:01, DEC = +60 00 01 exactly one second later.

Is the RA rate to type into the panel: (a) 1.0000, (b) 1 x 15 = 15.0000, or (c) 1 x 15 x cos(60) = 7.5000?

I'm pretty sure the DEC rate for this example would be 1.0000, but please confirm.

Thanks,
WB
1 - 9 of 9