Hi Roland or Howard,
Which ST series filter wheel (CFW-8A or CFW10) is correct for using
the AP ADATCC2 adapter to connect to ST10XME camera? The AP web site
says "common close coupled version", but I don't know the SBIG parts
by that name. There are two sizes of SBIG filter wheels for the ST
series cameras. The CFW-8A (now a CFW9 I believe), hold 5 filters, and
takes up 1 inch of backspace when closely coupled.
The CFW10 holds 10 filters, and takes up 0.6 inch when close coupled.
Thanks, Rick

In a message dated 1/3/2009 8:07:06 PM Central Standard Time,
divenuts@... writes:

Hi Rolando,
I have a new 1200GTO estimated to be delivered in Feb.....will
this 'bug' be corrected next month when my new mount is scheduled to
be delivered? I hate to hear about 'bugs' and the like when I have
been waiting for quite some time for an expensive product.
Thanks,
Charles Callaghan

There is no bug in the mount. All time problems are caused by individuals not
understanding how to use their mount. The position of an object in the sky is
dependent on the time of day, day of the year and location on the earth. An
error in any of those entries will cause the position of the object to shift
with respect to the horizon and meridian lines.

If you lie to the mount and tell it that is is 8am instead of 8pm, then it
will point to the object in the opposite part of the sky. If you then swing the
scope around and point it properly to the object and "Sync" on it, the mount
will try to go to every other object the "wrong way around". What is the wrong
way around? Well in a fork mount, which is the largest selling type of mount,
there is really no wrong way, because the scope can access an object in either
direction. However, in a German Equatorial, one always needs to have the
scope on the upper side of the mount and the counterweights below. Many people
come from a fork mount background and trade up to this German style mounting, and
they expect them to work the same. They do not, because the GEM has an added
complication - it needs to do a meridian flip when the scope begins to track
past the meridian line (straight up north to south line).

Theoretically one can point a scope from either side of the mount, however if
the scope is lower than the counterweight, there comes a point where the
scope will not clear the tripod or pier and will bang into it (this is not a
problem with a fork mount). Therefore, it is vital that the scope always be setup
properly, that the mount has the proper time, date and location information, so
that it can make the correct decision as to the placement of the scope.

There is an ultra-easy way for you to always start the scope in the proper
orientation at the beginning of each session. And that is called the reference
park position, or Park1. I use it almost exclusively when setting up a scope
and mount for the first time. That and correct time/date/location entry (needs
to be done only once ever) will result in perfect GoTos. Every other method
that people may have used with other mounts before owning this German style
mounting may have potential flaws in the setup.

Rolando


