Date   

NGC 3347 and NGC 3358

Geoff Smith
 

NGC 3347 is an elongated spiral galaxy, while NGC 3358 is a face-on lenticular galaxy There is a barely visible faint tidal stream between NGC 3347 and the smaller round spiral NGC 3354. Both NGC 3347 and NGC 3354 have similar red-shifts, suggesting that this is a genuine association and not merely a line-of-sight coincidence.

Plane Wave 12.5" CDK on AP900 with FLI Proline 16803

Technical details here https://www.astrobin.com/qlym15/

Higher resolution here https://www.astrobin.com/full/qlym15/0/

Geoff


Questions.....does wireless now work correctly with latest updates AND does your Sky Safari 6 Pro allow multiple Park positions now.

Robert Berta
 

Background....since I got my 1100 mount (early model) with CP4 I tried to get it to work reliably with Sky Safari 6 Pro wireless via the AP built in wireless module. This is with Android cell phone and also Samsung Galaxy tablets.

In addition I and other AP owners were hoping that Sky Safari 6 Pro would support the multiple choices of Park positions. After updating my CP4 to the latest version firmware I noted that one fix in the update log was an improvement to wireless. Keeping my finger crossed I gave it a try.

I am also a BETA tester for Sky Safari and the version I have now has multiple Park positions including a user selectable position...just like the mount hand controller with latest AP firmware hand controller updates.

I fired up my AP wireless and FINALLY it seemed to work correctly and doesn't drop the connection as both Android and Apple products had issues staying connected before.

Could some other owners test both the wireless with Sky Safari 6Pro and also whether their non-BETA version has the additional Park positions feature now? I am hoping that finally both issues have been put to bed. I will do some more testing myself soon.


Re: APPM Image Scale Question and Suggestions

Mike Dodd
 

On 4/17/2021 8:23 PM, Ray Gralak wrote:
What am I missing?
Marty said 2x2 binning was producing images with 1 arc-sec/pixel
scale. What other reason would there be for 2x2 binning to produce 1
arc/sec pixel when each pixel is 0.26 arc-seconds? It *should*
produce 0.52 arc-sec/pixel image, right?
Yes. Something didn't "click." Sorry for my confusion.

--- Mike


Re: APPM Image Scale Question and Suggestions

Ray Gralak
 

What am I missing?
Marty said 2x2 binning was producing images with 1 arc-sec/pixel scale. What other reason would there be for 2x2 binning to produce 1 arc/sec pixel when each pixel is 0.26 arc-seconds? It *should* produce 0.52 arc-sec/pixel image, right?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Mike Dodd
Sent: Saturday, April 17, 2021 3:43 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM Image Scale Question and Suggestions

On 4/17/2021 6:31 PM, Ray Gralak wrote:

However, since this is a color camera, if each group of 4-pixels is
considered 1 pixel, then you should enter 0.52 arc-secs/pixel in APPM
for the X and Y image scale values.
I don't understand that, Ray. A pixel is a pixel regardless of the color
filter over it.

When an image is debayered, the debayering algorithm gets light values
from every pixel, and assigns RGB values to the same pixels in the color
image.

the resulting color image has the same number of pixels as the
non-debayered image. The image size is unchanged.

What am I missing?

--- Mike







Re: APPM Image Scale Question and Suggestions

John Jennings
 

Mike,

I also have a 130GTX with Quad reducer/flattener on a APMach1. With a full frame QHY410C or my QHY268C (APS-C) it literally screams through the sky plate solving instantly like a maniac in the same Bortle 8 skies.

John


Re: APPM Image Scale Question and Suggestions

John Jennings
 

Mike,

You didn't mention if you are in a light polluted area or have dark skies. I live in a Bortle 8 sky. I had a lot of trouble Plate Solving with my Mewlon 300 reduced to f10 with the small pixels (4.63micron) of the QHY294C. I see your using USNO A2.0 for the narrow field of view. That helps a lot, but sometimes the GSC would work better in a specific area. For me in the city, it depended on what area of the sky I was solving for and how many stars were available. When I was doing a mapping run with APPC Pro with my AP900, if the Milky Way was overhead, it was a easy. At other times when the sky was star sparse, it was erratic.  I tried all types of binning with inconsistent results.  In the end, I switched  for a test to an old big pixel camera QHY8 (7.8micron) and binned x 2 and never had a problem. Almost 100% solves. I created a perfect mapping run and switched back to the 294C for imaging. When I finally switched to a full frame camera, it became easy too with the small pixels.  It's just tough with a narrow field of view, small pixels, small chip,  slow f ratio and bright skies.


