Roland,
Thanks for the help. That worked great.

Rick

By ESP...sorry, I am getting senile, I meant off list, at my email address.

Roland,
My mistake, it is the right ascension motor that has the loose connector. I removed four screws near it, but it seems more complicated. It doesn't slide out, it is hung up on something. Which other screws do I need to remove?

Rick

On Sep 15, 2010, at 12:58 12PM, chris1011@... wrote:

In a message dated 9/15/2010 2:42:07 PM Central Daylight Time,
yahoogroups@... writes:

My AP-1200 has a black box containing the declination motor. The
connector that I connect the declination cable to has come loose and can rotate.
To fix it, is it just a matter of removing the four screws that hold on the
plate that the connector is mounted to and tightening up the collar inside?
Or would I mess up something if I removed that plate?

Rick

Remove 4 screws and pull the cover off. You will see nothing that will
scare you. The system is very simple and you will be able to fix it. Trust me.

Rolando

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

My AP-1200 has a black box containing the declination motor. The connector that I connect the declination cable to has come loose and can rotate. To fix it, is it just a matter of removing the four screws that hold on the plate that the connector is mounted to and tightening up the collar inside? Or would I mess up something if I removed that plate?

Rick

In a message dated 9/15/2010 3:31:39 PM Central Daylight Time,
yahoogroups@... writes:

Roland,
My mistake, it is the right ascension motor that has the loose connector.
I removed four screws near it, but it seems more complicated. It doesn't
slide out, it is hung up on something. Which other screws do I need to
remove?

Rick

The 1200 RA connector cover cannot be easily removed with the motor box
attached to the mount. You will need to remove the motor gearbox box from its
mounting bracket so you can access the cover. Make sure that you do not have
any weight or torque on the axis as you remove this gearbox because once the
worm is unmeshed from the worm wheel, the axis can swing free. Best to
remove your scope and let the counterweights hang straight down.

If you don't have a permanent setup, and you can take the Dec axis off the
RA, then you will have no problem to remove the motor box. Putting it back
on and meshing the worm is not a big deal and it will be a valuable learning
experience.

Rolando

How are you controlling the mount by computer? Direct command entry
i.e. via HyperTerminal? ASCOM client software? If so, what driver?
Other software with native driver?



The mount will not revert to sidereal tracking without being told
specifically to do so. The move command :MS# does not affect
the tracking rate.



Mag. 7 skies!



Howard Hedlund

Astro-Physics, Inc.

815-282-1513

________________________________

From: ap-gto@... [mailto:ap-gto@...] On Behalf
Of rimfire44
Sent: Wednesday, September 15, 2010 12:33 PM
To: ap-gto@...
Subject: [ap-gto] Mount starts tracking without command





I am working with a 1200 GTO, controlling it with a computer. If I start
the mount tracking and then stop it, everything is fine. The tracking
stops as it should.
But if I write a new RA and DEC and send the move command the mount
starts tracking automatically. Is that the way it should be? Seems wrong
to me. Suppose I was just putting the system into a parked position. I
don't want it start tracking until I tell it to.

So what am I doing wrong or misunderstanding?

Thanks

I am working with a 1200 GTO, controlling it with a computer. If I start the mount tracking and then stop it, everything is fine. The tracking stops as it should.
But if I write a new RA and DEC and send the move command the mount starts tracking automatically. Is that the way it should be? Seems wrong to me. Suppose I was just putting the system into a parked position. I don't want it start tracking until I tell it to.

So what am I doing wrong or misunderstanding?

Thanks

Hi Derek,

Thanks, how do I contact you offline?

Richard

Hi Richard:

The files system seems to be up. If you could contact me offline and let me know which file you are referring to I could test it.

Derek

In a message dated 9/15/2010 2:42:07 PM Central Daylight Time,
yahoogroups@... writes:

My AP-1200 has a black box containing the declination motor. The
connector that I connect the declination cable to has come loose and can rotate.
To fix it, is it just a matter of removing the four screws that hold on the
plate that the connector is mounted to and tightening up the collar inside?
Or would I mess up something if I removed that plate?

Rick

Remove 4 screws and pull the cover off. You will see nothing that will
scare you. The system is very simple and you will be able to fix it. Trust me.

Rolando