**************
New year...new news. Be the first to know what is
making headlines. (http://www.aol.com/?ncid=emlcntaolcom00000026)

In a message dated 1/4/2009 6:25:48 PM Central Standard Time,
tekic545@... writes:

I had understood that in EXT mode the mount would rely on the laptop
for correct information as to current time and location.

There is no need to be that exact with respect to time, unless you are
operating remotely. If you are there at the mount, you should not use EXT. The
keypad clock is plenty accurate to allow you to slew to any object and get it in
the field. I have used my 1200 and keypad for about 5 years and have never once
used EXT or time from an external source. I have never updated my keypad time,
yet it always places the object into the field just fine. Small time errors
only shifts objects in RA but does not affect the placement of objects with
respect to each other. It does not affect Dec at all.

If you first go to a bright object or star upon power up and Recal the mount,
you will NEVER get lost. However, if you mess around with EXT settings and
your external computer sends wrong information to the servo at startup and then
you use Sync to center a known object, you can have severe problems. We have
NO CONTROL over external programs that may contain hidden bugs for the
intitialization of the mount, and if you rely on your 3rd party external program to do
this, then you can expect problems. If you are not in a remote situation, Do
Not use EXT. Do Not rely on 3rd party software to initialize your mount. Let
the keypad do initialization. The software in the keypad is thoroughly wrung
out and is essentially foolproof. We are working on a computer program that will
allow you to start the mount from your laptop, but until that is available,
please set the keypad to Autostart "Yes" and let it intitialize the mount.

Rolando


**************
New year...new news. Be the first to know what is
making headlines. (http://www.aol.com/?ncid=emlcntaolcom00000026)

In a message dated 1/4/2009 11:21:28 AM Central Standard Time,
tekic545@... writes:

I've been grappling with a similarly wild disorientation in my AP
900, which I run on EXT from my laptop.

Why do you set the keypad to EXT? It is designed to interface with an
external computer when in Autostart "Yes" mode. Why do you set it to EXT? There is no
need to do that. If you operate the mount as it was orignally intended, it
will always work fine. EXT mode was really intended for remote operation, not
for operation when you are there with your laptop.

Rolando


**************
New year...new news. Be the first to know what is
making headlines. (http://www.aol.com/?ncid=emlcntaolcom00000026)

In a message dated 1/4/2009 11:41:49 AM Central Standard Time,
RSastro00@... writes:

Last night just after sunset, I powered up my permanently aligned
AP1200 (GTOCP3 serial #1200653 with keypad software V4.12) using
autoconnect "no" followed by a synch on the moon, which was low in the
western sky.

two things,

First, if you are permanently aligned, the best way to set up your keypad is
Autoconnect Yes. The "No" option is for mounts that are set up fresh each
night.

Second, in a permanent setup, the correct sequence is to use Rcal whenever
you center a target. DO NOT use Sync. Sync is for initial calibration only for a
mount that is set up fresh from the start, not one that is permanently
aligned.

Third, there is no bug concerning the 00 hour. You may have set up your
keypad time improperly. Check your time and date entries. One of the most common
errors is to enter 8:00 for 8pm, when in fact it must be entered in military
time, so that 8pm is entered as 20:00 hours. Chances are that your time entry is
off by 12 hours, and that will indeed produce the results that you have found.


Lastly, it is not a good idea to ever "sync" or "Rcal" on the Moon. The Moon
has a highly variable orbit that is calculated in the keypad. The calculations
are approximate and can be off by many arc minutes, depending on your
location and especially the time. If you have made any time error in your keypad
entry, then the Moon will be very much off vesus the stars, and therefore is not a
reliable sync object.

Rolando


**************
New year...new news. Be the first to know what is
making headlines. (http://www.aol.com/?ncid=emlcntaolcom00000026)

At WSP last year we had fairly strong winds, enough that it was making it difficult to image with my C9 at 1125mm on my 1200, even without a dew shield. I switched to my E160 which is smaller, and half the F/l, and had perfect guiding under the same conditions. Use the proper tools for the conditions.

Dew rarely forms when it is breezy so I would normally not use a dew shield then, unless you need to block some light.

Dean

Robert Berta wrote:

I was at a star party that lasted a few days. One night it was very windy. I had my 6" refractor on my AP 900 GTO mount. I was worried that my 30-45 minute long images would be horrible...but the next day my guided images were tack sharp and stars were perfectly round and tack sharp...friends around me had a variety of SCTs on their mounts and their images were lousy due to the wind. Next day I decided to put my 11" SCT on and see how it would do...the wind was identical to the first night, speed and direction and I was imaging in the same area. Focal length was close to the refractor. Like the others the night before my images were now useless. I was thinking that this was a dramatic illustration of the difference in sail area between the two scope choices. I did note that I was using a dew shield about as long as the SCT and a future experiment might be to remove the dew shield. This would halve the sail area and might improve it enough to be useable. This could be a point in favor of refractors. I always thought the long lever moment of a refractor could be a detriment but the diameter might be more important. Wonder if any others have experienced this.

Bob,

You stated that the focal length of the refractor was *close* to that of the SCT ?!?!?!? Not by my calculations. The difference between 1100mm and 1900mm or larger is not trivial. Perhaps you could have used a 2x Barlow on the refractor and then compare the guiding from that to the SCT ?


Regards

Bill

I was at a star party that lasted a few days. One night it was very
windy. I had my 6" refractor on my AP 900 GTO mount. I was worried
that my 30-45 minute long images would be horrible...but the next day
my guided images were tack sharp and stars were perfectly round and
tack sharp...friends around me had a variety of SCTs on their mounts
and their images were lousy due to the wind. Next day I decided to
put my 11" SCT on and see how it would do...the wind was identical to
the first night, speed and direction and I was imaging in the same
area. Focal length was close to the refractor. Like the others the
night before my images were now useless. I was thinking that this
was a dramatic illustration of the difference in sail area between
the two scope choices. I did note that I was using a dew shield about
as long as the SCT and a future experiment might be to remove the dew
shield. This would halve the sail area and might improve it enough to
be useable. This could be a point in favor of refractors. I always
thought the long lever moment of a refractor could be a detriment but
the diameter might be more important. Wonder if any others have
experienced this.

Bob Berta
Michigan

Charles,

Thank you for this detailed explanation.

I had understood that in EXT mode the mount would rely on the laptop
for correct information as to current time and location.

In trying to trace where an 18-hour error (indicated in the keypad's
clock time) might have come from, I verified that the laptop's time
and date are correct -- and also that The Sky had the right location
and was set to use the computer's time, which is synched to an
Internet time server.

So, no resolution to the mystery. I now wait for clouds to disappear
to make sure the mount knows where it (and the zenith) are.

Tnx,

Bob

--- In ap-gto@..., "Charles Sinsofsky" <charles@...>
wrote:

Hello,

I thought I would provide a little 'write-up' about how the

mount, the

keypad, and external computers function with respect to the astrp-

phyiscs

goto mount and how mount movement/slewing choices are made. If any

who read

this and know all too well about and beyond this little primer,

please

accept my long-windedness as I wished only to help others who might
not.thank you



The keypad: what does it contain and how does I work:



- The keypad is a total self-contained 'In this case'

single

function computer, you could say like a small palm pilot or hand-

held

computer device. Its single function is to run the A/P keypad

program

- It contains, memory, a cpu, a real-time clock and a

battery. It

also contains two types of memory, permanent and non-permanent.

The

permanent memory uses an EPROM - this is a type of memory that is
read/writable and is programmable in the sense that if power were

removed

from this memory, it 'this memory' still retains it settings. The

values

stored here are the locations, date/time, and mount init settings,

like RA

backlash and a lot more!! The other type of memory is what is

within the

majority of peoples person computers that being RAM memory, once

power is

removed to this memory, its contents are lost.

- The keypad uses both of these memory types for various

functions.

- When you first apply power to the mount and of course

the keypad,

the keypads scans it internal EPROM type memory to setup the mount,

this

means send it date/time/ location, and an initial values for RA and

DEC if

so desired.



Of course the mount controller box is where all the fun is, that

meaning the

GTO box:



- This box is ANOTHER computer, it too has memory, and it

too has

its own CPU.

- The GTO box also has a real-time clock, and its keeps it

going BY

itself 'independent' of the keypad once it is initialized. Meaning

it starts

ticking away, calculating the various pieces of information it

needs to know

like most importantly the LST value at that current moment, meaning

the GTO

box needs to know 'where is the zenith' it does this WITH NO HELP

from the

keypad 'other then the init phase', however the init phase could

have easily

come from another source, ie: a computer program, feeding one of

the GTO's

RS232 serial ports. It does not need the keypad for this.



Now when ever ANY External source sends RA/DEC values to an ALREADY

init-ed

A/P GTO mount, the mount does NOT consult the keypad, it remember

has its

own internal clock/lst/ etc details and it "ON ITS OWN" decides how

to slew

to what-ever object it needs to, and in what way.



The keypad on the other hand also has a internal clock remember, it

also has

above the horizon checking routines '(like the mount itself does

inside the

GTO box independent of the keypad)', so we have two clocks here.

Once the

mount is initialized the keypad is now acting essentially like any

other

external source of RA/DEC numbers ie: to objects in the sky, etc.

However

the keypad likes to do extra work like check if an object is above

or below

the horizon by its own internal checking routines before it sends

RA/DEC

values to the mount.



Remember the values in the keypad are initially setup by the user,

ie: type

in what location / date and time will be used. The keypad then

calculates up

based on this information the LST value and we move on from there.



The GTO mount waits for some form or startup sequence, most cases

the keypad

performs this for us, or we can use an external program to do it,

the keypad

could then be in EXT mode 'meaning do not do init, get the date/time
location from the mount so the keypad now matches the mount. At

least that

is the concept.



Please note, that is the keypad for x-reasons shows a time and date

and a

calculated LST value on the '4' button from the opening menu that

appears

'wrong' .you should try to prove this out? Is the mount wrong?

Remember we

have two time clocks here, the mounts internal one 'that was setup'

by some

external program etc. and what the keypad NOW believes is the

time/date

based on polling that mount. Ie: asking the mount with commands,

return to

me ie: the keypad speaking what is the DATE / time / etc.. in the

mount

right now.



You can easily talk to the mount (meaning the GTO box, not the

keypad) with

hyperterminal or write a simple program to do just that "poll the

mount?"

What settings are inside the mount?? Remember all future slewing is

decided

by the GTO mount not the keypad. (however if you wanted the keypad

to be the

device that at this point sent the ra/dec values to the mount to

goto a

object, remember the keypad will do FIRST its own checking " is

this object

above or below" the horizon etc..and this of course will be based

on what

the keypad (not the GTO mount) thinks is the current date/time/ and

location

and calculated LST 'zenith' hour angle is.)



So what does this all mean? Well when using the keypad and the

mount one

should be aware of the fact we have two time clocks, the mount one

really

has precedence, this is the decider and this one controls what the

mount

does. The keypad is along for the ride AFTER the init is done.



I hope this explains a little more of what is happening inside the

mount and

the keypad when strange things happen. The movement of the mount is

totally

dependent on its own internal calculations of the LST and

time/date/ etc..

- and remember the keypad has ways to TRICK the GTO itself to move

the

zenith, with the offset-lst functions, so this is VERY important to
understand why sometimes the mount might 'slew' in the wrong

direction then

expected.some cases can cause this.



The keypad is more complex in the way it handles catalog data, but

comes

down to essentially the provider of RA/DEC values that the mount

decides

'meaning the GTO' box decides to use or not based on its own

internal clock

calculations.



EXT mode in the keypad is a way for the keypad 'to trust' the mount

in this

case to be the source of truth and reverse init, instead of the GTO

device

receiving from the keypad the required startup values, it now

polls the GTO

box, because it believes that the values it will get are true and

correct,

setup from an external source. Once it receives this data , it now

has to

assume it is correct and base its internal clock and calculation of

the LST

values from this point on.



Thank you

Charles Sinsofsky



From: ap-gto@... [mailto:ap-gto@...] On

Behalf Of

Charles Sinsofsky
Sent: Sunday, January 04, 2009 1:02 PM
To: ap-gto@...
Subject: RE: [ap-gto] Re: Time Problem



Hello,

This is NOT a bug, it is how the keypad works with respect to the

EXT

mode. The Ext mode requests 'polls' the mount for data/time

information and

also the timezone. There is no interaction from the keypad, all

date/time

etc..information is requested from the mount that was 'expected' to

be

updated by an 'external source' in this case being any computer

program that

could have initialized the mount originally

All the keypad is doing when in EXT mode is poll the mount for the
information it has within in it and then it will display it 'the

keypad in

this case' on its own display.

EXT mode does not permit the user to SET the time and date to the

mount or

request it simply because it already did this originally at startup

ie: when

power was applied to the keypad itself.

Please note the keypad is like a 'small computer' it has its own
calculations and database, etc.. and does essentially what any

decent

planetarium program does. If it is not used with the mount when the

mount is

turned on, ie: the main mount itself, the mount can work perfectly

fine

without the keypad provided it is updated with the initialization

done with

an external program.

Of course the keypad also does this as well, ie: initialization of

the

mount, but not totally n the EXT mode, it assumes in the EXT mode

that the

mount had this performed EXTERNALLY by another program ie: another

computer

so the keypad 'if in EXT mode' can later be powered on 'could be

literally

hours later' will ASK / POLL the mount for information and then it

to is

updated to reflect the date/time etc.. that the mount is at that

moment

using, and should reflect such later if perhaps someone were to ask

the

keypad' what is the current displayed time date/ lst etc.

There were some issues with the timezone of very specific timezones

that

could cause issues with the EXT mode, but the latest version 'that

is NOT

4.1.2, please see astro-physics web site for more details' that

corrects

some small issues with timezones for only a very small region where

EXT

zones must have an issue, more on that on the website.

But the EXT function as a whole is not a bug and works perfectly

fine. Just

remember the values sent to the mount will be what the laptop is

set to,

many a time I have helped out other a/p mount owners and found out

the

values in the external laptop that was used to setup the mount was

a) not

the correct date/ time or timezone, or b) the program was not using

the pc

own internal clock and sent completely wrong data

This of course does not always happen but one should check that to

be sure

of course.

Thank you

Charles Sinsofsky

From: ap-gto@... <mailto:ap-gto%40yahoogroups.com>
[mailto:ap-gto@... <mailto:ap-gto%40yahoogroups.com> ]

On Behalf

Of
Robert Gillette
Sent: Sunday, January 04, 2009 12:21 PM
To: ap-gto@... <mailto:ap-gto%40yahoogroups.com>
Subject: [ap-gto] Re: Time Problem

It is wonderful equipment and service couldn't be better, though
acknowledging this bug earlier might have been useful.

I've been grappling with a similarly wild disorientation in my AP
900, which I run on EXT from my laptop. Reading this string, I
checked the hand-control's time and found it was running nearly 18
hours slow.

How could this be? Is this a sign the battery needs replacing?

Bob Gillette

--- In ap-gto@... <mailto:ap-gto%40yahoogroups.com>
<mailto:ap-gto%40yahoogroups.com> , "Dan
Knauss" <dgknauss@> wrote:

I have had my 1200 since 2001. This is the first issue that I

have run

into that wasn't the result of operator error. This is a

wonderful

piece of

equipment. You'll love it. Don't worry over a very minor software

bug.

And you will note that AstroPhysics service is outstanding.

Dan Knauss



----- Original Message -----
From: "Dean S" <dean@>
To: <ap-gto@... <mailto:ap-gto%40yahoogroups.com>

<mailto:ap-gto%40yahoogroups.com> >

Sent: Saturday, January 03, 2009 8:44 PM
Subject: Re: [ap-gto] Re: Time Problem

Charles,

I have been monitoring the AP groups for several years now and

this is the

first time I have heard about this 'bug' so I don't think it is

much of an

issue. I have had my 1200 for over year, use The Sky6 with it,

and have

not
encounter it. I just don't think it is anything to worry about

if the

mount
is set up as Roland said.

Enjoy the new mount when you get it.

Dean

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]

All this is why some of star hop (with our GTO mounts). It's fun and we
don't have to fool around with a computer.

Rich
---------------------------------------------------------------------------------------------

The date/time was 03 Jan 2009/6:45 PM EST (UTC 23:45, LST 01:38:52). Location was 40N 75W.
Meridian delay was set to 0.

Thanks,
Dick



--- In ap-gto@..., "Charles Sinsofsky" <charles@...> wrote:

Interesting, the mount will choose what side to slew on based on the
position of the LST value. Ie: where is the zenith at the time it

chooses to

slew. If the mount has all its variables correct it will 'or should

always

choose the correct' side to slew to a specific object, and not as in

this

case suggest slew under itself ie: around the wrong way. I can see

one other

way this could be caused if the zenith ie: lst is set with the lst

'olst'

offset-lst option in the REV menu to push the lst from the true

zenith, this

then can directly affect where the mount will want to go to a specific
object etc.where it thinks the object is and where the zenith is?
I would like to have more details of all your settings, including if

you can

the exact time and all your location details and I can try

recreating this

on my test system to see what the mount would do exactly under these

set of

conditions.
Thank you
Charles Sinsofsky
From: ap-gto@... [mailto:ap-gto@...] On

Behalf Of

rsastroguy
Sent: Sunday, January 04, 2009 12:42 PM
To: ap-gto@...
Subject: [ap-gto] BUG OR OPERATIONAL ERROR?
Last night just after sunset, I powered up my permanently aligned
AP1200 (GTOCP3 serial #1200653 with keypad software V4.12) using
autoconnect "no" followed by a synch on the moon, which was low in the
western sky.
First slew (to NGC7772, RA/DEC = 23:52/16:15) was fine. I then
attempted an eastward slew to NGC7814 (RA/DEC = 00:03/16:09). The
distance between these two objects is about 3 degrees. The mount
attempted the second slew by moving to the WEST. Presumably it was
trying to get to the second object by travelling through 357 degrees!
Needless to say, I had to abort this slew.
I believe this problem is related to crossing the 00:00 line and may
reflect an issue with the software.
I would appreciate comments from other AP'ers who may have encountered
the same problem.
Regards,
Dick Steinberg
Philadelphia (40 N 75 W)

The date/time was 03 Jan 2009/6:45 PM EST (UTC 23:45, LST 01:38:52).
Location was 40N 75W.
Meridian delay was set to 0.

Thanks,
Dick



--- In ap-gto@..., "Charles Sinsofsky" <charles@...> wrote:

Interesting, the mount will choose what side to slew on based on the
position of the LST value. Ie: where is the zenith at the time it

chooses to

slew. If the mount has all its variables correct it will 'or should

always

choose the correct' side to slew to a specific object, and not as in

this

case suggest slew under itself ie: around the wrong way. I can see

one other

way this could be caused if the zenith ie: lst is set with the lst

'olst'

offset-lst option in the REV menu to push the lst from the true

zenith, this

then can directly affect where the mount will want to go to a specific
object etc.where it thinks the object is and where the zenith is?



I would like to have more details of all your settings, including if

you can

the exact time and all your location details and I can try

recreating this

on my test system to see what the mount would do exactly under these

set of

conditions.



Thank you

Charles Sinsofsky





From: ap-gto@... [mailto:ap-gto@...] On

Behalf Of

rsastroguy
Sent: Sunday, January 04, 2009 12:42 PM
To: ap-gto@...
Subject: [ap-gto] BUG OR OPERATIONAL ERROR?




Last night just after sunset, I powered up my permanently aligned
AP1200 (GTOCP3 serial #1200653 with keypad software V4.12) using
autoconnect "no" followed by a synch on the moon, which was low in the
western sky.

First slew (to NGC7772, RA/DEC = 23:52/16:15) was fine. I then
attempted an eastward slew to NGC7814 (RA/DEC = 00:03/16:09). The
distance between these two objects is about 3 degrees. The mount
attempted the second slew by moving to the WEST. Presumably it was
trying to get to the second object by travelling through 357 degrees!
Needless to say, I had to abort this slew.

I believe this problem is related to crossing the 00:00 line and may
reflect an issue with the software.

I would appreciate comments from other AP'ers who may have encountered
the same problem.

Regards,

Dick Steinberg
Philadelphia (40 N 75 W)

Hello,

I thought I would provide a little 'write-up' about how the mount, the
keypad, and external computers function with respect to the astrp-phyiscs
goto mount and how mount movement/slewing choices are made. If any who read
this and know all too well about and beyond this little primer, please
accept my long-windedness as I wished only to help others who might
not.thank you



The keypad: what does it contain and how does I work:



- The keypad is a total self-contained 'In this case' single
function computer, you could say like a small palm pilot or hand-held
computer device. Its single function is to run the A/P keypad program

- It contains, memory, a cpu, a real-time clock and a battery. It
also contains two types of memory, permanent and non-permanent. The
permanent memory uses an EPROM - this is a type of memory that is
read/writable and is programmable in the sense that if power were removed
from this memory, it 'this memory' still retains it settings. The values
stored here are the locations, date/time, and mount init settings, like RA
backlash and a lot more!! The other type of memory is what is within the
majority of peoples person computers that being RAM memory, once power is
removed to this memory, its contents are lost.

- The keypad uses both of these memory types for various functions.

- When you first apply power to the mount and of course the keypad,
the keypads scans it internal EPROM type memory to setup the mount, this
means send it date/time/ location, and an initial values for RA and DEC if
so desired.



Of course the mount controller box is where all the fun is, that meaning the
GTO box:



- This box is ANOTHER computer, it too has memory, and it too has
its own CPU.

- The GTO box also has a real-time clock, and its keeps it going BY
itself 'independent' of the keypad once it is initialized. Meaning it starts
ticking away, calculating the various pieces of information it needs to know
like most importantly the LST value at that current moment, meaning the GTO
box needs to know 'where is the zenith' it does this WITH NO HELP from the
keypad 'other then the init phase', however the init phase could have easily
come from another source, ie: a computer program, feeding one of the GTO's
RS232 serial ports. It does not need the keypad for this.



Now when ever ANY External source sends RA/DEC values to an ALREADY init-ed
A/P GTO mount, the mount does NOT consult the keypad, it remember has its
own internal clock/lst/ etc details and it "ON ITS OWN" decides how to slew
to what-ever object it needs to, and in what way.



The keypad on the other hand also has a internal clock remember, it also has
above the horizon checking routines '(like the mount itself does inside the
GTO box independent of the keypad)', so we have two clocks here. Once the
mount is initialized the keypad is now acting essentially like any other
external source of RA/DEC numbers ie: to objects in the sky, etc. However
the keypad likes to do extra work like check if an object is above or below
the horizon by its own internal checking routines before it sends RA/DEC
values to the mount.



Remember the values in the keypad are initially setup by the user, ie: type
in what location / date and time will be used. The keypad then calculates up
based on this information the LST value and we move on from there.



The GTO mount waits for some form or startup sequence, most cases the keypad
performs this for us, or we can use an external program to do it, the keypad
could then be in EXT mode 'meaning do not do init, get the date/time
location from the mount so the keypad now matches the mount. At least that
is the concept.



Please note, that is the keypad for x-reasons shows a time and date and a
calculated LST value on the '4' button from the opening menu that appears
'wrong' .you should try to prove this out? Is the mount wrong? Remember we
have two time clocks here, the mounts internal one 'that was setup' by some
external program etc. and what the keypad NOW believes is the time/date
based on polling that mount. Ie: asking the mount with commands, return to
me ie: the keypad speaking what is the DATE / time / etc.. in the mount
right now.



You can easily talk to the mount (meaning the GTO box, not the keypad) with
hyperterminal or write a simple program to do just that "poll the mount?"
What settings are inside the mount?? Remember all future slewing is decided
by the GTO mount not the keypad. (however if you wanted the keypad to be the
device that at this point sent the ra/dec values to the mount to goto a
object, remember the keypad will do FIRST its own checking " is this object
above or below" the horizon etc..and this of course will be based on what
the keypad (not the GTO mount) thinks is the current date/time/ and location
and calculated LST 'zenith' hour angle is.)



So what does this all mean? Well when using the keypad and the mount one
should be aware of the fact we have two time clocks, the mount one really
has precedence, this is the decider and this one controls what the mount
does. The keypad is along for the ride AFTER the init is done.



I hope this explains a little more of what is happening inside the mount and
the keypad when strange things happen. The movement of the mount is totally
dependent on its own internal calculations of the LST and time/date/ etc..
- and remember the keypad has ways to TRICK the GTO itself to move the
zenith, with the offset-lst functions, so this is VERY important to
understand why sometimes the mount might 'slew' in the wrong direction then
expected.some cases can cause this.



The keypad is more complex in the way it handles catalog data, but comes
down to essentially the provider of RA/DEC values that the mount decides
'meaning the GTO' box decides to use or not based on its own internal clock
calculations.



EXT mode in the keypad is a way for the keypad 'to trust' the mount in this
case to be the source of truth and reverse init, instead of the GTO device
receiving from the keypad the required startup values, it now polls the GTO
box, because it believes that the values it will get are true and correct,
setup from an external source. Once it receives this data , it now has to
assume it is correct and base its internal clock and calculation of the LST
values from this point on.



Thank you

Charles Sinsofsky



From: ap-gto@... [mailto:ap-gto@...] On Behalf Of
Charles Sinsofsky
Sent: Sunday, January 04, 2009 1:02 PM
To: ap-gto@...
Subject: RE: [ap-gto] Re: Time Problem



Hello,

This is NOT a bug, it is how the keypad works with respect to the EXT
mode. The Ext mode requests 'polls' the mount for data/time information and
also the timezone. There is no interaction from the keypad, all date/time
etc..information is requested from the mount that was 'expected' to be
updated by an 'external source' in this case being any computer program that
could have initialized the mount originally

All the keypad is doing when in EXT mode is poll the mount for the
information it has within in it and then it will display it 'the keypad in
this case' on its own display.

EXT mode does not permit the user to SET the time and date to the mount or
request it simply because it already did this originally at startup ie: when
power was applied to the keypad itself.

Please note the keypad is like a 'small computer' it has its own
calculations and database, etc.. and does essentially what any decent
planetarium program does. If it is not used with the mount when the mount is
turned on, ie: the main mount itself, the mount can work perfectly fine
without the keypad provided it is updated with the initialization done with
an external program.

Of course the keypad also does this as well, ie: initialization of the
mount, but not totally n the EXT mode, it assumes in the EXT mode that the
mount had this performed EXTERNALLY by another program ie: another computer
so the keypad 'if in EXT mode' can later be powered on 'could be literally
hours later' will ASK / POLL the mount for information and then it to is
updated to reflect the date/time etc.. that the mount is at that moment
using, and should reflect such later if perhaps someone were to ask the
keypad' what is the current displayed time date/ lst etc.

There were some issues with the timezone of very specific timezones that
could cause issues with the EXT mode, but the latest version 'that is NOT
4.1.2, please see astro-physics web site for more details' that corrects
some small issues with timezones for only a very small region where EXT
zones must have an issue, more on that on the website.

But the EXT function as a whole is not a bug and works perfectly fine. Just
remember the values sent to the mount will be what the laptop is set to,
many a time I have helped out other a/p mount owners and found out the
values in the external laptop that was used to setup the mount was a) not
the correct date/ time or timezone, or b) the program was not using the pc
own internal clock and sent completely wrong data

