Date   

Re: Stainless Steel Insert for Counterweight Shaft Threads

Roland Christen
 


I'd assume that that a we'll need to buy a new CW shaft because if the insert is screwed into the hole of the legacy mounts then its ID would be too small for the CW shaft to be screwed in.
No, not true. The bore size did not change, and all shafts will fit the new inserts.

Rolando


-----Original Message-----
From: Cheng-Yang Tan via groups.io <cytan299@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Sun, Nov 15, 2020 5:38 pm
Subject: Re: [ap-gto] Stainless Steel Insert for Counterweight Shaft Threads

Hi mhambrick
   I'd assume that that a we'll need to buy a new CW shaft because if the insert is screwed into the hole of the legacy mounts then its ID would be too small for the CW shaft to be screwed in.

cytan

On Sunday, November 15, 2020, 02:39:29 PM CST, M Hambrick <mhambrick563@...> wrote:


Hi Tony

Marj replied to an email that I sent to her stating that this insert is now included in the counterweight shaft adapters on the 1100 and I think also the 1600 mounts. She was not sure if they had any extras from the current production runs, but I read into her comments that they will probably make some and offer them for sale at some point in the future. Whenever that happens I plan to get one.

I don't really need one of these adapters at this time, because I have always been careful not to cross-thread the CW shaft into the adapter, but since I set up and take down my mount each session, those threads get a lot of wear. Eventually they are going to wear out or get cross threaded.

One thing that concerns me is that stainless on stainless threads are notorious about galling. I would recommend using a little bit of Never-Seez to keep this from happening. I wonder if a good high-strength bronze insert wouldn't be a better choice for insert material.


Re: Stainless Steel Insert for Counterweight Shaft Threads

Cheng-Yang Tan
 

Hi mhambrick
   I'd assume that that a we'll need to buy a new CW shaft because if the insert is screwed into the hole of the legacy mounts then its ID would be too small for the CW shaft to be screwed in.

cytan

On Sunday, November 15, 2020, 02:39:29 PM CST, M Hambrick <mhambrick563@...> wrote:


Hi Tony

Marj replied to an email that I sent to her stating that this insert is now included in the counterweight shaft adapters on the 1100 and I think also the 1600 mounts. She was not sure if they had any extras from the current production runs, but I read into her comments that they will probably make some and offer them for sale at some point in the future. Whenever that happens I plan to get one.

I don't really need one of these adapters at this time, because I have always been careful not to cross-thread the CW shaft into the adapter, but since I set up and take down my mount each session, those threads get a lot of wear. Eventually they are going to wear out or get cross threaded.

One thing that concerns me is that stainless on stainless threads are notorious about galling. I would recommend using a little bit of Never-Seez to keep this from happening. I wonder if a good high-strength bronze insert wouldn't be a better choice for insert material.


Re: “Lost in Space” remote resume

Ray Gralak
 

Hi Jim,

Would it be possible to patch APCC to allow it to sync with CW up if Prevent errant recalls is unchecked?
(Provided that was the probable cause of not syncing) I know we seem to be identifying real corner cases.
There is nothing wrong with APCC's plate solve and recal.

I think the problem was either a bad plate-solve, or that your computer and mount had different times, because of the recent time change. This affected where the mount's flip point was and probably caused the recal to incorrectly determine the counterweight status (up or down).

Another possibility is to use APCC's homing feature.

This would work if:

1) The clutches were not released nor had slipped.
2) A Home position had been defined in APCC.

If you want to prepare for the future, please read the section in the APCC help file for Homing for more information.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Jim Fakatselis
Sent: Sunday, November 15, 2020 2:12 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] “Lost in Space” remote resume

Thanks for your response.

That is precisely what I tried to do. I did an All sky solve in Maxim but when I tried to sync it I had the prevent
errant recals option checked and since it was so far off I just got an error.



When I unchecked the prevent errant recals it still did not re-establish pointing.



Ray Gralak suspects it may be because the counterweights were up. The only thing that seemed to work was
that I had a webcam there and I tried to position as closely as I could to Park 3 via camera upon Ray’s advice. I
then parked at current position, unparked from Park 3 and I could then sync. Ray did it !



My issue is that if I had no camera, there would seemed to have been no way to do re-establish proper pointing.

Would it be possible to patch APCC to allow it to sync with CW up if Prevent errant recalls is unchecked?
(Provided that was the probable cause of not syncing) I know we seem to be identifying real corner cases.



Jim



Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10



From: uncarollo2 <chris1011@aol.com> via groups.io <mailto:chris1011=aol.com@groups.io>
Sent: Sunday, November 15, 2020 4:22 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] “Lost in Space” remote resume





How could I resync mount remotely without going to observatory and resetting clutches at a park postion?

If you can figure out where the mount is pointing via All-Sky plate solve, then it's just a matter of doing a recal on
that position using APCC. Once you do a recal on a known point in the sky, then all parks will be correct also.
Use APCC exclusively for all mount functions, and use SkyX only for GoTos to the objects you wish to image. I
use SkyX for click&point GoTos and for doing recals after centering a star or object, but that's about it.



Rolando





-----Original Message-----
From: Jim Fakatselis <pashasdad@gmail.com>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Sun, Nov 15, 2020 3:07 pm
Subject: Re: [ap-gto] “Lost in Space” remote resume

