Tracking ISS with Horizons #APCC #Mach2GTO


David Johnson
 

Okay, I'm trying to use A-P's Horizons to track the ISS, and I have a couple of questions.  I was able to get the ephemeris data from JPL and load it into A-P's Horizons.  So I have data loaded in there at 1 minute intervals.

I tried the Test Tracking, and my first question is about the following.  It appears that it does the test tracking using the data for the time period you select, but the mount does not use that time period for pointing purposes but the current time.  What I mean is, for example, if I try to track using the data on 3/16, starting at, say, 9:28 p.m., it says that the ISS is at a certain celestial coordinate in my sky at that time.  The mount goes to that coordinate, but, of course, that coordinate is not at the same place in the sky now as it will be on 3/16 at 9:28 p.m., so the altitude and azimuth shown in the ephemeris data will not be where the telescope points now.  I noticed this because I naturally started trying to track as the ISS was coming up over the horizon and therefore the first altitude shown was something like 1.7 (degrees, I assume), but the telescope was obviously not pointing that low, and, indeed, APCC says that it was not that low.  If this is how Horizons works when doing Test Tracking, that's fine, but I just wanted to make sure I wasn't doing something wrong.

The second question is on the tracking itself.  I noticed that the mount was not able to keep up with the tracking when the apparent movement of the ISS became relatively fast, even though watching it, it was obvious the tracking was well within the slewing speed of the Mach2 on 24V, which is what I'm using.  The tracking appeared to fall well behind, as in 2H of RA for RA Delta and something equivalent (a few degrees) in Dec Delta.  Maybe this has something to do with the closed loop correction not being fast enough?  I also noticed that there is no check box for disabling the closed loop correction, as is shown in the APCC documentation.

Anyway, if I can't track the ISS with the Mach2, that's fine.  I just want to make sure it's not because I'm doing something wrong.  I have a real pass of the ISS coming over at 9:21 p.m. local time tonight, so I'm going to try "real tracking", albeit in my basement since it's raining outside.

Thanks.


Ray Gralak
 

Hi David,

1-minute intervals are not accurate enough.

You might try to do a 1-second interval. You can do this by specifying a start and end time and specifying an "equal interval (unitless)" step size. Then, specify a count that results in 1-second intervals. For example, if the range is one hour, the count to produce 1-second intervals would be 3600, because there are 3600 seconds in one hour.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of David Johnson
Sent: Monday, March 15, 2021 5:35 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] Tracking ISS with Horizons #APCC #Mach2GTO

Okay, I'm trying to use A-P's Horizons to track the ISS, and I have a couple of questions. I was able to get the
ephemeris data from JPL and load it into A-P's Horizons. So I have data loaded in there at 1 minute intervals.

I tried the Test Tracking, and my first question is about the following. It appears that it does the test tracking using
the data for the time period you select, but the mount does not use that time period for pointing purposes but the
current time. What I mean is, for example, if I try to track using the data on 3/16, starting at, say, 9:28 p.m., it says
that the ISS is at a certain celestial coordinate in my sky at that time. The mount goes to that coordinate, but, of
course, that coordinate is not at the same place in the sky now as it will be on 3/16 at 9:28 p.m., so the altitude and
azimuth shown in the ephemeris data will not be where the telescope points now. I noticed this because I naturally
started trying to track as the ISS was coming up over the horizon and therefore the first altitude shown was
something like 1.7 (degrees, I assume), but the telescope was obviously not pointing that low, and, indeed, APCC
says that it was not that low. If this is how Horizons works when doing Test Tracking, that's fine, but I just wanted
to make sure I wasn't doing something wrong.

The second question is on the tracking itself. I noticed that the mount was not able to keep up with the tracking
when the apparent movement of the ISS became relatively fast, even though watching it, it was obvious the tracking
was well within the slewing speed of the Mach2 on 24V, which is what I'm using. The tracking appeared to fall well
behind, as in 2H of RA for RA Delta and something equivalent (a few degrees) in Dec Delta. Maybe this has
something to do with the closed loop correction not being fast enough? I also noticed that there is no check box for
disabling the closed loop correction, as is shown in the APCC documentation.

Anyway, if I can't track the ISS with the Mach2, that's fine. I just want to make sure it's not because I'm doing
something wrong. I have a real pass of the ISS coming over at 9:21 p.m. local time tonight, so I'm going to try "real
tracking", albeit in my basement since it's raining outside.

Thanks.


David Johnson
 

Thanks for the info.  Here's what I tried next.  I did as you suggested and was able to get 1 hour's worth of data at 1-sec intervals, bounding the time where the ISS would be above the horizon here.  I then reset my computer's clock to be very close to the time of the data that I'm using for test tracking, so the telescope would be pointing roughly where it should be.  I also verified that the mount time was also set to this time.  The initial pointing this time was fine.

