RE: [ap-gto] Re: 1200/ACP gets lost


Nov 22, 2011

 


----------------------------

#34064 Nov 22, 2011

Am having an issue with the 1200 getting "lost" when run by ACP. Procedure

is to link The Sky (TS) to the mount, which activates the driver. Will use

the driver to move the telescope north so I can open the roll off roof, then

re park the mount via the driver. System will sit for a bit until I am

ready to start an imaging run (an hour perhaps, more or less). Will write a

script for ACP, that has a "waituntil" command, which tells the system to

sit until a certain time, and then it starts. So, start TS, it links to the

mount via the driver and then I start ACP. While ACP is waiting, the mount

is not tracking (nor is it parked). So when everything starts, the mount is

pointing further east than it thinks it is. Things are not in the field,

they are perhaps 5 or 6 CCD fields away. Both ACP and the driver display

the same time, and positional data as does ACP.it is just not actually

pointing to where it thinks it is.







Any suggestions?







In War: Resolution



In Defeat: Defiance



In Victory: Magnanimity



In Peace: Goodwill



Sir Winston Churchill



Mike J. Shade: mshade@...

Sonoita Hills Observatory, Sonoita Arizona

www.sonoitaobservatories.org/> www.sonoitaobservatories.org



Already, in the gathering dusk, a few of the stars are turning on their

lights.

Vega, the brightest one, is now dropping toward the west. Can it be half

a year since I watched her April rising in the east? Low down in the

southwest Antares blinks a sad farewell to fall...

Leslie Peltier, Starlight Nights



International Dark Sky Association: www.darksky.org/>

www.darksky.org



"I like the dark, it's cheap" Ebenezer Scrooge











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



----------------------------

#34065 Nov 22, 2011

Mike,







What version of the AP ASCOM driver are you using? Why are you connecting to

TheSky?







Steve



www.astral-imaging.com







_____



From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com] On Behalf Of

Mike Shade

Sent: Tuesday, November 22, 2011 9:53 PM

To: ap-gto@yahoogroups.com

Subject: [ap-gto] 1200/ACP gets lost











Am having an issue with the 1200 getting "lost" when run by ACP. Procedure

is to link The Sky (TS) to the mount, which activates the driver. Will use

the driver to move the telescope north so I can open the roll off roof, then

re park the mount via the driver. System will sit for a bit until I am

ready to start an imaging run (an hour perhaps, more or less). Will write a

script for ACP, that has a "waituntil" command, which tells the system to

sit until a certain time, and then it starts. So, start TS, it links to the

mount via the driver and then I start ACP. While ACP is waiting, the mount

is not tracking (nor is it parked). So when everything starts, the mount is

pointing further east than it thinks it is. Things are not in the field,

they are perhaps 5 or 6 CCD fields away. Both ACP and the driver display

the same time, and positional data as does ACP.it is just not actually

pointing to where it thinks it is.



Any suggestions?



In War: Resolution



In Defeat: Defiance



In Victory: Magnanimity



In Peace: Goodwill



Sir Winston Churchill



Mike J. Shade: mshade@... mailto:mshade%40q.com>

Sonoita Hills Observatory, Sonoita Arizona

www.sonoitaobservatories.org/> www.sonoitaobservatories.org



Already, in the gathering dusk, a few of the stars are turning on their

lights.

Vega, the brightest one, is now dropping toward the west. Can it be half

a year since I watched her April rising in the east? Low down in the

southwest Antares blinks a sad farewell to fall...

Leslie Peltier, Starlight Nights



International Dark Sky Association: www.darksky.org/>

www.darksky.org



"I like the dark, it's cheap" Ebenezer Scrooge



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











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



----------------------------

#34066 Nov 22, 2011

The mount is probably getting "lost" because you powered it on after not parking it. The default mode is to start

tracking if the mount was not parked. The time between when you power on and initialize is exactly the error in RA. So,

if that is so, always park your mount or leave the hand controller plugged in so it will initialize the mount.



-Ray Gralak

Author of Astro-Physics Command Center (APCC)

Author of PEMPro: www.ccdware.com

Author of Astro-Physics V2 ASCOM Driver: www.gralak.com/apdriver

Author of PulseGuide: www.pulseguide.com

Author of Sigma: www.gralak.com/sigma



> -----Original Message-----

> From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com] On Behalf Of Mike Shade

> Sent: Tuesday, November 22, 2011 6:53 PM

> To: ap-gto@yahoogroups.com

> Subject: [ap-gto] 1200/ACP gets lost

>

>

>

> Am having an issue with the 1200 getting "lost" when run by ACP. Procedure is to link The Sky

> (TS) to the mount, which activates the driver. Will use the driver to move the telescope

> north so I can open the roll off roof, then re park the mount via the driver. System will sit

> for a bit until I am ready to start an imaging run (an hour perhaps, more or less). Will

> write a script for ACP, that has a "waituntil" command, which tells the system to sit until a

> certain time, and then it starts. So, start TS, it links to the mount via the driver and then

> I start ACP. While ACP is waiting, the mount is not tracking (nor is it parked). So when

> everything starts, the mount is pointing further east than it thinks it is. Things are not in

> the field, they are perhaps 5 or 6 CCD fields away. Both ACP and the driver display the same

> time, and positional data as does ACP.it is just not actually pointing to where it thinks it

> is.

>

> Any suggestions?

>

> In War: Resolution

>

> In Defeat: Defiance

>

> In Victory: Magnanimity

>

> In Peace: Goodwill

>

> Sir Winston Churchill

>

> Mike J. Shade: mshade@... mailto:mshade%40q.com> Sonoita Hills Observatory, Sonoita

> Arizona www.sonoitaobservatories.org/> www.sonoitaobservatories.org

>

> Already, in the gathering dusk, a few of the stars are turning on their lights.

> Vega, the brightest one, is now dropping toward the west. Can it be half a year since I

> watched her April rising in the east? Low down in the southwest Antares blinks a sad farewell

> to fall...

> Leslie Peltier, Starlight Nights

>

> International Dark Sky Association: www.darksky.org/> www.darksky.org

>

> "I like the dark, it's cheap" Ebenezer Scrooge

>

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

>

>

>

>







----------------------------

#34070 Nov 23, 2011

Hi Angus,

> I think this is probably one of the reasons causing my mount to sometimes "lost" too. So I

> would like to have a totally clear understanding of the issues at play.

>

> 1) When power is on/restarted, you said that the default mode is to start tracking if mount

> was not parked. Can this be changed and how? Can I set it to not tracking so as to avoid this

> problem? Or can it be set such that it will never start tracking under any circumstances

> until after initialisation?



The behavior cannot be changed. The only things you can do are one of the following:



1) make sure to park the mount before powering off

2) make sure you have a PC connected and ready to initialize it when powering the mount.

3) leave the keypad plugged in so it will initialize the mount.

> 2) Does the mount (controller) keep the park/unpark state internally? Can this state be

> queried by an external application such as the ASCOM driver, PulseGuide etc?



Not in the publicly available firmware. The new (unreleased) firmware can detect park state.

> 3) If the state is kept internally and cannot be queried by an application. Then does an

> external application keep the park/unpark state independently? Then can they become out of

> sync and causing incorrect park/unpark decisions?



Yes, this can happen, which is why you should always use "Unpark from last parked position". The only exception should

be if you are setting up your mount manually and you want to unpark it from one of the park positions.

> 4) In the keypad manual (page 79 :PO# command), it says that if the mount was not parked and

> an unpark command is sent, it will cause the mount to lose its position. Is that true and how

> will this affect the position accuracy? Can this happen if I control the mount from ACP via

> the ASCOM driver? That is, will the mount get lost if ACP tries to park the mount multiple

> times through the ASCOM driver or tries to unpark the mount when it was not parked?



If you are using the latest beta version of the ASCOM driver this won't happen.

> 5) I have set keypad autoconnect mode to EXT. In order to avoid tracking/timing problem as

> described, must I make sure that the applicaton is connecting to the mount before I try to

> power up the mount? That is, I must make the application waiting for the mount to power up?



Only if you did not park the mount before powering it off. If the mount was parked then you can leave it sit for as long

as necessary after powering up. Only if you failed to park would this be a problem (note: an unexpected power failure

could unintentionally cause this so it's best to have a UPS backing up power).

> 6) What will happen given an inadvertant power lost scenario such as this. Application is

> connected to mount and operating. Power is lost. Power comes back up. Mount powers up. Mount

> starts tracking since it was not parked. Mount cannot get initialisation from application

> since it will take time for PC to reboot and application to restart (even if it is configured

> to do so). When application restarts and reconnects to mount, mount will be "lost" due to the

> time differences of mount/application restart. Is this the case? Is there anyway we can set

> up things to avoid such problems?



Yes, use a UPS, or leave the keypad plugged in. If you use an UPS make sure it is also backing up your PC. Most UPS

devices come with monitoring software which will allow you to run a script or application. Such a script or application

could potentially park the mount before power is completely lost.



-Ray

> --- In ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com> , "Ray Gralak" groups1@...>

> wrote:

> >

> > The mount is probably getting "lost" because you powered it on after

> > not parking it. The default mode is to start tracking if the mount was

> > not parked. The time between when you power on and initialize is exactly the error in RA.

> So, if that is so, always park your mount or leave the hand controller plugged in so it will

> initialize the mount.

> >

> > -Ray Gralak

> > Author of Astro-Physics Command Center (APCC) Author of PEMPro:

> > www.ccdware.com Author of Astro-Physics V2 ASCOM Driver:

> > www.gralak.com/apdriver Author of PulseGuide:

> > www.pulseguide.com Author of Sigma: www.gralak.com/sigma

>

>

>

>



----------------------------

#34071 Nov 23, 2011

Ah, Ray, increased clarity on the issue.Thanks.







Mike Shade







From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com] On Behalf Of

Ray Gralak

Sent: Wednesday, November 23, 2011 7:31 AM

To: ap-gto@yahoogroups.com

Subject: RE: [ap-gto] Re: 1200/ACP gets lost











Hi Angus,

> I think this is probably one of the reasons causing my mount to sometimes

"lost" too. So I > would like to have a totally clear understanding of the issues at play.

>

> 1) When power is on/restarted, you said that the default mode is to start

tracking if mount > was not parked. Can this be changed and how? Can I set it to not tracking

so as to avoid this > problem? Or can it be set such that it will never start tracking under any

circumstances > until after initialisation?



The behavior cannot be changed. The only things you can do are one of the

following:



1) make sure to park the mount before powering off

2) make sure you have a PC connected and ready to initialize it when

powering the mount.

3) leave the keypad plugged in so it will initialize the mount.

> 2) Does the mount (controller) keep the park/unpark state internally? Can

this state be > queried by an external application such as the ASCOM driver, PulseGuide

etc?



Not in the publicly available firmware. The new (unreleased) firmware can

detect park state.

> 3) If the state is kept internally and cannot be queried by an

application. Then does an > external application keep the park/unpark state independently? Then can

they become out of > sync and causing incorrect park/unpark decisions?



Yes, this can happen, which is why you should always use "Unpark from last

parked position". The only exception should

be if you are setting up your mount manually and you want to unpark it from

one of the park positions.

> 4) In the keypad manual (page 79 :PO# command), it says that if the mount

was not parked and > an unpark command is sent, it will cause the mount to lose its position.

Is that true and how > will this affect the position accuracy? Can this happen if I control the

mount from ACP via > the ASCOM driver? That is, will the mount get lost if ACP tries to park

the mount multiple > times through the ASCOM driver or tries to unpark the mount when it was

not parked?



If you are using the latest beta version of the ASCOM driver this won't

happen.

> 5) I have set keypad autoconnect mode to EXT. In order to avoid