The mount is operated remotely in my observatory, no clutches could be moved. Mount was only moved with the
directional arrows in APCC only.



I suspect the cause of getting lost was trying to park using TheSkyX while I had never clearly defined a park
position in TSX. Pressing the Park scope option got it lost I suspect. I believe this is when it got lost. Do you think
that was the cause?



I could no longer go to any park positions since they were all corrupt. How could I resync mount remotely without
going to observatory and resetting clutches at a park postion?



Thanks for your help,

Jim





Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10



From: uncarollo2 <chris1011@aol.com> via groups.io <mailto:chris1011=aolcom@groups.io>
Sent: Saturday, November 14, 2020 4:58 PM
To: main@ap-gtogroups.io <mailto:main@ap-gto.groups.io>
Subject: Re: [ap-gto] “Lost in Space” remote resume



1) On a Mach1, if you moved the mount manually with clutches loose, the mount does not keep track of the new
position that you moved to and the memory will only know the previous position until you do a sync or recal on a
known object.



2) If you move the mount using the motors with a slew or with the buttons, then the mount servo will keep track of
the new position.



3) if you get the mount totally lost by doing a manual move via the clutches, or by doing an errant sync, then the
easiest way to find home again is to loosen both RA and Dec clutches, sent the mount to park 3 while holding the
scope until the motors stop moving, and then manually placing the scope in park3 position and re-tightening the
clutches. Then you are good to go and the mount knows where the scope is pointing in the sky.



On a Mach2 mount you don't have to worry about moving the scope with the clutches loose - the encoders track
very movement, whether you move it manually or using the motors.



Rolando

-----Original Message-----
From: Jim Fakatselis <pashasdad@gmail.com>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Sat, Nov 14, 2020 12:54 am
Subject: Re: [ap-gto] “Lost in Space” remote resume

Hmmm…I positioned the scope myself and I know the CW was down, however, I believe I saw the CW up flag in
APCC when it was positioned for all sky sync. Guess the mount thought the CW was up. Could that be it?



Thank you Ray.





Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10



From: Ray Gralak <mailto:groups3@gralak.com>
Sent: Saturday, November 14, 2020 12:28 AM
To: main@ap-gto.groups.io <mailto:main@ap-gtogroups.io>
Subject: Re: [ap-gto] “Lost in Space” remote resume



My question is why didn’t the first method work?


There are at least two possibilities:



1. the mount was in a counterweight-up position when synched.



2. the synch coordinates were bad, which can happen, and is the very reason for the option to prevent errant
recalls.



-Ray Gralak

Author of PEMPro

Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro

Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver



-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Jim Fakatselis
Sent: Friday, November 13, 2020 6:40 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] “Lost in Space” remote resume
[Edited Message Follows]
Ray,
Last week my observatory Mach1GTO got lost and the slews became corrupted, i.e. lost in space. Found that
all

sky solve with Maxim resulted in an error in APCC that indicated I was too far from the position the mount
thought

it was pointing to.
One of the two suggestions you had recommended for that remote resync was:
“ In APCC's advanced settings, you can uncheck "Prevent errant RECALs". That will allow the platesolve/sync
to

be used anywhere in the sky. Make sure to reenable the option afterwards.”
After doing another all sky search in Maxim it came up with a plate solve solution and I synced this new mount
position in Maxim to plate solve coordinates. This did not result in the mount being restored to the proper
position. As I tried to park it, it started driving towards the pier.
Can APCC not sync it properly through Maxim? Or what did I do incorrectly?
I then tried your other suggestion using a camera on my observatory to bring it close to Park 3 as I could
ascertain by looking at mount in camera with errant recals restored. When I parked it to current position then
unparked from Park 3 it work as you said. All was good
My question is why didn’t the first method work?
Thanks in advance,
Jim














<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-
email&utm_content=emailclient&utm_term=icon>

Virus-free. www.avast.com <https://www.avast.com/sig-
email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>






Re: PEMPro Data gathering

Mike Shade
 

Hi Mike,

1600GTO, early model (just had bearings replaced in RA/DEC gear boxes), Planewave CDK 17/unbinned image
scale .631"/pixel/permanent setup
Is it best to gather data at 0 dec (about 55 degrees elevation), or higher (80 degrees) to minimize seeing effects?
55 degrees elevation is more than good enough for measuring periodic error. If you want to minimize seeing issues, try waiting until early morning, a couple of hours before dawn, and start collecting data then. Usually localized seeing effects from the scope, the ground, and nearby structures are minimal as they have had the whole evening to normalize to the temperature.

Doing 10-12 cycles, as Bryan suggested, might help produce a more accurate result. However, don't go too long much longer because if the drift becomes too complicated, it can't be entirely separated from the PE data and can be detrimental to getting the most accurate PEC curve.

I generally get 400 points or more, that is something like 5-6 cycles. Will try a longer data gathering time and see what that does.

To minimize seeing effects, better to use a shorter exposure, say .25" and a longer delay between exposures, say
3" OR a longer exposure and longer delay (1" exposure/3" delay)?
There is a tradeoff here that depends on the cycle time of your camera. If the camera takes 2 seconds between exposures, you don't want to use a 0.25 second exposure because you are only sampling the star for 0.25 seconds every 2 seconds. You might want to choose a two-second, or three-second, exposure. That would capture the star 50% or more of the time. However, if you can use a video camera (on a brighter star), there is no harm to collect data at video frame rates.

