Date   

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


Re: Newbie needs APPM software advice #APCC

KHursh
 

It's part of APCC Pro. You can read about it in the manual. 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.


Re: Newbie needs APPM software advice #APCC

Worsel
 

Mike

It is part of APCC Pro.

See Chapter 13 in the APCC Pro manual.  https://www.astro-physics.info/tech_support/software/apcc/apcc-pro.pdf


Bryan


Re: Newbie needs APPM software advice #APCC

Mike Dodd
 

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


Re: Newbie needs APPM software advice #APCC

KHursh
 

A-P Point Mapping. 


Re: Newbie needs APPM software advice #APCC

Mike Dodd
 

I must have slept through the class -- what is APPM? I know about APCC, and an considering that myself for my 1200 mount. But I don't know anything about APPM.

--- Mike


Re: Newbie needs APPM software advice #APCC

Joseph Beyer
 

Jil,

Like everything your experience will depend on your entire setup.  Given my sky conditions from my backyard I'm limited to 3-5 minute subs with a DSLR camera.  I wanted to try unguided imaging with my late model Mach1 using APPM and it works very well.  I can easily take 3 minutes images across the sky and maintain pinpoint stars.  On nights with good seeing 5 minute subs are similar.  Setting up and running APPM is actually quite easy.  There are only a few steps needed to get things working so trouble shooting is simple.  It took more time to get SGP up and running with it than it did APPM.  I'm confident in saying you'll appreciate all the features and improved accuracy the program provides.

Joe


Re: Starting with counterweight up in SGPro #Mach2GTO

Eric Weiner
 

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: AP1200 wont slew correctly

Jeff B
 

"You need a new battery and re-load the database.

Rolando"

Boom.

I just did this myself as well for one of my keypads and I also updated it to the latest firmware.  Straight forward to do all, just take your time, and the reloads and update both do take a bit of run time so I mowed the lawn and raked some grass up while the ones and zeros slowly were doing their thing.

Jeff

On Fri, Apr 16, 2021 at 11:47 AM Roland Christen via groups.io <chris1011=aol.com@groups.io> wrote:
You need a new battery and re-load the database.

Rolando



-----Original Message-----
From: Luke Dodd <lkdodd@...>
To: main@ap-gto.groups.io
Sent: Thu, Apr 15, 2021 7:04 pm
Subject: [ap-gto] AP1200 wont slew correctly

Hi
 
I have returned to astrophotography after a 10 year break and dragged out my AP1200. Its running the GTOCP3 version. Problem I am having is the mount wont slew to objects correctly.
 
For example I synch on sirius and when I do a Goto command to M42 the keypad states object 30 degrees below horizon?
 
If I synch on Canopus it wont slew to Eta Carinae, it slews but the the scope is pointing about 20 Degrees off?
 
Even after I have refreshed the lat/long and time zone, coordinates of objects seems way off.
 
Do i have corrupted database? any help appreciated.
 
regards Luke

--
Roland Christen
Astro-Physics

1841 - 1860 of 79684