When I go to the files section of ap-go and try to open a file I get the following; "The requested document is not accessible" Is this a problem on my end?

Thanks for any help

In a message dated 9/14/2010 1:13:27 PM Central Daylight Time,
mogulskier_groups@... writes:

Just following directions. Documentation says synch first, then RECAL.

Dave

Yes, the very very first time you ever use the mount, you can do that.
After that time and forever more, you do not ever need to do it again because
once you define the scope/mount relationship, this should never need to be
done again (unless you divorce them and start with a new partnership).

Of course, if you tear them apart every night and set everything up fresh
the next time, you can use sync if you wish. I never do because I always set
up the same orientation that I tear down - i.e. I park in one of the 3 park
positions and then put the scope up the same way next time and simply Resume
from Park. The mount even knows which park to resume from without me having
to spoon feed the info.

We tried to make it as simple as possible so you just turn on the power and
go directly to your observing session, but of course you are quite welcome
to make it complicated if you really want to. Just sayin' that you don't
need to.

Rolando

I always park my scope in AP position 2 (scope pointing at eastern horizon). For some reason though, with the new

driver set to use

RCAL, it got turned upside down (similar to Jeff's)

Look over the settings and make sure you are unparking from "last parked position" if you did a park to a specific
position. But if you have moved the scope around by loosening the clutches since the last park or are setting up from
scratch it's safest to set the driver to unpark from a park position (Park 2 in your case).

-Ray Gralak
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma

-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...] On Behalf Of mogulskier_groups
Sent: Tuesday, September 14, 2010 11:12 AM
To: ap-gto@...
Subject: [ap-gto] Re: "altitude" direction setting?



Re/ multiple hubs.

1) I use the same laptop with different mounts and multiple configurations. I'd rather have all the different software

components (I have

many) configured to connect to whatever I have set up without having to remember to go to each of them and reconfigure

2) ACP is a hub, but it is also a pointing corrector. Think of ACP at this point in the process as MaxPoint or TPoint.

With the configuration I have, all I have to do is to configure ACP to point to, for example, a Gemini mount, and all

the other software

falls into place. Sometimes, I bypass ACP altogether - don't always use ACP.

Doing it this way, they all connect to Generic Hub.

So the question still remains... what causes the mount to think it's inverted? What causes PinPoint to produce a

Position Angle 180

degrees from where it 'truly' is? What's the workflow to avoid this?

I always park my scope in AP position 2 (scope pointing at eastern horizon). For some reason though, with the new

driver set to use

RCAL, it got turned upside down (similar to Jeff's)

Dave

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

Hi Dave,

I think I recently had the same problem. I had the "Use RCal instead of Synch" option turned on. Someone please

correct me if I'm

wrong... If I disconnect the APv2 driver and then power down the mount... then the next day, start it all up

again...

and if the APv2

driver is set to use "RCAL instead of Synch", is it true that the first synch for that night will be a RCAL

instead of

a Synch? This is how it

seems to be behaving.

If "SYNC to RCAL" is checked then *ALL* syncs from ASCOM clients will be RCALs.

My workaround is this:
1) Power up the mount
2) Connect to the driver (I use MaximDL > Generic Hub > ACP Hub > APv2)

Why would you connect through two hubs when you connect directly to the driver, which is a hub?

3) Change the APv2 driver to use Synch (uncheck the RCAL option)
4) Synch my first star for the night. It must be in the Eastern hemisphere, otherwise my mount gets upside down

(plate

solves show

orientation of 180 instead of 0 degrees). This establishes the proper "side of pier" upon the first synch. If

memory

serves me correctly,

this is one of the objectives of a synch.
5) Now, go to the APv2 driver and change the setting back to "Use RCAL"

None of the above is required. All you need to do is resume from last park position or from one of the 3 park

positions.

Slew to your first object, then if you want, re-center and Sync (which is really a RCAL).

I hope I'm not correct in this. It seems very hokey.

Sorry, you're not correct. :-)

Also, I tried using the virtual hand controller software to do custom tracking on a comet. I do not understand

this.

In addition, the values

in the custom tracking boxes for RA and DEC custom tracking rates should have more information and they should be

spin

buttons.

However, the granularity of the spin count would need to be adjustable. I think this feature is very valueable,