The camera cycles pretty quickly as it is a pretty small portion of the whole frame. I can do say a .25" exposure and a .25" delay easily, or even quicker if need be.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Mike Shade
Sent: Sunday, November 15, 2020 7:28 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] PEMPro Data gathering

Have a few questions on best practices for PemPro data gathering.



1600GTO, early model (just had bearings replaced in RA/DEC gear boxes), Planewave CDK 17/unbinned image
scale .631"/pixel/permanent setup



Is it best to gather data at 0 dec (about 55 degrees elevation), or higher (80 degrees) to minimize seeing effects?



If higher data gathering, calibrate here as well?



To minimize seeing effects, better to use a shorter exposure, say .25" and a longer delay between exposures, say
3" OR a longer exposure and longer delay (1" exposure/3" delay)?



When gathering data, I can watch the star in Maxim move quite a bit off of centroid in random directions. Some is
of course real PE, the rest noise. I know the program can account for this to some extent, but this is a lot of noise
and wonder if it is being represented in the final curve.



Generally get about 400 points for a PEC curve, more or less.



Thanks.



Mike J. Shade

Mike J. Shade Photography:

mshadephotography.com



In War: Resolution

In Defeat: Defiance

In Victory: Magnanimity

In Peace: Goodwill

Sir Winston Churchill

Already, in the gathering dusk, a few of the stars are turning on their lights.

Vega, the brightest one, is now dropping towards the west. Can it be half

a year since I watched her April rising in the east? Low in the southwest

Antares blinks a sad farwell to fall...

Leslie Peltier, Starlight Nights



International Dark Sky Association: www.darksky.org <http://www.darksky.org/>






Re: “Lost in Space” remote resume

Jim Fakatselis
 

Thanks for your response.

That is precisely what I tried to do. I did an All sky solve in Maxim but when I tried to sync it I had the prevent errant recals option checked and since it was so far off I just got an error.

 

When I unchecked the prevent errant recals it still did not re-establish pointing.

 

Ray Gralak suspects it may be because the counterweights were up. The only thing that seemed to work was that I had a webcam there and I tried to position as closely as I could to Park 3 via camera upon Ray’s advice. I then parked at current position, unparked from Park 3 and I could then sync. Ray did it !

 

My issue is that if I had no camera, there would seemed to have been no way to do re-establish proper pointing.

Would it be possible to patch APCC to allow it to sync with CW up if Prevent errant recalls is unchecked? (Provided that was the probable cause of not syncing) I know we seem to be identifying real corner cases.

 

Jim

 

Sent from Mail for Windows 10

 

From: uncarollo2 <chris1011@...> via groups.io
Sent: Sunday, November 15, 2020 4:22 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] “Lost in Space” remote resume

 

 

How could I resync mount remotely without going to observatory and resetting clutches at a park postion?

If you can figure out where the mount is pointing via All-Sky plate solve, then it's just a matter of doing a recal on that position using APCC. Once you do a recal on a known point in the sky, then all parks will be correct also. Use APCC exclusively for all mount functions, and use SkyX only for GoTos to the objects you wish to image. I use SkyX for click&point GoTos and for doing recals after centering a star or object, but that's about it.

 

Rolando

 

 

-----Original Message-----
From: Jim Fakatselis <pashasdad@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Sun, Nov 15, 2020 3:07 pm
Subject: Re: [ap-gto] “Lost in Space” remote resume

The mount is operated remotely in my observatory, no clutches could be moved. Mount was only moved with the directional arrows in APCC only.

 

I suspect the cause of getting lost was trying to park using TheSkyX while I had never clearly defined a park position in TSX. Pressing the Park scope option got it lost I suspect. I believe this is when it got lost. Do you think that was the cause?

 

I could no longer go to any park positions since they were all corrupt.  How could I resync mount remotely without going to observatory and resetting clutches at a park postion?

 

Thanks for your help,

Jim

 

 

Sent from Mail for Windows 10

 

From: uncarollo2 <chris1011@...> via groups.io
Sent: Saturday, November 14, 2020 4:58 PM
To: main@...
Subject: Re: [ap-gto] “Lost in Space” remote resume

 

1) On a Mach1, if you moved the mount manually with clutches loose, the mount does not keep track of the new position that you moved to and the memory will only know the previous position until you do a sync or recal on a known object.

 

2) If you move the mount using the motors with a slew or with the buttons, then the mount servo will keep track of the new position.

 

3) if you get the mount totally lost by doing a manual move via the clutches, or by doing an errant sync, then the easiest way to find home again is to loosen both RA and Dec clutches, sent the mount to park 3 while holding the scope until the motors stop moving, and then manually placing the scope in park3 position and re-tightening the clutches. Then you are good to go and the mount knows where the scope is pointing in the sky. 

 

On a Mach2 mount you don't have to worry about moving the scope with the clutches loose - the encoders track very movement, whether you move it manually or using the motors.

 

Rolando

-----Original Message-----
From: Jim Fakatselis <pashasdad@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Sat, Nov 14, 2020 12:54 am
Subject: Re: [ap-gto] “Lost in Space” remote resume

Hmmm…I positioned the scope myself and I know the CW was down, however, I believe I saw the CW up flag in APCC when it was positioned for all sky sync. Guess the mount thought the CW was up. Could that be it?

 

