Date   

Re: Power Supply for 900GTO

Roland Christen
 

In a message dated 6/7/2006 5:40:24 PM Central Daylight Time,
toddklaus@... writes:>
Hi Roland,

Any update on this power supply?

thanks,
Todd

--- In ap-gto@..., chris1011@... wrote:
We are presently testing a new 15 volt 10 amp supply which will be
perfect
for observatory use. We should have it available on our web site
very soon.
We are working out the cable for this power supply. I has only two banana
plugs in the back for power output, so we have to make up an interface cable for
our power cord.

Roland christen


Cases for AP 1200

Mal Speer <mal@...>
 

I know that this was probably discussed before, but does anyone have
any suggestions for some light weight cases?
Mal


Re: Power Supply for 900GTO

Todd Klaus
 

Hi Roland,

Any update on this power supply?

thanks,
Todd


--- In ap-gto@..., chris1011@... wrote:
We are presently testing a new 15 volt 10 amp supply which will be
perfect
for observatory use. We should have it available on our web site
very soon.

Roland Christen


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


Difference between 1200 and 900

William R. Mattil <wrmattil@...>
 

Guys,

My new AP1200 arrived today and when set up next to my AP900 the size difference is amazing. Never seemed to notice this before. Slew is much quieter than the older 900 too. All in all I'm stoked. Thanks Roland !


Regards

Bill

--

William R. Mattil : http://www.celestial-images.com


Re: While I wait for my Mach1GTO...

elraeburn <eraeburn@...>
 

Robert,

You've probably seen this on the Mach1GTO page at the AP website:

The Mach1GTO can be mounted directly into the top of an
Astro-Physics 6" Portable Pier or a new collapsible pier
that is under development.

Last I spoke to AP about the collapsible pier, the plan was to have
them ready in time for the Mach1GTO shipments. I'm waiting to compare
this device to the Portable Pier. You can be sure Mr. Christen will
design and build these things to be sufficient for imaging, but this
is dependent on the intended payload for the mount--dimensions of the
OTA(s), and total weight. What do you mean by "long focal length"?
Are you sure you are not exceeding the advertised capacity of the mount?

-Eric


--- In ap-gto@..., "Robert Schlingensiepen" <schling@...>
wrote:

Hi all,

Just joined the group. While I wait for my Mach1GTO, I need to figure
out which portable pier/tripod to use.

At first sight, the adjustable hardwood tripod sold by AP seems like
an attractive choice because it requires no assembly and is
adjustable, all for a reasonable price (at least compared to upscale
portable piers).

I was wondering whether anybody out there is a satisfied user of this
tripod for demanding CCD imaging (long focal length, >5 min exposures,
etc.) with a 400 or 600 mount. The last thing I want to do is to place
the mount on a platform that won't allow it to perform at its best.

And thanks in advance for any other comments/suggestions.

Regards,

Robert Schlingensiepen


While I wait for my Mach1GTO...

Robert Schlingensiepen <schling@...>
 

Hi all,

Just joined the group. While I wait for my Mach1GTO, I need to figure
out which portable pier/tripod to use.

At first sight, the adjustable hardwood tripod sold by AP seems like
an attractive choice because it requires no assembly and is
adjustable, all for a reasonable price (at least compared to upscale
portable piers).

I was wondering whether anybody out there is a satisfied user of this
tripod for demanding CCD imaging (long focal length, >5 min exposures,
etc.) with a 400 or 600 mount. The last thing I want to do is to place
the mount on a platform that won't allow it to perform at its best.

And thanks in advance for any other comments/suggestions.

Regards,

Robert Schlingensiepen


Re: AP1200 operation via external programs

Ajai Sehgal
 

This is nonsense. The driver must support the standard interfaces but CAN
support special purpose interfaces that abstract the new inovative
functionality. This is not a problem if the manufacturer of the hardware is
in control of the driver as AP will now be.

Ajai

_____

