Date   

Side-by-Side Balancing Procedure

M Hambrick
 

I have decided to change my imaging train from a piggyback arrangement to a side-by-side arrangement. I have three different imaging / guiding configurations that I must convert, and I started with the heaviest system I will be using. I have been following Roland's side-by-side balancing procedure, and for the most part it is pretty straightforward. In each step, the balancing is done using a wood dowel rod:

  1. Balance the first scope on its dovetail plate with all attachments and cables and mark the balance point.
  2. Balance the second scope on its dovetail plate with all attachments and cables and mark the balance point.
  3. Balance the side-by-side plate front to back with only the dovetail saddle plates attached and mark the balance point.
  4. Attach the scopes and dovetail plates to the respective saddle plates, lining up the balance points for the scopes with the front-to-back balance point on the side-by-side plate.
  5. Balance the side-by-side plate with the scopes attached (balancing is perpendicular to that in step 3) and mark the balance point.
  6. Mark the center of the mounting hole pattern that will be used to attach the primary (bottom) saddle plate to the declination top plate.
  7. Attach the entire system (scopes, dovetail plates, and side-by-side plate) to the primary saddle plate, lining up the mark from step 5 on the side-by-side plate with the mark at the center of the mounting holes in the primary saddle plate.
  8. Adjust the position of the side-by-side dovetail plate with scopes attached in the primary saddle plate so that it balances at the center of the mounting holes, then mark the balance point. saddle.
  9. When balanced, mark the position of the side-by-side plate in the primary saddle where it balances.
I did steps 7 - 9 with the primary dovetail saddle attached to the declination top plate, and I did the final balancing following the precision balancing procedure described in the mount manual. I am not sure the results were exactly what are described in the procedure, but what I ended up with seems intuitively to be correct.

  1. The balance points of the individual scopes and dovetail plates determined in steps 1 and 2 are centered over the north - south axis of the declination top plate.
  2. The balance point of the side-by side dovetail plate determined in step 5 is centered over the east - west axis of the declination top plate.
Does this make sense ?

Mike


Re: Moving APCC to a different computer

Ray Gralak
 

Hi Larry,

After installing APCC on a different computer, is there an easy way to copy APCC and APPM settings and
model to the second computer?
To copy all of the settings for APCC, APPM, and the driver, you can copy the folder c:\programdata\Astro-Physics from your old PC to the new PC.

Also, can APCC be active on two computers if I am only using one at a time?
Yes.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Larry Phillips
Sent: Thursday, December 9, 2021 6:45 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] Moving APCC to a different computer

After installing APCC on a different computer, is there an easy way to copy APCC and APPM settings and
model to the second computer?
Also, can APCC be active on two computers if I am only using one at a time?

Larry


Re: AP1600 Lost

Dale Ghent
 

Ah yes, I forgot about "Prevent Errant RECALs" (I have that turned off in my setups because of all the testing I do with NINA, so the last time that has gotten in the way of things has faded from my memory.)

On Dec 9, 2021, at 09:53, Ray Gralak <iogroups@...> wrote:

Hi Bob,

What Dale suggests will work unless the pointing error is more than 5 degrees and "Prevent Errant Recals" is enabled in APCC's Advanced settings. If you disable "Prevent Errant RECALs", make sure to re-enable it after syncing!

BTW, if you manually move the mount to the Park 3 position and unpark from Park 3, the mount should be pointing within 5 degrees. Thus, when you do a RECAL to regain precise pointing you will not need to disable "Prevent errant RECALs".

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Bob Enouen
Sent: Thursday, December 9, 2021 5:46 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] AP1600 Lost

Ahh! Thanks so much Dale! I’ll do that at the next clear sky night - which will be Sunday night here in
Springboro, OH.

Bob


Robert J. Enouen
Cell 513-504-4410

On Dec 9, 2021, at 8:12 AM, Dale Ghent <daleg@...> wrote:



Use the N/S/E/W buttons, either in APCC or in NINA, to drive the mount and point the telescope at a clear
patch of sky, then a manual plate solve+sync inside NINA from the Imaging -> Plate Solve window. The mount
will then know how it's oriented. There's no need to undo clutches and manually sling the OTA around to a
park position.