Thank you Ray.

 

 

Sent from Mail for Windows 10

 

From: Ray Gralak
Sent: Saturday, November 14, 2020 12:28 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] “Lost in Space” remote resume

 

> My question is why didn’t the first method work?

 

There are at least two possibilities:

 

1. the mount was in a counterweight-up position when synched.

 

2. the synch coordinates were bad, which can happen, and is the very reason for the option to prevent errant recalls.

 

-Ray Gralak

Author of PEMPro

Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro

Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

 

> -----Original Message-----

> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Jim Fakatselis

> Sent: Friday, November 13, 2020 6:40 PM

> To: main@ap-gto.groups.io

> Subject: [ap-gto] “Lost in Space” remote resume

>

> [Edited Message Follows]

>

>

> Ray,

> Last week my observatory Mach1GTO got lost and the slews became corrupted, i.e. lost in space.  Found that all

> sky solve with Maxim resulted in an error in APCC that indicated I was too far from the position the mount thought

> it was pointing to.

>

>

> One of the two suggestions you had recommended for that remote resync was:

>

>

> “ In APCC's advanced settings, you can uncheck "Prevent errant RECALs". That will allow the platesolve/sync to

> be used anywhere in the sky. Make sure to reenable the option afterwards.”

>

>

>

>

> After  doing another all sky search in Maxim it came up with a plate solve solution and I synced this new mount

> position in Maxim to plate solve coordinates. This did not result in the mount being restored to the proper

> position.  As I tried to park it, it started driving towards the pier.

>

> Can APCC not sync it properly through Maxim?  Or what did I do incorrectly?

>

> I then tried your other suggestion using a camera on my observatory to bring it close to Park 3 as I could

> ascertain by looking at mount in camera with errant recals restored. When I parked it to current position then

> unparked from Park 3 it work as you said. All was good

>

> My question is why didn’t the first method work?

>

> Thanks in advance,

> Jim

>

>

>

>

 

 

 

 

 

 

 

Virus-free. www.avast.com

 

 


Re: [ap-ug] Soul Nebula / Westerhout 5 SHO

Jeff B
 

Wow.


On Sun, Nov 15, 2020 at 4:03 PM Pete Lardizabal <p14@...> wrote:
Beauty Dale!

⭐️⭐️⭐️⭐️⭐️

Pete

> On Nov 15, 2020, at 3:25 PM, Dale Ghent <daleg@...> wrote:
>
> I had a rash of clear nights with passable seeing the past week, so I managed to get 32 hours of data on the Soul Nebula
>
> 130GTX, Mach1, QHY600.
>
> https://www.astrobin.com/full/x6124n/0/
>
>
>
>
>







Re: consistent goto error on meridian flip w/1200

Steven Panish
 

Thanks for the input, Roland.  It always seemed most likely to be orthogonality related to the dovetail bar on the C9.25.   All the AP stuff I trust.  The software compensation feature sounds great...but I have a CP3.  I'll try shimming first, which will be a bit of a random walk combined with a binary search.  

Steve

On Sun, Nov 15, 2020 at 12:55 PM uncarollo2 <chris1011@...> via groups.io <chris1011=aol.com@groups.io> wrote:
Typically the mount is very accurate as far as orthogonality. I have measured the gearwheel accuracies of a number of mounts and they consistently fall below 15 arc seconds for the entire 360 degree rotation. In other words, the gearbox and worm wheels are extremely accurate and would not impact the orthogonal error that you experience.

The main culprit is usually the optical tube assembly. The optical axis of a telescope does not always line up precisely with the mechanical mounting of the tube. A 1 degree error of the mounting system will produce a 2 degree pointing error when flipping from one side to the other. The solution is to measure the pointing error an shim the tube assembly or mounting rings to eliminate the mechanical error. The other solution is to compensate for it with software. We now have incorporated an automated routine in the CP4 and new keypad software that measures the ortho error and compensates for it.

Roland Christen



-----Original Message-----
From: Steven Panish <scpanish@...>
To: main@ap-gto.groups.io
Sent: Sat, Nov 14, 2020 7:31 pm
Subject: [ap-gto] consistent goto error on meridian flip w/1200

My venerable 1200 has a large and consistent goto error after a meridian flip.  It is roughly 2 deg in RA and a couple minutes in Dec, I haven't actually measured it.  Very consistent, so in spite of being way off the sensor I know how to move the scope E/W to get the target back in sight.  After a recal, goto accuracy is restored.  This isn't mirror flop, the finder scope also shows the issue and I can use that for centering as well.  Mostly I avoid the problem by starting an imaging run counterweight up and avoiding a meridian flip altogether.  I bought this 1200 3 years ago and it has always had the issue.

Does anyone have a clue as to what is wrong?  Orthogonality?  The scope is a C9.25 and the finder is mounted on the scop so the dovetail could be off, everything else is AP and should be precise.   I can work with it but it would be nice to not have to think about it.  

Steve


Re: “Lost in Space” remote resume

Roland Christen
 


How could I resync mount remotely without going to observatory and resetting clutches at a park postion?
If you can figure out where the mount is pointing via All-Sky plate solve, then it's just a matter of doing a recal on that position using APCC. Once you do a recal on a known point in the sky, then all parks will be correct also. Use APCC exclusively for all mount functions, and use SkyX only for GoTos to the objects you wish to image. I use SkyX for click&point GoTos and for doing recals after centering a star or object, but that's about it.