From: ap-gto@... [mailto:ap-gto@...] On Behalf Of
Bryan Henry
Sent: Tuesday, June 06, 2006 4:26 AM
To: ap-gto@...
Subject: [ap-gto] Re: AP1200 operation via external programs



The concept of a driver for a common interface sounds good but there
is a down side for the innovative hardware manufacturer. Suppose the
innovative manufacturer has developed some awesome new feature. He
participates in the standard process to get it in the driver. Two
things have happened: there is a delay in releasing the new feature
and now his competitors know what he is doing.

The driver concept favors the "me too" manufacturer, not the
innovative manufacturer. Just my two cents.

Bryan

--- In ap-gto@yahoogroups. <mailto:ap-gto%40yahoogroups.com> com, "Bob
Denny" <rdenny@...> wrote:
I should probably read ahead, but here goes: The problem with asking
multiple client programs to support special interfaces is -- it
defeats the whole reason for a driver in the first place. If various
programs must talk to unique "extension" intefaces, the questions
become "How many different extensions must I support?" and "What
about
all the variations in features exposed by these unique interfaces?"
You end up right back at the basic problem. Developing special code
for every mount out there.

I completely understand the mount vendors' desire to add feratures
to
make their mounts "better". But in the end, if the mount is to be
broadly supported by multiplew programs, the common interface is
going
to drive the designs.

We spend a lot of time and energy developing a standard interface
with
optional features (via CanXxx flags) so that variations in mount
features could be supported by clients. If a mount vendor wants to
see
another feature added to the standard, they need to participate in
the
next generation standard process. Another reason mount makers need
to
get engaged.

-- Bob


Re: AP1200 operation via external programs

planetary_hunter
 

The concept of a driver for a common interface sounds good but there
is a down side for the innovative hardware manufacturer. Suppose the
innovative manufacturer has developed some awesome new feature. He
participates in the standard process to get it in the driver. Two
things have happened: there is a delay in releasing the new feature
and now his competitors know what he is doing.

The driver concept favors the "me too" manufacturer, not the
innovative manufacturer. Just my two cents.

Bryan

--- In ap-gto@..., "Bob Denny" <rdenny@...> wrote:
I should probably read ahead, but here goes: The problem with asking
multiple client programs to support special interfaces is -- it
defeats the whole reason for a driver in the first place. If various
programs must talk to unique "extension" intefaces, the questions
become "How many different extensions must I support?" and "What
about
all the variations in features exposed by these unique interfaces?"
You end up right back at the basic problem. Developing special code
for every mount out there.

I completely understand the mount vendors' desire to add feratures
to
make their mounts "better". But in the end, if the mount is to be
broadly supported by multiplew programs, the common interface is
going
to drive the designs.

We spend a lot of time and energy developing a standard interface
with
optional features (via CanXxx flags) so that variations in mount
features could be supported by clients. If a mount vendor wants to
see
another feature added to the standard, they need to participate in
the
next generation standard process. Another reason mount makers need
to
get engaged.

-- Bob


Lube for an AP1200?

dean_rw
 

I'm thinking of cleaning and relubing my GTOCP2 and was wondering what
lube to use and where I might be able to find some. Any pointers on
how to go about doing this would also be appreciated.

Thanks,
Dean


Re: AP1200 operation via external programs

Bob Denny
 

Nicolas:
Probably a private interface extending the ascom one, should be
provided too, to give access to ap specific parameters, from a
programatic point of view.
I should probably read ahead, but here goes: The problem with asking
multiple client programs to support special interfaces is -- it
defeats the whole reason for a driver in the first place. If various
programs must talk to unique "extension" intefaces, the questions
become "How many different extensions must I support?" and "What about
all the variations in features exposed by these unique interfaces?"
You end up right back at the basic problem. Developing special code
for every mount out there.

I completely understand the mount vendors' desire to add feratures to
make their mounts "better". But in the end, if the mount is to be
broadly supported by multiplew programs, the common interface is going
to drive the designs.