This of course does not always happen but one should check that to be sure
of course.

Thank you

Charles Sinsofsky

From: ap-gto@... <mailto:ap-gto%40yahoogroups.com>
[mailto:ap-gto@... <mailto:ap-gto%40yahoogroups.com> ] On Behalf
Of
Robert Gillette
Sent: Sunday, January 04, 2009 12:21 PM
To: ap-gto@... <mailto:ap-gto%40yahoogroups.com>
Subject: [ap-gto] Re: Time Problem

It is wonderful equipment and service couldn't be better, though
acknowledging this bug earlier might have been useful.

I've been grappling with a similarly wild disorientation in my AP
900, which I run on EXT from my laptop. Reading this string, I
checked the hand-control's time and found it was running nearly 18
hours slow.

How could this be? Is this a sign the battery needs replacing?

Bob Gillette

--- In ap-gto@... <mailto:ap-gto%40yahoogroups.com>
<mailto:ap-gto%40yahoogroups.com> , "Dan
Knauss" <dgknauss@...> wrote:

I have had my 1200 since 2001. This is the first issue that I

have run

into that wasn't the result of operator error. This is a wonderful

piece of

equipment. You'll love it. Don't worry over a very minor software

bug.

And you will note that AstroPhysics service is outstanding.

Dan Knauss