but it

should be on its own

configuration page. Using this feature, I was able to track comet Hartley (103P) for 2 hours last night, taking

5-minute unguided images

with round nucleus.

There are no plans to enhance the input of tracking rate values. If you want you could make a simple little ASCOM

client

application to change tracking rates in the way you have described.

-Ray Gralak
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma

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

gto%40yahoogroups.com> ] On Behalf Of mogulskier_groups

Sent: Monday, September 13, 2010 6:51 PM
To: ap-gto@... <mailto:ap-gto%40yahoogroups.com>
Subject: [ap-gto] Re: "altitude" direction setting?



Hi Jeff,

I think I recently had the same problem. I had the "Use RCal instead of Synch" option turned on. Someone please

correct me if I'm

wrong... If I disconnect the APv2 driver and then power down the mount... then the next day, start it all up

again...

and if the APv2

driver is set to use "RCAL instead of Synch", is it true that the first synch for that night will be a RCAL

instead of

a Synch? This is how it

seems to be behaving.

My workaround is this:
1) Power up the mount
2) Connect to the driver (I use MaximDL > Generic Hub > ACP Hub > APv2)
3) Change the APv2 driver to use Synch (uncheck the RCAL option)
4) Synch my first star for the night. It must be in the Eastern hemisphere, otherwise my mount gets upside down

(plate

solves show

orientation of 180 instead of 0 degrees). This establishes the proper "side of pier" upon the first synch. If

memory

serves me correctly,

this is one of the objectives of a synch.
5) Now, go to the APv2 driver and change the setting back to "Use RCAL"

I hope I'm not correct in this. It seems very hokey. If I am correct in this, then the driver should be changed

with

and additional

checkbox to "Next/first 'synch' is a synch - then use RCAL". Thus the new checkbox would override the RCAL option

for

the next

synch.

Also, I tried using the virtual hand controller software to do custom tracking on a comet. I do not understand

this.

In addition, the values

in the custom tracking boxes for RA and DEC custom tracking rates should have more information and they should be

spin

buttons.

However, the granularity of the spin count would need to be adjustable. I think this feature is very valueable,

but it

should be on its own

configuration page. Using this feature, I was able to track comet Hartley (103P) for 2 hours last night, taking

5-minute unguided images

with round nucleus.

I await response from the experts.

Thanks

Dave Samuels

--- In ap-gto@... <mailto:ap-gto%40yahoogroups.com> <mailto:ap-gto%40yahoogroups.com> , Jeff Crilly

<jlc@>

wrote:

Ok .. I redid the startup and did a sync on vega and I think that fixed the inverted altitude problem.
(I'm also trying to get pempro to load pem. When I loaded the curve last night it seemed to get worse... I tried

inverting it but that

didn't seem to help. Not sure what was going on but il give it another try tonite.)

jeff

On Sep 11, 2010, at 9:30 PM, Jeff Crilly <jlc@> wrote:

Ok, I normally use just the hand controller with ap1200, but am venturing into automating some of my imaging

workflow.

Hence i'm debugging the mount - computer setup...

Here's the problem.. When I connect up TheSky5 using the ascom AP V2 driver (and teleAPI), thesky shows the

telescope pointing

"in the other direction".

Eg if the ota is pointing south and above the horizon, thesky shows it pointing north and below the horizon.

Also, the V2 readout shows negative altitude. And I just noticed the handpad also has a negative altitude

reading.

Turns out zero

degrees alt is with the ota pointing straight up... Is this correct?

Gotos from the handpad are fine.. this has been working fine for years.

I suppose maybe I mounted the saddle "backwards" years ago, but I don't really see how it matters.. Once

calibrated

I would expect

the alt/az calculation to be based off the ra/dec and location.

Also I normally start up with a resume from ref park 1.

Is there a way to reverse the altitude?
Or maybe I've got something set wrong? ie is there a common root cause that results in this behavior?

Thx

jeff

NB does a good job filtering out light pollution. I'm able to shoot 30 min subs here in pleasanton under a full moon with NB. When you get to NB, give it a try. Without it, I'm limited to about 3 minutes with a clear filter. (STL 11k). The ST10 is much more sensitive than the STL 11k though.

Just following directions. Documentation says synch first, then RECAL.

Dave

Re/ multiple hubs.

1) I use the same laptop with different mounts and multiple configurations. I'd rather have all the different software components (I have many) configured to connect to whatever I have set up without having to remember to go to each of them and reconfigure