tracking/timing problem as > described, must I make sure that the applicaton is connecting to the mount

before I try to > power up the mount? That is, I must make the application waiting for the

mount to power up?



Only if you did not park the mount before powering it off. If the mount was

parked then you can leave it sit for as long

as necessary after powering up. Only if you failed to park would this be a

problem (note: an unexpected power failure

could unintentionally cause this so it's best to have a UPS backing up

power).

> 6) What will happen given an inadvertant power lost scenario such as this.

Application is > connected to mount and operating. Power is lost. Power comes back up.

Mount powers up. Mount > starts tracking since it was not parked. Mount cannot get initialisation

from application > since it will take time for PC to reboot and application to restart (even

if it is configured > to do so). When application restarts and reconnects to mount, mount will

be "lost" due to the > time differences of mount/application restart. Is this the case? Is there

anyway we can set > up things to avoid such problems?



Yes, use a UPS, or leave the keypad plugged in. If you use an UPS make sure

it is also backing up your PC. Most UPS

devices come with monitoring software which will allow you to run a script

or application. Such a script or application

could potentially park the mount before power is completely lost.



-Ray

> --- In ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

mailto:ap-gto%40yahoogroups.com> , "Ray Gralak" groups1@...> > wrote:

> >

> > The mount is probably getting "lost" because you powered it on after

> > not parking it. The default mode is to start tracking if the mount was

> > not parked. The time between when you power on and initialize is exactly

the error in RA. > So, if that is so, always park your mount or leave the hand controller

plugged in so it will > initialize the mount.

> >

> > -Ray Gralak

> > Author of Astro-Physics Command Center (APCC) Author of PEMPro:

> > www.ccdware.com Author of Astro-Physics V2 ASCOM Driver:

> > www.gralak.com/apdriver Author of PulseGuide:

> > www.pulseguide.com Author of Sigma: www.gralak.com/sigma

>

>

>

>











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







----------------------------

#34074 Nov 23, 2011

Hi Ray,



Thanks very much for the prompt and detailed feedbacks. It basically confirms most of my understandings.



Given the current behaviour, I think the most fullproof solution is to connect a keypad to the mount and set autoconnect to YES. It will always be there to initialise the mount when needed.



But the biggest problem is that the keypad clock will gradually become out of sync with the PC (which can be synced to an atomic clock). I wonder if the follow can work:



1) What if I set the keypad to "Get Time/Loc FrMnt"? Will this actually sync the keypad's clock to that of the controller regularly or is this a once off sync at the time this command is selected. Or it does not change the keypad clock at all?



2) Further to above. When the PC application connects to the controller, I can update the controller's clock so that it will remain accurate. Will this change be propagated to the keypad clock? That is, can I get the three clocks in sync whenever the PC application initialises the mount?



3) Further to above. With these settings active (ie autoconnect=YES, Get Time/Loc FrMnt). If the mount powers down and up again, will the keypad initialise the controller with the keypad clock?



4) Further to above. If I set "Sync Mount to PC Time" within the initialisation setup of the ASCOM driver, the driver should poll the PC clock every 5 seconds to ensure that the controller clock remains within 2 seconds from the PC clock. That should get the controller clock very much in sync with the PC. And the Get Time/Loc FrMnt setting will in turn keep the keypad clock in sync as well? Will this work?



Glad to know that the park state can be queried by application in the future. However I think it will be best if mount tracking can remain off until after initialisation. Or at least an application can enable/disable this behaviour. This will ensure that the mount won't get lost. Any reason why this is not considered in future firmware release?



Best regards,

Angus Lau



--- In ap-gto@yahoogroups.com, "Ray Gralak" groups1@...> wrote:

>

> Hi Angus,

>

> > I think this is probably one of the reasons causing my mount to sometimes "lost" too. So I

> > would like to have a totally clear understanding of the issues at play.

> >

> > 1) When power is on/restarted, you said that the default mode is to start tracking if mount

> > was not parked. Can this be changed and how? Can I set it to not tracking so as to avoid this

> > problem? Or can it be set such that it will never start tracking under any circumstances

> > until after initialisation?

>

> The behavior cannot be changed. The only things you can do are one of the following:

>

> 1) make sure to park the mount before powering off

> 2) make sure you have a PC connected and ready to initialize it when powering the mount.

> 3) leave the keypad plugged in so it will initialize the mount.

>

> > 2) Does the mount (controller) keep the park/unpark state internally? Can this state be

> > queried by an external application such as the ASCOM driver, PulseGuide etc?

>

> Not in the publicly available firmware. The new (unreleased) firmware can detect park state.

>

> > 3) If the state is kept internally and cannot be queried by an application. Then does an

> > external application keep the park/unpark state independently? Then can they become out of

> > sync and causing incorrect park/unpark decisions?

>

> Yes, this can happen, which is why you should always use "Unpark from last parked position". The only exception should

> be if you are setting up your mount manually and you want to unpark it from one of the park positions.

>

> > 4) In the keypad manual (page 79 :PO# command), it says that if the mount was not parked and

> > an unpark command is sent, it will cause the mount to lose its position. Is that true and how

> > will this affect the position accuracy? Can this happen if I control the mount from ACP via

> > the ASCOM driver? That is, will the mount get lost if ACP tries to park the mount multiple

> > times through the ASCOM driver or tries to unpark the mount when it was not parked?

>

> If you are using the latest beta version of the ASCOM driver this won't happen.

>

> > 5) I have set keypad autoconnect mode to EXT. In order to avoid tracking/timing problem as

> > described, must I make sure that the applicaton is connecting to the mount before I try to

> > power up the mount? That is, I must make the application waiting for the mount to power up?

>

> Only if you did not park the mount before powering it off. If the mount was parked then you can leave it sit for as long

> as necessary after powering up. Only if you failed to park would this be a problem (note: an unexpected power failure

> could unintentionally cause this so it's best to have a UPS backing up power).

>

> > 6) What will happen given an inadvertant power lost scenario such as this. Application is

> > connected to mount and operating. Power is lost. Power comes back up. Mount powers up. Mount

> > starts tracking since it was not parked. Mount cannot get initialisation from application

> > since it will take time for PC to reboot and application to restart (even if it is configured

> > to do so). When application restarts and reconnects to mount, mount will be "lost" due to the

> > time differences of mount/application restart. Is this the case? Is there anyway we can set

> > up things to avoid such problems?

>

> Yes, use a UPS, or leave the keypad plugged in. If you use an UPS make sure it is also backing up your PC. Most UPS

> devices come with monitoring software which will allow you to run a script or application. Such a script or application

> could potentially park the mount before power is completely lost.

>

> -Ray

>

> > --- In ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com> , "Ray Gralak" groups1@>

> > wrote:

> > >

> > > The mount is probably getting "lost" because you powered it on after

> > > not parking it. The default mode is to start tracking if the mount was

> > > not parked. The time between when you power on and initialize is exactly the error in RA.

> > So, if that is so, always park your mount or leave the hand controller plugged in so it will

> > initialize the mount.

> > >

> > > -Ray Gralak

> > > Author of Astro-Physics Command Center (APCC) Author of PEMPro:

> > > www.ccdware.com Author of Astro-Physics V2 ASCOM Driver:

> > > www.gralak.com/apdriver Author of PulseGuide:

> > > www.pulseguide.com Author of Sigma: www.gralak.com/sigma

> >

> >

> >

> >

>







----------------------------

#34075 Nov 23, 2011

Unfortunately I'm not a keypad expert (I rarely use it) so maybe Howard or someone else will be able to answer your

questions or you should consult the manual for details.

> Glad to know that the park state can be queried by application in the future. However I think

> it will be best if mount tracking can remain off until after initialisation. Or at least an

> application can enable/disable this behaviour. This will ensure that the mount won't get

> lost. Any reason why this is not considered in future firmware release?



It was considered but didn't make it in rev S.



-Ray Gralak

Author of Astro-Physics Command Center (APCC)

Author of PEMPro: www.ccdware.com

Author of Astro-Physics V2 ASCOM Driver: www.gralak.com/apdriver

Author of PulseGuide: www.pulseguide.com

Author of Sigma: www.gralak.com/sigma



> -----Original Message-----

> From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com] On Behalf Of anguskmlau

> Sent: Wednesday, November 23, 2011 8:33 AM

> To: ap-gto@yahoogroups.com

> Subject: [ap-gto] Re: 1200/ACP gets lost

>

>

>

> Hi Ray,

>

> Thanks very much for the prompt and detailed feedbacks. It basically confirms most of my

> understandings.

>

> Given the current behaviour, I think the most fullproof solution is to connect a keypad to

> the mount and set autoconnect to YES. It will always be there to initialise the mount when

> needed.

>

> But the biggest problem is that the keypad clock will gradually become out of sync with the

> PC (which can be synced to an atomic clock). I wonder if the follow can work:

>

> 1) What if I set the keypad to "Get Time/Loc FrMnt"? Will this actually sync the keypad's

> clock to that of the controller regularly or is this a once off sync at the time this command

> is selected. Or it does not change the keypad clock at all?

>

> 2) Further to above. When the PC application connects to the controller, I can update the

> controller's clock so that it will remain accurate. Will this change be propagated to the

> keypad clock? That is, can I get the three clocks in sync whenever the PC application

> initialises the mount?

>

> 3) Further to above. With these settings active (ie autoconnect=YES, Get Time/Loc FrMnt). If

> the mount powers down and up again, will the keypad initialise the controller with the keypad

> clock?

>

> 4) Further to above. If I set "Sync Mount to PC Time" within the initialisation setup of the

> ASCOM driver, the driver should poll the PC clock every 5 seconds to ensure that the

> controller clock remains within 2 seconds from the PC clock. That should get the controller

> clock very much in sync with the PC. And the Get Time/Loc FrMnt setting will in turn keep the

> keypad clock in sync as well? Will this work?

>

> Glad to know that the park state can be queried by application in the future. However I think

> it will be best if mount tracking can remain off until after initialisation. Or at least an

> application can enable/disable this behaviour. This will ensure that the mount won't get

> lost. Any reason why this is not considered in future firmware release?

>

> Best regards,

> Angus Lau

>

> --- In ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com> , "Ray Gralak" groups1@...>

> wrote:

> >

> > Hi Angus,

> >

> > > I think this is probably one of the reasons causing my mount to

> > > sometimes "lost" too. So I would like to have a totally clear understanding of the issues

> at play.

> > >

> > > 1) When power is on/restarted, you said that the default mode is to

> > > start tracking if mount was not parked. Can this be changed and how?

> > > Can I set it to not tracking so as to avoid this problem? Or can it

> > > be set such that it will never start tracking under any circumstances until after

> initialisation?

> >

> > The behavior cannot be changed. The only things you can do are one of the following:

> >

> > 1) make sure to park the mount before powering off

> > 2) make sure you have a PC connected and ready to initialize it when powering the mount.

> > 3) leave the keypad plugged in so it will initialize the mount.

> >

> > > 2) Does the mount (controller) keep the park/unpark state

> > > internally? Can this state be queried by an external application such as the ASCOM

> driver, PulseGuide etc?

> >

> > Not in the publicly available firmware. The new (unreleased) firmware can detect park

> state.

> >

> > > 3) If the state is kept internally and cannot be queried by an

> > > application. Then does an external application keep the park/unpark

> > > state independently? Then can they become out of sync and causing incorrect park/unpark

> decisions?

> >

> > Yes, this can happen, which is why you should always use "Unpark from

> > last parked position". The only exception should be if you are setting up your mount