The main question is /how/ your mount got to disoriented. One of the ways this can happen is if you have
the mount parked in a particular position and then command it to unpark, but from a different position instead
of Last parked or from the actual park position it was parked at.


On Dec 9, 2021, at 08:05, Bob Enouen <renouen@...> wrote:

Hi Ray,

My observatory-based AP1600 CP4 lost its location last night after a few days of no activity due to
clouds. It’s been tracking great using a 300+ point APPM model on 180 second unguided exposures with a
RC 16” that has a 3250mm focal length. I’m forwarding the APPC Pro logs and the NINA logs for the last two
days for reference.

My question: I assume that if I physically release the RA/Dec gear boxes and move the mount to Park 3
and then Recal using Alt/Az in APPC Pro to that position this will get me close enough to then Recal using
PlateSolving. I do not have a hand control. Is this correct?

Thanks, Bob


Robert J. Enouen
Cell 513-504-4410
20211205-024656-2.0.0.2006.912.log
20211208-172149-2.0.0.2006.6568.log
ApccZip-BOB_ENOUEN-2021-12-09-061744.zip











Re: AP1600 Lost

Dale Ghent
 

What I is happening is that you have a saved site in APCC and NINA has its own lat/long (and now elevation) settings under Options > General > Astrometry. The prompt you see is because the two differ by a large enough amoun, and this triggers NINA to ask which one you want to use as the source of truth.

If you select "NINA to Telescope", NINA will tell the ASCOM driver to use its coordinates. If you select "Telescope to NINA", NINA will overwrite the profile settings with what the ASCOM driver is claiming to be the lat/long (and, now, elevation.) If you choose "NINA to Telescope", I believe what will happen in the APCC case is that the ASCOM driver will accept the coordinates that NINA sends, but only for the lifetime of the driver as it'll always launch and initialize with the site setting you have designated in APCC's initialization settings.

What you want to do in this case is first ensure that your site settings in APCC are indeed what you want them to be (you're in an observatory, it's not moving anywhere!) and, when NINA prompts you, select "Telescope to NINA". This will sync APCC's lat/long into your NINA profile and, since they're now the same, you'll avoid being asked the next time you start NINA with that profile.

On Dec 9, 2021, at 09:04, michael mccann via groups.io <mmccawsprojects@...> wrote:

Fast question, sort of related, when NINA first connects to APCC it always ask whether to sync mount-to.-NINA or NINA-to-mount. Which is preferred for one setup in observatory ?
On Dec 9, 2021, at 06:12, Dale Ghent <daleg@...> wrote:

Use the N/S/E/W buttons, either in APCC or in NINA, to drive the mount and point the telescope at a clear patch of sky, then a manual plate solve+sync inside NINA from the Imaging -> Plate Solve window. The mount will then know how it's oriented. There's no need to undo clutches and manually sling the OTA around to a park position.




Re: AP1600 Lost

Ray Gralak
 

Hi Bob,

What Dale suggests will work unless the pointing error is more than 5 degrees and "Prevent Errant Recals" is enabled in APCC's Advanced settings. If you disable "Prevent Errant RECALs", make sure to re-enable it after syncing!

BTW, if you manually move the mount to the Park 3 position and unpark from Park 3, the mount should be pointing within 5 degrees. Thus, when you do a RECAL to regain precise pointing you will not need to disable "Prevent errant RECALs".

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Bob Enouen
Sent: Thursday, December 9, 2021 5:46 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] AP1600 Lost

Ahh! Thanks so much Dale! I’ll do that at the next clear sky night - which will be Sunday night here in
Springboro, OH.

Bob


Robert J. Enouen
Cell 513-504-4410

On Dec 9, 2021, at 8:12 AM, Dale Ghent <daleg@...> wrote:



Use the N/S/E/W buttons, either in APCC or in NINA, to drive the mount and point the telescope at a clear
patch of sky, then a manual plate solve+sync inside NINA from the Imaging -> Plate Solve window. The mount
will then know how it's oriented. There's no need to undo clutches and manually sling the OTA around to a
park position.