We spend a lot of time and energy developing a standard interface with
optional features (via CanXxx flags) so that variations in mount
features could be supported by clients. If a mount vendor wants to see
another feature added to the standard, they need to participate in the
next generation standard process. Another reason mount makers need to
get engaged.

-- Bob


Re: AP1200 operation via external programs

Bob Denny
 

Nicolas:
Probably a private interface extending the ascom one, should be
provided too, to give access to ap specific parameters, from a
programatic point of view.
I should probably read ahead, but here goes: The problem with asking
multiple client programs to support special interfaces is -- it
defeats the whole reason for a driver in the first place. If various
programs must talk to unique "extension" intefaces, the questions
become "How many different extensions must I support?" and "What about
all the variations in features exposed by these unique interfaces?"
You end up right back at the basic problem. Developing special code
for every mount out there.

I completely understand the mount vendors' desire to add feratures to
make their mounts "better". But in the end, if the mount is to be
broadly supported by multiplew programs, the common interface is going
to drive the designs.

We spend a lot of time and energy developing a standard interface with
optional features (via CanXxx flags) so that variations in mount
features could be supported by clients. If a mount vendor wants to see
another feature added to the standard, they need to participate in the
next generation standard process. Another reason mount makers need to
get engaged.

-- Bob


Re: AP1200 operation via external programs

Todd Klaus
 

Hi Ray,

Any chance of adding joystick support? I've gotten used to using my
wireless logitech wingman with my CGE for slewing, changing button
speeds, etc., and it would be great to have that feature with my new 900.

Thanks again for all your hard work!

Todd

--- In ap-gto@..., "Ray Gralak" <rgr@...> wrote:

Hi John,

I've suggested to Roland in the past that there should be a more rigid
packet protocol like what Bisque uses. In fact, that is what I thought
he meant in his message about a week ago.

And yes, that feature could be a watchdog timer (but kind of in
reverse, since it is not the equipment that dies, but the software
controlling it! :-)

-Ray

-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...]
On Behalf Of John Stone
Sent: Friday, May 26, 2006 8:34 PM
To: ap-gto@...
Subject: [ap-gto] Re: AP1200 operation via external programs

This is exactly the sort of problem that would be solved by updating
the mount control protocol with various fault tolerance provisions.
The suggestion Ray already made, which is often referred to as a
"watchdog timer" would help substantially for the simple case of an
unplugged cable, crashed software, computer gets rebooted by Windows
Update, or some other similar circumstance. It might be possible to
implement a watchdog timer with minimal changes to the existing
protocol, though it may not be practical with the existing mount
controllers for other reasons. This doesn't help if you get garbled
data over a bad cable though, so I'd also like to see command
checksums someday, though that would require a new protocol which
would no longer be similar to the old LX200 protocol. One might be
able to make the mount controller capable of responding to both the
current AP protocol and a new protocol designed to address these
issues by adding another protocol mode command, say something along
the lines of the existing "U#" command which changes the protocol to
"long format". One could make another such command the sets the
port
to "new protocol" mode, for example. All of these suggestions may
be
totally impractical for the existing mount controllers however.
Some
or all of these may have to wait until AP makes a GTO CP4
controller.
That said, if AP made a new mount controller with improved fault
tolerance features, I'd upgrade :)

John Stone


--- In ap-gto@..., "mcmillanjr4221" <valueware@>
wrote:

Hi Ray,

Thanks for this...

Your last paragraph is the one I'm thinking (worrying) about...

"The worst possible case would be if the PC halts or PulseGuide
terminates. In that case the mount is susceptible to tracking
until
a pier collision occurs. One possible way to avoid this would be a
new command in the GTOCP3 that when issued stops tracking
if nothing
is received from the serial port for a certain period of time. I
have no idea though if this is possible or what other side effects
there might be, so I can't say if this is a good idea or not.
Maybe
Roland will comment if he thinks this is possible."

Consider this scenerio:

1) ACP sends a slew command to the driver
2) The driver interprets this command and sends it to the mount
3) The mount executes the slew
4) ACP asks the driver to tell it when the slew has stopped
I'm not
quite sure, but I think this is probably a polling process - e.g.
ACP really continually asks the driver whether the slew is still
in
progress.
5) The mount stops
6) The driver tries to determine whether the slew has stopped
since
there is no direct feedback from the mount that tells it the slew
has stopped
7) The driver notifies ACP that the slew is no longer going on

Under what condition(s) would #6 not get accomplished such that #7
never happens? And, if those conditions are understood, is there
some failsafe remedy?

Jim

--- In ap-gto@..., "Ray Gralak" <rgr@> wrote:

Hi Jim,

There are really two issues here:

1) Providing correct feedback to the calling application that
slewing
has completed. I'm guessing ACP is reading the "Slewing"
property
to
determine this.

2) That in case of application or network communications failure
tracking should stop after an appropriate amount of time. This
would
be another example of a need for a fail safe mechanism.

To tackle the first issue, as long as ACP calls the Slewing
property
and the driver can communicate with PulseGuide then the state of
Slewing will return correctly. If it is an application bug (not
saying
it is) then you probably will experience the same
behavior with the
new driver, otherwise you will likely not see this bug as
Pulseguide
knows how to reset and retry sending commands to the
mount. It will
not get stuck if some errant characters or incomplete number of
characters are received.

In the event of the second issue, two things could happen. The
driver,
detecting a network failure, would throw an exception.
Note that if
PulseGuide and the application are on the same PC there is
virtually
no chance for a network failure unless the user is mucking
around
with
network settings (not a good idea! :-).

If the application fails or a network failure occurs and
PulseGuide
does not receive any messages from the application then
PulseGuide
could optionally be set up to stop tracking on the mount.
(Remember
the delayed stop feature of PulseGuide?)

The worst possible case would be if the PC halts or PulseGuide
terminates. In that case the mount is susceptible to tracking
until a
pier collision occurs. One possible way to avoid this would be a
new
command in the GTOCP3 that when issued stops tracking if
nothing is
received from the serial port for a certain period of
time. I have
no
idea though if this is possible or what other side effects there
might
be, so I can't say if this is a good idea or not. Maybe
Roland will
comment if he thinks this is possible.

-Ray




-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...]
On Behalf Of mcmillanjr4221
Sent: Friday, May 26, 2006 4:59 AM
To: ap-gto@...
Subject: [ap-gto] Re: AP1200 operation via external programs

Hi Ray,

A couple of times in the past few years, I've had the
situation
where no end-of-slew info got reported back to ACP so it just
hung -

meaning ACP kept waiting for the end-of-slew so it did nothing
and
the mount, having finished its slew, just kept tracking,
eventually
hitting the pier and/or wrapping the cables.

I don't know what caused the problem. I seriously doubt it
was
a
driver issue. I suspect some kind of glitch with the
USB/serial
converter caused by a power spike, but I don't know.

My question: do you plan to put some kind of time-out logic
in
the
driver to catch this type of situation? Perhaps the broader
question is: is it the driver's responsibility to deal with
this
kind of error or is it the application's responsibility?

Thanks in advance.

Jim

--- In ap-gto@..., "Ray Gralak" <rgr@> wrote:

Hi John,

I've got about 20 years of network protocol
experience (dating
back to
XNS days :-), in minicomputers (remember those? :-),
Windows,
*nix,
and embedded real-time systems. I have a very robust scheme
that I
have used in many of the client-server systems I've
written so
you
need not worry. A couple years back I expounded some of the
details
either here or on the ASCOM list. PulseGuide (the server
component)
will always have fail-safe timeouts for certain
operations that
can
potentially fail and leave the telescope in an undesirable
state
(e.g.
starting but not stopping a E/W/N/S centering movement).

When time permits, probably after the new driver and all
features
are
working, I will write up the protocol spec for external
application
communications, and probably provide some C++ and VB client
source
code examples.

-Ray