bugs in my 1200!

Steven Panish
 

I think this is a George or Howard question, but any knowlegable input is welcome. 

After removing the saddle from my 1200, I saw that the unused perimeter screw holes in th dec head had been stuffed with mud, likely by a mud dauber or similar wasp enthralled by such a nice nursery site.  I used a small screwdriver to break out the dried mud, and then vacuumed the holes, but for sure some of the dirt went inside the head, and the threads are still clogged and more dirt will be broken loose when I use those holes.  Is that area inside the head sensitive to the dirt?  Should I remove the cap screws and pull the housing to clean it, or is further cleaning unnecessary?

I guess the bird poop question can go to another group....

thanks,

Steve


Re: APPM Image Scale Question and Suggestions

Mike Dodd
 

On 4/17/2021 6:31 PM, Ray Gralak wrote:

However, since this is a color camera, if each group of 4-pixels is
considered 1 pixel, then you should enter 0.52 arc-secs/pixel in APPM
for the X and Y image scale values.
I don't understand that, Ray. A pixel is a pixel regardless of the color filter over it.

When an image is debayered, the debayering algorithm gets light values from every pixel, and assigns RGB values to the same pixels in the color image.

the resulting color image has the same number of pixels as the non-debayered image. The image size is unchanged.

What am I missing?

--- Mike


Re: APPM Image Scale Question and Suggestions

Ray Gralak
 

Hi Marty,

2x2 binning of 0.26 arc-secs/pixel should be 0.52 arc-secs/pixel, not 1.0 arc-secs/pixel.

However, since this is a color camera, if each group of 4-pixels is considered 1 pixel, then you should enter 0.52 arc-secs/pixel in APPM for the X and Y image scale values.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of mjb87 via groups.io
Sent: Saturday, April 17, 2021 9:12 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM Image Scale Question and Suggestions

Hi everyone.

I have used APPM successfully with my Mach2 and 130mm Starfire GTX. I am now trying to build a model for my
1100 with a CFF 300 on it. I have some specific questions about image scale. I'm using USNO A2.0.

The camera is a ASI1600MC-Cool with a 0.67 focal reducer on a 300mm f/15 Cassegrain. I calculate unbinned
image scale at just under 0.26, which is of course pretty small. I binned 2x2. My initial run was not successful --
many failures, often reported as due to potential image scale issues. Later, using the image-link-test solve
capabilities, I was able to get a couple of the earlier images to solve, but the estimated image scale in those
calculations was reported just over 1.0. When I re-ran the image-link-test solving with that 1.0 entered for image
scale I got about half the images to solve easily.

Question #1: Is this inconsistency because of the 2x2 binning? Does the plate-solve results in the Image-Link-Test
display estimated unbinned or binned image scale? The math works: 4 x 0.26 is about what was reported.

Question #2: Just to confirm, then, that when I enter X-scale and Y-scale factors in the platesolve setup, I should
enter the unbinned values, right (0.26)? The software will then adjust, I assume, for the binning.

Question #3: What options should I play with to reduce the potential for failed solutions due to image scale issues.
How high can I set (realistically) the Image Scale Tolerance? Is 50% too high? 100%? I also assume it would be
helpful to set Catalog Expansion to a higher value, maybe to the max at 0.8. I'n not trying to get fast solutions, just
more solutions.

Question #4: Any other suggestions for running APPM with such a small image scale? I was worried about getting
enough stars so I increased the exposure time on the camera (from 5 to 15) and reduced the sigma above mean
(from 4 to 3). Anything else?

Thanks.

Marty


Re: APPM Image Scale Question and Suggestions

mjb87@...
 
Edited

Hi Brian,

I did exactly that. Entered 0.26 for both X and Y and then 2x2 binning. I only raise it because when you look at the results *(when I retested some images the next day) of image-link testing when it reports the image's estimated scale it reported 1.04. So I suspect the latter is binned results. 