The main question is /how/ your mount got to disoriented. One of the ways this can happen is if you have
the mount parked in a particular position and then command it to unpark, but from a different position instead
of Last parked or from the actual park position it was parked at.


On Dec 9, 2021, at 08:05, Bob Enouen <renouen@...> wrote:

Hi Ray,

My observatory-based AP1600 CP4 lost its location last night after a few days of no activity due to
clouds. It’s been tracking great using a 300+ point APPM model on 180 second unguided exposures with a
RC 16” that has a 3250mm focal length. I’m forwarding the APPC Pro logs and the NINA logs for the last two
days for reference.

My question: I assume that if I physically release the RA/Dec gear boxes and move the mount to Park 3
and then Recal using Alt/Az in APPC Pro to that position this will get me close enough to then Recal using
PlateSolving. I do not have a hand control. Is this correct?

Thanks, Bob


Robert J. Enouen
Cell 513-504-4410
20211205-024656-2.0.0.2006.912.log
20211208-172149-2.0.0.2006.6568.log
ApccZip-BOB_ENOUEN-2021-12-09-061744.zip






Moving APCC to a different computer

Larry Phillips
 

After installing APCC on a different computer, is there an easy way to copy APCC and APPM settings and model to the second computer?
Also, can APCC be active on two computers if I am only using one at a time?

Larry


Re: AP1600 Lost

michael mccann
 

Fast question, sort of related, when NINA first connects to APCC it always ask whether to sync mount-to.-NINA or NINA-to-mount. Which is preferred for one setup in observatory ?

On Dec 9, 2021, at 06:12, Dale Ghent <daleg@...> wrote:

Use the N/S/E/W buttons, either in APCC or in NINA, to drive the mount and point the telescope at a clear patch of sky, then a manual plate solve+sync inside NINA from the Imaging -> Plate Solve window. The mount will then know how it's oriented. There's no need to undo clutches and manually sling the OTA around to a park position.


Re: AP1600 Lost

Dale Ghent
 

To add, if the root cause for loss of orientation is still a mystery, another common cause is that the clock on your imaging computer has drifted substantially enough. This is evident if the loss of orientation appears to be on the RA axis only.

On Dec 9, 2021, at 08:46, Bob Enouen <renouen@...> wrote:

Ahh! Thanks so much Dale! I’ll do that at the next clear sky night - which will be Sunday night here in Springboro, OH.

Bob


Robert J. Enouen
Cell 513-504-4410

On Dec 9, 2021, at 8:12 AM, Dale Ghent <daleg@...> wrote:



Use the N/S/E/W buttons, either in APCC or in NINA, to drive the mount and point the telescope at a clear patch of sky, then a manual plate solve+sync inside NINA from the Imaging -> Plate Solve window. The mount will then know how it's oriented. There's no need to undo clutches and manually sling the OTA around to a park position.

The main question is /how/ your mount got to disoriented. One of the ways this can happen is if you have the mount parked in a particular position and then command it to unpark, but from a different position instead of Last parked or from the actual park position it was parked at.


On Dec 9, 2021, at 08:05, Bob Enouen <renouen@...> wrote:

Hi Ray,

My observatory-based AP1600 CP4 lost its location last night after a few days of no activity due to clouds. It’s been tracking great using a 300+ point APPM model on 180 second unguided exposures with a RC 16” that has a 3250mm focal length. I’m forwarding the APPC Pro logs and the NINA logs for the last two days for reference.

My question: I assume that if I physically release the RA/Dec gear boxes and move the mount to Park 3 and then Recal using Alt/Az in APPC Pro to that position this will get me close enough to then Recal using PlateSolving. I do not have a hand control. Is this correct?

Thanks, Bob


Robert J. Enouen
Cell 513-504-4410
20211205-024656-2.0.0.2006.912.log
20211208-172149-2.0.0.2006.6568.log
ApccZip-BOB_ENOUEN-2021-12-09-061744.zip








Re: AP1600 Lost

Bob Enouen
 

Ahh! Thanks so much Dale! I’ll do that at the next clear sky night - which will be Sunday night here in Springboro, OH.