----- Original Message -----
From: "Dean S" <dean@...>
To: <ap-gto@... <mailto:ap-gto%40yahoogroups.com>

<mailto:ap-gto%40yahoogroups.com> >

Sent: Saturday, January 03, 2009 8:44 PM
Subject: Re: [ap-gto] Re: Time Problem

Charles,

I have been monitoring the AP groups for several years now and

this is the

first time I have heard about this 'bug' so I don't think it is

much of an

issue. I have had my 1200 for over year, use The Sky6 with it,

and have

not
encounter it. I just don't think it is anything to worry about

if the

mount
is set up as Roland said.

Enjoy the new mount when you get it.

Dean

Interesting, the mount will choose what side to slew on based on the
position of the LST value. Ie: where is the zenith at the time it chooses to
slew. If the mount has all its variables correct it will 'or should always
choose the correct' side to slew to a specific object, and not as in this
case suggest slew under itself ie: around the wrong way. I can see one other
way this could be caused if the zenith ie: lst is set with the lst 'olst'
offset-lst option in the REV menu to push the lst from the true zenith, this
then can directly affect where the mount will want to go to a specific
object etc.where it thinks the object is and where the zenith is?



I would like to have more details of all your settings, including if you can
the exact time and all your location details and I can try recreating this
on my test system to see what the mount would do exactly under these set of
conditions.