Marty


Re: #Mach2GTO #APCC #Absolute_Encoders #Mach2GTO #APCC #Absolute_Encoders

John Upton
 

Rolando & Ray,

   Thank you both for the details and deep dive into how this works. I appreciated the depth of the information.

   Now that Rolando mentions that the tracking is not turned off when Home Position is found, I recall that I also observed that and had left out a step in my procedure in the initial post here. Immediately after the Home Position had been found, I had to Toggle Tracking off before querying the mount's position. I had not considered the slight offset that happens when the motors are de-energized following a Park command compared to just stopping the tracking after finding Home.

   Your explanations tied all of that together nicely.

John


Re: APPM Image Scale Question and Suggestions

 

Hi Marty

Just to confirm, you should enter the unbinned image scale, and then choose your binning in APPM

I'm not sure what you did in this regard

Brian


On Sat, Apr 17, 2021 at 9:12 AM mjb87 via groups.io <mjb87=verizon.net@groups.io> wrote:
Hi everyone.

I have used APPM successfully with my Mach2 and 130mm Starfire GTX. I am now trying to build a model for my 1100 with a CFF 300 on it.  I have some specific questions about image scale. I'm using USNO A2.0.

The camera is a ASI1600MC-Cool with a 0.67 focal reducer on a 300mm f/15 Cassegrain. I calculate unbinned image scale at just under 0.26, which is of course pretty small. I binned 2x2. My initial run was not successful -- many failures, often reported as due to potential image scale issues. Later, using the image-link-test solve capabilities, I was able to get a couple of the earlier images to solve, but the estimated image scale in those calculations was reported just over 1.0. When I re-ran the image-link-test solving with that 1.0 entered for image scale I got about half the images to solve easily.

Question #1: Is this inconsistency because of the 2x2 binning? Does the plate-solve results in the Image-Link-Test display estimated unbinned or binned image scale?  The math works: 4 x 0.26 is about what was reported. 

Question #2: Just to confirm, then, that when I enter X-scale and Y-scale factors in the platesolve setup, I should enter the unbinned values, right (0.26)? The software will then adjust, I assume, for the binning.

Question #3:  What options should I play with to reduce the potential for failed solutions due to image scale issues.  How high can I set (realistically) the Image Scale Tolerance?  Is 50% too high?  100%?  I also assume it would be helpful to set Catalog Expansion to a higher value, maybe to the max at 0.8.  I'n not trying to get fast solutions, just more solutions.

Question #4: Any other suggestions for running APPM with such a small image scale?  I was worried about getting enough stars so I increased the exposure time on the camera (from 5 to 15) and reduced the sigma above mean (from 4 to 3). Anything else?

Thanks.

 Marty



--
Brian 



Brian Valente


APPM Image Scale Question and Suggestions

mjb87@...
 

Hi everyone.

I have used APPM successfully with my Mach2 and 130mm Starfire GTX. I am now trying to build a model for my 1100 with a CFF 300 on it.  I have some specific questions about image scale. I'm using USNO A2.0.

The camera is a ASI1600MC-Cool with a 0.67 focal reducer on a 300mm f/15 Cassegrain. I calculate unbinned image scale at just under 0.26, which is of course pretty small. I binned 2x2. My initial run was not successful -- many failures, often reported as due to potential image scale issues. Later, using the image-link-test solve capabilities, I was able to get a couple of the earlier images to solve, but the estimated image scale in those calculations was reported just over 1.0. When I re-ran the image-link-test solving with that 1.0 entered for image scale I got about half the images to solve easily.

Question #1: Is this inconsistency because of the 2x2 binning? Does the plate-solve results in the Image-Link-Test display estimated unbinned or binned image scale?  The math works: 4 x 0.26 is about what was reported. 

Question #2: Just to confirm, then, that when I enter X-scale and Y-scale factors in the platesolve setup, I should enter the unbinned values, right (0.26)? The software will then adjust, I assume, for the binning.

Question #3:  What options should I play with to reduce the potential for failed solutions due to image scale issues.  How high can I set (realistically) the Image Scale Tolerance?  Is 50% too high?  100%?  I also assume it would be helpful to set Catalog Expansion to a higher value, maybe to the max at 0.8.  I'n not trying to get fast solutions, just more solutions.