Bob


Robert J. Enouen
Cell 513-504-4410

On Dec 9, 2021, at 8:12 AM, Dale Ghent <daleg@...> wrote:



Use the N/S/E/W buttons, either in APCC or in NINA, to drive the mount and point the telescope at a clear patch of sky, then a manual plate solve+sync inside NINA from the Imaging -> Plate Solve window. The mount will then know how it's oriented. There's no need to undo clutches and manually sling the OTA around to a park position.

The main question is /how/ your mount got to disoriented. One of the ways this can happen is if you have the mount parked in a particular position and then command it to unpark, but from a different position instead of Last parked or from the actual park position it was parked at.


On Dec 9, 2021, at 08:05, Bob Enouen <renouen@...> wrote:

Hi Ray,

My observatory-based AP1600 CP4 lost its location last night after a few days of no activity due to clouds. It’s been tracking great using a 300+ point APPM model on 180 second unguided exposures with a RC 16” that has a 3250mm focal length. I’m forwarding the APPC Pro logs and the NINA logs for the last two days for reference.

My question: I assume that if I physically release the RA/Dec gear boxes and move the mount to Park 3 and then Recal using Alt/Az in APPC Pro to that position this will get me close enough to then Recal using PlateSolving. I do not have a hand control. Is this correct?

Thanks, Bob


Robert J. Enouen
Cell 513-504-4410
20211205-024656-2.0.0.2006.912.log
20211208-172149-2.0.0.2006.6568.log
ApccZip-BOB_ENOUEN-2021-12-09-061744.zip





Re: AP1600 Lost

Dale Ghent
 

Use the N/S/E/W buttons, either in APCC or in NINA, to drive the mount and point the telescope at a clear patch of sky, then a manual plate solve+sync inside NINA from the Imaging -> Plate Solve window. The mount will then know how it's oriented. There's no need to undo clutches and manually sling the OTA around to a park position.

The main question is /how/ your mount got to disoriented. One of the ways this can happen is if you have the mount parked in a particular position and then command it to unpark, but from a different position instead of Last parked or from the actual park position it was parked at.

On Dec 9, 2021, at 08:05, Bob Enouen <renouen@...> wrote:

Hi Ray,

My observatory-based AP1600 CP4 lost its location last night after a few days of no activity due to clouds. It’s been tracking great using a 300+ point APPM model on 180 second unguided exposures with a RC 16” that has a 3250mm focal length. I’m forwarding the APPC Pro logs and the NINA logs for the last two days for reference.

My question: I assume that if I physically release the RA/Dec gear boxes and move the mount to Park 3 and then Recal using Alt/Az in APPC Pro to that position this will get me close enough to then Recal using PlateSolving. I do not have a hand control. Is this correct?

Thanks, Bob


Robert J. Enouen
Cell 513-504-4410
20211205-024656-2.0.0.2006.912.log
20211208-172149-2.0.0.2006.6568.log
ApccZip-BOB_ENOUEN-2021-12-09-061744.zip


AP1600 Lost

Bob Enouen
 

Hi Ray,

My observatory-based AP1600 CP4 lost its location last night after a few days of no activity due to clouds.  It’s been tracking great using a 300+ point APPM model on 180 second unguided exposures with a RC 16” that has a 3250mm focal length.  I’m forwarding the APPC Pro logs and the NINA logs for the last two days for reference.

My question: I assume that if I physically release the RA/Dec gear boxes and move the mount to Park 3 and then Recal using Alt/Az in APPC Pro to that position this will get me close enough to then Recal using PlateSolving.  I do not have a hand control.  Is this correct?

Thanks, Bob


Robert J. Enouen
Cell 513-504-4410


Re: APPM error

Sam Saeed
 

Hi Ray,

 

All sky model Data Points = 363 (took almost 2.75 hours)

I remote into the computer using an ethernet network.

Software running during the event were: APCC, APPM, MaximDL, and FocusMax (can’t remember if I had quit FocusMax before starting the modeling or not)

Nothing else running except windows 10 OS, no updates no Antivirus. This is a basic computer used for image acquisition only.

