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

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.

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.