2) ACP is a hub, but it is also a pointing corrector. Think of ACP at this point in the process as MaxPoint or TPoint.

With the configuration I have, all I have to do is to configure ACP to point to, for example, a Gemini mount, and all the other software falls into place. Sometimes, I bypass ACP altogether - don't always use ACP.

Doing it this way, they all connect to Generic Hub.

So the question still remains... what causes the mount to think it's inverted? What causes PinPoint to produce a Position Angle 180 degrees from where it 'truly' is? What's the workflow to avoid this?

I always park my scope in AP position 2 (scope pointing at eastern horizon). For some reason though, with the new driver set to use RCAL, it got turned upside down (similar to Jeff's)

Dave

Hi Jeff,

You wrote:

At the end of the night, I typically park, then tear down. When I setup again I start the mount in the park position and resume. This has
worked fine with the hand paddle. Am even able to do gotos in the daytime and find saturn. Btw I use rcal all the time.. Usually on a star
or dso. It is possible that I had not done a startup sync in a long time-- maybe the last time was with a different saddle in a different (180
degree?) position than the current saddle. (dunno for sure but I could see where the orientation was mixed up 180 degrees but gotos
would work ok)

Yes, you could have put the mount into a position that it completely out of "sync" with actual position if you had loosened the clutches and moved the scope around and then later didn't explicitly unpark from one of the park positions. If I'm setting up from scratch I always move the scope into approximately the Park 3 position and unpark from "Park 3". Then later I will RCAL on a star to refine the pointing accuracy.

BTW, when the driver unparks from one of the Park or Alt/Az positions the SYNC command is always used regardless of the convert RCAL to SYNC option.

Btw, I did manage to get thesky, pempro, and maxim all talking with the mount at the same time via the ap v2 driver. It worked very
nicely. I prefer less software (especially on windows) but having center-object in maxim will probly save some time. The ap v2 driver is
very nice imo. (I've still got a few computer glitches to work out but that will need to wait until we get out of the current sf fog cycle)

Thanks for the kind feedback, Jeff.

-Ray Gralak
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma

-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...] On Behalf Of Jeff Crilly
Sent: Tuesday, September 14, 2010 2:47 AM
To: ap-gto@...
Subject: Re: [ap-gto] Re: "altitude" direction setting?



At the end of the night, I typically park, then tear down. When I setup again I start the mount in the park position and resume. This has
worked fine with the hand paddle. Am even able to do gotos in the daytime and find saturn. Btw I use rcal all the time.. Usually on a star
or dso. It is possible that I had not done a startup sync in a long time-- maybe the last time was with a different saddle in a different (180
degree?) position than the current saddle. (dunno for sure but I could see where the orientation was mixed up 180 degrees but gotos
would work ok)

Operator headspace.

Btw, I did manage to get thesky, pempro, and maxim all talking with the mount at the same time via the ap v2 driver. It worked very
nicely. I prefer less software (especially on windows) but having center-object in maxim will probly save some time. The ap v2 driver is
very nice imo. (I've still got a few computer glitches to work out but that will need to wait until we get out of the current sf fog cycle)


jeff

On Sep 13, 2010, at 7:17 PM, "Ray Gralak" <groups@... <mailto:groups%40gralak.com> > wrote:

Hi Dave,

I think I recently had the same problem. I had the "Use RCal instead of Synch" option turned on. Someone please

correct me if I'm

wrong... If I disconnect the APv2 driver and then power down the mount... then the next day, start it all up again...

and if the APv2

driver is set to use "RCAL instead of Synch", is it true that the first synch for that night will be a RCAL instead of

a Synch? This is how it

seems to be behaving.

If "SYNC to RCAL" is checked then *ALL* syncs from ASCOM clients will be RCALs.

My workaround is this:
1) Power up the mount
2) Connect to the driver (I use MaximDL > Generic Hub > ACP Hub > APv2)

Why would you connect through two hubs when you connect directly to the driver, which is a hub?