Rolando


-----Original Message-----
From: Jim Fakatselis <pashasdad@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Sun, Nov 15, 2020 3:07 pm
Subject: Re: [ap-gto] “Lost in Space” remote resume

The mount is operated remotely in my observatory, no clutches could be moved. Mount was only moved with the directional arrows in APCC only.
 
I suspect the cause of getting lost was trying to park using TheSkyX while I had never clearly defined a park position in TSX. Pressing the Park scope option got it lost I suspect. I believe this is when it got lost. Do you think that was the cause?
 
I could no longer go to any park positions since they were all corrupt.  How could I resync mount remotely without going to observatory and resetting clutches at a park postion?
 
Thanks for your help,
Jim
 
 
Sent from Mail for Windows 10
 
From: uncarollo2 <chris1011@...> via groups.io
Sent: Saturday, November 14, 2020 4:58 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] “Lost in Space” remote resume
 
1) On a Mach1, if you moved the mount manually with clutches loose, the mount does not keep track of the new position that you moved to and the memory will only know the previous position until you do a sync or recal on a known object.
 
2) If you move the mount using the motors with a slew or with the buttons, then the mount servo will keep track of the new position.
 
3) if you get the mount totally lost by doing a manual move via the clutches, or by doing an errant sync, then the easiest way to find home again is to loosen both RA and Dec clutches, sent the mount to park 3 while holding the scope until the motors stop moving, and then manually placing the scope in park3 position and re-tightening the clutches. Then you are good to go and the mount knows where the scope is pointing in the sky. 
 
On a Mach2 mount you don't have to worry about moving the scope with the clutches loose - the encoders track very movement, whether you move it manually or using the motors.
 
Rolando

-----Original Message-----
From: Jim Fakatselis <pashasdad@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Sat, Nov 14, 2020 12:54 am
Subject: Re: [ap-gto] “Lost in Space” remote resume
Hmmm…I positioned the scope myself and I know the CW was down, however, I believe I saw the CW up flag in APCC when it was positioned for all sky sync. Guess the mount thought the CW was up. Could that be it?
 
Thank you Ray.
 
 
Sent from Mail for Windows 10
 
From: Ray Gralak
Sent: Saturday, November 14, 2020 12:28 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] “Lost in Space” remote resume
 
> My question is why didn’t the first method work?
 
There are at least two possibilities:
 
1. the mount was in a counterweight-up position when synched.
 
2. the synch coordinates were bad, which can happen, and is the very reason for the option to prevent errant recalls.
 
-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
 
> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Jim Fakatselis
> Sent: Friday, November 13, 2020 6:40 PM
> To: main@ap-gto.groups.io
> Subject: [ap-gto] “Lost in Space” remote resume
>
> [Edited Message Follows]
>
>
> Ray,
> Last week my observatory Mach1GTO got lost and the slews became corrupted, i.e. lost in space.  Found that all
> sky solve with Maxim resulted in an error in APCC that indicated I was too far from the position the mount thought
> it was pointing to.
>
>
> One of the two suggestions you had recommended for that remote resync was:
>
>
> “ In APCC's advanced settings, you can uncheck "Prevent errant RECALs". That will allow the platesolve/sync to
> be used anywhere in the sky. Make sure to reenable the option afterwards.”
>
>
>
>
> After  doing another all sky search in Maxim it came up with a plate solve solution and I synced this new mount
> position in Maxim to plate solve coordinates. This did not result in the mount being restored to the proper
> position.  As I tried to park it, it started driving towards the pier.
>
> Can APCC not sync it properly through Maxim?  Or what did I do incorrectly?
>
> I then tried your other suggestion using a camera on my observatory to bring it close to Park 3 as I could
> ascertain by looking at mount in camera with errant recals restored. When I parked it to current position then
> unparked from Park 3 it work as you said. All was good
>
> My question is why didn’t the first method work?
>
> Thanks in advance,
> Jim
>
>
>
>
 
 
 
 
 
 
 
Virus-free. www.avast.com
 


Re: “Lost in Space” remote resume

Jim Fakatselis
 

The mount is operated remotely in my observatory, no clutches could be moved. Mount was only moved with the directional arrows in APCC only.

 

I suspect the cause of getting lost was trying to park using TheSkyX while I had never clearly defined a park position in TSX. Pressing the Park scope option got it lost I suspect. I believe this is when it got lost. Do you think that was the cause?

 

I could no longer go to any park positions since they were all corrupt.  How could I resync mount remotely without going to observatory and resetting clutches at a park postion?

 

Thanks for your help,

Jim

 

 

Sent from Mail for Windows 10

 

From: uncarollo2 <chris1011@...> via groups.io
Sent: Saturday, November 14, 2020 4:58 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] “Lost in Space” remote resume

 

1) On a Mach1, if you moved the mount manually with clutches loose, the mount does not keep track of the new position that you moved to and the memory will only know the previous position until you do a sync or recal on a known object.

 

2) If you move the mount using the motors with a slew or with the buttons, then the mount servo will keep track of the new position.

 