Thank you

Charles Sinsofsky





From: ap-gto@... [mailto:ap-gto@...] On Behalf Of
rsastroguy
Sent: Sunday, January 04, 2009 12:42 PM
To: ap-gto@...
Subject: [ap-gto] BUG OR OPERATIONAL ERROR?




Last night just after sunset, I powered up my permanently aligned
AP1200 (GTOCP3 serial #1200653 with keypad software V4.12) using
autoconnect "no" followed by a synch on the moon, which was low in the
western sky.

First slew (to NGC7772, RA/DEC = 23:52/16:15) was fine. I then
attempted an eastward slew to NGC7814 (RA/DEC = 00:03/16:09). The
distance between these two objects is about 3 degrees. The mount
attempted the second slew by moving to the WEST. Presumably it was
trying to get to the second object by travelling through 357 degrees!
Needless to say, I had to abort this slew.

I believe this problem is related to crossing the 00:00 line and may
reflect an issue with the software.

I would appreciate comments from other AP'ers who may have encountered
the same problem.

Regards,

Dick Steinberg
Philadelphia (40 N 75 W)

Hello,

This is NOT a bug, it is how the keypad works with respect to the EXT
mode. The Ext mode requests 'polls' the mount for data/time information and
also the timezone. There is no interaction from the keypad, all date/time
etc..information is requested from the mount that was 'expected' to be
updated by an 'external source' in this case being any computer program that
could have initialized the mount originally



All the keypad is doing when in EXT mode is poll the mount for the
information it has within in it and then it will display it 'the keypad in
this case' on its own display.



EXT mode does not permit the user to SET the time and date to the mount or
request it simply because it already did this originally at startup ie: when
power was applied to the keypad itself.



Please note the keypad is like a 'small computer' it has its own
calculations and database, etc.. and does essentially what any decent
planetarium program does. If it is not used with the mount when the mount is
turned on, ie: the main mount itself, the mount can work perfectly fine
without the keypad provided it is updated with the initialization done with
an external program.



Of course the keypad also does this as well, ie: initialization of the
mount, but not totally n the EXT mode, it assumes in the EXT mode that the
mount had this performed EXTERNALLY by another program ie: another computer
so the keypad 'if in EXT mode' can later be powered on 'could be literally
hours later' will ASK / POLL the mount for information and then it to is
updated to reflect the date/time etc.. that the mount is at that moment
using, and should reflect such later if perhaps someone were to ask the
keypad' what is the current displayed time date/ lst etc.



There were some issues with the timezone of very specific timezones that
could cause issues with the EXT mode, but the latest version 'that is NOT
4.1.2, please see astro-physics web site for more details' that corrects
some small issues with timezones for only a very small region where EXT
zones must have an issue, more on that on the website.



But the EXT function as a whole is not a bug and works perfectly fine. Just
remember the values sent to the mount will be what the laptop is set to,
many a time I have helped out other a/p mount owners and found out the
values in the external laptop that was used to setup the mount was a) not
the correct date/ time or timezone, or b) the program was not using the pc
own internal clock and sent completely wrong data



