|
As a new owner of an A-P GTO-AE mount with GTOCP4 and, as of a couple of days ago, a KEYVFK2 GTO keypad, I’m wondering how serious a need I might have for APCC and APPM. I’m not yet a serious imager, and the local sky brightness pretty well limits me to exposures of 180s or so on objects imaged without use of a narrowband filter. No question in my mind that APCC is something that I eventually will want to learn, but if I can ease into things first, I’d like to do that.
After reading the numerous informative recent posts on the subject of APCC, I’m thinking that for my present purposes, accurate polar alignment, Sky Safari, and the keypad with its own modeling feature might suffice until my imaging skills have improved, and I’m able to take the mount to dark-sky locations.
I’m curious, specifically, how precisely the Sky Safari app (laptop, iPad, or both) communicates with an A-P GTO-AE mount. My procedure is to pole-align with RAPAS, start with mount and Sky Safari at Park 3, GOTO a reference star, manually center the star in the eyepiece, and tell SS to ALIGN ON that star. My experiments show that if I use SS to GOTO an object in a distant part of the sky, it will put the scope within typically 0.5º or so of being centered on the target. Then, without doing an ALIGN ON that object, if I use SS to GOTO the star originally aligned on, it slews the mount to put the star dead-center (I haven’t tried this with a high-power EP, but I will tonight).
What I take from this is, first, that the inaccuracy of the original GOTO is likely due to imperfect PA and atmospheric refraction (another experiment for tonight: initially ALIGN ON and then GOTO not just random stars, but ones that are at the same elevation, to take refraction out of the equation), and second, that the spot-on return to the alignment star indicates accurate communication of either servo ticks or AE position to Sky Safari. Does anyone know?
Next, now that I have the keypad, does Sky Safari offer any additional functionality aside from the graphic presentation and the touch-and-GOTO capability?
Also, once I’ve constructed a pointing model with the keypad, if I use SS (assuming there’s a reason to do that), will the app’s GOTO command go through the pointing model, so to speak, and take advantage of its corrections?
I would appreciate any other advice or comments on use of SS, the keypad, or both without the use of APCC.
—howard
|
|
|
Hi Howard
>>>My procedure is to pole-align with RAPAS, start with mount and Sky Safari at Park 3, GOTO a reference star, manually center the star in the eyepiece, and tell SS to ALIGN ON that star. My experiments show that if I use SS to GOTO an object in a distant part of the sky, it will put the scope within typically 0.5º or so of being centered on the target. Then, without doing an ALIGN ON that object, if I use SS to GOTO the star originally aligned on, it slews the mount to put the star dead-center (I haven’t tried this with a high-power EP, but I will tonight).
Yes, that all sounds good to me
>>>What I take from this is, first, that the inaccuracy of the original GOTO is likely due to imperfect PA....
It's polar misalignment, but also a slightly imprecise position of your Park 3. Your procedure you outlined to start in park 3, goto, center, and then align corrects for all those things.
>>>now that I have the keypad, does Sky Safari offer any additional functionality aside from the graphic presentation and the touch-and-GOTO capability?
Sky Safari is really just a different way to visualize the sky. You can browse through lists of 'tonight's best objects', click on a the sky map and issue a goto, etc. From a telescope control standpoint, the keypad does many more things than SkySafari. I think of them as complementary. For example you can use SkySafari for your target browsing and goto, and then the keypad for centering/aligning, and also any advanced features (various park positions, additional dec arc modeling, etc.)
A planetarium program like SkySafari isn't required, but I personally find it enjoyable to use for visualizing the sky, finding targets organically, and then issuing gotos. >>>once I’ve constructed a pointing model with the keypad, if I use SS (assuming there’s a reason to do that), will the app’s GOTO command go through the pointing model, so to speak, and take advantage of its corrections?
Short answer is yes. SkySafari doesn't know anything about the pointing correction model, it only sends coordinates to the mount. The mount and control software calculate the correct position of the target.
Sounds like you have a pretty good handle on things, i think your workflow is a good starting point
As a new owner of an A-P GTO-AE mount with GTOCP4 and, as of a couple of days ago, a KEYVFK2 GTO keypad, I’m wondering how serious a need I might have for APCC and APPM. I’m not yet a serious imager, and the local sky brightness pretty well limits me to exposures of 180s or so on objects imaged without use of a narrowband filter. No question in my mind that APCC is something that I eventually will want to learn, but if I can ease into things first, I’d like to do that.
After reading the numerous informative recent posts on the subject of APCC, I’m thinking that for my present purposes, accurate polar alignment, Sky Safari, and the keypad with its own modeling feature might suffice until my imaging skills have improved, and I’m able to take the mount to dark-sky locations.
I’m curious, specifically, how precisely the Sky Safari app (laptop, iPad, or both) communicates with an A-P GTO-AE mount. My procedure is to pole-align with RAPAS, start with mount and Sky Safari at Park 3, GOTO a reference star, manually center the star in the eyepiece, and tell SS to ALIGN ON that star. My experiments show that if I use SS to GOTO an object in a distant part of the sky, it will put the scope within typically 0.5º or so of being centered on the target. Then, without doing an ALIGN ON that object, if I use SS to GOTO the star originally aligned on, it slews the mount to put the star dead-center (I haven’t tried this with a high-power EP, but I will tonight).
What I take from this is, first, that the inaccuracy of the original GOTO is likely due to imperfect PA and atmospheric refraction (another experiment for tonight: initially ALIGN ON and then GOTO not just random stars, but ones that are at the same elevation, to take refraction out of the equation), and second, that the spot-on return to the alignment star indicates accurate communication of either servo ticks or AE position to Sky Safari. Does anyone know?
Next, now that I have the keypad, does Sky Safari offer any additional functionality aside from the graphic presentation and the touch-and-GOTO capability?
Also, once I’ve constructed a pointing model with the keypad, if I use SS (assuming there’s a reason to do that), will the app’s GOTO command go through the pointing model, so to speak, and take advantage of its corrections?
I would appreciate any other advice or comments on use of SS, the keypad, or both without the use of APCC.
—howard
|
|
|
Thanks, Brian. That’s very encouraging and helpful.
I wondered why you discounted atmospheric refraction as a source of the pointing error I’d described, but then I looked at a graph of displacement vs. elevation. I hadn’t recalled that it’s so nonlinear – almost half a degree at the horizon, yes, but down all the way to 5' at 10º elevation, and 1', a Jupiter disk, at 45º.
First outing of the keypad tonight.
On Nov 2, 2022, at 4:01 PM, Brian Valente <bvalente@...> wrote:
Hi Howard
>>>My procedure is to pole-align with RAPAS, start with mount and Sky Safari at Park 3, GOTO a reference star, manually center the star in the eyepiece, and tell SS to ALIGN ON that star. My experiments show that if I use SS to GOTO an object in a distant part of the sky, it will put the scope within typically 0.5º or so of being centered on the target. Then, without doing an ALIGN ON that object, if I use SS to GOTO the star originally aligned on, it slews the mount to put the star dead-center (I haven’t tried this with a high-power EP, but I will tonight).
Yes, that all sounds good to me
>>>What I take from this is, first, that the inaccuracy of the original GOTO is likely due to imperfect PA....
It's polar misalignment, but also a slightly imprecise position of your Park 3. Your procedure you outlined to start in park 3, goto, center, and then align corrects for all those things.
>>>now that I have the keypad, does Sky Safari offer any additional functionality aside from the graphic presentation and the touch-and-GOTO capability?
Sky Safari is really just a different way to visualize the sky. You can browse through lists of 'tonight's best objects', click on a the sky map and issue a goto, etc. From a telescope control standpoint, the keypad does many more things than SkySafari. I think of them as complementary. For example you can use SkySafari for your target browsing and goto, and then the keypad for centering/aligning, and also any advanced features (various park positions, additional dec arc modeling, etc.)
A planetarium program like SkySafari isn't required, but I personally find it enjoyable to use for visualizing the sky, finding targets organically, and then issuing gotos. >>>once I’ve constructed a pointing model with the keypad, if I use SS (assuming there’s a reason to do that), will the app’s GOTO command go through the pointing model, so to speak, and take advantage of its corrections?
Short answer is yes. SkySafari doesn't know anything about the pointing correction model, it only sends coordinates to the mount. The mount and control software calculate the correct position of the target.
Sounds like you have a pretty good handle on things, i think your workflow is a good starting point As a new owner of an A-P GTO-AE mount with GTOCP4 and, as of a couple of days ago, a KEYVFK2 GTO keypad, I’m wondering how serious a need I might have for APCC and APPM. I’m not yet a serious imager, and the local sky brightness pretty well limits me to exposures of 180s or so on objects imaged without use of a narrowband filter. No question in my mind that APCC is something that I eventually will want to learn, but if I can ease into things first, I’d like to do that.
After reading the numerous informative recent posts on the subject of APCC, I’m thinking that for my present purposes, accurate polar alignment, Sky Safari, and the keypad with its own modeling feature might suffice until my imaging skills have improved, and I’m able to take the mount to dark-sky locations.
I’m curious, specifically, how precisely the Sky Safari app (laptop, iPad, or both) communicates with an A-P GTO-AE mount. My procedure is to pole-align with RAPAS, start with mount and Sky Safari at Park 3, GOTO a reference star, manually center the star in the eyepiece, and tell SS to ALIGN ON that star. My experiments show that if I use SS to GOTO an object in a distant part of the sky, it will put the scope within typically 0.5º or so of being centered on the target. Then, without doing an ALIGN ON that object, if I use SS to GOTO the star originally aligned on, it slews the mount to put the star dead-center (I haven’t tried this with a high-power EP, but I will tonight).
What I take from this is, first, that the inaccuracy of the original GOTO is likely due to imperfect PA and atmospheric refraction (another experiment for tonight: initially ALIGN ON and then GOTO not just random stars, but ones that are at the same elevation, to take refraction out of the equation), and second, that the spot-on return to the alignment star indicates accurate communication of either servo ticks or AE position to Sky Safari. Does anyone know?
Next, now that I have the keypad, does Sky Safari offer any additional functionality aside from the graphic presentation and the touch-and-GOTO capability?
Also, once I’ve constructed a pointing model with the keypad, if I use SS (assuming there’s a reason to do that), will the app’s GOTO command go through the pointing model, so to speak, and take advantage of its corrections?
I would appreciate any other advice or comments on use of SS, the keypad, or both without the use of APCC.
—howard
--
|
|
|
Hi Howard
sorry i didn't mean to exclude refraction. I wasn't discounting it. I have found the polar misalignment and Park 3 position offset to be more significant contributors, but yes refraction is a contributor as well
Thanks, Brian. That’s very encouraging and helpful.
I wondered why you discounted atmospheric refraction as a source of the pointing error I’d described, but then I looked at a graph of displacement vs. elevation. I hadn’t recalled that it’s so nonlinear – almost half a degree at the horizon, yes, but down all the way to 5' at 10º elevation, and 1', a Jupiter disk, at 45º.
First outing of the keypad tonight.
—howard
On Nov 2, 2022, at 4:01 PM, Brian Valente < bvalente@...> wrote:
Hi Howard
>>>My procedure is to pole-align with RAPAS, start with mount and Sky Safari at Park 3, GOTO a reference star, manually center the star in the eyepiece, and tell SS to ALIGN ON that star. My experiments show that if I use SS to GOTO an object in a distant part of the sky, it will put the scope within typically 0.5º or so of being centered on the target. Then, without doing an ALIGN ON that object, if I use SS to GOTO the star originally aligned on, it slews the mount to put the star dead-center (I haven’t tried this with a high-power EP, but I will tonight).
Yes, that all sounds good to me
>>>What I take from this is, first, that the inaccuracy of the original GOTO is likely due to imperfect PA....
It's polar misalignment, but also a slightly imprecise position of your Park 3. Your procedure you outlined to start in park 3, goto, center, and then align corrects for all those things.
>>>now that I have the keypad, does Sky Safari offer any additional functionality aside from the graphic presentation and the touch-and-GOTO capability?
Sky Safari is really just a different way to visualize the sky. You can browse through lists of 'tonight's best objects', click on a the sky map and issue a goto, etc. From a telescope control standpoint, the keypad does many more things than SkySafari. I think of them as complementary. For example you can use SkySafari for your target browsing and goto, and then the keypad for centering/aligning, and also any advanced features (various park positions, additional dec arc modeling, etc.)
A planetarium program like SkySafari isn't required, but I personally find it enjoyable to use for visualizing the sky, finding targets organically, and then issuing gotos. >>>once I’ve constructed a pointing model with the keypad, if I use SS (assuming there’s a reason to do that), will the app’s GOTO command go through the pointing model, so to speak, and take advantage of its corrections?
Short answer is yes. SkySafari doesn't know anything about the pointing correction model, it only sends coordinates to the mount. The mount and control software calculate the correct position of the target.
Sounds like you have a pretty good handle on things, i think your workflow is a good starting point As a new owner of an A-P GTO-AE mount with GTOCP4 and, as of a couple of days ago, a KEYVFK2 GTO keypad, I’m wondering how serious a need I might have for APCC and APPM. I’m not yet a serious imager, and the local sky brightness pretty well limits me to exposures of 180s or so on objects imaged without use of a narrowband filter. No question in my mind that APCC is something that I eventually will want to learn, but if I can ease into things first, I’d like to do that.
After reading the numerous informative recent posts on the subject of APCC, I’m thinking that for my present purposes, accurate polar alignment, Sky Safari, and the keypad with its own modeling feature might suffice until my imaging skills have improved, and I’m able to take the mount to dark-sky locations.
I’m curious, specifically, how precisely the Sky Safari app (laptop, iPad, or both) communicates with an A-P GTO-AE mount. My procedure is to pole-align with RAPAS, start with mount and Sky Safari at Park 3, GOTO a reference star, manually center the star in the eyepiece, and tell SS to ALIGN ON that star. My experiments show that if I use SS to GOTO an object in a distant part of the sky, it will put the scope within typically 0.5º or so of being centered on the target. Then, without doing an ALIGN ON that object, if I use SS to GOTO the star originally aligned on, it slews the mount to put the star dead-center (I haven’t tried this with a high-power EP, but I will tonight).
What I take from this is, first, that the inaccuracy of the original GOTO is likely due to imperfect PA and atmospheric refraction (another experiment for tonight: initially ALIGN ON and then GOTO not just random stars, but ones that are at the same elevation, to take refraction out of the equation), and second, that the spot-on return to the alignment star indicates accurate communication of either servo ticks or AE position to Sky Safari. Does anyone know?
Next, now that I have the keypad, does Sky Safari offer any additional functionality aside from the graphic presentation and the touch-and-GOTO capability?
Also, once I’ve constructed a pointing model with the keypad, if I use SS (assuming there’s a reason to do that), will the app’s GOTO command go through the pointing model, so to speak, and take advantage of its corrections?
I would appreciate any other advice or comments on use of SS, the keypad, or both without the use of APCC.
—howard
--
|
|
|
The Park 3 position error derives from the fact that there’s a clutch between the scope saddle and the encoder, correct? That is, between the worm gear and the part that carries the Dec top plate, the encoder being on the worm gear and the clutch between the worm gear and the top plate? The AE knows exactly how the worm gear is oriented but doesn’t know how the scope sits relative to the gear? After the first star alignment is done, the ambiguity is gone, and if the clutch is never released, any manual slewing done by releasing the worm, there’s no further park-position error?
I don’t release the clutches, so I shouldn’t be dealing with a park position error once SS has been through a star alignment, correct?
On Nov 2, 2022, at 5:05 PM, Brian Valente <bvalente@...> wrote:
Hi Howard
sorry i didn't mean to exclude refraction. I wasn't discounting it. I have found the polar misalignment and Park 3 position offset to be more significant contributors, but yes refraction is a contributor as well Thanks, Brian. That’s very encouraging and helpful.
I wondered why you discounted atmospheric refraction as a source of the pointing error I’d described, but then I looked at a graph of displacement vs. elevation. I hadn’t recalled that it’s so nonlinear – almost half a degree at the horizon, yes, but down all the way to 5' at 10º elevation, and 1', a Jupiter disk, at 45º.
First outing of the keypad tonight.
—howard
On Nov 2, 2022, at 4:01 PM, Brian Valente < bvalente@...> wrote:
Hi Howard
>>>My procedure is to pole-align with RAPAS, start with mount and Sky Safari at Park 3, GOTO a reference star, manually center the star in the eyepiece, and tell SS to ALIGN ON that star. My experiments show that if I use SS to GOTO an object in a distant part of the sky, it will put the scope within typically 0.5º or so of being centered on the target. Then, without doing an ALIGN ON that object, if I use SS to GOTO the star originally aligned on, it slews the mount to put the star dead-center (I haven’t tried this with a high-power EP, but I will tonight).
Yes, that all sounds good to me
>>>What I take from this is, first, that the inaccuracy of the original GOTO is likely due to imperfect PA....
It's polar misalignment, but also a slightly imprecise position of your Park 3. Your procedure you outlined to start in park 3, goto, center, and then align corrects for all those things.
>>>now that I have the keypad, does Sky Safari offer any additional functionality aside from the graphic presentation and the touch-and-GOTO capability?
Sky Safari is really just a different way to visualize the sky. You can browse through lists of 'tonight's best objects', click on a the sky map and issue a goto, etc. From a telescope control standpoint, the keypad does many more things than SkySafari. I think of them as complementary. For example you can use SkySafari for your target browsing and goto, and then the keypad for centering/aligning, and also any advanced features (various park positions, additional dec arc modeling, etc.)
A planetarium program like SkySafari isn't required, but I personally find it enjoyable to use for visualizing the sky, finding targets organically, and then issuing gotos. >>>once I’ve constructed a pointing model with the keypad, if I use SS (assuming there’s a reason to do that), will the app’s GOTO command go through the pointing model, so to speak, and take advantage of its corrections?
Short answer is yes. SkySafari doesn't know anything about the pointing correction model, it only sends coordinates to the mount. The mount and control software calculate the correct position of the target.
Sounds like you have a pretty good handle on things, i think your workflow is a good starting point As a new owner of an A-P GTO-AE mount with GTOCP4 and, as of a couple of days ago, a KEYVFK2 GTO keypad, I’m wondering how serious a need I might have for APCC and APPM. I’m not yet a serious imager, and the local sky brightness pretty well limits me to exposures of 180s or so on objects imaged without use of a narrowband filter. No question in my mind that APCC is something that I eventually will want to learn, but if I can ease into things first, I’d like to do that.
After reading the numerous informative recent posts on the subject of APCC, I’m thinking that for my present purposes, accurate polar alignment, Sky Safari, and the keypad with its own modeling feature might suffice until my imaging skills have improved, and I’m able to take the mount to dark-sky locations.
I’m curious, specifically, how precisely the Sky Safari app (laptop, iPad, or both) communicates with an A-P GTO-AE mount. My procedure is to pole-align with RAPAS, start with mount and Sky Safari at Park 3, GOTO a reference star, manually center the star in the eyepiece, and tell SS to ALIGN ON that star. My experiments show that if I use SS to GOTO an object in a distant part of the sky, it will put the scope within typically 0.5º or so of being centered on the target. Then, without doing an ALIGN ON that object, if I use SS to GOTO the star originally aligned on, it slews the mount to put the star dead-center (I haven’t tried this with a high-power EP, but I will tonight).
What I take from this is, first, that the inaccuracy of the original GOTO is likely due to imperfect PA and atmospheric refraction (another experiment for tonight: initially ALIGN ON and then GOTO not just random stars, but ones that are at the same elevation, to take refraction out of the equation), and second, that the spot-on return to the alignment star indicates accurate communication of either servo ticks or AE position to Sky Safari. Does anyone know?
Next, now that I have the keypad, does Sky Safari offer any additional functionality aside from the graphic presentation and the touch-and-GOTO capability?
Also, once I’ve constructed a pointing model with the keypad, if I use SS (assuming there’s a reason to do that), will the app’s GOTO command go through the pointing model, so to speak, and take advantage of its corrections?
I would appreciate any other advice or comments on use of SS, the keypad, or both without the use of APCC.
—howard
--
--
|
|
|
Hi Howard
Roughly yes, that's a good understanding
Provided you don't release the clutches and park at Park 3, when you restart the next night (again without releasing the clutches) your initial goto should eliminate any park offset
The Park 3 position error derives from the fact that there’s a clutch between the scope saddle and the encoder, correct? That is, between the worm gear and the part that carries the Dec top plate, the encoder being on the worm gear and the clutch between the worm gear and the top plate? The AE knows exactly how the worm gear is oriented but doesn’t know how the scope sits relative to the gear? After the first star alignment is done, the ambiguity is gone, and if the clutch is never released, any manual slewing done by releasing the worm, there’s no further park-position error?
I don’t release the clutches, so I shouldn’t be dealing with a park position error once SS has been through a star alignment, correct?
On Nov 2, 2022, at 5:05 PM, Brian Valente < bvalente@...> wrote:
Hi Howard
sorry i didn't mean to exclude refraction. I wasn't discounting it. I have found the polar misalignment and Park 3 position offset to be more significant contributors, but yes refraction is a contributor as well Thanks, Brian. That’s very encouraging and helpful.
I wondered why you discounted atmospheric refraction as a source of the pointing error I’d described, but then I looked at a graph of displacement vs. elevation. I hadn’t recalled that it’s so nonlinear – almost half a degree at the horizon, yes, but down all the way to 5' at 10º elevation, and 1', a Jupiter disk, at 45º.
First outing of the keypad tonight.
—howard
On Nov 2, 2022, at 4:01 PM, Brian Valente < bvalente@...> wrote:
Hi Howard
>>>My procedure is to pole-align with RAPAS, start with mount and Sky Safari at Park 3, GOTO a reference star, manually center the star in the eyepiece, and tell SS to ALIGN ON that star. My experiments show that if I use SS to GOTO an object in a distant part of the sky, it will put the scope within typically 0.5º or so of being centered on the target. Then, without doing an ALIGN ON that object, if I use SS to GOTO the star originally aligned on, it slews the mount to put the star dead-center (I haven’t tried this with a high-power EP, but I will tonight).
Yes, that all sounds good to me
>>>What I take from this is, first, that the inaccuracy of the original GOTO is likely due to imperfect PA....
It's polar misalignment, but also a slightly imprecise position of your Park 3. Your procedure you outlined to start in park 3, goto, center, and then align corrects for all those things.
>>>now that I have the keypad, does Sky Safari offer any additional functionality aside from the graphic presentation and the touch-and-GOTO capability?
Sky Safari is really just a different way to visualize the sky. You can browse through lists of 'tonight's best objects', click on a the sky map and issue a goto, etc. From a telescope control standpoint, the keypad does many more things than SkySafari. I think of them as complementary. For example you can use SkySafari for your target browsing and goto, and then the keypad for centering/aligning, and also any advanced features (various park positions, additional dec arc modeling, etc.)
A planetarium program like SkySafari isn't required, but I personally find it enjoyable to use for visualizing the sky, finding targets organically, and then issuing gotos. >>>once I’ve constructed a pointing model with the keypad, if I use SS (assuming there’s a reason to do that), will the app’s GOTO command go through the pointing model, so to speak, and take advantage of its corrections?
Short answer is yes. SkySafari doesn't know anything about the pointing correction model, it only sends coordinates to the mount. The mount and control software calculate the correct position of the target.
Sounds like you have a pretty good handle on things, i think your workflow is a good starting point As a new owner of an A-P GTO-AE mount with GTOCP4 and, as of a couple of days ago, a KEYVFK2 GTO keypad, I’m wondering how serious a need I might have for APCC and APPM. I’m not yet a serious imager, and the local sky brightness pretty well limits me to exposures of 180s or so on objects imaged without use of a narrowband filter. No question in my mind that APCC is something that I eventually will want to learn, but if I can ease into things first, I’d like to do that.
After reading the numerous informative recent posts on the subject of APCC, I’m thinking that for my present purposes, accurate polar alignment, Sky Safari, and the keypad with its own modeling feature might suffice until my imaging skills have improved, and I’m able to take the mount to dark-sky locations.
I’m curious, specifically, how precisely the Sky Safari app (laptop, iPad, or both) communicates with an A-P GTO-AE mount. My procedure is to pole-align with RAPAS, start with mount and Sky Safari at Park 3, GOTO a reference star, manually center the star in the eyepiece, and tell SS to ALIGN ON that star. My experiments show that if I use SS to GOTO an object in a distant part of the sky, it will put the scope within typically 0.5º or so of being centered on the target. Then, without doing an ALIGN ON that object, if I use SS to GOTO the star originally aligned on, it slews the mount to put the star dead-center (I haven’t tried this with a high-power EP, but I will tonight).
What I take from this is, first, that the inaccuracy of the original GOTO is likely due to imperfect PA and atmospheric refraction (another experiment for tonight: initially ALIGN ON and then GOTO not just random stars, but ones that are at the same elevation, to take refraction out of the equation), and second, that the spot-on return to the alignment star indicates accurate communication of either servo ticks or AE position to Sky Safari. Does anyone know?
Next, now that I have the keypad, does Sky Safari offer any additional functionality aside from the graphic presentation and the touch-and-GOTO capability?
Also, once I’ve constructed a pointing model with the keypad, if I use SS (assuming there’s a reason to do that), will the app’s GOTO command go through the pointing model, so to speak, and take advantage of its corrections?
I would appreciate any other advice or comments on use of SS, the keypad, or both without the use of APCC.
—howard
--
--
|
|
|
Hi Howard,
One tip on polar aligning that you might want to consider is PS Align Pro App. It corrects for atmospheric refraction based on your location. There are instructions on setting up the RAPAS, too. It’s important to first polar align using the drift method and then calibrate the RAPAS with the adjusting screws to the Align Pro App. I attached the instructions for your convenience. Overall, I think you are on the right path with your approach.
On Nov 2, 2022, at 9:42 AM, Howard Ritter via groups.io <howard.ritter@...> wrote:
As a new owner of an A-P GTO-AE mount with GTOCP4 and, as of a couple of days ago, a KEYVFK2 GTO keypad, I’m wondering how serious a need I might have for APCC and APPM. I’m not yet a serious imager, and the local sky brightness pretty well limits me to exposures of 180s or so on objects imaged without use of a narrowband filter. No question in my mind that APCC is something that I eventually will want to learn, but if I can ease into things first, I’d like to do that.
After reading the numerous informative recent posts on the subject of APCC, I’m thinking that for my present purposes, accurate polar alignment, Sky Safari, and the keypad with its own modeling feature might suffice until my imaging skills have improved, and I’m able to take the mount to dark-sky locations.
I’m curious, specifically, how precisely the Sky Safari app (laptop, iPad, or both) communicates with an A-P GTO-AE mount. My procedure is to pole-align with RAPAS, start with mount and Sky Safari at Park 3, GOTO a reference star, manually center the star in the eyepiece, and tell SS to ALIGN ON that star. My experiments show that if I use SS to GOTO an object in a distant part of the sky, it will put the scope within typically 0.5º or so of being centered on the target. Then, without doing an ALIGN ON that object, if I use SS to GOTO the star originally aligned on, it slews the mount to put the star dead-center (I haven’t tried this with a high-power EP, but I will tonight).
What I take from this is, first, that the inaccuracy of the original GOTO is likely due to imperfect PA and atmospheric refraction (another experiment for tonight: initially ALIGN ON and then GOTO not just random stars, but ones that are at the same elevation, to take refraction out of the equation), and second, that the spot-on return to the alignment star indicates accurate communication of either servo ticks or AE position to Sky Safari. Does anyone know?
Next, now that I have the keypad, does Sky Safari offer any additional functionality aside from the graphic presentation and the touch-and-GOTO capability?
Also, once I’ve constructed a pointing model with the keypad, if I use SS (assuming there’s a reason to do that), will the app’s GOTO command go through the pointing model, so to speak, and take advantage of its corrections?
I would appreciate any other advice or comments on use of SS, the keypad, or both without the use of APCC.
—howard
|
|
|
Thanks, Don. I already use PS Align Pro, just haven’t yet brought myself to devote sky time to a drift alignment and RAPAS calibration. But I didn’t know about the Apple Watch version of the app, It’ll be worth $5 just not to have to occupy one hand wrangling the iPhone or iPad while aligning!
On Nov 2, 2022, at 6:03 PM, Donald Rudny <mkea13800@...> wrote:
Hi Howard,
One tip on polar aligning that you might want to consider is PS Align Pro App. It corrects for atmospheric refraction based on your location. There are instructions on setting up the RAPAS, too. It’s important to first polar align using the drift method and then calibrate the RAPAS with the adjusting screws to the Align Pro App. I attached the instructions for your convenience. Overall, I think you are on the right path with your approach.
On Nov 2, 2022, at 9:42 AM, Howard Ritter via groups.io <howard.ritter@...> wrote:
As a new owner of an A-P GTO-AE mount with GTOCP4 and, as of a couple of days ago, a KEYVFK2 GTO keypad, I’m wondering how serious a need I might have for APCC and APPM. I’m not yet a serious imager, and the local sky brightness pretty well limits me to exposures of 180s or so on objects imaged without use of a narrowband filter. No question in my mind that APCC is something that I eventually will want to learn, but if I can ease into things first, I’d like to do that.
After reading the numerous informative recent posts on the subject of APCC, I’m thinking that for my present purposes, accurate polar alignment, Sky Safari, and the keypad with its own modeling feature might suffice until my imaging skills have improved, and I’m able to take the mount to dark-sky locations.
I’m curious, specifically, how precisely the Sky Safari app (laptop, iPad, or both) communicates with an A-P GTO-AE mount. My procedure is to pole-align with RAPAS, start with mount and Sky Safari at Park 3, GOTO a reference star, manually center the star in the eyepiece, and tell SS to ALIGN ON that star. My experiments show that if I use SS to GOTO an object in a distant part of the sky, it will put the scope within typically 0.5º or so of being centered on the target. Then, without doing an ALIGN ON that object, if I use SS to GOTO the star originally aligned on, it slews the mount to put the star dead-center (I haven’t tried this with a high-power EP, but I will tonight).
What I take from this is, first, that the inaccuracy of the original GOTO is likely due to imperfect PA and atmospheric refraction (another experiment for tonight: initially ALIGN ON and then GOTO not just random stars, but ones that are at the same elevation, to take refraction out of the equation), and second, that the spot-on return to the alignment star indicates accurate communication of either servo ticks or AE position to Sky Safari. Does anyone know?
Next, now that I have the keypad, does Sky Safari offer any additional functionality aside from the graphic presentation and the touch-and-GOTO capability?
Also, once I’ve constructed a pointing model with the keypad, if I use SS (assuming there’s a reason to do that), will the app’s GOTO command go through the pointing model, so to speak, and take advantage of its corrections?
I would appreciate any other advice or comments on use of SS, the keypad, or both without the use of APCC.
—howard
|
|
|
Barbara Harris
Definitely handy to have the Apple Watch version of PS Align pro.
Barbara
|
|
|
I’ve installed it. I’m waiting for a clear night so I can prove you guys right!
On Nov 14, 2022, at 9:47 AM, Barbara Harris via groups.io <babsharris13@...> wrote:
Definitely handy to have the Apple Watch version of PS Align pro.
Barbara
|
|
|
It hasn't been mentioned, but in addition to PA and refraction, orthogonality contributes to pointing error. The model may correct for that, given enough points.
I did drift align to get 20 minutes without drift in both axes, and then adjusted the RAPAS - the error wasn't huge, but it was far enough off that having PSAlign correct for refraction would hardly make a difference in comparison.
Once orthogonality was corrected, I was getting within about 7' pointing all over the sky, but now it's more like 10', and I think my pier may have settled a bit over the year. So I'll give it another go when I get some time and a good night. However, my CP3, using the HC, has always been about half a degree off for the planets, even when it is accurately going to other objects in the same part of the sky.
Chip W.
|
|
|
Thanks for the report from personal experience. Doing a drift alignment and RAPAS calibration is top of the list for the next clear night.
—Howard
On Nov 14, 2022, at 22:00, weems@... wrote: It hasn't been mentioned, but in addition to PA and refraction, orthogonality contributes to pointing error. The model may correct for that, given enough points.
I did drift align to get 20 minutes without drift in both axes, and then adjusted the RAPAS - the error wasn't huge, but it was far enough off that having PSAlign correct for refraction would hardly make a difference in comparison.
Once orthogonality was corrected, I was getting within about 7' pointing all over the sky, but now it's more like 10', and I think my pier may have settled a bit over the year. So I'll give it another go when I get some time and a good night. However, my CP3, using the HC, has always been about half a degree off for the planets, even when it is accurately going to other objects in the same part of the sky.
Chip W.
|
|
|