Question #4: Any other suggestions for running APPM with such a small image scale?  I was worried about getting enough stars so I increased the exposure time on the camera (from 5 to 15) and reduced the sigma above mean (from 4 to 3). Anything else?

Thanks.

 Marty


Re: #Mach2GTO #APCC #Absolute_Encoders #Mach2GTO #APCC #Absolute_Encoders

Roland Christen
 

Find home sends the mount to the Park 3 position but does not park the mount. It also re-calibrates the mount to this position so that you can recover from mount being lost due to an errant sync or recal. The mount will also resume tracking at the sidereal rate. Therefore the RA position will not change (mount continues to track the RA) but the Altitude/Azimuth will slowly change as the mount tracks the earth's rotation.

Park3 sends the mount to the same position but does not recalibrate the mount. It also shuts off power to the motors which stops tracking in RA. The RA position changes as the earth turns on its axis, but the Altitude/Azimuth position will remain the same. The exact Alt/Az position will change very slightly as the motors are de-energized because being steppers, they will drop into the nearest null position of the rotor/stator alignment. This amounts to +- 7.2 arc seconds of precise position change when the holding current is removed. However, this means nothing since the absolute encoders keep track of the precise shaft position at all times when the mount is de-energized in Park or even when power is removed. Therefore, to be absolutely accurate when turning power back on, simply start the mount from present position instead of forcing it to start from Park3 or other park positions.

Rolando



-----Original Message-----
From: John Upton <upton@...>
To: main@ap-gto.groups.io
Sent: Fri, Apr 16, 2021 10:31 pm
Subject: [ap-gto] #Mach2GTO #APCC #Absolute_Encoders

Hi Everyone,

   Being new to Astro-Physics mounts and hampered by cloudy skies since getting my Mach2 a couple of weeks ago, I have a bunch of small questions. I'll be asking these over the next few days.

Here is Question #1:
What is the difference between the Mach2 Home and Park-3 positions?

   I have noticed that if I tell APCC to Find home (from the AE Tab) and then query its position (from the GoTo/Recal Tab) it gives me position almost exactly as I expected -- Alt/Az is equal to my Latitude and Azimuth of 0. The mount is not parked after this Find Home operation but tracking is turned off.

   Now, If I Park the mount to Park-3 using the Park Tab of APCC, the mount will slew ever so slightly -- practically invisible to the eye. However after this miniscule slew, if I again query the mount's position as before, I see that the reported position is ever so slightly different from that reported after the Homing. The reported Alt/Az now shows the altitude a little off a tiny amount from my Latitude and the Azimuth is now up to 10 arc-seconds from 0 and seems to vary from one Park to the next.

   What I have read in the manuals, says the Find Home is highly accurate and is set via the encoders at the factory. That is easy to understand. However, why is this not consider to be the same physical position as Park-3?

   It's not like this is terribly important because the difference in positions is tiny but why is there a difference at all?

John

--
Roland Christen
Astro-Physics


Re: Starting with counterweight up in SGPro #Mach2GTO

Eric Weiner
 

Ray,

Fair. I’ll ask Jared and let the folks here know how he responds.

Eric

On Apr 17, 2021, at 07:20, Ray Gralak <iogroups@siriusimaging.com> wrote:

Eric,

As a follow on, regarding operations with imaging software. I use SGP. It seems that once you have the horizon and
meridian limits set correctly in APCC for CW up east and west slews that all meridian tracking and pier flip features
in SGP should be turned off, and that meridian reporting from APCC to SGP should also be turned off. Would you
agree?
That's a question for the SGP developers. It may be that SGP always expects the pier side to match what it should be, but it won’t be in counterweight-up positions.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Eric Weiner
Sent: Friday, April 16, 2021 9:19 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Starting with counterweight up in SGPro #Mach2GTO

Ray,

Thanks. After I sent those messages I watched your videos a few more times and re-read the APCC instructions. I
found that I have been creating the meridian limit models incorrectly. The instructions clearly state how to set the
first point, something I wasn’t doing, and that for subsequent points one should slew to the horizon if you don’t hit
the pier. I wasn’t doing that either. Reading is fundamental... everything is working perfectly now.