This of course does not always happen but one should check that to be sure
of course.



Thank you

Charles Sinsofsky





From: ap-gto@... [mailto:ap-gto@...] On Behalf Of
Robert Gillette
Sent: Sunday, January 04, 2009 12:21 PM
To: ap-gto@...
Subject: [ap-gto] Re: Time Problem



It is wonderful equipment and service couldn't be better, though
acknowledging this bug earlier might have been useful.

I've been grappling with a similarly wild disorientation in my AP
900, which I run on EXT from my laptop. Reading this string, I
checked the hand-control's time and found it was running nearly 18
hours slow.

How could this be? Is this a sign the battery needs replacing?

Bob Gillette

--- In ap-gto@... <mailto:ap-gto%40yahoogroups.com> , "Dan
Knauss" <dgknauss@...> wrote:

I have had my 1200 since 2001. This is the first issue that I

have run

into that wasn't the result of operator error. This is a wonderful

piece of

equipment. You'll love it. Don't worry over a very minor software

bug.

And you will note that AstroPhysics service is outstanding.

Dan Knauss



----- Original Message -----
From: "Dean S" <dean@...>
To: <ap-gto@... <mailto:ap-gto%40yahoogroups.com> >
Sent: Saturday, January 03, 2009 8:44 PM
Subject: Re: [ap-gto] Re: Time Problem

