Question: ROLAND’S GTO QUICK STAR DRIFT METHOD - 2020 VERSION


John Upton
 

Hi,

   I have a question about Roland's Quick Star Drift Alignment Method as documented in the Mack2 User manual. (Appendix C on Page 41.) I tried it out the other night and all seemed to go pretty well. The Azimuth Alignment step went perfectly and was easy to perform. I did use a shortcut of sorts by simply doing a Plate Solve and Recal just West of the Zenith before slewing to a star in the south just West of the meridian.

   My main question is whether (or how much) this method depends on having previously corrected for any Orthogonality / Cone Error of the OTA. I had quite a bit of East / West offset difference when I performed the second stage of the method to dial in the Altitude adjustment. I was surprised at how much I have to change the Altitude axis (nearly a full turn of the Altitude adjuster) to move the star N/S to get back to the crosshair. I had started by using the Park 5 / Level OTA initial adjustment before beginning this method.  Any idea why the Altitude had to change considerably after leveling in Park 5? (I  pretty much trust the Level since I have calibrated it carefully and get exactly the same repeatable reading when turning it 180° with less that 0.05° reading difference.)

   So, back the main question; does this method work equally well even in the presence of orthogonality error? I really like the method as it is very , very fast but wonder about the E/W star offsets I see when adjusting the altitude of the RA axis in the second half of the procedure.


John


John Upton
 

Hi, Again.

   I see a typo in my first post. The mount is a Mach2, of course, rather than a Mack2 -- although it seems as a stable and robust as a Mack truck.

   I have a related question about Orthogonality error. When you use the Orthogonality (Ortho Model) correction method in the KeyPad to correct for orthogonality, does this "stick" in the CP5 control box or KeyPad? (I cannot find where I read it but think the correction value is actually stored in the CP5 box. Right or wrong?)

   So, if I perform the KeyPad Ortho Model correction procedure, I understand that creating an APCC model will override it. However, on a subsequent night after having moved the mount, does the KeyPad's orthogonality correction apply once again if a new model is not created (since the old model will not be valid)? Or, do I need to rerun the Ortho Model procedure on the KeyPad again?

   If the KeyPad correction is always present, then it should help with the E/W offsets I see when performing the polar alignment method in the first post. (Or, I could be completely off base.)


John


Roland Christen
 

First question; Yes it works even with horrible orthogonality.

Any idea why the Altitude had to change considerably after leveling in Park 5?
This question is quite easy: The parks are governed by the time you have set in the keypad (or your laptop). If you are off by 1 hour, the parks will be off by 15 degrees in RA. For every second that you are off, your park positions will be off by 15 arc seconds.

This is also a way to check your exact local time - simply change the time in the keypad by a minute or so (or even a few seconds) and park again until your park position is exactly parallel to the earth. Presto, you have now synchronized your time to the stars.

Rolando


-----Original Message-----
From: John Upton <upton@...>
To: main@ap-gto.groups.io
Sent: Mon, Sep 13, 2021 3:22 pm
Subject: [ap-gto] Question: ROLAND’S GTO QUICK STAR DRIFT METHOD - 2020 VERSION

Hi,

   I have a question about Roland's Quick Star Drift Alignment Method as documented in the Mack2 User manual. (Appendix C on Page 41.) I tried it out the other night and all seemed to go pretty well. The Azimuth Alignment step went perfectly and was easy to perform. I did use a shortcut of sorts by simply doing a Plate Solve and Recal just West of the Zenith before slewing to a star in the south just West of the meridian.

   My main question is whether (or how much) this method depends on having previously corrected for any Orthogonality / Cone Error of the OTA. I had quite a bit of East / West offset difference when I performed the second stage of the method to dial in the Altitude adjustment. I was surprised at how much I have to change the Altitude axis (nearly a full turn of the Altitude adjuster) to move the star N/S to get back to the crosshair. I had started by using the Park 5 / Level OTA initial adjustment before beginning this method.  Any idea why the Altitude had to change considerably after leveling in Park 5? (I  pretty much trust the Level since I have calibrated it carefully and get exactly the same repeatable reading when turning it 180° with less that 0.05° reading difference.)

   So, back the main question; does this method work equally well even in the presence of orthogonality error? I really like the method as it is very , very fast but wonder about the E/W star offsets I see when adjusting the altitude of the RA axis in the second half of the procedure.