-----Original Message-----
From: ap-gto@...
[mailto:ap-gto@...]
On Behalf Of John Stone
Sent: Thursday, May 25, 2006 9:52 PM
To: ap-gto@...
Subject: [ap-gto] Re: AP1200 operation via external
programs

Ray,
I'm curious about your UDP protocol, as I would
like to be
able to
use PulseGuide from my camera control software. I'm also
curious
what
you've done for network fault tolerance in your protocol
(e.g.
command
the mount to do something, then lose network
indefinitely...)

John Stone

--- In ap-gto@..., "Ray Gralak" <rgr@> wrote:

Yes, here are some of the changes that I will make
PulseGuide:

1. I will create a new client ASCOM driver that supports
the
V2
Telescope standard (the current driver only supports
v1).
2. This ASCOM driver will communicate with PulseGuide
via
the
UDP
protocol, which will allow the client application to
optionally be on
a different PC than PulseGuide.
3. This will also allow multiple applications to
simultaneously
talk
to PulseGuide (e.g. it will be a hub).
4. The protocol interface will be published so
applications on
Macs,
LINUX, etc. will be able to control PulseGuide remotely.
5. PulseGuide will be outfitted with one or more virtual
serial ports
that will allow one or more planetarium programs to
connect to

it
simultaneously, even if the planetarium software does
not
have

an
ASCOM driver. This could be used for instance to run
TheSky
in native
mode instead of limping through the TeleAPI
interface that
many people
have had a problem with.
6. PulseGuide will be able to ensure the mount is always
properly
initialized.
7. PulseGuide will manage incoming requests in a smart
manner so as to
not overload the mount (e.g. querying the mount once a
second
for
RA/Dec instead of N times if N applications are
connected).
8. PulseGuide will watch the commands being sent to the
mount
and
insert its own if the Planetarium program changes
something
and
doesn't restore it (e.g. Using a Centering rate then not
restoring the
guide rate afterwards).

The intent of these changes is to provide the most
robust
software
interface capabilities found in any amateur mount
to date.

Any suggestions for features are now being accepted!

Thanks,

-Ray Gralak



-----Original Message-----
From: ap-gto@... [mailto:ap-
gto@...]

On Behalf Of chris1011@
Sent: Tuesday, May 23, 2006 10:23 AM
To: ap-gto@...
Subject: Re: [ap-gto] Re: AP1200 operation via
external
programs

In a message dated 5/23/2006 4:59:50 AM Central
Daylight
Time,
nico@ writes:


The Ascom driver should include the same software
features

as in the
keypad, because it needs to know the 'knowledge' of
the
mount, in
order to send the most appropriate sequences to the
mount.

Ajai made
his maximum to send the best command, whithout this
knowledge. The

Ascom driver should be able to display the same
interface as the
keypad (probably from the setupDialog call). In a
first
step this
feature could be activated only when the
mount is used
with ascom
applications, without keypad.
I am working with Ray Gralack to establish a method
whereby
Pulse Guide
becomes the central program that is called upon by the
ASCOM

platform to perform
all startup functions as well as other control
functions. It

will become the
defacto control center when the keypad is not
being used.

People have a misconception that there is something
fundamentally wrong or
incompatible between the AP mounts and ASCOM. That is
a
false
assumption. What
the real issue is, there are no planetarium programs
that
can
properly control
the mount, and there are no plans by these planetarium
writers that I know of
to change their programs to allow full control of the
mount.

That is the
reason we send a copy of Pulse Guide with every mount.
Pulse

guide is the keypad on
your laptop. It has all the features of the keypad
except
the
data for all
the objects in the keypad memory. We could
include those
also
if there is need
for it, however it is assumed that if you wish to use
your
laptop, then you
will want to use your own planetrium program to call
up
these
objects.

As it sits now, almost all planetarium programs will
allow
you to link
directly to the mount and will show you where
your scope
is
pointed, as well as
allow slews to all places in the sky. Some will allow
you to