As a follow on, regarding operations with imaging software. I use SGP. It seems that once you have the horizon and
meridian limits set correctly in APCC for CW up east and west slews that all meridian tracking and pier flip features
in SGP should be turned off, and that meridian reporting from APCC to SGP should also be turned off. Would you
agree? It sure seems unnecessary at that point since the APCC horizon and meridian limit settings will take care of
all slews and stock tracking at the limits.

Eric

On Apr 16, 2021, at 07:19, Ray Gralak <iogroups@siriusimaging.com> wrote:
Hi Eric,

Would you say it is best practice to just reflect the
greater of the two limits w.r.t. east and west for margin.
No, that might cause a pier collision if the West limits exceed the East limits.

Instead, since you want East limits for both pier sides, you should:

1) Click "Reflect East".
2) Click "More" -> "Copy East to West"

This will set the East values for both East and West meridian limits.

Also, you might want to save the meridian limits to disk first, which would allow you to start from the original data
in the future.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Eric Weiner
Sent: Thursday, April 15, 2021 9:33 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Starting with counterweight up in SGPro #Mach2GTO

Ray,

I’ve got a follow on question to this topic. I created a detailed meridian tracking limit for my setup (Mach2/Tak
130NFB). The limits ended up not being symmetric for east and west, with larger limits in the west. Therefore,
when
the negative values in the east side are copied over to the west side, there is still a positive limit remaining on
the west
side. Will this prevent this technique from working correctly? Would you say it is best practice to just reflect the
greater of the two limits w.r.t. east and west for margin, then apply this CW up technique described in this
thread?















Re: #Mach2GTO #APCC #Absolute_Encoders #Mach2GTO #APCC #Absolute_Encoders

Ray Gralak
 

Hi John,

Home is a physically fixed position. However, the park positions can vary slightly because they are relative to the last synched or recalibrated coordinates, which may be "off" slightly because of polar alignment error, equipment flexure, refraction, etc.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of John Upton
Sent: Friday, April 16, 2021 8:31 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] #Mach2GTO #APCC #Absolute_Encoders

Hi Everyone,

Being new to Astro-Physics mounts and hampered by cloudy skies since getting my Mach2 a couple of weeks ago, I
have a bunch of small questions. I'll be asking these over the next few days.

Here is Question #1:
What is the difference between the Mach2 Home and Park-3 positions?

I have noticed that if I tell APCC to Find home (from the AE Tab) and then query its position (from the GoTo/Recal
Tab) it gives me position almost exactly as I expected -- Alt/Az is equal to my Latitude and Azimuth of 0. The mount is
not parked after this Find Home operation but tracking is turned off.

Now, If I Park the mount to Park-3 using the Park Tab of APCC, the mount will slew ever so slightly -- practically
invisible to the eye. However after this miniscule slew, if I again query the mount's position as before, I see that the
reported position is ever so slightly different from that reported after the Homing. The reported Alt/Az now shows the
altitude a little off a tiny amount from my Latitude and the Azimuth is now up to 10 arc-seconds from 0 and seems to
vary from one Park to the next.

What I have read in the manuals, says the Find Home is highly accurate and is set via the encoders at the factory.
That is easy to understand. However, why is this not consider to be the same physical position as Park-3?

It's not like this is terribly important because the difference in positions is tiny but why is there a difference at all?

John


Re: Starting with counterweight up in SGPro #Mach2GTO

Ray Gralak
 

Eric,

As a follow on, regarding operations with imaging software. I use SGP. It seems that once you have the horizon and
meridian limits set correctly in APCC for CW up east and west slews that all meridian tracking and pier flip features
in SGP should be turned off, and that meridian reporting from APCC to SGP should also be turned off. Would you
agree?
That's a question for the SGP developers. It may be that SGP always expects the pier side to match what it should be, but it won’t be in counterweight-up positions.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Eric Weiner
Sent: Friday, April 16, 2021 9:19 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Starting with counterweight up in SGPro #Mach2GTO

Ray,

Thanks. After I sent those messages I watched your videos a few more times and re-read the APCC instructions. I
found that I have been creating the meridian limit models incorrectly. The instructions clearly state how to set the
first point, something I wasn’t doing, and that for subsequent points one should slew to the horizon if you don’t hit
the pier. I wasn’t doing that either. Reading is fundamental... everything is working perfectly now.