> manually and you want to unpark it from one of the park positions.

> >

> > > 4) In the keypad manual (page 79 :PO# command), it says that if the

> > > mount was not parked and an unpark command is sent, it will cause

> > > the mount to lose its position. Is that true and how will this

> > > affect the position accuracy? Can this happen if I control the mount

> > > from ACP via the ASCOM driver? That is, will the mount get lost if ACP tries to park the

> mount multiple times through the ASCOM driver or tries to unpark the mount when it was not

> parked?

> >

> > If you are using the latest beta version of the ASCOM driver this won't happen.

> >

> > > 5) I have set keypad autoconnect mode to EXT. In order to avoid

> > > tracking/timing problem as described, must I make sure that the

> > > applicaton is connecting to the mount before I try to power up the mount? That is, I must

> make the application waiting for the mount to power up?

> >

> > Only if you did not park the mount before powering it off. If the

> > mount was parked then you can leave it sit for as long as necessary

> > after powering up. Only if you failed to park would this be a problem (note: an unexpected

> power failure could unintentionally cause this so it's best to have a UPS backing up power).

> >

> > > 6) What will happen given an inadvertant power lost scenario such as

> > > this. Application is connected to mount and operating. Power is

> > > lost. Power comes back up. Mount powers up. Mount starts tracking

> > > since it was not parked. Mount cannot get initialisation from

> > > application since it will take time for PC to reboot and application

> > > to restart (even if it is configured to do so). When application

> > > restarts and reconnects to mount, mount will be "lost" due to the time differences of

> mount/application restart. Is this the case? Is there anyway we can set up things to avoid

> such problems?

> >

> > Yes, use a UPS, or leave the keypad plugged in. If you use an UPS make

> > sure it is also backing up your PC. Most UPS devices come with

> > monitoring software which will allow you to run a script or application. Such a script or

> application could potentially park the mount before power is completely lost.

> >

> > -Ray

> >

> > > --- In ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

> > > mailto:ap-gto%40yahoogroups.com> , "Ray Gralak" groups1@>

> > > wrote:

> > > >

> > > > The mount is probably getting "lost" because you powered it on

> > > > after not parking it. The default mode is to start tracking if the

> > > > mount was not parked. The time between when you power on and initialize is exactly the

> error in RA.

> > > So, if that is so, always park your mount or leave the hand

> > > controller plugged in so it will initialize the mount.

> > > >

> > > > -Ray Gralak

> > > > Author of Astro-Physics Command Center (APCC) Author of PEMPro:

> > > > www.ccdware.com Author of Astro-Physics V2 ASCOM Driver:

> > > > www.gralak.com/apdriver Author of PulseGuide:

> > > > www.pulseguide.com Author of Sigma:

> > > > www.gralak.com/sigma

> > >

> > >

> > >

> > >

> >

>

>

>

>







----------------------------

#34077 Nov 23, 2011

It's a pity these potential problem holes are not plugged in the firmware



Well, it's a matter of how you look at this issue. The mount was designed to work for both visual and imaging work. One

design decision was that if a mount is powered off (presumably by a visual observer) that it had better start tracking

when powered on! Just think of the support issues if it didn't! (e.g., my mount is broken... it won't track!) This was

one of the reasons it was not put in the firmware.



For imaging there is an expected level of extra work involved so "parking" the mount *is* the fix to the "problem hole"

for imagers.



-Ray Gralak

Author of Astro-Physics Command Center (APCC)

Author of PEMPro: www.ccdware.com

Author of Astro-Physics V2 ASCOM Driver: www.gralak.com/apdriver

Author of PulseGuide: www.pulseguide.com

Author of Sigma: www.gralak.com/sigma



> -----Original Message-----

> From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com] On Behalf Of anguskmlau

> Sent: Wednesday, November 23, 2011 9:23 AM

> To: ap-gto@yahoogroups.com

> Subject: [ap-gto] Re: 1200/ACP gets lost

>

>

>

> Thanks, Ray!

>

> I have read the manuals and all available documentations cover to cover several times. But

> sometimes the manuals are not entirely clear. I have difficulty getting hold of Howard, he

> seems to be very busy lately...

>

> It's a pity these potential problem holes are not plugged in the firmware. I think this is

> very important for truely remote setups. It is a real pain to recover remotely once the mount

> lost it's position.

>

> Another alternative I may take is to home my mount everytime it starts up (like the

> Paramount) since I have the home switches installed. I have tried it and it almost always

> home to within 10-20 arcmin of park position 2. But even then it does not guarantee a

> successful plate-solve after the initial slew. Have to enable spiral search in PinPoint in

> order to make it work.

>

> At present, I have to use a terminal emulator to enter the home command ($HA#). This is quite

> difficult to automate using ACP scripts. Will the APCC allow easy automated homing within

> ACP? Will the homing be more accurate (say within a few arcmins) so that a subsequent plate-

> solve can be almost guaranteed?

>

> Thanks again!

>

> Angus Lau

>

> --- In ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com> , "Ray Gralak" groups1@...>

> wrote:

> >

> > Unfortunately I'm not a keypad expert (I rarely use it) so maybe

> > Howard or someone else will be able to answer your questions or you should consult the

> manual for details.

> >

> > > Glad to know that the park state can be queried by application in

> > > the future. However I think it will be best if mount tracking can

> > > remain off until after initialisation. Or at least an application

> > > can enable/disable this behaviour. This will ensure that the mount won't get lost. Any

> reason why this is not considered in future firmware release?

> >

> > It was considered but didn't make it in rev S.

> >

> > -Ray Gralak

> > Author of Astro-Physics Command Center (APCC) Author of PEMPro:

> > www.ccdware.com Author of Astro-Physics V2 ASCOM Driver:

> > www.gralak.com/apdriver Author of PulseGuide:

> > www.pulseguide.com Author of Sigma: www.gralak.com/sigma

> >

> >

> > > -----Original Message-----

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

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

> > > On Behalf Of anguskmlau

> > > Sent: Wednesday, November 23, 2011 8:33 AM

> > > To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

> > > Subject: [ap-gto] Re: 1200/ACP gets lost

> > >

> > >

> > >

> > > Hi Ray,

> > >

> > > Thanks very much for the prompt and detailed feedbacks. It basically

> > > confirms most of my understandings.

> > >

> > > Given the current behaviour, I think the most fullproof solution is

> > > to connect a keypad to the mount and set autoconnect to YES. It will

> > > always be there to initialise the mount when needed.

> > >

> > > But the biggest problem is that the keypad clock will gradually

> > > become out of sync with the PC (which can be synced to an atomic clock). I wonder if the

> follow can work:

> > >

> > > 1) What if I set the keypad to "Get Time/Loc FrMnt"? Will this

> > > actually sync the keypad's clock to that of the controller regularly

> > > or is this a once off sync at the time this command is selected. Or it does not change

> the keypad clock at all?

> > >

> > > 2) Further to above. When the PC application connects to the

> > > controller, I can update the controller's clock so that it will

> > > remain accurate. Will this change be propagated to the keypad clock?

> > > That is, can I get the three clocks in sync whenever the PC application initialises the

> mount?

> > >

> > > 3) Further to above. With these settings active (ie autoconnect=YES,

> > > Get Time/Loc FrMnt). If the mount powers down and up again, will the

> > > keypad initialise the controller with the keypad clock?

> > >

> > > 4) Further to above. If I set "Sync Mount to PC Time" within the

> > > initialisation setup of the ASCOM driver, the driver should poll the

> > > PC clock every 5 seconds to ensure that the controller clock remains

> > > within 2 seconds from the PC clock. That should get the controller

> > > clock very much in sync with the PC. And the Get Time/Loc FrMnt setting will in turn keep

> the keypad clock in sync as well? Will this work?

> > >

> > > Glad to know that the park state can be queried by application in

> > > the future. However I think it will be best if mount tracking can

> > > remain off until after initialisation. Or at least an application

> > > can enable/disable this behaviour. This will ensure that the mount won't get lost. Any

> reason why this is not considered in future firmware release?

> > >

> > > Best regards,

> > > Angus Lau

> > >

>

>

>

>







----------------------------

#34078 Nov 23, 2011

Understand the considerations and may be the best default. But if an imager can configure the behavior, it should not compromise the visual users.



Yes, I believe most imagers will try to park the mount at end of day. But there are always unforseen circumstances which left the mount not parked properly. It is under such occassions which causes a lot of pain...



Any comments on the homing feature of APCC?



Thanks,



Angus Lau



--- In ap-gto@yahoogroups.com, "Ray Gralak" groups1@...> wrote:

>

> > It's a pity these potential problem holes are not plugged in the firmware

>

> Well, it's a matter of how you look at this issue. The mount was designed to work for both visual and imaging work. One

> design decision was that if a mount is powered off (presumably by a visual observer) that it had better start tracking

> when powered on! Just think of the support issues if it didn't! (e.g., my mount is broken... it won't track!) This was

> one of the reasons it was not put in the firmware.

>

> For imaging there is an expected level of extra work involved so "parking" the mount *is* the fix to the "problem hole"

> for imagers.

>

> -Ray Gralak

> Author of Astro-Physics Command Center (APCC)

> Author of PEMPro: www.ccdware.com

> Author of Astro-Physics V2 ASCOM Driver: www.gralak.com/apdriver

> Author of PulseGuide: www.pulseguide.com

> Author of Sigma: www.gralak.com/sigma

>

>

> > -----Original Message-----

> > From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com] On Behalf Of anguskmlau

> > Sent: Wednesday, November 23, 2011 9:23 AM

> > To: ap-gto@yahoogroups.com

> > Subject: [ap-gto] Re: 1200/ACP gets lost

> >

> >

> >

> > Thanks, Ray!

> >

> > I have read the manuals and all available documentations cover to cover several times. But

> > sometimes the manuals are not entirely clear. I have difficulty getting hold of Howard, he

> > seems to be very busy lately...

> >

> > It's a pity these potential problem holes are not plugged in the firmware. I think this is

> > very important for truely remote setups. It is a real pain to recover remotely once the mount

> > lost it's position.

> >

> > Another alternative I may take is to home my mount everytime it starts up (like the

> > Paramount) since I have the home switches installed. I have tried it and it almost always

> > home to within 10-20 arcmin of park position 2. But even then it does not guarantee a

> > successful plate-solve after the initial slew. Have to enable spiral search in PinPoint in

> > order to make it work.

> >

> > At present, I have to use a terminal emulator to enter the home command ($HA#). This is quite

> > difficult to automate using ACP scripts. Will the APCC allow easy automated homing within

> > ACP? Will the homing be more accurate (say within a few arcmins) so that a subsequent plate-

> > solve can be almost guaranteed?

> >

> > Thanks again!

> >

> > Angus Lau

> >



----------------------------

#34079 Nov 23, 2011

Hi Angus and group,



I believe I may have a better solution for the power glitch problem. Leave the keypad set to auto-connect = EXT so that you do not experience any time syncing problems between the keypad, the servo, and your PC. However, make sure that the keypad's tracking rate is set to 8=T:STOP In versions 4.17 and later of the keypad firmware, the tracking rate of zero or stop will be sent to the servo by the keypad immediately upon power-up; before any initialization takes place. There is normally about a one-second delay, equivalent to only 15 arcseconds, where the servo will start tracking before the tracking is stopped, but that is insignificant. The catch is that the keypad tracking rate MUST be set to STOP. You must remember this if you actually use the keypad. In the next keypad firmware, the EXT mode will always start by setting the tracking to stop regardless of the keypad's tracking rate setting.



BTW, I apologize for my recent absence. I've been fighting a nasty respiratory bug I picked up around AIC. However, to quote Monty Python: "I'm not dead yet!"



Mag. 7 Skies!



Howard Hedlund

Astro-Physics, Inc.

Phone: 815-282-1513

www.astro-physics.comwww.astro-physics.com/>

Please include this e-mail with your response.



P Consider the environment before printing this e-mail.





From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com] On Behalf Of anguskmlau