All devices (Camera, mount, focuser, Mbox) are connected using USB 3 interface.

 

However, I must mention this. I always have the Bluetooth and wifi hardware disabled all the time since I use an ethernet network. This particular evening, the internet to my observatory was not working due to some local reasons. I had to activate the wifi to use a hot spot from my cell phone to the the imaging computer just for internet connectivity. I have been using APCC and APPM for a year and half now on this computer. I find it exceptionally reliable with very minor things here and there that were easily resolved. This is the first time to see this particular error. So the only difference between then and now is the wifi interface was active.

 

As I mentioned before, the model seem to load anyway even after triggering the error.

 

Hope this helps

 

Sam

 

 

From: <main@ap-gto.groups.io> on behalf of Ray Gralak <iogroups@...>
Reply-To: <main@ap-gto.groups.io>
Date: Wednesday, December 8, 2021 at 12:09 PM
To: <main@ap-gto.groups.io>
Subject: Re: [ap-gto] APPM error

 

Sam,

 

The CPU is 8-years old but should be powerful enough. Three more questions:

 

  1. How many data points are in your model(s)?
  2. Are you directly on the computer or remoted into it when you load a model?
  3. Are there any other applications consuming CPU or updating the user interface when you load a model?

 

-Ray

 

From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Sam Saeed via groups.io
Sent: Wednesday, December 8, 2021 10:06 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM error

 

Hi Ray:

 

Thanks for the quick response.

 

Computer specs are in the attached screen shot. In addition the storage is Samsung 500GB SSD. This computer is a bit old (maybe 7 years old).

 

Sam Saeed

 

 

Graphical user interface, text, application

Description automatically generated

 

 

 

 

 

On 12/8/21, 8:32 AM, "Ray Gralak" <main@ap-gto.groups.io on behalf of iogroups@...> wrote:

 

    Hi Sam,

 

    That message means that APCC's command buffers were all used up. This can happen if APCC was doing something computationally expensive (like calculating a big model). It should clear itself out after APCC completes the computations. How many points were in your model? Also, which CPU does your computer use?

 

    -Ray

 

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

    > From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Sam Saeed via groups.io

    > Sent: Wednesday, December 8, 2021 8:18 AM

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

    > Subject: [ap-gto] APPM error

    >

    > This last weekend, I started getting this error every time I switch models in APPM. Please see attached screen

    > shot.

    >

    >

    >

    > In spite of the error, the model seems to load. But I’m not sure if it’s functioning properly or not as I could not

    > test it due to change in weather conditions.

    >

    >

    >

    > Has anyone seen this before? Any ideas?

    >

    >

    >

    > Thanks for your help

    >

    >

    >

    > Sam Saeed

    >

    >

    >

    >

    >

    > Graphical user interface

    > Description automatically generated

    >

    >

 

 

 

   

 

 


Re: AP-1100 Guiding Questions

Roland Christen
 

Another way you can determine if your backstop is set too tight and you have stiction, you can do this:

Turn the locking lever on the gearbox back (counterclockwise) by just a few degrees (not 180 for full unlock). What this does is to artificially move the backstop enough to reduce the pressure of the worm teeth on the worm wheel. Then see if the Dec guiding improves. You can also do a calibration and backlash test using 300msec pulses and see if the graphs look cleaner and more like the ideal.

We always adjust the backstop here at the factory, and use almost no pressure when setting it. Depending on how much vibration occurs during shipping, this setting may either loosen up or tighten. It's something you should be aware of if you want the mount operating at its best. Adjusting this is in the manual.

Roland

-----Original Message-----
From: chris1011@...
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Wed, Dec 8, 2021 3:24 pm
Subject: Re: [ap-gto] AP-1100 Guiding Questions