As a follow on, regarding operations with imaging software. I use SGP. It seems that once you have the horizon and
meridian limits set correctly in APCC for CW up east and west slews that all meridian tracking and pier flip features
in SGP should be turned off, and that meridian reporting from APCC to SGP should also be turned off. Would you
agree? It sure seems unnecessary at that point since the APCC horizon and meridian limit settings will take care of
all slews and stock tracking at the limits.

Eric

On Apr 16, 2021, at 07:19, Ray Gralak <iogroups@siriusimaging.com> wrote:

Hi Eric,

Would you say it is best practice to just reflect the
greater of the two limits w.r.t. east and west for margin.
No, that might cause a pier collision if the West limits exceed the East limits.

Instead, since you want East limits for both pier sides, you should:

1) Click "Reflect East".
2) Click "More" -> "Copy East to West"

This will set the East values for both East and West meridian limits.

Also, you might want to save the meridian limits to disk first, which would allow you to start from the original data
in the future.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Eric Weiner
Sent: Thursday, April 15, 2021 9:33 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Starting with counterweight up in SGPro #Mach2GTO

Ray,

I’ve got a follow on question to this topic. I created a detailed meridian tracking limit for my setup (Mach2/Tak
130NFB). The limits ended up not being symmetric for east and west, with larger limits in the west. Therefore,
when
the negative values in the east side are copied over to the west side, there is still a positive limit remaining on
the west
side. Will this prevent this technique from working correctly? Would you say it is best practice to just reflect the
greater of the two limits w.r.t. east and west for margin, then apply this CW up technique described in this
thread?










#Mach2GTO #APCC #Absolute_Encoders #Mach2GTO #APCC #Absolute_Encoders

John Upton
 

Hi Everyone,

   Being new to Astro-Physics mounts and hampered by cloudy skies since getting my Mach2 a couple of weeks ago, I have a bunch of small questions. I'll be asking these over the next few days.

Here is Question #1:
What is the difference between the Mach2 Home and Park-3 positions?

   I have noticed that if I tell APCC to Find home (from the AE Tab) and then query its position (from the GoTo/Recal Tab) it gives me position almost exactly as I expected -- Alt/Az is equal to my Latitude and Azimuth of 0. The mount is not parked after this Find Home operation but tracking is turned off.

   Now, If I Park the mount to Park-3 using the Park Tab of APCC, the mount will slew ever so slightly -- practically invisible to the eye. However after this miniscule slew, if I again query the mount's position as before, I see that the reported position is ever so slightly different from that reported after the Homing. The reported Alt/Az now shows the altitude a little off a tiny amount from my Latitude and the Azimuth is now up to 10 arc-seconds from 0 and seems to vary from one Park to the next.

   What I have read in the manuals, says the Find Home is highly accurate and is set via the encoders at the factory. That is easy to understand. However, why is this not consider to be the same physical position as Park-3?

   It's not like this is terribly important because the difference in positions is tiny but why is there a difference at all?

John


Re: Newbie needs APPM software advice #APCC

Mike Dodd
 

On 4/16/2021 9:53 PM, KHursh via groups.io wrote:
It's part of APCC Pro. You can read about it in the manual.
Thanks (and Bryan too). I have the manual, and I will check it out.

It allows
APCC to map the sky for the purpose of tracking and pointing to such a
high degree of accuracy that one shouldn't need to guide at moderate
focal lengths and reasonable subframe length.
That's specifically why I'm considering APCC Pro. I have a 130mm f/7 OTA, and typically take 10-minute subs. My guiding usually runs around 0.5 arcsec RMS error, but I wouldn't mind if it were better.

--- Mike


Re: Newbie needs APPM software advice #APCC

 

  >>>What is APPM?

Astro Physics Point Mapper. it's part of Astro Physics Control Center (APCC) software, it's for building a sky model for more accurate pointing and tracking.




On Fri, Apr 16, 2021 at 6:49 PM Mike Dodd <mike@...> wrote:
On 4/16/2021 9:45 PM, KHursh via groups.io wrote:
> A-P Point Mapping

Hmmm.... I don't see anything about that on the AP website. Is it needed
along with APCC?

--- mike








--
Brian 



Brian Valente

5241 - 5260 of 83092