Sent: Wednesday, November 23, 2011 11:50 AM

To: ap-gto@yahoogroups.com

Subject: [ap-gto] Re: 1200/ACP gets lost







Understand the considerations and may be the best default. But if an imager can configure the behavior, it should not compromise the visual users.



Yes, I believe most imagers will try to park the mount at end of day. But there are always unforseen circumstances which left the mount not parked properly. It is under such occassions which causes a lot of pain...



Any comments on the homing feature of APCC?



Thanks,



Angus Lau

--- In ap-gto@yahoogroups.commailto:ap-gto%40yahoogroups.com>, "Ray Gralak" groups1@...mailto:groups1@...>> wrote:

>

> > It's a pity these potential problem holes are not plugged in the firmware

>

> Well, it's a matter of how you look at this issue. The mount was designed to work for both visual and imaging work. One

> design decision was that if a mount is powered off (presumably by a visual observer) that it had better start tracking

> when powered on! Just think of the support issues if it didn't! (e.g., my mount is broken... it won't track!) This was

> one of the reasons it was not put in the firmware.

>

> For imaging there is an expected level of extra work involved so "parking" the mount *is* the fix to the "problem hole"

> for imagers.

>

> -Ray Gralak

> Author of Astro-Physics Command Center (APCC)

> Author of PEMPro: www.ccdware.com

> Author of Astro-Physics V2 ASCOM Driver: www.gralak.com/apdriver

> Author of PulseGuide: www.pulseguide.com

> Author of Sigma: www.gralak.com/sigma

>

>

> > -----Original Message-----

> > From: ap-gto@yahoogroups.commailto:ap-gto%40yahoogroups.com> [mailto:ap-gto@yahoogroups.commailto:ap-gto%40yahoogroups.com>] On Behalf Of anguskmlau

> > Sent: Wednesday, November 23, 2011 9:23 AM

> > To: ap-gto@yahoogroups.commailto:ap-gto%40yahoogroups.com>

> > Subject: [ap-gto] Re: 1200/ACP gets lost

> >

> >

> >

> > Thanks, Ray!

> >

> > I have read the manuals and all available documentations cover to cover several times. But

> > sometimes the manuals are not entirely clear. I have difficulty getting hold of Howard, he

> > seems to be very busy lately...

> >

> > It's a pity these potential problem holes are not plugged in the firmware. I think this is

> > very important for truely remote setups. It is a real pain to recover remotely once the mount

> > lost it's position.

> >

> > Another alternative I may take is to home my mount everytime it starts up (like the

> > Paramount) since I have the home switches installed. I have tried it and it almost always

> > home to within 10-20 arcmin of park position 2. But even then it does not guarantee a

> > successful plate-solve after the initial slew. Have to enable spiral search in PinPoint in

> > order to make it work.

> >

> > At present, I have to use a terminal emulator to enter the home command ($HA#). This is quite

> > difficult to automate using ACP scripts. Will the APCC allow easy automated homing within

> > ACP? Will the homing be more accurate (say within a few arcmins) so that a subsequent plate-

> > solve can be almost guaranteed?

> >

> > Thanks again!

> >

> > Angus Lau

> >







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







----------------------------

#34081 Nov 23, 2011

Default sidereal rotation is fundamental to the servo (the GTOCPx control box). Don't think of it as a rate that you set. Think of sidereal as the "normal" state of the servo. Think of the STOP rate as being a "special" rate that sets the normal back to zero - sort of a minus sidereal that undoes the normal state.



If the servo is powered up with no contrary instructions (i.e. from the keypad) , it will always start in its default state of sidereal rotation unless it was parked at the last power-down. If you want to change the normal state (sidereal) to a different one (stop), you must have some way of delivering the command to the servo. With this in mind, if you want to employ the keypad as a safety mechanism, it needs to be connected with the tracking rate set to STOP.



This will work with the keypad's auto-connect set to either EXT or to YES. The difference is that with "YES", the keypad initializes the servo with its internal time and location data. This data may not match the PC when it is connected later. With EXT, no initialization data is sent, and the keypad simply waits for initialization data to be sent from a PC. However, in either case, the keypad will (almost) immediately send the tracking rate command that matches its rate when it was powered down. This is why a keypad set to tracking rate=STOP can work as a safety mechanism for power glitches.



Mag. 7 Skies!



Howard Hedlund

Astro-Physics, Inc.

Phone: 815-282-1513

www.astro-physics.comwww.astro-physics.com/>

Please include this e-mail with your response.



P Consider the environment before printing this e-mail.





From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com] On Behalf Of Mike Shade

Sent: Wednesday, November 23, 2011 1:20 PM

To: ap-gto@yahoogroups.com

Subject: RE: [ap-gto] Re: 1200/ACP gets lost







Question: What if you do NOT use or have the keypad plugged in at all? Or,

are you suggesting that even if one is running the system remotely and in an

automated manner via a PC, one leave the keypad plugged in?



From: ap-gto@yahoogroups.commailto:ap-gto%40yahoogroups.com> [mailto:ap-gto@yahoogroups.commailto:ap-gto%40yahoogroups.com>] On Behalf Of

Howard

Sent: Wednesday, November 23, 2011 11:57 AM

To: ap-gto@yahoogroups.commailto:ap-gto%40yahoogroups.com>

Subject: RE: [ap-gto] Re: 1200/ACP gets lost



Hi Angus and group,



I believe I may have a better solution for the power glitch problem. Leave

the keypad set to auto-connect = EXT so that you do not experience any time

syncing problems between the keypad, the servo, and your PC. However, make

sure that the keypad's tracking rate is set to 8=T:STOP In versions 4.17 and

later of the keypad firmware, the tracking rate of zero or stop will be sent

to the servo by the keypad immediately upon power-up; before any

initialization takes place. There is normally about a one-second delay,

equivalent to only 15 arcseconds, where the servo will start tracking before

the tracking is stopped, but that is insignificant. The catch is that the

keypad tracking rate MUST be set to STOP. You must remember this if you

actually use the keypad. In the next keypad firmware, the EXT mode will

always start by setting the tracking to stop regardless of the keypad's

tracking rate setting.



BTW, I apologize for my recent absence. I've been fighting a nasty

respiratory bug I picked up around AIC. However, to quote Monty Python: "I'm

not dead yet!"



Mag. 7 Skies!



Howard Hedlund

Astro-Physics, Inc.

Phone: 815-282-1513

www.astro-physics.comwww.astro-physics.com/>

Please include this e-mail with your response.



P Consider the environment before printing this e-mail.



From: ap-gto@yahoogroups.commailto:ap-gto%40yahoogroups.com> mailto:ap-gto%40yahoogroups.com>

[mailto:ap-gto@yahoogroups.commailto:ap-gto%40yahoogroups.com> mailto:ap-gto%40yahoogroups.com> ] On Behalf

Of anguskmlau

Sent: Wednesday, November 23, 2011 11:50 AM

To: ap-gto@yahoogroups.commailto:ap-gto%40yahoogroups.com> mailto:ap-gto%40yahoogroups.com>

Subject: [ap-gto] Re: 1200/ACP gets lost



Understand the considerations and may be the best default. But if an imager

can configure the behavior, it should not compromise the visual users.



Yes, I believe most imagers will try to park the mount at end of day. But

there are always unforseen circumstances which left the mount not parked

properly. It is under such occassions which causes a lot of pain...



Any comments on the homing feature of APCC?



Thanks,



Angus Lau



--- In ap-gto@yahoogroups.commailto:ap-gto%40yahoogroups.com> mailto:ap-gto%40yahoogroups.com>

mailto:ap-gto%40yahoogroups.com>, "Ray Gralak"

groups1@...mailto:groups1@...mailto:groups1@...%3cmailto:groups1@...>>> wrote: >

> > It's a pity these potential problem holes are not plugged in the

firmware >

> Well, it's a matter of how you look at this issue. The mount was designed

to work for both visual and imaging work. One > design decision was that if a mount is powered off (presumably by a visual

observer) that it had better start tracking > when powered on! Just think of the support issues if it didn't! (e.g., my

mount is broken... it won't track!) This was > one of the reasons it was not put in the firmware.

>

> For imaging there is an expected level of extra work involved so "parking"

the mount *is* the fix to the "problem hole" > for imagers.

>

> -Ray Gralak

> Author of Astro-Physics Command Center (APCC)

> Author of PEMPro: www.ccdware.com

> Author of Astro-Physics V2 ASCOM Driver: www.gralak.com/apdriver

> Author of PulseGuide: www.pulseguide.com

> Author of Sigma: www.gralak.com/sigma

>

>

> > -----Original Message-----

> > From: ap-gto@yahoogroups.commailto:ap-gto%40yahoogroups.com> mailto:ap-gto%40yahoogroups.com>

mailto:ap-gto%40yahoogroups.com> [mailto:ap-gto@yahoogroups.commailto:ap-gto%40yahoogroups.com>

mailto:ap-gto%40yahoogroups.com> mailto:ap-gto%40yahoogroups.com>] On

Behalf Of anguskmlau > > Sent: Wednesday, November 23, 2011 9:23 AM

> > To: ap-gto@yahoogroups.commailto:ap-gto%40yahoogroups.com> mailto:ap-gto%40yahoogroups.com>

mailto:ap-gto%40yahoogroups.com> > > Subject: [ap-gto] Re: 1200/ACP gets lost

> >

> >

> >

> > Thanks, Ray!

> >

> > I have read the manuals and all available documentations cover to cover

several times. But > > sometimes the manuals are not entirely clear. I have difficulty getting

hold of Howard, he > > seems to be very busy lately...

> >

> > It's a pity these potential problem holes are not plugged in the

firmware. I think this is > > very important for truely remote setups. It is a real pain to recover

remotely once the mount > > lost it's position.

> >

> > Another alternative I may take is to home my mount everytime it starts

up (like the > > Paramount) since I have the home switches installed. I have tried it and

it almost always > > home to within 10-20 arcmin of park position 2. But even then it does

not guarantee a > > successful plate-solve after the initial slew. Have to enable spiral

search in PinPoint in > > order to make it work.

> >

> > At present, I have to use a terminal emulator to enter the home command

($HA#). This is quite > > difficult to automate using ACP scripts. Will the APCC allow easy

automated homing within > > ACP? Will the homing be more accurate (say within a few arcmins) so that

a subsequent plate- > > solve can be almost guaranteed?

> >

> > Thanks again!

> >

> > Angus Lau

> >



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



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







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







----------------------------

#34085 Nov 23, 2011

I am a little confused as you are. I do NOT use or leave the keypad plugged

in, running everything from the PC.So leave the keypad plugged in or.?

Still a bit unclear.







From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com] On Behalf Of

mihalco

Sent: Wednesday, November 23, 2011 5:01 PM

To: ap-gto@yahoogroups.com

Subject: [ap-gto] Re: 1200/ACP gets lost











Re-reading your post, I may have misunderstood. 4.17 (or later) ONLY sends a

rate command IF the tracking rate is set to zero, otherwise it leaves things

alone?

Thanks,

Kurt



--- In ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com> , "mihalco"

mihalco@...> wrote: >

> Hi Howard,

> I normally let the PC initialize the mount, and leave the keypad