move the scope
incrementally to center the object, however, there are
bugs
in those commands which
can affect your guiding, pointing, etc. Ray has
suggested
that in the future,
Pulse Guide will act as the central control program
(along
with ASCOM or
without), which will interpret the commands from these
various programs and correct
them to allow error free operation of the mount. I
will
leave
it to Ray to
expand further since he is the expert on these
matters.

Let me just say that we fully intend to make our
mounts
compatible with each
and every program in use by amateurs, no matter how
lacking
they are in
function. We have supported our mountings all
along with
free
software upgrades as
new features and uses become available, and we fully
intend
to continue this.
We are not going to be held hostage to planetarium
program
limitations and will
find a way around any and all shortcomings. As I said
before

and say again,
if any planetarium program writers want to upgrade the
operation of their
controls, I will make all resources available to help
them
develop it.

Roland Christen


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



To UNSUBSCRIBE, or for general information on the
ap-gto
list
see http://groups.yahoo.com/group/ap-gto
Yahoo! Groups Links












To UNSUBSCRIBE, or for general information on the
ap-gto list
see http://groups.yahoo.com/group/ap-gto
Yahoo! Groups Links











To UNSUBSCRIBE, or for general information on the ap-gto list
see http://groups.yahoo.com/group/ap-gto
Yahoo! Groups Links












To UNSUBSCRIBE, or for general information on the ap-gto list
see http://groups.yahoo.com/group/ap-gto
Yahoo! Groups Links







Re: Slight RA jump on DEC direction reversal

mcmillanjr4221
 

Hi Pete,

I don't think this is normal. I suggest you run the diagnostic
routine in PulseGuide and send the results to Roland.

Also, 3 seconds of DEC backlash seems a bit excessive to me. With
careful adjustment of the worm mesh, my AP1200 DEC backlash is more
like 0.6 seconds at 0.5x sidereal.

FWIW.

Jim McMillan

--- In ap-gto@..., "Peter Santangeli" <peter@...> wrote:


A quick question... In adjusting my DEC backlash today (which seems
to
be at about 3 seconds at 0.5x speed), I noticed that RA "jumps" a bit
down when DEC is reversed.

Is this a normal thing? Can it be minimized/eliminated?

Pete


Slight RA jump on DEC direction reversal

Peter Santangeli
 

A quick question... In adjusting my DEC backlash today (which seems to
be at about 3 seconds at 0.5x speed), I noticed that RA "jumps" a bit
down when DEC is reversed.

Is this a normal thing? Can it be minimized/eliminated?

Pete


Re: Pier height selection help needed...

ayiomamitis
 

Edd,

There is a semi permasmile on my face thanks to the arrival of the
AP160 and which is about to become a permanent permasmile with the
arrival of the AP1200GTO.

Oh how many times I have pulled my hair thanks to the "guiding" of my
Losmandy G-11 and/or the number of exposures tossed out thanks to the
countless little ovals which were supposed to be stars. Even with my
AP160 at 1200 mm focal length, I cannot go unguided past 20-25
seconds. With my Pronto (450 mm focal length), I am lucky if I can get
2 minutes exposures binned 2x2 on my ST2000XM.

If only I could find the words to describe my anxiety for the arrival
of the AP1200GTO. I had a similar problem with first light of my AP160
last May ... BREATHTAKING.

These toys (AP160, AP1200GTO) should be outlawed ... they are "deadly"
weapons and tools!

Anthony.

--- In ap-gto@..., "eddwen2001" <Eddwen@...> wrote:

I've never seen a picture of Anthony, so I don't know what he looks
like. but I can sure see him smiling ear-to-ear.

Edd Weninger