3) Change the APv2 driver to use Synch (uncheck the RCAL option)
4) Synch my first star for the night. It must be in the Eastern hemisphere, otherwise my mount gets upside down (plate

solves show

orientation of 180 instead of 0 degrees). This establishes the proper "side of pier" upon the first synch. If memory

serves me correctly,

this is one of the objectives of a synch.
5) Now, go to the APv2 driver and change the setting back to "Use RCAL"

None of the above is required. All you need to do is resume from last park position or from one of the 3 park positions.
Slew to your first object, then if you want, re-center and Sync (which is really a RCAL).

I hope I'm not correct in this. It seems very hokey.

Sorry, you're not correct. :-)

Also, I tried using the virtual hand controller software to do custom tracking on a comet. I do not understand this.

In addition, the values

in the custom tracking boxes for RA and DEC custom tracking rates should have more information and they should be spin

buttons.

However, the granularity of the spin count would need to be adjustable. I think this feature is very valueable, but it

should be on its own

configuration page. Using this feature, I was able to track comet Hartley (103P) for 2 hours last night, taking

5-minute unguided images

with round nucleus.

There are no plans to enhance the input of tracking rate values. If you want you could make a simple little ASCOM client
application to change tracking rates in the way you have described.

-Ray Gralak
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma

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

gto%40yahoogroups.com> ] On Behalf Of mogulskier_groups

Sent: Monday, September 13, 2010 6:51 PM
To: ap-gto@... <mailto:ap-gto%40yahoogroups.com>
Subject: [ap-gto] Re: "altitude" direction setting?



Hi Jeff,

I think I recently had the same problem. I had the "Use RCal instead of Synch" option turned on. Someone please

correct me if I'm

wrong... If I disconnect the APv2 driver and then power down the mount... then the next day, start it all up again...

and if the APv2

driver is set to use "RCAL instead of Synch", is it true that the first synch for that night will be a RCAL instead of

a Synch? This is how it

seems to be behaving.

My workaround is this:
1) Power up the mount
2) Connect to the driver (I use MaximDL > Generic Hub > ACP Hub > APv2)
3) Change the APv2 driver to use Synch (uncheck the RCAL option)
4) Synch my first star for the night. It must be in the Eastern hemisphere, otherwise my mount gets upside down (plate

solves show

orientation of 180 instead of 0 degrees). This establishes the proper "side of pier" upon the first synch. If memory

serves me correctly,

this is one of the objectives of a synch.
5) Now, go to the APv2 driver and change the setting back to "Use RCAL"

I hope I'm not correct in this. It seems very hokey. If I am correct in this, then the driver should be changed with

and additional

checkbox to "Next/first 'synch' is a synch - then use RCAL". Thus the new checkbox would override the RCAL option for

the next

synch.

Also, I tried using the virtual hand controller software to do custom tracking on a comet. I do not understand this.

In addition, the values

in the custom tracking boxes for RA and DEC custom tracking rates should have more information and they should be spin

buttons.

However, the granularity of the spin count would need to be adjustable. I think this feature is very valueable, but it

should be on its own

configuration page. Using this feature, I was able to track comet Hartley (103P) for 2 hours last night, taking

5-minute unguided images

with round nucleus.

I await response from the experts.

Thanks

Dave Samuels

--- In ap-gto@... <mailto:ap-gto%40yahoogroups.com> <mailto:ap-gto%40yahoogroups.com> , Jeff Crilly <jlc@...>

wrote:

Ok .. I redid the startup and did a sync on vega and I think that fixed the inverted altitude problem.
(I'm also trying to get pempro to load pem. When I loaded the curve last night it seemed to get worse... I tried

inverting it but that

didn't seem to help. Not sure what was going on but il give it another try tonite.)

jeff

On Sep 11, 2010, at 9:30 PM, Jeff Crilly <jlc@...> wrote:

Ok, I normally use just the hand controller with ap1200, but am venturing into automating some of my imaging

workflow.

Hence i'm debugging the mount - computer setup...

Here's the problem.. When I connect up TheSky5 using the ascom AP V2 driver (and teleAPI), thesky shows the

telescope pointing

"in the other direction".

Eg if the ota is pointing south and above the horizon, thesky shows it pointing north and below the horizon.

Also, the V2 readout shows negative altitude. And I just noticed the handpad also has a negative altitude reading.

Turns out zero

degrees alt is with the ota pointing straight up... Is this correct?

Gotos from the handpad are fine.. this has been working fine for years.

I suppose maybe I mounted the saddle "backwards" years ago, but I don't really see how it matters.. Once calibrated

I would expect

the alt/az calculation to be based off the ra/dec and location.

Also I normally start up with a resume from ref park 1.

Is there a way to reverse the altitude?
Or maybe I've got something set wrong? ie is there a common root cause that results in this behavior?

Thx

jeff



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

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

At the end of the night, I typically park, then tear down. When I setup again I start the mount in the park position and resume. This has worked fine with the hand paddle. Am even able to do gotos in the daytime and find saturn. Btw I use rcal all the time.. Usually on a star or dso. It is possible that I had not done a startup sync in a long time-- maybe the last time was with a different saddle in a different (180 degree?) position than the current saddle. (dunno for sure but I could see where the orientation was mixed up 180 degrees but gotos would work ok)

Operator headspace.

Btw, I did manage to get thesky, pempro, and maxim all talking with the mount at the same time via the ap v2 driver. It worked very nicely. I prefer less software (especially on windows) but having center-object in maxim will probly save some time. The ap v2 driver is very nice imo. (I've still got a few computer glitches to work out but that will need to wait until we get out of the current sf fog cycle)


jeff

Hi Dave,

I think I recently had the same problem. I had the "Use RCal instead of Synch" option turned on. Someone please

correct me if I'm

wrong... If I disconnect the APv2 driver and then power down the mount... then the next day, start it all up again...

and if the APv2

driver is set to use "RCAL instead of Synch", is it true that the first synch for that night will be a RCAL instead of

a Synch? This is how it

seems to be behaving.

If "SYNC to RCAL" is checked then *ALL* syncs from ASCOM clients will be RCALs.

My workaround is this:
1) Power up the mount
2) Connect to the driver (I use MaximDL > Generic Hub > ACP Hub > APv2)

Why would you connect through two hubs when you connect directly to the driver, which is a hub?

3) Change the APv2 driver to use Synch (uncheck the RCAL option)
4) Synch my first star for the night. It must be in the Eastern hemisphere, otherwise my mount gets upside down (plate

solves show

orientation of 180 instead of 0 degrees). This establishes the proper "side of pier" upon the first synch. If memory

serves me correctly,

this is one of the objectives of a synch.
5) Now, go to the APv2 driver and change the setting back to "Use RCAL"

None of the above is required. All you need to do is resume from last park position or from one of the 3 park positions.
Slew to your first object, then if you want, re-center and Sync (which is really a RCAL).

I hope I'm not correct in this. It seems very hokey.

Sorry, you're not correct. :-)

Also, I tried using the virtual hand controller software to do custom tracking on a comet. I do not understand this.

In addition, the values

in the custom tracking boxes for RA and DEC custom tracking rates should have more information and they should be spin

buttons.

However, the granularity of the spin count would need to be adjustable. I think this feature is very valueable, but it

should be on its own

configuration page. Using this feature, I was able to track comet Hartley (103P) for 2 hours last night, taking

5-minute unguided images

with round nucleus.

There are no plans to enhance the input of tracking rate values. If you want you could make a simple little ASCOM client
application to change tracking rates in the way you have described.

-Ray Gralak
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma

-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...] On Behalf Of mogulskier_groups
Sent: Monday, September 13, 2010 6:51 PM
To: ap-gto@...
Subject: [ap-gto] Re: "altitude" direction setting?



Hi Jeff,

I think I recently had the same problem. I had the "Use RCal instead of Synch" option turned on. Someone please

correct me if I'm

wrong... If I disconnect the APv2 driver and then power down the mount... then the next day, start it all up again...

and if the APv2

driver is set to use "RCAL instead of Synch", is it true that the first synch for that night will be a RCAL instead of

a Synch? This is how it

seems to be behaving.

My workaround is this:
1) Power up the mount
2) Connect to the driver (I use MaximDL > Generic Hub > ACP Hub > APv2)
3) Change the APv2 driver to use Synch (uncheck the RCAL option)
4) Synch my first star for the night. It must be in the Eastern hemisphere, otherwise my mount gets upside down (plate

solves show

orientation of 180 instead of 0 degrees). This establishes the proper "side of pier" upon the first synch. If memory