disconnected (There is significantly less drain on the battery powering the

mount without the keypad). Now, say I come along later and plug in the

keypad (which is set to EXT). You're saying that 4.17 (or later) will STOP

the tracking? Now my PC isn't pointing at the target I slewed to. It could

also ruin an exposure sequence. Seems like the meaning of EXT has been

redefined. It used to be if the mount was initialized, if a keypad in EXT

mode was plugged in, it left things alone, right? > Kurt

>

> --- In ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com> , Howard

howard@> wrote: > >

> > Hi Angus and group,

> >

> > I believe I may have a better solution for the power glitch problem.

Leave the keypad set to auto-connect = EXT so that you do not experience any

time syncing problems between the keypad, the servo, and your PC. However,

make sure that the keypad's tracking rate is set to 8=T:STOP In versions

4.17 and later of the keypad firmware, the tracking rate of zero or stop

will be sent to the servo by the keypad immediately upon power-up; before

any initialization takes place. There is normally about a one-second delay,

equivalent to only 15 arcseconds, where the servo will start tracking before

the tracking is stopped, but that is insignificant. The catch is that the

keypad tracking rate MUST be set to STOP. You must remember this if you

actually use the keypad. In the next keypad firmware, the EXT mode will

always start by setting the tracking to stop regardless of the keypad's

tracking rate setting. > >

> > BTW, I apologize for my recent absence. I've been fighting a nasty

respiratory bug I picked up around AIC. However, to quote Monty Python: "I'm

not dead yet!" > >

> > Mag. 7 Skies!

> >

> > Howard Hedlund

> > Astro-Physics, Inc.

> > Phone: 815-282-1513

> > www.astro-physics.comwww.astro-physics.com/>

> > Please include this e-mail with your response.

> >

> > P Consider the environment before printing this e-mail.

> >

> >

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

[mailto:ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com> ] On Behalf

Of anguskmlau > > Sent: Wednesday, November 23, 2011 11:50 AM

> > To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

> > Subject: [ap-gto] Re: 1200/ACP gets lost

> >

> >

> >

> > Understand the considerations and may be the best default. But if an

imager can configure the behavior, it should not compromise the visual

users. > >

> > Yes, I believe most imagers will try to park the mount at end of day.

But there are always unforseen circumstances which left the mount not parked

properly. It is under such occassions which causes a lot of pain... > >

> > Any comments on the homing feature of APCC?

> >

> > Thanks,

> >

> > Angus Lau

> >

> > --- In ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

mailto:ap-gto%40yahoogroups.com>, "Ray Gralak" groups1@mailto:groups1@>>

wrote: > > >

> > > > It's a pity these potential problem holes are not plugged in the

firmware > > >

> > > Well, it's a matter of how you look at this issue. The mount was

designed to work for both visual and imaging work. One > > > design decision was that if a mount is powered off (presumably by a

visual observer) that it had better start tracking > > > when powered on! Just think of the support issues if it didn't! (e.g.,

my mount is broken... it won't track!) This was > > > one of the reasons it was not put in the firmware.

> > >

> > > For imaging there is an expected level of extra work involved so

"parking" the mount *is* the fix to the "problem hole" > > > for imagers.

> > >

> > > -Ray Gralak

> > > Author of Astro-Physics Command Center (APCC)

> > > Author of PEMPro: www.ccdware.com

> > > Author of Astro-Physics V2 ASCOM Driver:

www.gralak.com/apdriver > > > Author of PulseGuide: www.pulseguide.com

> > > Author of Sigma: www.gralak.com/sigma

> > >

> > >

> > > > -----Original Message-----

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

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

mailto:ap-gto%40yahoogroups.com> mailto:ap-gto%40yahoogroups.com>] On

Behalf Of anguskmlau > > > > Sent: Wednesday, November 23, 2011 9:23 AM

> > > > To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

mailto:ap-gto%40yahoogroups.com> > > > > Subject: [ap-gto] Re: 1200/ACP gets lost

> > > >

> > > >

> > > >

> > > > Thanks, Ray!

> > > >

> > > > I have read the manuals and all available documentations cover to

cover several times. But > > > > sometimes the manuals are not entirely clear. I have difficulty

getting hold of Howard, he > > > > seems to be very busy lately...

> > > >

> > > > It's a pity these potential problem holes are not plugged in the

firmware. I think this is > > > > very important for truely remote setups. It is a real pain to

recover remotely once the mount > > > > lost it's position.

> > > >

> > > > Another alternative I may take is to home my mount everytime it

starts up (like the > > > > Paramount) since I have the home switches installed. I have tried it

and it almost always > > > > home to within 10-20 arcmin of park position 2. But even then it

does not guarantee a > > > > successful plate-solve after the initial slew. Have to enable spiral

search in PinPoint in > > > > order to make it work.

> > > >

> > > > At present, I have to use a terminal emulator to enter the home

command ($HA#). This is quite > > > > difficult to automate using ACP scripts. Will the APCC allow easy

automated homing within > > > > ACP? Will the homing be more accurate (say within a few arcmins) so

that a subsequent plate- > > > > solve can be almost guaranteed?

> > > >

> > > > Thanks again!

> > > >

> > > > Angus Lau

> > > >

> >

> >

> >

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

> >

>











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







----------------------------

#34088 Nov 23, 2011

Thanks Howard!

Good to know the keypad (in EXT mode) always sets whatever the last rate was. I never noticed any changes when I plugged in the keypad, so I assumed it didn't do anything. Just for discussion, why not have the servo ALWAYS power up in Park state? The ASCOM driver would already handle this, and the keypad software (for those visual guys) could simple unpark it if it's not set to EXT. Might save tracking into the pier if something failed.

Kurt

--- In ap-gto@yahoogroups.com, Howard howard@...> wrote:

>

> Hi Kurt.

>

> I'm sorry if I didn't explain it well enough. The keypad will set the tracking rate to whatever its last setting was when it is plugged in. If you are using the keypad as a safety mechanism (instead of the better solution that would involve a battery backup system with automated shut-down including a park), then you will have the keypad set to EXT and the keypad's tracking rate to stop. You would also always leave the keypad plugged in since an unplugged keypad would provide no safety mechanism.

>

> Plugging a keypad into an initialized and running mount when the keypad has been set to stop will indeed stop the tracking, but you wouldn't do this under any normal usage. If you are using the keypad as an occasional tool for a quick GoTo or for centering, then leave the tracking rate set to sidereal on the keypad. You have no reason to ever set the keypad to stop, and the keypad will therefore never be inclined to set the mount's rate to stop. In other words, you can plug a keypad that has auto-connect = EXT into your mount at any time without affecting tracking as long as the keypad's rate is set to sidereal.

>

> BTW, I believe that this has been the case since the beginning of the version 4.x keypad firmware. I just didn't have a keypad with v.4.12 or earlier handy to test. I could confirm that it works that way in v.4.17, so that is what I wrote.

>

> The future version that will include the default stop setting for EXT will only set the stop rate on a mount that is NOT initialized. The keypad and other software (like the AP V2 ASCOM Driver) knows that a mount is not initialized because RA = 0 and Dec = 90 when the servo is polled. This would be the logic for the keypad in EXT mode upon connection / power-up: If the poll yields 0 and 90, set tracking to stop. If the poll yields anything else (meaning the mount has been initialized and is in operation), don't set the tracking at all as this should have been set by the external software. This should take care of all the contingencies (I hope!)

>

> Be aware: I believe that the current keypad firmware always sends its last set tracking rate upon connection to a mount. It does this regardless of the autoconnect setting and regardless of whether the mount is initialized or not. I have this in the list of things for our keypad firmware guy to change using the logic described above.

>

> I hope this clears things up.

>

> Mag. 7 Skies!

>

> Howard Hedlund

> Astro-Physics, Inc.

> Phone: 815-282-1513

> www.astro-physics.comwww.astro-physics.com/>

> Please include this e-mail with your response.

>



----------------------------

#34092 Nov 24, 2011

Steve,



Did the mount lose its position after you finally initialized it with ACP?



-Ray Gralak

Author of Astro-Physics Command Center (APCC)

Author of PEMPro: www.ccdware.com

Author of Astro-Physics V2 ASCOM Driver: www.gralak.com/apdriver

Author of PulseGuide: www.pulseguide.com

Author of Sigma: www.gralak.com/sigma



> -----Original Message-----

> From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com] On Behalf Of Steve Reilly

> Sent: Wednesday, November 23, 2011 10:30 PM

> To: ap-gto@yahoogroups.com

> Subject: RE: [ap-gto] Re: 1200/ACP gets lost

>

>

>

> Hey Ray,

>

> Interestingly enough I had powered my AP1200 this evening and forgot about it while doing

> some other chores. I have to say I hadn't seen this behavior before but when I looked in on

> the mount several hours later it was well past the park 3 position I always park it at. I use

> ACP and the hand controller is not connected. After an imaging run, ACP parks the mount and

> closes the roof, disconnects the mount and camera.

>

> To start the system I power up the equipment, connect MaxIm to the camera, start the cooling,

> start ACP and connect to the mount and camera. Then I start the plan. Seems I'm following the

> conditions you stated so I'm not sure why the mount was tracking. I can say that ACP was not

> connected after powering up this afternoon. I don't usually power up and not connect ACP so I

> don't see this normally.

>

> Steve

>

> www.astral-imaging.com

>

> _____

>

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

> gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com> ] On Behalf Of Ray Gralak

> Sent: Wednesday, November 23, 2011 9:31 AM

> To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

> Subject: RE: [ap-gto] Re: 1200/ACP gets lost

>

> Hi Angus,

>

> > I think this is probably one of the reasons causing my mount to

> > sometimes

> "lost" too. So I

> > would like to have a totally clear understanding of the issues at play.

> >

> > 1) When power is on/restarted, you said that the default mode is to

> > start

> tracking if mount

> > was not parked. Can this be changed and how? Can I set it to not

> > tracking

> so as to avoid this

> > problem? Or can it be set such that it will never start tracking under

> > any

> circumstances

> > until after initialisation?

>

> The behavior cannot be changed. The only things you can do are one of the

> following:

>

> 1) make sure to park the mount before powering off

> 2) make sure you have a PC connected and ready to initialize it when powering the mount.

> 3) leave the keypad plugged in so it will initialize the mount.

>

> > 2) Does the mount (controller) keep the park/unpark state internally?

> > Can

> this state be

> > queried by an external application such as the ASCOM driver,

> > PulseGuide

> etc?

>

> Not in the publicly available firmware. The new (unreleased) firmware can detect park state.

>

> > 3) If the state is kept internally and cannot be queried by an

> application. Then does an

> > external application keep the park/unpark state independently? Then

> > can

> they become out of

> > sync and causing incorrect park/unpark decisions?

>

> Yes, this can happen, which is why you should always use "Unpark from last parked position".

> The only exception should be if you are setting up your mount manually and you want to unpark

> it from one of the park positions.

>

> > 4) In the keypad manual (page 79 :PO# command), it says that if the

> > mount

> was not parked and

> > an unpark command is sent, it will cause the mount to lose its position.

> Is that true and how

> > will this affect the position accuracy? Can this happen if I control

> > the

> mount from ACP via

> > the ASCOM driver? That is, will the mount get lost if ACP tries to

> > park

> the mount multiple

> > times through the ASCOM driver or tries to unpark the mount when it

> > was

> not parked?

>

> If you are using the latest beta version of the ASCOM driver this won't happen.

>

> > 5) I have set keypad autoconnect mode to EXT. In order to avoid

> tracking/timing problem as

> > described, must I make sure that the applicaton is connecting to the

> > mount