Play in Dec, I have measured it using the guiding assistant from PHD2 at different moments in time and generally got very small but inconsistent values for the backlash: from about 100msec up to about 400msec. I do not know how to interpret the variance. Maybe it is actually due to stiction (i.e. static friction) in Dec.
Stiction will show up in the backlash graph. During reversal the star actually moves further away from the zero line instead of heading towards the commanded zero point. The image below shows a Chinese import mount during reversal. The reversing command should send the next star position downward as the white dots show. Instead the star continues in the wrong direction, then doesn't move until several more commands are sent (green arrow). The Guiding Assistant doesn't know the difference between backlash and retrograde motion and subsequent non-movement of the axis, so it calls the delay backlash. The fact is, most of it is not backlash at all, and users attempt to fix it by tightening the mesh even more causes even more problems.

This particular graph is really really bad, some 100 times worse than anything you might encounter with an 1100. The pulse size of the movement shown below is 1799msec, which results in each step being a 27 arc sec command at 1x guide rate. for a precision mount like the 1100, I would not use anywhere near that size step for a backlash test. If you are looking for stiction at the arc sec level, the size of the step should be no greater than 300msec. For even finer resolution I would use 133msec steps. That would give you a resolution of 2 arc sec in axis motion. If you have any stiction, you will see it with those step sizes.

Roland



-----Original Message-----
From: Horia <ATM@...>
To: main@ap-gto.groups.io
Sent: Wed, Dec 8, 2021 1:39 pm
Subject: Re: [ap-gto] AP-1100 Guiding Questions

Thanks everybody for your support.
 
This is a new (both to me and to the world) mount. It left Astro-Physics end of August 2021.
 
For the moment the wether is as bad as bad goes and it looks like it will stay that way for the coming weeks so that I can only present older data.
 
@Roland
>> Your Dec guiding shows static friction which can be caused two ways.
>> 1) it will occur if your Dec axis is unbalanced.
>> 2) it will occur if you force the worm into mesh too tightly by not leaving
>> a small amount of clearance in the backstop adjustment.
 
I must have a closer look at this, especially the meshing. Both axes are well balanced: I can disengage the Dec worm and put the telescope in whatever position from horizontal to vertical and it will stay there.
 
Re. Play in Dec, I have measured it using the guiding assistant from PHD2 at different moments in time and generally got very small but inconsistent values for the backlash: from about 100msec up to about 400msec. I do not know how to interpret the variance. Maybe it is actually due to stiction (i.e. static friction) in Dec.
 
@Brian
This is a guide log from October. It contains just one Calibration run and mostly one free run (no guiding):
 
and this is the corresponding Graphic:
 
@Linwood
For the guiding assistant pls. see above.
 
Re. wires: I use through the mount cabling:
  • One cable for the Dec motor
  • One cable for Power (13.8V) – ultra flexible silicon cable
  • One USB cable
The USB/ Power distribution box is mounted directly on the saddle and there are no dangling wires:
 
 
 
 
For a closer look:
 
@Luca
For polar alignment pls. see above. I do not think the spikes in Dec are due to it.
 
Kind Regards,
Horia
 

--
Roland Christen
Astro-Physics


Re: AP-1100 Guiding Questions

Roland Christen
 


Play in Dec, I have measured it using the guiding assistant from PHD2 at different moments in time and generally got very small but inconsistent values for the backlash: from about 100msec up to about 400msec. I do not know how to interpret the variance. Maybe it is actually due to stiction (i.e. static friction) in Dec.
Stiction will show up in the backlash graph. During reversal the star actually moves further away from the zero line instead of heading towards the commanded zero point. The image below shows a Chinese import mount during reversal. The reversing command should send the next star position downward as the white dots show. Instead the star continues in the wrong direction, then doesn't move until several more commands are sent (green arrow). The Guiding Assistant doesn't know the difference between backlash and retrograde motion and subsequent non-movement of the axis, so it calls the delay backlash. The fact is, most of it is not backlash at all, and users attempt to fix it by tightening the mesh even more causes even more problems.

This particular graph is really really bad, some 100 times worse than anything you might encounter with an 1100. The pulse size of the movement shown below is 1799msec, which results in each step being a 27 arc sec command at 1x guide rate. for a precision mount like the 1100, I would not use anywhere near that size step for a backlash test. If you are looking for stiction at the arc sec level, the size of the step should be no greater than 300msec. For even finer resolution I would use 133msec steps. That would give you a resolution of 2 arc sec in axis motion. If you have any stiction, you will see it with those step sizes.