3) if you get the mount totally lost by doing a manual move via the clutches, or by doing an errant sync, then the easiest way to find home again is to loosen both RA and Dec clutches, sent the mount to park 3 while holding the scope until the motors stop moving, and then manually placing the scope in park3 position and re-tightening the clutches. Then you are good to go and the mount knows where the scope is pointing in the sky. 

 

On a Mach2 mount you don't have to worry about moving the scope with the clutches loose - the encoders track very movement, whether you move it manually or using the motors.

 

Rolando

-----Original Message-----
From: Jim Fakatselis <pashasdad@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Sat, Nov 14, 2020 12:54 am
Subject: Re: [ap-gto] “Lost in Space” remote resume

Hmmm…I positioned the scope myself and I know the CW was down, however, I believe I saw the CW up flag in APCC when it was positioned for all sky sync. Guess the mount thought the CW was up. Could that be it?

 

Thank you Ray.

 

 

Sent from Mail for Windows 10

 

From: Ray Gralak
Sent: Saturday, November 14, 2020 12:28 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] “Lost in Space” remote resume

 

> My question is why didn’t the first method work?

 

There are at least two possibilities:

 

1. the mount was in a counterweight-up position when synched.

 

2. the synch coordinates were bad, which can happen, and is the very reason for the option to prevent errant recalls.

 

-Ray Gralak

Author of PEMPro

Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro

Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

 

> -----Original Message-----

> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Jim Fakatselis

> Sent: Friday, November 13, 2020 6:40 PM

> To: main@ap-gto.groups.io

> Subject: [ap-gto] “Lost in Space” remote resume

>

> [Edited Message Follows]

>

>

> Ray,

> Last week my observatory Mach1GTO got lost and the slews became corrupted, i.e. lost in space.  Found that all

> sky solve with Maxim resulted in an error in APCC that indicated I was too far from the position the mount thought

> it was pointing to.

>

>

> One of the two suggestions you had recommended for that remote resync was:

>

>

> “ In APCC's advanced settings, you can uncheck "Prevent errant RECALs". That will allow the platesolve/sync to

> be used anywhere in the sky. Make sure to reenable the option afterwards.”

>

>

>

>

> After  doing another all sky search in Maxim it came up with a plate solve solution and I synced this new mount

> position in Maxim to plate solve coordinates. This did not result in the mount being restored to the proper

> position.  As I tried to park it, it started driving towards the pier.

>

> Can APCC not sync it properly through Maxim?  Or what did I do incorrectly?

>

> I then tried your other suggestion using a camera on my observatory to bring it close to Park 3 as I could

> ascertain by looking at mount in camera with errant recals restored. When I parked it to current position then

> unparked from Park 3 it work as you said. All was good

>

> My question is why didn’t the first method work?

>

> Thanks in advance,

> Jim

>

>

>

>

 

 

 

 

 

 

 

Virus-free. www.avast.com

 


Re: [ap-ug] Soul Nebula / Westerhout 5 SHO

Pete Lardizabal
 

Beauty Dale!

⭐️⭐️⭐️⭐️⭐️

Pete

On Nov 15, 2020, at 3:25 PM, Dale Ghent <daleg@elemental.org> wrote:

I had a rash of clear nights with passable seeing the past week, so I managed to get 32 hours of data on the Soul Nebula

130GTX, Mach1, QHY600.

https://www.astrobin.com/full/x6124n/0/





Re: Stainless Steel Insert for Counterweight Shaft Threads

M Hambrick
 

Hi Tony

Marj replied to an email that I sent to her stating that this insert is now included in the counterweight shaft adapters on the 1100 and I think also the 1600 mounts. She was not sure if they had any extras from the current production runs, but I read into her comments that they will probably make some and offer them for sale at some point in the future. Whenever that happens I plan to get one.

I don't really need one of these adapters at this time, because I have always been careful not to cross-thread the CW shaft into the adapter, but since I set up and take down my mount each session, those threads get a lot of wear. Eventually they are going to wear out or get cross threaded.

One thing that concerns me is that stainless on stainless threads are notorious about galling. I would recommend using a little bit of Never-Seez to keep this from happening. I wonder if a good high-strength bronze insert wouldn't be a better choice for insert material.


Re: Soul Nebula / Westerhout 5 SHO

Roland Christen
 

Lots of nice detail and bang-on color! Great shot.

Rolando


-----Original Message-----
From: Dale Ghent <daleg@...>
To: main@ap-gto.groups.io
Cc: main@ap-ug.groups.io
Sent: Sun, Nov 15, 2020 2:25 pm
Subject: [ap-gto] Soul Nebula / Westerhout 5 SHO

I had a rash of clear nights with passable seeing the past week, so I managed to get 32 hours of data on the Soul Nebula

130GTX, Mach1, QHY600.








Soul Nebula / Westerhout 5 SHO

Dale Ghent
 

I had a rash of clear nights with passable seeing the past week, so I managed to get 32 hours of data on the Soul Nebula

130GTX, Mach1, QHY600.

https://www.astrobin.com/full/x6124n/0/


Re: Yet Another M31: knocking the rust off in bortle 8

Dale Ghent
 

Thank you for all of the appreciation, everyone :) It's encouraging after a long break and means a lot.

/dale

On Nov 13, 2020, at 7:51 PM, Don Anderson via groups.io <jockey_ca=yahoo.ca@groups.io> wrote:

Very well done Dale! You should be pleased with that one. Gives me incentive to try LRGB in my Bortle 8 skies!

Don Anderson


On Friday, November 13, 2020, 11:08:17 a.m. MST, Dale Ghent <daleg@elemental.org> wrote:


After a summer of little time for astrophotography and my main imaging rig undergoing a near total reconfiguration to accommodate a QHY600, I finally was able to get a few sessions in over the month of October and break in the new system. I haven't seriously imaged broadband before because I live under lusciously gray bortle 8 skies in the jet stream-inflicted mid-Atlantic, and escaping this atmospheric morass means a few hours' drive in any of the cardinal directions... so I've just kind of stuck to narrowband. I'm actually pretty happy with the outcome of this little project, my first Ha+LRGB. I've since fixed some spacing and tilt and am working on some more targets as weather allows.

https://www.astrobin.com/full/hrq1cy/0/

Details in the tech card, etc.

/dale




Re: SGP Pier flip failure (AP1100/APMM pro and SGP)

Luca Marinelli
 
Edited

Michael,

I responded to your question on the SGP forum. In my opinion, you are trying to fix too many things in one go. Try to get the flips to work in the Western sky before you worry about pre-flipping in the Eastern sky. As I mentioned in the other forum, you may want to double check how you setup your Eastern and Western meridian limits. You mentioned that you mirrored both. If your Western limits are in the Eastern sky, SGP will not allow the mount to flip because it hasn't hit the meridian limit yet. I made a mistake some time ago when I programed the meridian limits and reversed my Eastern and Western meridian limits. In APCC pro while showing both Eastern and Western limits, everything looked great but nothing worked. I made sure that Eastern limits were in the Eastern sky and Western limits were in the Western sky and all is well. Finally, you did not mention which version of APCC you are running. Ray fixed a bug a couple of months ago that gave me problems with meridian flips a couple of months ago. Update to the latest version of APCC if you haven't yet. 

Good luck!

Luca 


Re: PEMPro Data gathering

Ray Gralak
 

Hi Mike,

1600GTO, early model (just had bearings replaced in RA/DEC gear boxes), Planewave CDK 17/unbinned image
scale .631"/pixel/permanent setup
Is it best to gather data at 0 dec (about 55 degrees elevation), or higher (80 degrees) to minimize seeing effects?
55 degrees elevation is more than good enough for measuring periodic error. If you want to minimize seeing issues, try waiting until early morning, a couple of hours before dawn, and start collecting data then. Usually localized seeing effects from the scope, the ground, and nearby structures are minimal as they have had the whole evening to normalize to the temperature.

Doing 10-12 cycles, as Bryan suggested, might help produce a more accurate result. However, don't go too long much longer because if the drift becomes too complicated, it can't be entirely separated from the PE data and can be detrimental to getting the most accurate PEC curve.

To minimize seeing effects, better to use a shorter exposure, say .25" and a longer delay between exposures, say
3" OR a longer exposure and longer delay (1" exposure/3" delay)?
There is a tradeoff here that depends on the cycle time of your camera. If the camera takes 2 seconds between exposures, you don't want to use a 0.25 second exposure because you are only sampling the star for 0.25 seconds every 2 seconds. You might want to choose a two-second, or three-second, exposure. That would capture the star 50% or more of the time. However, if you can use a video camera (on a brighter star), there is no harm to collect data at video frame rates.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Mike Shade
Sent: Sunday, November 15, 2020 7:28 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] PEMPro Data gathering

Have a few questions on best practices for PemPro data gathering.



1600GTO, early model (just had bearings replaced in RA/DEC gear boxes), Planewave CDK 17/unbinned image
scale .631"/pixel/permanent setup



Is it best to gather data at 0 dec (about 55 degrees elevation), or higher (80 degrees) to minimize seeing effects?



If higher data gathering, calibrate here as well?



To minimize seeing effects, better to use a shorter exposure, say .25" and a longer delay between exposures, say
3" OR a longer exposure and longer delay (1" exposure/3" delay)?



When gathering data, I can watch the star in Maxim move quite a bit off of centroid in random directions. Some is
of course real PE, the rest noise. I know the program can account for this to some extent, but this is a lot of noise
and wonder if it is being represented in the final curve.



Generally get about 400 points for a PEC curve, more or less.



Thanks.



Mike J. Shade

Mike J. Shade Photography:

mshadephotography.com



In War: Resolution

In Defeat: Defiance

In Victory: Magnanimity

In Peace: Goodwill

Sir Winston Churchill

Already, in the gathering dusk, a few of the stars are turning on their lights.

Vega, the brightest one, is now dropping towards the west. Can it be half

a year since I watched her April rising in the east? Low in the southwest

Antares blinks a sad farwell to fall...

Leslie Peltier, Starlight Nights



International Dark Sky Association: www.darksky.org <http://www.darksky.org/>






Re: consistent goto error on meridian flip w/1200

Roland Christen
 

Typically the mount is very accurate as far as orthogonality. I have measured the gearwheel accuracies of a number of mounts and they consistently fall below 15 arc seconds for the entire 360 degree rotation. In other words, the gearbox and worm wheels are extremely accurate and would not impact the orthogonal error that you experience.