John

--
Roland Christen
Astro-Physics


John Upton
 

Roland,

   Thanks for the quick answer regarding orthogonality not affecting the polar alignment method.

On Mon, Sep 13, 2021 at 04:00 PM, Roland Christen wrote:
This question is quite easy: The parks are governed by the time you have set in the keypad (or your laptop). If you are off by 1 hour, the parks will be off by 15 degrees in RA. For every second that you are off, your park positions will be off by 15 arc seconds.
   This was a bit of a surprise to me but after thinking about it, I think I understand. It would have to work this way for non-encoder mounts to work correctly and there is no reason to rewrite the underlying code for encoder mounts. I had been in an encoder mindset and assumed incorrectly that the mount Parked based on encoder positions. I see the error in my thought process.

   To bump my question in the second post, do you or Ray have any clarifications regarding the interactions / interoperability of the Ortho Model performed by the KeyPad versus the pointing model created by APCC? The questions I want to understand are:

  1. I assume the APCC model takes precedence when a KeyPad Ortho Model has been built. Is that correct?
  2. Does the APCC model erase the results of the KeyPad Ortho Model or simply override it?
  3. If the APCC point corrections are turned off, does the most recent KeyPad Ortho Model once again take effect or does a new one need to be built?
   For some observing and simple single object imaging sessions, I think I would like to just have the orthogonality error corrected without creating / running a pointing model. Ideally, in that situation, I would prefer not to have to rerun the KeyPad Ortho Model at the beginning of each session when I don't want to run APPM.


John


Roland Christen
 


I had been in an encoder mindset and assumed incorrectly that the mount Parked based on encoder positions.
The 1100/1600 encoder mounts use the original park positions based on time. That's because the encoders are attached to the worm wheel, not the output shaft. There was no way to attach any encoders to the output shaft because there is no shaft on these mounts, just a "lazy Susan" that gets clamped to the worm wheel when the clutches are tightened.

On the other hand, for the Mach2 we decided to go with a separate shaft onto which the encoder is attached. This shaft rotates with the scope, rather than with the worm wheel, therefore you can unlock the clutches and move the scope manually and the encoders will follow that movement. This allowed us to use the encoders to determine the park positions rather than basing it on time. Therefore, on the Mach2, the parks are always in the same position, and we also have a home position that is encoder based and can be replicated to the arc sec level every time.

Rolando


-----Original Message-----
From: John Upton <upton@...>
To: main@ap-gto.groups.io
Sent: Mon, Sep 13, 2021 10:20 pm
Subject: Re: [ap-gto] Question: ROLAND’S GTO QUICK STAR DRIFT METHOD - 2020 VERSION

Roland,

   Thanks for the quick answer regarding orthogonality not affecting the polar alignment method.

On Mon, Sep 13, 2021 at 04:00 PM, Roland Christen wrote:
This question is quite easy: The parks are governed by the time you have set in the keypad (or your laptop). If you are off by 1 hour, the parks will be off by 15 degrees in RA. For every second that you are off, your park positions will be off by 15 arc seconds.
   This was a bit of a surprise to me but after thinking about it, I think I understand. It would have to work this way for non-encoder mounts to work correctly and there is no reason to rewrite the underlying code for encoder mounts. I had been in an encoder mindset and assumed incorrectly that the mount Parked based on encoder positions. I see the error in my thought process.

   To bump my question in the second post, do you or Ray have any clarifications regarding the interactions / interoperability of the Ortho Model performed by the KeyPad versus the pointing model created by APCC? The questions I want to understand are:

  1. I assume the APCC model takes precedence when a KeyPad Ortho Model has been built. Is that correct?
  2. Does the APCC model erase the results of the KeyPad Ortho Model or simply override it?
  3. If the APCC point corrections are turned off, does the most recent KeyPad Ortho Model once again take effect or does a new one need to be built?
   For some observing and simple single object imaging sessions, I think I would like to just have the orthogonality error corrected without creating / running a pointing model. Ideally, in that situation, I would prefer not to have to rerun the KeyPad Ortho Model at the beginning of each session when I don't want to run APPM.