Charles,

I have been monitoring the AP groups for several years now and

this is the

first time I have heard about this 'bug' so I don't think it is

much of an

issue. I have had my 1200 for over year, use The Sky6 with it,

and have

not
encounter it. I just don't think it is anything to worry about

if the

mount
is set up as Roland said.

Enjoy the new mount when you get it.

Dean

Last night just after sunset, I powered up my permanently aligned
AP1200 (GTOCP3 serial #1200653 with keypad software V4.12) using
autoconnect "no" followed by a synch on the moon, which was low in the
western sky.

First slew (to NGC7772, RA/DEC = 23:52/16:15) was fine. I then
attempted an eastward slew to NGC7814 (RA/DEC = 00:03/16:09). The
distance between these two objects is about 3 degrees. The mount
attempted the second slew by moving to the WEST. Presumably it was
trying to get to the second object by travelling through 357 degrees!
Needless to say, I had to abort this slew.

I believe this problem is related to crossing the 00:00 line and may
reflect an issue with the software.

I would appreciate comments from other AP'ers who may have encountered
the same problem.

Regards,

Dick Steinberg
Philadelphia (40 N 75 W)

It is wonderful equipment and service couldn't be better, though
acknowledging this bug earlier might have been useful.

I've been grappling with a similarly wild disorientation in my AP
900, which I run on EXT from my laptop. Reading this string, I
checked the hand-control's time and found it was running nearly 18
hours slow.

How could this be? Is this a sign the battery needs replacing?

Bob Gillette

--- In ap-gto@..., "Dan Knauss" <dgknauss@...> wrote:

I have had my 1200 since 2001. This is the first issue that I

have run

into that wasn't the result of operator error. This is a wonderful

piece of

equipment. You'll love it. Don't worry over a very minor software

bug.

And you will note that AstroPhysics service is outstanding.

Dan Knauss



----- Original Message -----
From: "Dean S" <dean@...>
To: <ap-gto@...>
Sent: Saturday, January 03, 2009 8:44 PM
Subject: Re: [ap-gto] Re: Time Problem

Charles,

I have been monitoring the AP groups for several years now and

this is the

first time I have heard about this 'bug' so I don't think it is

much of an

issue. I have had my 1200 for over year, use The Sky6 with it,

and have

not
encounter it. I just don't think it is anything to worry about

if the

mount
is set up as Roland said.

Enjoy the new mount when you get it.

Dean

I have had my 1200 since 2001. This is the first issue that I have run into that wasn't the result of operator error. This is a wonderful piece of equipment. You'll love it. Don't worry over a very minor software bug. And you will note that AstroPhysics service is outstanding.

Dan Knauss

Marco, you SHOULD be pleased - I think it is gorgeous!

Stuart

Dear all, eventually I had a chance to take one more shot with my TEC140, the AP Mach1 and the Proline 16803.
The target is a very classic and maybe a bit boring, however I am quite pleased with the result, in particular considering my moderately polluted sky.

Here is the link:
http://www.astrosurf.com/lorenzi/ccd/m31_ccd.htm

It is amazing how with moderate aperture and FL modern technology permits to get a nice bunch of details!
Hope you will enjoy
Clear Skies
Marco

Charles,

I have been monitoring the AP groups for several years now and this is the first time I have heard about this 'bug' so I don't think it is much of an issue. I have had my 1200 for over year, use The Sky6 with it, and have not encounter it. I just don't think it is anything to worry about if the mount is set up as Roland said.

Enjoy the new mount when you get it.

Dean