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


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

Join main@ap-gto.groups.io to automatically receive all group messages.