> before I try to

> > power up the mount? That is, I must make the application waiting for

> > the

> mount to power up?

>

> Only if you did not park the mount before powering it off. If the mount was parked then you

> can leave it sit for as long as necessary after powering up. Only if you failed to park would

> this be a problem (note: an unexpected power failure could unintentionally cause this so it's

> best to have a UPS backing up power).

>

> > 6) What will happen given an inadvertant power lost scenario such as this.

> Application is

> > connected to mount and operating. Power is lost. Power comes back up.

> Mount powers up. Mount

> > starts tracking since it was not parked. Mount cannot get

> > initialisation

> from application

> > since it will take time for PC to reboot and application to restart

> > (even

> if it is configured

> > to do so). When application restarts and reconnects to mount, mount

> > will

> be "lost" due to the

> > time differences of mount/application restart. Is this the case? Is

> > there

> anyway we can set

> > up things to avoid such problems?

>

> Yes, use a UPS, or leave the keypad plugged in. If you use an UPS make sure it is also

> backing up your PC. Most UPS devices come with monitoring software which will allow you to

> run a script or application. Such a script or application could potentially park the mount

> before power is completely lost.

>

> -Ray

>

> > --- In ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

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

> mailto:ap-gto%40yahoogroups.com> , "Ray Gralak" groups1@...>

> > wrote:

> > >

> > > The mount is probably getting "lost" because you powered it on after

> > > not parking it. The default mode is to start tracking if the mount

> > > was not parked. The time between when you power on and initialize is

> > > exactly

> the error in RA.

> > So, if that is so, always park your mount or leave the hand controller

> plugged in so it will

> > initialize the mount.

> > >

> > > -Ray Gralak

> > > Author of Astro-Physics Command Center (APCC) Author of PEMPro:

> > > www.ccdware.com Author of Astro-Physics V2 ASCOM Driver:

> > > www.gralak.com/apdriver Author of PulseGuide:

> > > www.pulseguide.com Author of Sigma:

> > > www.gralak.com/sigma

> >

> >

> >

> >

>

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

>

>

>

>







----------------------------

#34094 Nov 24, 2011

Yes it did. I did a "start from park 3 after manually leveling the axis. It

was only in RA of course.







Steve



www.astral-imaging.com







_____



From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com] On Behalf Of

Ray Gralak

Sent: Thursday, November 24, 2011 11:36 AM

To: ap-gto@yahoogroups.com

Subject: RE: [ap-gto] Re: 1200/ACP gets lost











Steve,



Did the mount lose its position after you finally initialized it with ACP?



-Ray Gralak

Author of Astro-Physics Command Center (APCC)

Author of PEMPro: www.ccdware.com

Author of Astro-Physics V2 ASCOM Driver: www.gralak.com/apdriver

Author of PulseGuide: www.pulseguide.com

Author of Sigma: www.gralak.com/sigma

> -----Original Message-----

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

[mailto:ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com> ] On Behalf

Of Steve Reilly > Sent: Wednesday, November 23, 2011 10:30 PM

> To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

> Subject: RE: [ap-gto] Re: 1200/ACP gets lost

>

>

>

> Hey Ray,

>

> Interestingly enough I had powered my AP1200 this evening and forgot about

it while doing > some other chores. I have to say I hadn't seen this behavior before but

when I looked in on > the mount several hours later it was well past the park 3 position I

always park it at. I use > ACP and the hand controller is not connected. After an imaging run, ACP

parks the mount and > closes the roof, disconnects the mount and camera.

>

> To start the system I power up the equipment, connect MaxIm to the camera,

start the cooling, > start ACP and connect to the mount and camera. Then I start the plan.

Seems I'm following the > conditions you stated so I'm not sure why the mount was tracking. I can

say that ACP was not > connected after powering up this afternoon. I don't usually power up and

not connect ACP so I > don't see this normally.

>

> Steve

>

> www.astral-imaging.com

>

> _____

>

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

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

mailto:ap-gto%40yahoogroups.com> ] On Behalf Of Ray Gralak > Sent: Wednesday, November 23, 2011 9:31 AM

> To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

mailto:ap-gto%40yahoogroups.com> > Subject: RE: [ap-gto] Re: 1200/ACP gets lost

>

> Hi Angus,

>

> > I think this is probably one of the reasons causing my mount to

> > sometimes

> "lost" too. So I

> > would like to have a totally clear understanding of the issues at play.

> >

> > 1) When power is on/restarted, you said that the default mode is to

> > start

> tracking if mount

> > was not parked. Can this be changed and how? Can I set it to not

> > tracking

> so as to avoid this

> > problem? Or can it be set such that it will never start tracking under

> > any

> circumstances

> > until after initialisation?

>

> The behavior cannot be changed. The only things you can do are one of the

> following:

>

> 1) make sure to park the mount before powering off

> 2) make sure you have a PC connected and ready to initialize it when

powering the mount. > 3) leave the keypad plugged in so it will initialize the mount.

>

> > 2) Does the mount (controller) keep the park/unpark state internally?

> > Can

> this state be

> > queried by an external application such as the ASCOM driver,

> > PulseGuide

> etc?

>

> Not in the publicly available firmware. The new (unreleased) firmware can

detect park state. >

> > 3) If the state is kept internally and cannot be queried by an

> application. Then does an

> > external application keep the park/unpark state independently? Then

> > can

> they become out of

> > sync and causing incorrect park/unpark decisions?

>

> Yes, this can happen, which is why you should always use "Unpark from last

parked position". > The only exception should be if you are setting up your mount manually and

you want to unpark > it from one of the park positions.

>

> > 4) In the keypad manual (page 79 :PO# command), it says that if the

> > mount

> was not parked and

> > an unpark command is sent, it will cause the mount to lose its position.

> Is that true and how

> > will this affect the position accuracy? Can this happen if I control

> > the

> mount from ACP via

> > the ASCOM driver? That is, will the mount get lost if ACP tries to

> > park

> the mount multiple

> > times through the ASCOM driver or tries to unpark the mount when it

> > was

> not parked?

>

> If you are using the latest beta version of the ASCOM driver this won't

happen. >

> > 5) I have set keypad autoconnect mode to EXT. In order to avoid

> tracking/timing problem as

> > described, must I make sure that the applicaton is connecting to the

> > mount

> before I try to

> > power up the mount? That is, I must make the application waiting for

> > the

> mount to power up?

>

> Only if you did not park the mount before powering it off. If the mount

was parked then you > can leave it sit for as long as necessary after powering up. Only if you

failed to park would > this be a problem (note: an unexpected power failure could unintentionally

cause this so it's > best to have a UPS backing up power).

>

> > 6) What will happen given an inadvertant power lost scenario such as

this. > Application is

> > connected to mount and operating. Power is lost. Power comes back up.

> Mount powers up. Mount

> > starts tracking since it was not parked. Mount cannot get

> > initialisation

> from application

> > since it will take time for PC to reboot and application to restart

> > (even

> if it is configured

> > to do so). When application restarts and reconnects to mount, mount

> > will

> be "lost" due to the

> > time differences of mount/application restart. Is this the case? Is

> > there

> anyway we can set

> > up things to avoid such problems?

>

> Yes, use a UPS, or leave the keypad plugged in. If you use an UPS make

sure it is also > backing up your PC. Most UPS devices come with monitoring software which

will allow you to > run a script or application. Such a script or application could

potentially park the mount > before power is completely lost.

>

> -Ray

>

> > --- In ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

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

> mailto:ap-gto%40yahoogroups.com> , "Ray Gralak" groups1@...>

> > wrote:

> > >

> > > The mount is probably getting "lost" because you powered it on after

> > > not parking it. The default mode is to start tracking if the mount

> > > was not parked. The time between when you power on and initialize is

> > > exactly

> the error in RA.

> > So, if that is so, always park your mount or leave the hand controller

> plugged in so it will

> > initialize the mount.

> > >

> > > -Ray Gralak

> > > Author of Astro-Physics Command Center (APCC) Author of PEMPro:

> > > www.ccdware.com Author of Astro-Physics V2 ASCOM Driver:

> > > www.gralak.com/apdriver Author of PulseGuide:

> > > www.pulseguide.com Author of Sigma:

> > > www.gralak.com/sigma

> >

> >

> >

> >

>

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

>

>

>

>











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







----------------------------

#34096 Nov 25, 2011

Yes it did. I did a "start from park 3 after manually leveling the axis. It was only in RA of

> course.



Steve, Park 3 has the scope pointing to the pole with the scope centered over the mount (counterweight shaft pointing to

the ground). What axis where you leveling?



-Ray Gralak

Author of Astro-Physics Command Center (APCC)

Author of PEMPro: www.ccdware.com

Author of Astro-Physics V2 ASCOM Driver: www.gralak.com/apdriver

Author of PulseGuide: www.pulseguide.com

Author of Sigma: www.gralak.com/sigma



> -----Original Message-----

> From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com] On Behalf Of Steve Reilly

> Sent: Thursday, November 24, 2011 12:43 PM

> To: ap-gto@yahoogroups.com

> Subject: RE: [ap-gto] Re: 1200/ACP gets lost

>

>

>

> Yes it did. I did a "start from park 3 after manually leveling the axis. It was only in RA of

> course.

>

> Steve

>

> www.astral-imaging.com

>

> _____

>

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

> gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com> ] On Behalf Of Ray Gralak

> Sent: Thursday, November 24, 2011 11:36 AM

> To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

> Subject: RE: [ap-gto] Re: 1200/ACP gets lost

>

> Steve,

>

> Did the mount lose its position after you finally initialized it with ACP?

>

> -Ray Gralak

> Author of Astro-Physics Command Center (APCC) Author of PEMPro: www.ccdware.com Author

> of Astro-Physics V2 ASCOM Driver: www.gralak.com/apdriver Author of PulseGuide:

> www.pulseguide.com Author of Sigma: www.gralak.com/sigma

>

> > -----Original Message-----

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

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

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

> gto%40yahoogroups.com> ] On Behalf Of Steve Reilly

> > Sent: Wednesday, November 23, 2011 10:30 PM

> > To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

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

> > Subject: RE: [ap-gto] Re: 1200/ACP gets lost

> >

> >

> >

> > Hey Ray,

> >

> > Interestingly enough I had powered my AP1200 this evening and forgot

> > about

> it while doing

> > some other chores. I have to say I hadn't seen this behavior before

> > but

> when I looked in on

> > the mount several hours later it was well past the park 3 position I

> always park it at. I use

> > ACP and the hand controller is not connected. After an imaging run,

> > ACP

> parks the mount and

> > closes the roof, disconnects the mount and camera.

> >

> > To start the system I power up the equipment, connect MaxIm to the

> > camera,

> start the cooling,

> > start ACP and connect to the mount and camera. Then I start the plan.

> Seems I'm following the

> > conditions you stated so I'm not sure why the mount was tracking. I

> > can

> say that ACP was not

> > connected after powering up this afternoon. I don't usually power up

> > and

> not connect ACP so I

> > don't see this normally.

> >

> > Steve

> >

> > www.astral-imaging.com

> >

> > _____

> >

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

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

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

> > gto@yahoogroups.com mailto:gto%40yahoogroups.com>

> > mailto:gto%40yahoogroups.com>

> mailto:ap-gto%40yahoogroups.com> ] On Behalf Of Ray Gralak

> > Sent: Wednesday, November 23, 2011 9:31 AM

> > To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

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

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

> > Subject: RE: [ap-gto] Re: 1200/ACP gets lost

> >

> > Hi Angus,

> >

> > > I think this is probably one of the reasons causing my mount to

> > > sometimes