Roland



-----Original Message-----
From: Horia <ATM@...>
To: main@ap-gto.groups.io
Sent: Wed, Dec 8, 2021 1:39 pm
Subject: Re: [ap-gto] AP-1100 Guiding Questions

Thanks everybody for your support.
 
This is a new (both to me and to the world) mount. It left Astro-Physics end of August 2021.
 
For the moment the wether is as bad as bad goes and it looks like it will stay that way for the coming weeks so that I can only present older data.
 
@Roland
>> Your Dec guiding shows static friction which can be caused two ways.
>> 1) it will occur if your Dec axis is unbalanced.
>> 2) it will occur if you force the worm into mesh too tightly by not leaving
>> a small amount of clearance in the backstop adjustment.
 
I must have a closer look at this, especially the meshing. Both axes are well balanced: I can disengage the Dec worm and put the telescope in whatever position from horizontal to vertical and it will stay there.
 
Re. Play in Dec, I have measured it using the guiding assistant from PHD2 at different moments in time and generally got very small but inconsistent values for the backlash: from about 100msec up to about 400msec. I do not know how to interpret the variance. Maybe it is actually due to stiction (i.e. static friction) in Dec.
 
@Brian
This is a guide log from October. It contains just one Calibration run and mostly one free run (no guiding):
 
and this is the corresponding Graphic:
 
@Linwood
For the guiding assistant pls. see above.
 
Re. wires: I use through the mount cabling:
  • One cable for the Dec motor
  • One cable for Power (13.8V) – ultra flexible silicon cable
  • One USB cable
The USB/ Power distribution box is mounted directly on the saddle and there are no dangling wires:
 
 
 
 
For a closer look:
 
@Luca
For polar alignment pls. see above. I do not think the spikes in Dec are due to it.
 
Kind Regards,
Horia
 

--
Roland Christen
Astro-Physics


Re: AP-1100 Guiding Questions

ap@CaptivePhotons.com
 

Just to be clear -- again -- I was not suggesting that the calibration axes needed to align with the RA/DEC, only that the data points were a bit further off the calibration axes than I was used to seeing.  If they are good, great.  Sorry for the confusion.

And it may have been mine that had WAY too many points, as I may have changed things.  I posted it to show how close the points were to the calibration axes. 

This is the OP's calibration graph just for reference in case I confused things by posting a different one: 

I will go crawl back into my cave waiting for clear skies now.  :) 


Re: AP-1100 Guiding Questions

Worsel
 

FYI

The RA and Dec lines on the calibration graph do not need to align with the graph axes.  PHD2 can account for that.  What IS important is the the RA and Dec lines are close to orthogonal.   Horia's graph looks good. PHD2 would have alerted you if the orthogonality error was high.

See https://openphdguiding.org/man/Tools.htm#Calibration_Details

It did take 18 steps to complete a calibration.  PHD2 recommendation is 8-14 steps.  If you use the built-in calculator (Guiding Tab - Advanced), it will determine the exposure time needed to achieve just 12 steps.  18 steps is not terrible...it just takes longer to complete a calibration.  Too few steps is not desirable and will raise an alert.

Bryan


Re: AP-1100 Guiding Questions

ap@CaptivePhotons.com
 

Brian Valente wrote:

 

  • Linwood i'm not sure what you are referring to but the angle of the measurements vs the plot lines are not important 

 

I was referring to how far his calibration points were off the lines, not that the axes were not space aligned.


Re: AP-1100 Guiding Questions

 

Linwood i'm not sure what you are referring to but the angle of the measurements vs the plot lines are not important 

Part of calibration's purpose is to measure that angle offset and then it's used for guiding later. Orthogonality between the red and blue lines is important

Your calibration looks excellent here

On Wed, Dec 8, 2021 at 12:37 PM ap@... <ap@...> wrote:

Horia wrote:

 

  • The USB/ Power distribution box is mounted directly on the saddle and there are no dangling wires:

That's a cool setup, I did something similar with a Pegasus Pocket Powerbox under my saddle.

 