John

--
Roland Christen
Astro-Physics


John Upton
 

Roland,

On Tue, Sep 14, 2021 at 11:41 AM, Roland Christen wrote:
On the other hand, for the Mach2 we decided to go with a separate shaft onto which the encoder is attached. This shaft rotates with the scope, rather than with the worm wheel, therefore you can unlock the clutches and move the scope manually and the encoders will follow that movement. This allowed us to use the encoders to determine the park positions rather than basing it on time. Therefore, on the Mach2, the parks are always in the same position, and we also have a home position that is encoder based and can be replicated to the arc sec level every time.
   OK, so the Mach2 is handled as an exception in the code compared to the other AP mounts. Park positions for the Mach2 are determined by the encoders as I originally thought.

   That brings me back to my original question:

   If I carefully level the Mount / OTA in Park 5 position, what factors will cause the Altitude adjustment portion of your improved 2020 polar alignment procedure to see largish errors in Altitude? I was seeing between about 40 and 50 arc-minutes error after having carefully leveling the OTA at Park 5. (The level I used was carefully calibrated and read the same value after turning it 180°. There was no +/- change in the two readings.)


John


Roland Christen
 


what factors will cause the Altitude adjustment portion of your improved 2020 polar alignment procedure to see largish errors in Altitude? I was seeing between about 40 and 50 arc-minutes error after having carefully leveling the OTA at Park 5.
Again, time. The altitude of any object in RA is determined by time. The altitude can also vary somewhat depending on how level the mount head is.

Rolando


-----Original Message-----
From: John Upton <upton@...>
To: main@ap-gto.groups.io
Sent: Tue, Sep 14, 2021 8:45 pm
Subject: Re: [ap-gto] Question: ROLAND’S GTO QUICK STAR DRIFT METHOD - 2020 VERSION

Roland,

On Tue, Sep 14, 2021 at 11:41 AM, Roland Christen wrote:
On the other hand, for the Mach2 we decided to go with a separate shaft onto which the encoder is attached. This shaft rotates with the scope, rather than with the worm wheel, therefore you can unlock the clutches and move the scope manually and the encoders will follow that movement. This allowed us to use the encoders to determine the park positions rather than basing it on time. Therefore, on the Mach2, the parks are always in the same position, and we also have a home position that is encoder based and can be replicated to the arc sec level every time.
   OK, so the Mach2 is handled as an exception in the code compared to the other AP mounts. Park positions for the Mach2 are determined by the encoders as I originally thought.

   That brings me back to my original question:

   If I carefully level the Mount / OTA in Park 5 position, what factors will cause the Altitude adjustment portion of your improved 2020 polar alignment procedure to see largish errors in Altitude? I was seeing between about 40 and 50 arc-minutes error after having carefully leveling the OTA at Park 5. (The level I used was carefully calibrated and read the same value after turning it 180°. There was no +/- change in the two readings.)


John

--
Roland Christen
Astro-Physics


John Upton
 

Roland,

On Tue, Sep 14, 2021 at 09:17 PM, Roland Christen wrote:
Again, time. The altitude of any object in RA is determined by time. The altitude can also vary somewhat depending on how level the mount head is.
   Ok, I think I finally get it. While the Park position is encoder based, the actual RA slew position depends on time. That might need an altitude adjustment to compensate. Thank you for your patience. 


John