> > "lost" too. So I

> > > would like to have a totally clear understanding of the issues at play.

> > >

> > > 1) When power is on/restarted, you said that the default mode is to

> > > start

> > tracking if mount

> > > was not parked. Can this be changed and how? Can I set it to not

> > > tracking

> > so as to avoid this

> > > problem? Or can it be set such that it will never start tracking

> > > under any

> > circumstances

> > > until after initialisation?

> >

> > The behavior cannot be changed. The only things you can do are one of

> > the

> > following:

> >

> > 1) make sure to park the mount before powering off

> > 2) make sure you have a PC connected and ready to initialize it when

> powering the mount.

> > 3) leave the keypad plugged in so it will initialize the mount.

> >

> > > 2) Does the mount (controller) keep the park/unpark state internally?

> > > Can

> > this state be

> > > queried by an external application such as the ASCOM driver,

> > > PulseGuide

> > etc?

> >

> > Not in the publicly available firmware. The new (unreleased) firmware

> > can

> detect park state.

> >

> > > 3) If the state is kept internally and cannot be queried by an

> > application. Then does an

> > > external application keep the park/unpark state independently? Then

> > > can

> > they become out of

> > > sync and causing incorrect park/unpark decisions?

> >

> > Yes, this can happen, which is why you should always use "Unpark from

> > last

> parked position".

> > The only exception should be if you are setting up your mount manually

> > and

> you want to unpark

> > it from one of the park positions.

> >

> > > 4) In the keypad manual (page 79 :PO# command), it says that if the

> > > mount

> > was not parked and

> > > an unpark command is sent, it will cause the mount to lose its position.

> > Is that true and how

> > > will this affect the position accuracy? Can this happen if I control

> > > the

> > mount from ACP via

> > > the ASCOM driver? That is, will the mount get lost if ACP tries to

> > > park

> > the mount multiple

> > > times through the ASCOM driver or tries to unpark the mount when it

> > > was

> > not parked?

> >

> > If you are using the latest beta version of the ASCOM driver this

> > won't

> happen.

> >

> > > 5) I have set keypad autoconnect mode to EXT. In order to avoid

> > tracking/timing problem as

> > > described, must I make sure that the applicaton is connecting to the

> > > mount

> > before I try to

> > > power up the mount? That is, I must make the application waiting for

> > > the

> > mount to power up?

> >

> > Only if you did not park the mount before powering it off. If the

> > mount

> was parked then you

> > can leave it sit for as long as necessary after powering up. Only if

> > you

> failed to park would

> > this be a problem (note: an unexpected power failure could

> > unintentionally

> cause this so it's

> > best to have a UPS backing up power).

> >

> > > 6) What will happen given an inadvertant power lost scenario such as

> this.

> > Application is

> > > connected to mount and operating. Power is lost. Power comes back up.

> > Mount powers up. Mount

> > > starts tracking since it was not parked. Mount cannot get

> > > initialisation

> > from application

> > > since it will take time for PC to reboot and application to restart

> > > (even

> > if it is configured

> > > to do so). When application restarts and reconnects to mount, mount

> > > will

> > be "lost" due to the

> > > time differences of mount/application restart. Is this the case? Is

> > > there

> > anyway we can set

> > > up things to avoid such problems?

> >

> > Yes, use a UPS, or leave the keypad plugged in. If you use an UPS make

> sure it is also

> > backing up your PC. Most UPS devices come with monitoring software

> > which

> will allow you to

> > run a script or application. Such a script or application could

> potentially park the mount

> > before power is completely lost.

> >

> > -Ray

> >

> > > --- In ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

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

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

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

> > mailto:ap-gto%40yahoogroups.com> , "Ray Gralak" groups1@...>

> > > wrote:

> > > >

> > > > The mount is probably getting "lost" because you powered it on

> > > > after not parking it. The default mode is to start tracking if the

> > > > mount was not parked. The time between when you power on and

> > > > initialize is exactly

> > the error in RA.

> > > So, if that is so, always park your mount or leave the hand

> > > controller

> > plugged in so it will

> > > initialize the mount.

> > > >

> > > > -Ray Gralak

> > > > Author of Astro-Physics Command Center (APCC) Author of PEMPro:

> > > > www.ccdware.com Author of Astro-Physics V2 ASCOM Driver:

> > > > www.gralak.com/apdriver Author of PulseGuide:

> > > > www.pulseguide.com Author of Sigma:

> > > > www.gralak.com/sigma

> > >

> > >

> > >

> > >

> >

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

> >

> >

> >

> >

>

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

>

>

>

>







----------------------------

#34097 Nov 25, 2011

Ray,







That's a typo on my part, it is park 1 I use.







Steve



www.astral-imaging.com







_____



From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com] On Behalf Of

Ray Gralak

Sent: Friday, November 25, 2011 11:22 AM

To: ap-gto@yahoogroups.com

Subject: RE: [ap-gto] Re: 1200/ACP gets lost









> Yes it did. I did a "start from park 3 after manually leveling the axis.

It was only in RA of > course.



Steve, Park 3 has the scope pointing to the pole with the scope centered

over the mount (counterweight shaft pointing to

the ground). What axis where you leveling?



-Ray Gralak

Author of Astro-Physics Command Center (APCC)

Author of PEMPro: www.ccdware.com

Author of Astro-Physics V2 ASCOM Driver: www.gralak.com/apdriver

Author of PulseGuide: www.pulseguide.com

Author of Sigma: www.gralak.com/sigma

> -----Original Message-----

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

[mailto:ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com> ] On Behalf

Of Steve Reilly > Sent: Thursday, November 24, 2011 12:43 PM

> To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

> Subject: RE: [ap-gto] Re: 1200/ACP gets lost

>

>

>

> Yes it did. I did a "start from park 3 after manually leveling the axis.

It was only in RA of > course.

>

> Steve

>

> www.astral-imaging.com

>

> _____

>

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

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

mailto:ap-gto%40yahoogroups.com> ] On Behalf Of Ray Gralak > Sent: Thursday, November 24, 2011 11:36 AM

> To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

mailto:ap-gto%40yahoogroups.com> > Subject: RE: [ap-gto] Re: 1200/ACP gets lost

>

> Steve,

>

> Did the mount lose its position after you finally initialized it with ACP?

>

> -Ray Gralak

> Author of Astro-Physics Command Center (APCC) Author of PEMPro:

www.ccdware.com Author > of Astro-Physics V2 ASCOM Driver: www.gralak.com/apdriver Author of

PulseGuide: > www.pulseguide.com Author of Sigma: www.gralak.com/sigma

>

> > -----Original Message-----

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

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

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

mailto:ap-gto%40yahoogroups.com> mailto:ap- > gto%40yahoogroups.com> ] On Behalf Of Steve Reilly

> > Sent: Wednesday, November 23, 2011 10:30 PM

> > To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

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

> > Subject: RE: [ap-gto] Re: 1200/ACP gets lost

> >

> >

> >

> > Hey Ray,

> >

> > Interestingly enough I had powered my AP1200 this evening and forgot

> > about

> it while doing

> > some other chores. I have to say I hadn't seen this behavior before

> > but

> when I looked in on

> > the mount several hours later it was well past the park 3 position I

> always park it at. I use

> > ACP and the hand controller is not connected. After an imaging run,

> > ACP

> parks the mount and

> > closes the roof, disconnects the mount and camera.

> >

> > To start the system I power up the equipment, connect MaxIm to the

> > camera,

> start the cooling,

> > start ACP and connect to the mount and camera. Then I start the plan.

> Seems I'm following the

> > conditions you stated so I'm not sure why the mount was tracking. I

> > can

> say that ACP was not

> > connected after powering up this afternoon. I don't usually power up

> > and

> not connect ACP so I

> > don't see this normally.

> >

> > Steve

> >

> > www.astral-imaging.com

> >

> > _____

> >

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

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

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

> > gto@yahoogroups.com mailto:gto%40yahoogroups.com>

mailto:gto%40yahoogroups.com> > > mailto:gto%40yahoogroups.com>

> mailto:ap-gto%40yahoogroups.com> ] On Behalf Of Ray Gralak

> > Sent: Wednesday, November 23, 2011 9:31 AM

> > To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

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

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

> > Subject: RE: [ap-gto] Re: 1200/ACP gets lost

> >

> > Hi Angus,

> >

> > > I think this is probably one of the reasons causing my mount to

> > > sometimes

> > "lost" too. So I

> > > would like to have a totally clear understanding of the issues at

play. > > >

> > > 1) When power is on/restarted, you said that the default mode is to

> > > start

> > tracking if mount

> > > was not parked. Can this be changed and how? Can I set it to not

> > > tracking

> > so as to avoid this

> > > problem? Or can it be set such that it will never start tracking

> > > under any

> > circumstances

> > > until after initialisation?

> >

> > The behavior cannot be changed. The only things you can do are one of

> > the

> > following:

> >

> > 1) make sure to park the mount before powering off

> > 2) make sure you have a PC connected and ready to initialize it when

> powering the mount.

> > 3) leave the keypad plugged in so it will initialize the mount.

> >

> > > 2) Does the mount (controller) keep the park/unpark state internally?

> > > Can

> > this state be

> > > queried by an external application such as the ASCOM driver,

> > > PulseGuide

> > etc?

> >

> > Not in the publicly available firmware. The new (unreleased) firmware

> > can

> detect park state.

> >

> > > 3) If the state is kept internally and cannot be queried by an

> > application. Then does an

> > > external application keep the park/unpark state independently? Then

> > > can

> > they become out of

> > > sync and causing incorrect park/unpark decisions?

> >

> > Yes, this can happen, which is why you should always use "Unpark from

> > last

> parked position".

> > The only exception should be if you are setting up your mount manually

> > and

> you want to unpark

> > it from one of the park positions.

> >

> > > 4) In the keypad manual (page 79 :PO# command), it says that if the

> > > mount

> > was not parked and

> > > an unpark command is sent, it will cause the mount to lose its

position. > > Is that true and how

> > > will this affect the position accuracy? Can this happen if I control

> > > the

> > mount from ACP via

> > > the ASCOM driver? That is, will the mount get lost if ACP tries to

> > > park

> > the mount multiple

> > > times through the ASCOM driver or tries to unpark the mount when it

> > > was

> > not parked?

> >

> > If you are using the latest beta version of the ASCOM driver this

> > won't

> happen.

> >

> > > 5) I have set keypad autoconnect mode to EXT. In order to avoid

> > tracking/timing problem as

> > > described, must I make sure that the applicaton is connecting to the

> > > mount

> > before I try to

> > > power up the mount? That is, I must make the application waiting for

> > > the

> > mount to power up?

> >

> > Only if you did not park the mount before powering it off. If the

> > mount

> was parked then you

> > can leave it sit for as long as necessary after powering up. Only if

> > you

> failed to park would

> > this be a problem (note: an unexpected power failure could

> > unintentionally

> cause this so it's

> > best to have a UPS backing up power).

> >

> > > 6) What will happen given an inadvertant power lost scenario such as

> this.

> > Application is

> > > connected to mount and operating. Power is lost. Power comes back up.

> > Mount powers up. Mount

> > > starts tracking since it was not parked. Mount cannot get

> > > initialisation

> > from application

> > > since it will take time for PC to reboot and application to restart

> > > (even

> > if it is configured

> > > to do so). When application restarts and reconnects to mount, mount

> > > will

> > be "lost" due to the

> > > time differences of mount/application restart. Is this the case? Is

> > > there

> > anyway we can set

> > > up things to avoid such problems?

> >

> > Yes, use a UPS, or leave the keypad plugged in. If you use an UPS make