serves me correctly,

this is one of the objectives of a synch.
5) Now, go to the APv2 driver and change the setting back to "Use RCAL"

I hope I'm not correct in this. It seems very hokey. If I am correct in this, then the driver should be changed with

and additional

checkbox to "Next/first 'synch' is a synch - then use RCAL". Thus the new checkbox would override the RCAL option for

the next

synch.

Also, I tried using the virtual hand controller software to do custom tracking on a comet. I do not understand this.

In addition, the values

in the custom tracking boxes for RA and DEC custom tracking rates should have more information and they should be spin

buttons.

However, the granularity of the spin count would need to be adjustable. I think this feature is very valueable, but it

should be on its own

configuration page. Using this feature, I was able to track comet Hartley (103P) for 2 hours last night, taking

5-minute unguided images

with round nucleus.

I await response from the experts.

Thanks

Dave Samuels

--- In ap-gto@... <mailto:ap-gto%40yahoogroups.com> , Jeff Crilly <jlc@...> wrote:

Ok .. I redid the startup and did a sync on vega and I think that fixed the inverted altitude problem.
(I'm also trying to get pempro to load pem. When I loaded the curve last night it seemed to get worse... I tried

inverting it but that

didn't seem to help. Not sure what was going on but il give it another try tonite.)

jeff

On Sep 11, 2010, at 9:30 PM, Jeff Crilly <jlc@...> wrote:

Ok, I normally use just the hand controller with ap1200, but am venturing into automating some of my imaging

workflow.

Hence i'm debugging the mount - computer setup...

Here's the problem.. When I connect up TheSky5 using the ascom AP V2 driver (and teleAPI), thesky shows the

telescope pointing

"in the other direction".

Eg if the ota is pointing south and above the horizon, thesky shows it pointing north and below the horizon.

Also, the V2 readout shows negative altitude. And I just noticed the handpad also has a negative altitude reading.

Turns out zero

degrees alt is with the ota pointing straight up... Is this correct?

Gotos from the handpad are fine.. this has been working fine for years.

I suppose maybe I mounted the saddle "backwards" years ago, but I don't really see how it matters.. Once calibrated

I would expect

the alt/az calculation to be based off the ra/dec and location.

Also I normally start up with a resume from ref park 1.

Is there a way to reverse the altitude?
Or maybe I've got something set wrong? ie is there a common root cause that results in this behavior?

Thx

jeff

Hi Jeff,

I think I recently had the same problem. I had the "Use RCal instead of Synch" option turned on. Someone please correct me if I'm wrong... If I disconnect the APv2 driver and then power down the mount... then the next day, start it all up again... and if the APv2 driver is set to use "RCAL instead of Synch", is it true that the first synch for that night will be a RCAL instead of a Synch? This is how it seems to be behaving.

My workaround is this:
1) Power up the mount
2) Connect to the driver (I use MaximDL > Generic Hub > ACP Hub > APv2)
3) Change the APv2 driver to use Synch (uncheck the RCAL option)
4) Synch my first star for the night. It must be in the Eastern hemisphere, otherwise my mount gets upside down (plate solves show orientation of 180 instead of 0 degrees). This establishes the proper "side of pier" upon the first synch. If memory serves me correctly, this is one of the objectives of a synch.
5) Now, go to the APv2 driver and change the setting back to "Use RCAL"

I hope I'm not correct in this. It seems very hokey. If I am correct in this, then the driver should be changed with and additional checkbox to "Next/first 'synch' is a synch - then use RCAL". Thus the new checkbox would override the RCAL option for the next synch.

Also, I tried using the virtual hand controller software to do custom tracking on a comet. I do not understand this. In addition, the values in the custom tracking boxes for RA and DEC custom tracking rates should have more information and they should be spin buttons. However, the granularity of the spin count would need to be adjustable. I think this feature is very valueable, but it should be on its own configuration page. Using this feature, I was able to track comet Hartley (103P) for 2 hours last night, taking 5-minute unguided images with round nucleus.

I await response from the experts.

Thanks

Dave Samuels