I doubt this is the issue, but for clarity I am talking about the wires that go through the mount.  Those wires will not snag in the conventional sense, but do need enough slack that they smoothly turns inside the axis as the axis turns.  If it is tight, as it turns, it will stick and release a bit on insides of the axis.  So all I was suggesting is make sure where it comes out from the mount on the saddle and on the bottom if you tug a bit on it with your fingers there's just a bit of slack.


If it was that I would expect it to be less frequent than your spikes, but just mentioning it.

 

Unrelated: In looking at the calibration, both axis are a bit more off the lines than mine.  I have encoders, so that might be the reason, I have no other experience as have not tried turning them off.   Below is my last calibration run.  

 

I'm clueless what it would suggest if yours is abnormal; it is not backlash since it is on RA also.   I'll let someone smarter comment more fully on the guide logs, but the RA axis drift looks larger than I would have expected (which could be calibration especially since it is similar to DEC), but again I could be jaded by encoders. 

 

 



--
Brian 



Brian Valente


Re: AP-1100 Guiding Questions

ap@CaptivePhotons.com
 

Horia wrote:

 

  • The USB/ Power distribution box is mounted directly on the saddle and there are no dangling wires:

That's a cool setup, I did something similar with a Pegasus Pocket Powerbox under my saddle.

 

I doubt this is the issue, but for clarity I am talking about the wires that go through the mount.  Those wires will not snag in the conventional sense, but do need enough slack that they smoothly turns inside the axis as the axis turns.  If it is tight, as it turns, it will stick and release a bit on insides of the axis.  So all I was suggesting is make sure where it comes out from the mount on the saddle and on the bottom if you tug a bit on it with your fingers there's just a bit of slack.


If it was that I would expect it to be less frequent than your spikes, but just mentioning it.

 

Unrelated: In looking at the calibration, both axis are a bit more off the lines than mine.  I have encoders, so that might be the reason, I have no other experience as have not tried turning them off.   Below is my last calibration run.  

 

I'm clueless what it would suggest if yours is abnormal; it is not backlash since it is on RA also.   I'll let someone smarter comment more fully on the guide logs, but the RA axis drift looks larger than I would have expected (which could be calibration especially since it is similar to DEC), but again I could be jaded by encoders. 

 

 


Re: APPM error

Ray Gralak
 

Sam,

 

The CPU is 8-years old but should be powerful enough. Three more questions:

 

1)    How many data points are in your model(s)?

2)    Are you directly on the computer or remoted into it when you load a model?

3)    Are there any other applications consuming CPU or updating the user interface when you load a model?

 

-Ray

 

From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Sam Saeed via groups.io
Sent: Wednesday, December 8, 2021 10:06 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM error

 

Hi Ray:

 

Thanks for the quick response.

 

Computer specs are in the attached screen shot. In addition the storage is Samsung 500GB SSD. This computer is a bit old (maybe 7 years old).

 

Sam Saeed

 

 

Graphical user interface, text, application

Description automatically generated

 

 

 

 

 

On 12/8/21, 8:32 AM, "Ray Gralak" <main@ap-gto.groups.io on behalf of iogroups@...> wrote:

 

    Hi Sam,

 

    That message means that APCC's command buffers were all used up. This can happen if APCC was doing something computationally expensive (like calculating a big model). It should clear itself out after APCC completes the computations. How many points were in your model? Also, which CPU does your computer use?

 

    -Ray

 

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

    > From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Sam Saeed via groups.io

    > Sent: Wednesday, December 8, 2021 8:18 AM

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

    > Subject: [ap-gto] APPM error

    >

    > This last weekend, I started getting this error every time I switch models in APPM. Please see attached screen

    > shot.

    >

    >

    >

    > In spite of the error, the model seems to load. But I’m not sure if it’s functioning properly or not as I could not

    > test it due to change in weather conditions.

    >

    >

    >

    > Has anyone seen this before? Any ideas?

    >

    >

    >

    > Thanks for your help

    >

    >

    >

    > Sam Saeed

    >

    >

    >

    >

    >

    > Graphical user interface

    > Description automatically generated

    >

    >

 

 

 

   

 

 

4861 - 4880 of 88201