> sure it is also

> > backing up your PC. Most UPS devices come with monitoring software

> > which

> will allow you to

> > run a script or application. Such a script or application could

> potentially park the mount

> > before power is completely lost.

> >

> > -Ray

> >

> > > --- In ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

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

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

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

> > mailto:ap-gto%40yahoogroups.com> , "Ray Gralak" groups1@...>

> > > wrote:

> > > >

> > > > The mount is probably getting "lost" because you powered it on

> > > > after not parking it. The default mode is to start tracking if the

> > > > mount was not parked. The time between when you power on and

> > > > initialize is exactly

> > the error in RA.

> > > So, if that is so, always park your mount or leave the hand

> > > controller

> > plugged in so it will

> > > initialize the mount.

> > > >

> > > > -Ray Gralak

> > > > Author of Astro-Physics Command Center (APCC) Author of PEMPro:

> > > > www.ccdware.com Author of Astro-Physics V2 ASCOM Driver:

> > > > www.gralak.com/apdriver Author of PulseGuide:

> > > > www.pulseguide.com Author of Sigma:

> > > > www.gralak.com/sigma

> > >

> > >

> > >

> > >

> >

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

> >

> >

> >

> >

>

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

>

>

>

>











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







----------------------------

#34098 Nov 25, 2011

OK, so what exactly happened? You unparked from Park 1 (BTW, which version of AP driver?) and what went wrong? It's

unclear from your earlier post, which made it seem like you had just powered on the scope and let it track instead of

unparking from park 1. That is you wrote:

> > > Interestingly enough I had powered my AP1200 this evening and forgot

> > > about it while doing some other chores.



-Ray Gralak

Author of Astro-Physics Command Center (APCC)

Author of PEMPro: www.ccdware.com

Author of Astro-Physics V2 ASCOM Driver: www.gralak.com/apdriver

Author of PulseGuide: www.pulseguide.com

Author of Sigma: www.gralak.com/sigma



> -----Original Message-----

> From: ap-gto@yahoogroups.com [mailto:ap-gto@yahoogroups.com] On Behalf Of Steve Reilly

> Sent: Friday, November 25, 2011 9:42 AM

> To: ap-gto@yahoogroups.com

> Subject: RE: [ap-gto] Re: 1200/ACP gets lost

>

>

>

> Ray,

>

> That's a typo on my part, it is park 1 I use.

>

> Steve

>

> www.astral-imaging.com

>

> _____

>

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

> gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com> ] On Behalf Of Ray Gralak

> Sent: Friday, November 25, 2011 11:22 AM

> To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

> Subject: RE: [ap-gto] Re: 1200/ACP gets lost

>

> > Yes it did. I did a "start from park 3 after manually leveling the axis.

> It was only in RA of

> > course.

>

> Steve, Park 3 has the scope pointing to the pole with the scope centered over the mount

> (counterweight shaft pointing to the ground). What axis where you leveling?

>

> -Ray Gralak

> Author of Astro-Physics Command Center (APCC) Author of PEMPro: www.ccdware.com Author

> of Astro-Physics V2 ASCOM Driver: www.gralak.com/apdriver Author of PulseGuide:

> www.pulseguide.com Author of Sigma: www.gralak.com/sigma

>

> > -----Original Message-----

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

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

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

> gto%40yahoogroups.com> ] On Behalf Of Steve Reilly

> > Sent: Thursday, November 24, 2011 12:43 PM

> > To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

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

> > Subject: RE: [ap-gto] Re: 1200/ACP gets lost

> >

> >

> >

> > Yes it did. I did a "start from park 3 after manually leveling the axis.

> It was only in RA of

> > course.

> >

> > Steve

> >

> > www.astral-imaging.com

> >

> > _____

> >

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

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

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

> > gto@yahoogroups.com mailto:gto%40yahoogroups.com>

> > mailto:gto%40yahoogroups.com>

> mailto:ap-gto%40yahoogroups.com> ] On Behalf Of Ray Gralak

> > Sent: Thursday, November 24, 2011 11:36 AM

> > To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

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

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

> > Subject: RE: [ap-gto] Re: 1200/ACP gets lost

> >

> > Steve,

> >

> > Did the mount lose its position after you finally initialized it with ACP?

> >

> > -Ray Gralak

> > Author of Astro-Physics Command Center (APCC) Author of PEMPro:

> www.ccdware.com Author

> > of Astro-Physics V2 ASCOM Driver: www.gralak.com/apdriver

> > Author of

> PulseGuide:

> > www.pulseguide.com Author of Sigma: www.gralak.com/sigma

> >

> > > -----Original Message-----

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

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

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

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

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

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

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

> > gto%40yahoogroups.com> ] On Behalf Of Steve Reilly

> > > Sent: Wednesday, November 23, 2011 10:30 PM

> > > To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

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

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

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

> > > Subject: RE: [ap-gto] Re: 1200/ACP gets lost

> > >

> > >

> > >

> > > Hey Ray,

> > >

> > > Interestingly enough I had powered my AP1200 this evening and forgot

> > > about

> > it while doing

> > > some other chores. I have to say I hadn't seen this behavior before

> > > but

> > when I looked in on

> > > the mount several hours later it was well past the park 3 position I

> > always park it at. I use

> > > ACP and the hand controller is not connected. After an imaging run,

> > > ACP

> > parks the mount and

> > > closes the roof, disconnects the mount and camera.

> > >

> > > To start the system I power up the equipment, connect MaxIm to the

> > > camera,

> > start the cooling,

> > > start ACP and connect to the mount and camera. Then I start the plan.

> > Seems I'm following the

> > > conditions you stated so I'm not sure why the mount was tracking. I

> > > can

> > say that ACP was not

> > > connected after powering up this afternoon. I don't usually power up

> > > and

> > not connect ACP so I

> > > don't see this normally.

> > >

> > > Steve

> > >

> > > www.astral-imaging.com

> > >

> > > _____

> > >

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

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

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

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

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

> > > gto@yahoogroups.com mailto:gto%40yahoogroups.com>

> > > mailto:gto%40yahoogroups.com>

> mailto:gto%40yahoogroups.com>

> > > mailto:gto%40yahoogroups.com>

> > mailto:ap-gto%40yahoogroups.com> ] On Behalf Of Ray Gralak

> > > Sent: Wednesday, November 23, 2011 9:31 AM

> > > To: ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

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

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

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

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

> > > Subject: RE: [ap-gto] Re: 1200/ACP gets lost

> > >

> > > Hi Angus,

> > >

> > > > I think this is probably one of the reasons causing my mount to

> > > > sometimes

> > > "lost" too. So I

> > > > would like to have a totally clear understanding of the issues at

> play.

> > > >

> > > > 1) When power is on/restarted, you said that the default mode is

> > > > to start

> > > tracking if mount

> > > > was not parked. Can this be changed and how? Can I set it to not

> > > > tracking

> > > so as to avoid this

> > > > problem? Or can it be set such that it will never start tracking

> > > > under any

> > > circumstances

> > > > until after initialisation?

> > >

> > > The behavior cannot be changed. The only things you can do are one

> > > of the

> > > following:

> > >

> > > 1) make sure to park the mount before powering off

> > > 2) make sure you have a PC connected and ready to initialize it when

> > powering the mount.

> > > 3) leave the keypad plugged in so it will initialize the mount.

> > >

> > > > 2) Does the mount (controller) keep the park/unpark state internally?

> > > > Can

> > > this state be

> > > > queried by an external application such as the ASCOM driver,

> > > > PulseGuide

> > > etc?

> > >

> > > Not in the publicly available firmware. The new (unreleased)

> > > firmware can

> > detect park state.

> > >

> > > > 3) If the state is kept internally and cannot be queried by an

> > > application. Then does an

> > > > external application keep the park/unpark state independently?

> > > > Then can

> > > they become out of

> > > > sync and causing incorrect park/unpark decisions?

> > >

> > > Yes, this can happen, which is why you should always use "Unpark

> > > from last

> > parked position".

> > > The only exception should be if you are setting up your mount

> > > manually and

> > you want to unpark

> > > it from one of the park positions.

> > >

> > > > 4) In the keypad manual (page 79 :PO# command), it says that if

> > > > the mount

> > > was not parked and

> > > > an unpark command is sent, it will cause the mount to lose its

> position.

> > > Is that true and how

> > > > will this affect the position accuracy? Can this happen if I

> > > > control the

> > > mount from ACP via

> > > > the ASCOM driver? That is, will the mount get lost if ACP tries to

> > > > park

> > > the mount multiple

> > > > times through the ASCOM driver or tries to unpark the mount when

> > > > it was

> > > not parked?

> > >

> > > If you are using the latest beta version of the ASCOM driver this

> > > won't

> > happen.

> > >

> > > > 5) I have set keypad autoconnect mode to EXT. In order to avoid

> > > tracking/timing problem as

> > > > described, must I make sure that the applicaton is connecting to

> > > > the mount

> > > before I try to

> > > > power up the mount? That is, I must make the application waiting

> > > > for the

> > > mount to power up?

> > >

> > > Only if you did not park the mount before powering it off. If the

> > > mount

> > was parked then you

> > > can leave it sit for as long as necessary after powering up. Only if

> > > you

> > failed to park would

> > > this be a problem (note: an unexpected power failure could

> > > unintentionally

> > cause this so it's

> > > best to have a UPS backing up power).

> > >

> > > > 6) What will happen given an inadvertant power lost scenario such

> > > > as

> > this.

> > > Application is

> > > > connected to mount and operating. Power is lost. Power comes back up.

> > > Mount powers up. Mount

> > > > starts tracking since it was not parked. Mount cannot get

> > > > initialisation

> > > from application

> > > > since it will take time for PC to reboot and application to

> > > > restart (even

> > > if it is configured

> > > > to do so). When application restarts and reconnects to mount,

> > > > mount will

> > > be "lost" due to the

> > > > time differences of mount/application restart. Is this the case?

> > > > Is there

> > > anyway we can set

> > > > up things to avoid such problems?

> > >

> > > Yes, use a UPS, or leave the keypad plugged in. If you use an UPS

> > > make

> > sure it is also

> > > backing up your PC. Most UPS devices come with monitoring software

> > > which

> > will allow you to

> > > run a script or application. Such a script or application could

> > potentially park the mount

> > > before power is completely lost.

> > >

> > > -Ray

> > >

> > > > --- In ap-gto@yahoogroups.com mailto:ap-gto%40yahoogroups.com>

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

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

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

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

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

> > > mailto:ap-gto%40yahoogroups.com> , "Ray Gralak" groups1@...>

> > > > wrote:

> > > > >

> > > > > The mount is probably getting "lost" because you powered it on

> > > > > after not parking it. The default mode is to start tracking if

> > > > > the mount was not parked. The time between when you power on and

> > > > > initialize is exactly

> > > the error in RA.

> > > > So, if that is so, always park your mount or leave the hand

> > > > controller

> > > plugged in so it will

> > > > initialize the mount.

> > > > >

> > > > > -Ray Gralak

> > > > > Author of Astro-Physics Command Center (APCC) Author of PEMPro:

> > > > > www.ccdware.com Author of Astro-Physics V2 ASCOM Driver:

> > > > > www.gralak.com/apdriver Author of PulseGuide:

> > > > > www.pulseguide.com Author of Sigma:

> > > > > www.gralak.com/sigma

> > > >

> > > >

> > > >

> > > >

> > >

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

> > >

> > >

> > >

> > >

> >

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

> >

> >

> >

> >

>

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

>

>

>

>






S
e
n
i
o
r
T
u
b
e
.
o
r
g