The main culprit is usually the optical tube assembly. The optical axis of a telescope does not always line up precisely with the mechanical mounting of the tube. A 1 degree error of the mounting system will produce a 2 degree pointing error when flipping from one side to the other. The solution is to measure the pointing error an shim the tube assembly or mounting rings to eliminate the mechanical error. The other solution is to compensate for it with software. We now have incorporated an automated routine in the CP4 and new keypad software that measures the ortho error and compensates for it.

Roland Christen



-----Original Message-----
From: Steven Panish <scpanish@...>
To: main@ap-gto.groups.io
Sent: Sat, Nov 14, 2020 7:31 pm
Subject: [ap-gto] consistent goto error on meridian flip w/1200

My venerable 1200 has a large and consistent goto error after a meridian flip.  It is roughly 2 deg in RA and a couple minutes in Dec, I haven't actually measured it.  Very consistent, so in spite of being way off the sensor I know how to move the scope E/W to get the target back in sight.  After a recal, goto accuracy is restored.  This isn't mirror flop, the finder scope also shows the issue and I can use that for centering as well.  Mostly I avoid the problem by starting an imaging run counterweight up and avoiding a meridian flip altogether.  I bought this 1200 3 years ago and it has always had the issue.

Does anyone have a clue as to what is wrong?  Orthogonality?  The scope is a C9.25 and the finder is mounted on the scop so the dovetail could be off, everything else is AP and should be precise.   I can work with it but it would be nice to not have to think about it.  

Steve


Re: Stainless Steel Insert for Counterweight Shaft Threads

Harley Davidson
 

Thank you M Hambrick! I would assume AP could just make a new CW shaft adapter with that feature built in and you buy that and replace the one you have. Yet another wait list :)  I would definitely buy one for my 1600.

tony

On 11/13/2020 8:50 AM, M Hambrick wrote:
After watching Tony & Moose's most excellent video showing him unpacking his brand new Mach 2. I would like to know if the stainless steel insert in the counterweight shaft holder has been incorporated into the other mounts ? In particular the 1100 ? 


Re: PEMPro Data gathering

 

Hi Mike

generally you want the intersection of celestial equator and meridian. you want to avoid low altitude and near the poles

exposure time doesn't matter as much - a few seconds is fine

regarding noise, PEMPro does a great job of filtering that kind of stuff out. i'd say more cycles would help that. i typically aim for 12-15 cycles



On Sun, Nov 15, 2020 at 7:28 AM Mike Shade <mshade@q.com> wrote:

Have a few questions on best practices for PemPro data gathering.

 

1600GTO, early model (just had bearings replaced in RA/DEC gear boxes), Planewave CDK 17/unbinned image scale .631"/pixel/permanent setup

 

Is it best to gather data at 0 dec (about 55 degrees elevation), or higher (80 degrees) to minimize seeing effects?

 

If higher data gathering, calibrate here as well?

 

To minimize seeing effects, better to use a shorter exposure, say .25" and a longer delay between exposures, say 3" OR a longer exposure and longer delay (1" exposure/3" delay)?

 

When gathering data, I can watch the star in Maxim move quite a bit off of centroid in random directions.  Some is of course real PE, the rest noise.  I know the program can account for this to some extent, but this is a lot of noise and wonder if it is being represented in the final curve.

 

Generally get about 400 points for a PEC curve, more or less.

 

Thanks.

 

Mike J. Shade

Mike J. Shade Photography:

mshadephotography.com

 

In War: Resolution

In Defeat: Defiance

In Victory: Magnanimity

In Peace: Goodwill

Sir Winston Churchill

Already, in the gathering dusk, a few of the stars are turning on their lights.

Vega, the brightest one, is now dropping towards the west.  Can it be half

a year since I watched her April rising in the east?  Low in the southwest

Antares blinks a sad farwell to fall...

Leslie Peltier, Starlight Nights

 

International Dark Sky Association: www.darksky.org

 

 



--
Brian 



Brian Valente


PEMPro Data gathering

Mike Shade
 

Have a few questions on best practices for PemPro data gathering.

 

1600GTO, early model (just had bearings replaced in RA/DEC gear boxes), Planewave CDK 17/unbinned image scale .631"/pixel/permanent setup

 

Is it best to gather data at 0 dec (about 55 degrees elevation), or higher (80 degrees) to minimize seeing effects?

 

If higher data gathering, calibrate here as well?

 

To minimize seeing effects, better to use a shorter exposure, say .25" and a longer delay between exposures, say 3" OR a longer exposure and longer delay (1" exposure/3" delay)?

 

When gathering data, I can watch the star in Maxim move quite a bit off of centroid in random directions.  Some is of course real PE, the rest noise.  I know the program can account for this to some extent, but this is a lot of noise and wonder if it is being represented in the final curve.

 

Generally get about 400 points for a PEC curve, more or less.

 

Thanks.

 

Mike J. Shade

Mike J. Shade Photography:

mshadephotography.com

 

In War: Resolution

In Defeat: Defiance

In Victory: Magnanimity

In Peace: Goodwill

Sir Winston Churchill

Already, in the gathering dusk, a few of the stars are turning on their lights.

Vega, the brightest one, is now dropping towards the west.  Can it be half

a year since I watched her April rising in the east?  Low in the southwest

Antares blinks a sad farwell to fall...

Leslie Peltier, Starlight Nights

 

International Dark Sky Association: www.darksky.org

 

 

5601 - 5620 of 79807