(AP1200/AP155 on 46" pier, slightly too low)

--- In ap-gto@..., "ayiomamitis" <ayiomami@> wrote:

I ordered the 54" pier and hopefully will be able to provide feedback
and experience shortly upon the arrival of the new AP1200GTO which
will gracefully host my baby (AP160).

Anthony.


Re: Pier height selection help needed...

Edd Weninger
 

I've never seen a picture of Anthony, so I don't know what he looks
like. but I can sure see him smiling ear-to-ear.

Edd Weninger

(AP1200/AP155 on 46" pier, slightly too low)

--- In ap-gto@..., "ayiomamitis" <ayiomami@...> wrote:

I ordered the 54" pier and hopefully will be able to provide feedback
and experience shortly upon the arrival of the new AP1200GTO which
will gracefully host my baby (AP160).

Anthony.


Re: Pier height selection help needed...

ayiomamitis
 

--- In ap-gto@..., "Mike Chapa" <mjchapa@...> wrote:

Hi Jeff,

Wouldn't you be using a diagonal when using it with an eyepiece?
That's my only input :-)

Dave
I would go with the 48". I have the 24" on JMI wheely bars and am
literally on the ground at zenith with a 6" f7 refractor and a
diagonal...
I ordered the 54" pier and hopefully will be able to provide feedback
and experience shortly upon the arrival of the new AP1200GTO which
will gracefully host my baby (AP160).

Anthony.


Mike Chapa
http://www.chapaccd.com


Re: Pier height selection help needed...

Mike Chapa <mjchapa@...>
 

Hi Jeff,

Wouldn't you be using a diagonal when using it with an eyepiece?
That's my only input :-)

Dave
I would go with the 48". I have the 24" on JMI wheely bars and am
literally on the ground at zenith with a 6" f7 refractor and a
diagonal...

Mike Chapa
http://www.chapaccd.com


Re: Ray IT WORKED! - please read

Dr. David Toth
 

At 06:42 PM 5/27/2006, sink45ny wrote:
Ray I used Help--->"check for updates" in CCDSoft and it reported there
were no updates.
Good thing you directed me to the hotfix site.

I previously reported using CCDSoft version version 5.1.5.9 which I
got from the executable's property page.
It was really version 5.00.159.
For the version number, look under help. Microsoft can come up with some bizarre results at times if you look at the files properties.

Dave


Re: Pier height selection help needed...

mogulskier_groups
 

Hi Jeff,

Wouldn't you be using a diagonal when using it with an eyepiece?
That's my only input :-)

Dave

--- In ap-gto@..., "jeff_crilly" <ne14mx@...> wrote:


Last time for me, I promise. (Btw, I've been thinking of compiling
some dimensions, i.e. eyepiece-height-@-zenith-from-pier-top for
various OTAs on the AP1200 and AP900.)

I'm trying to finalize the AP1200 pier hieght. Either 42" or 48"
is
appropos for me -- the downside w/ 48 is that the saddle might be
too
high to easily get a 30 lb OTA up there. Otoh, if 42" is too
short,
I'll be crawling on the ground at zenith.

I did a bit of estimating, and some math...

Zenith is the worst case, so assuming the DEC is horizontal, the
center of the DEC shaft looks to me to be about 10" from the TOP of
the pier.

(I assumed the diameter of the DEC top to be about 7".)

With a 12" SCT, the back of the SCT (including diagonal) is
probably
8" from the center of the DEC axis. (assuming tail heavy SCT.)

This puts the eyepiece about 2" ABOVE the pier height.

So eyepiece height w/ the 12" SCT for 10x42 and 10x48 is around...

42" pier: eyepeice 40 inches above the ground.
48" pier: eyepiece 46 inches above the ground.

Seated comfortably (knees at 90 degrees), I find that 40" requires
the
neck to be bent just a little. (I'm 5'9")

So, I suspect the 42" pier will work w/ the AP1200, and an SCT,
visually.

However, a refractor (right now FSQ) is going to have an eyepiece
height way too low on the 42" pier. (Fwiw, I use the FSQ on an
AP900
w/ a 48" pier and it is ok.)

Its really a tossup for me.. the 42" has the advantage of being
lower
when loading the AP1200 and OTA on it, at the expense of being a
tad
bit too low for viewing at the zenith, which is fairly rare.

Anyone have direct experience?

Am I missing something?

thanks

jeff