What happened was that I still had problems with RA keeping up.  The RA custom rate started out okay, and the RA Delta was okay, but RA started slowing down quickly and even dropped below sidereal rate.  Naturally, the RA Delta went way up.  It was pushing 2h when I stopped. Certainly, the tracking should have been well within the Mach2's slewing capability.  I tried it a couple of times, and the same thing happened.


David Johnson
 

Here’s what happens.  You may even be able to hear the mount slow down in the background.


Ray Gralak
 

Hi David,

I would need to see the APCC and AP V2 driver logs to see what happened. One possibility is that the computer could not send commands fast enough, but I don't know why any of the rates would go below sidereal unless a limit was hit.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of David Johnson
Sent: Tuesday, March 16, 2021 7:27 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Tracking ISS with Horizons #APCC #Mach2GTO

Thanks for the info. Here's what I tried next. I did as you suggested and was able to get 1 hour's worth of data at
1-sec intervals, bounding the time where the ISS would be above the horizon here. I then reset my computer's
clock to be very close to the time of the data that I'm using for test tracking, so the telescope would be pointing
roughly where it should be. I also verified that the mount time was also set to this time. The initial pointing this time
was fine.

What happened was that I still had problems with RA keeping up. The RA custom rate started out okay, and the RA
Delta was okay, but RA started slowing down quickly and even dropped below sidereal rate. Naturally, the RA Delta
went way up. It was pushing 2h when I stopped. Certainly, the tracking should have been well within the Mach2's
slewing capability. I tried it a couple of times, and the same thing happened.


David Johnson
 

Is this what you need?  I can see that changing the system clock could make debugging more confusing.  I can try it in "real time" one of these nights when the ISS makes a pass.  Thanks.


Ray Gralak
 

David,

 

If you attached a large file, it probably was stripped. To get the logs, please use the APCC log zipper utility (not the AP V2 Log zipper) and include all APCC and AP V2 Logs for the last day.

 

If you would tell me the approximate time you observed the Mach2 slowdown that would help narrow down where to look in the log files.

 

Lastly, because of the size of the zipped file, you should provide a link to the zip file through a service like dropbox, google, or one-drive.

 

-Ray

 

From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of David Johnson
Sent: Tuesday, March 16, 2021 8:37 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Tracking ISS with Horizons #APCC #Mach2GTO

 

Is this what you need?  I can see that changing the system clock could make debugging more confusing.  I can try it in "real time" one of these nights when the ISS makes a pass.  Thanks.


David Johnson
 

Okay, I’ve been playing around with this, both using the Test Tracking and in real-time, albeit in my basement due to the clouds, and I am learning how this works, but I do have one relatively simple question.  

Tonight I did a run in real-time and also using Test Tracking.  The numbers in Test Tracking puzzle me..  The first image shows the screen during the real-time run.  Note the values for RA and Dec rates, in arc-sec/sec and arc-sec/hour.  Both rates show as roughly comparable for both units (arc-sec/sec and arc-sec/hr).



Now, look at the second image.  The values in arc-sec/hr are roughly the same, but the values in arc-sec/sec are more than an order of magnitude different.  Am I missing something here?



Thanks.


Brent Boshart
 

It appears the first screen displays RA rate in arcsec/sec but the second screen displays the RA rate in sec/sec?  Since there is 15 degrees in 1 hr RA to convert sec/sec to arcsec/ hr would be 11.06992 x 15 x 60 x 60 = 597775.   I cannot explain why it does that but that is what appears to be happening?


David Johnson
 

Just to be clear, the first image was during real-time using the regular tracking, the second was using Test Tracking.


Ray Gralak
 

Now, look at the second image. The values in arc-sec/hr are roughly the same,
but the values in arc-sec/sec are
more than an order of magnitude different. Am I missing something here?
It could be a typo in the units. Remember that one RA sec/sec is 15 arc-sec/sec. I'll fix that in the next build, but it should not affect the tracking.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of David Johnson
Sent: Wednesday, March 17, 2021 6:48 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Tracking ISS with Horizons #APCC #Mach2GTO

Okay, I’ve been playing around with this, both using the Test Tracking and in real-time, albeit in my basement due
to the clouds, and I am learning how this works, but I do have one relatively simple question.

Tonight I did a run in real-time and also using Test Tracking. The numbers in Test Tracking puzzle me.. The first
image shows the screen during the real-time run. Note the values for RA and Dec rates, in arc-sec/sec and arc-
sec/hour. Both rates show as roughly comparable for both units (arc-sec/sec and arc-sec/hr).



Now, look at the second image. The values in arc-sec/hr are roughly the same, but the values in arc-sec/sec are
more than an order of magnitude different. Am I missing something here?



Thanks.