Date   

Re: Which GTOCP* connection do you use?

Eric Dreher
 

I agree completely, which was why I mentioned it.  If the Pegasus had been out when I built my box, I'd have purchased it instead.

Best of luck, and enjoy!


Re: Which GTOCP* connection do you use?

Patrick Spencer
 

It appears the Pegasus Powerbox is a more practical solution for someone in my position. But I still think the box you made is really cool.


Re: Model priority APPM vs TSX Tpoint

Dale Ghent
 

Definitely prefer APPM over TPoint. I believe that TPoint for non-SB mounts is just a pointing model, where APPM for A-P mounts provides pointing /and/ tracking models.

If you're using TSX as a planetarium, just use it as a planetarium. Have it connect to the A-P ASCOM driver and interact with the mount through that. With an APPM model active in APCC, the ensemble will just do the right thing. As far as TSX is concerned, it's interacting with just another ASCOM-driven mount and it doesn't need to make any special considerations beyond that.

On Mar 16, 2021, at 11:55, Shailesh Trivedi <strivedi@brightfeathers.com> wrote:

If you have an APPM model and a Tpoint model in The SkyX and use TSX as the planetarium of choice, what takes precedence? And is there any way to force one or the other?

Shailesh


Re: AP 1600, Universal Time and Connecting to Auxiliary Astronomy Programs for Control

Dale Ghent
 


As the document implies, confusion can be lessened by just running all the things in UTC, especially if the person is unaccustomed to operating in multiple time zones. By having your PC and keypad display in UTC, you won't have to change the GMT offset on the keypad twice each year and the time on the keypad will always match the time displayed on your PC. In that sense, such consistency might be attractive to some people.

But it isn't an absolute must for proper operation of the mount. You can still run your PC and keypad in any combination of UTC and local time, you just need to be aware of what the keypad is set to regardless, and if it is set to something other than GMT/UTC, then you will need to manually adjust the timezone offset twice a year if you are in a locale that observes some form of DST.

In Windows (and, at least Windows 10, I'm not sure about previous versions) you can configure the clock in the system tray to display the time in multiple timezones. For example, my imaging PC's clock's main display is my local time zone (US/Eastern), but I added UTC as well if you mouse over it. You add time zones to display under the system time settings in Windows.



On Mar 16, 2021, at 11:29, Jack Huerkamp <Mallincamusa@...> wrote:

Dale,

I got this link from George at Astro-Physics in which it says for a
dedicated observatory PC, to set its clock to UT along with the hand
controller being set to UT:

https://astro-physics.info/tech_support/mounts/keypad/keypad-setting-gmt-utc
.pdf

But it sounds like you are saying to set the observatory PC to local time
and the hand controller to UT, since SkyTools in my case is looking to the
computer time to locate targets.

If so, I will go to the observatory today and set the computer back to local
time, set SkyTools as well and see what happens.

Yours truly,

Jack

Jack Huerkamp
Jack's Astro Accessories, LLC
38388 Pine Street
Pearl River, LA 70452-5192
985-445-5063
mallincamusa@...
www.mallincamusa.com
30.37N  89.76W

All of us get lost in the darkness.
Dreamers learn to steer by the stars.
..............Neil Peart



-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Dale Ghent
Sent: Tuesday, March 16, 2021 8:58 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] AP 1600, Universal Time and Connecting to Auxiliary
Astronomy Programs for Control


So here's the deal: the mount CP deals only in UTC. All calculations
involving positions of objects in the sky are done UTC. For the purposes of
a mount's internal operations, UTC is the only thing that matters.

When you set the timezone on the keypad, you are essentially just
configuring the keypad's display and input of UTC time as local time. The
mount itself doesn't care that your offset from GMT is now -5 instead of -6.
That factors into none of its operations and calculations. What it does
factor into is how your keypad displays time, and how it converts time that
you input to and from UTC. The former - displaying the same time as your
local time - is just for convenience. The latter - inputting your local time
- is critical for the mount to derive the proper UTC time if you were to
program the mount's clock using the keypad. So if your local time is
18:45:00 and you were to program your mount's clock using the keypad today,
it would definitely need to know your current offset from GMT so that the
proper conversion to UTC can take place (that it would be 23:45:00 UTC).

The reason why you have to manually set the GMT offset in your keypad every
time DST begins or ends (or if you move to a different timezone altogether)
is because the keypad lacks its own timezone database that it can use to do
this automatically. You might ask "well how hard would it be for the keypad
to have one so that I don't need to do this". It's a valid question, but the
reasons are fairly basic. The timezone database is large and would occupy a
non-trivial amount of the keypad's very finite amount of static memory. It
also changes quite often as various countries and locales change their DST
observances or, in rare cases, which timezone(s) they are in. This would
demand that A-P issue several firmware updates a year in order to keep up
with these changes.

As for the computer and accessing the mount through the ASCOM driver, this
changes the situation in terms of mount time management. In this case, it is
presumed that your computer's clock is reasonably accurate as any modern OS
will automatically sync the computer's clock to an internet time source at
least once a week or more often, assuming it has internet access. There is a
setting in the A-P ASCOM driver to sync the computer's clock to the mount.
This should always be on if your computer's clock is reasonably accurate.
The ASCOM driver itself will then program the mount in UTC time directly in
this case. Despite your computer's timezone being set to US/Central, the OS
itself still operates in UTC internally. Because your OS does have a
maintained timezone database, it can do the display and input conversions
between your timezone and its internal clock, which runs in UTC.

So, the only reason why you would want to run your computer in UTC is if you
prefer viewing time that way. Even if you set the display of time on your PC
to be in your local timezone, the mount is still going to get programmed
with the proper time in UTC. It makes no difference to the mount.

As for the keypad, you can also just leave it with a timezone offset of 0 so
that it displays and takes input in UTC. However if you want it do display
and take time input in terms of your local time, you will need to manually
set the proper GMT offset whenever DST starts and ends.


On Mar 16, 2021, at 09:13, Jack Huerkamp <Mallincamusa@...> wrote:

I use SkyTools 3 and SkyTools 4 to control my AP1600 mount using the ASCOM
driver.  But every 6 months, I was having to switch the AP keypad from
standard time to daylight savings time and then back again 6 months later.
It was suggested to me to set the AP keypad to UT and also setting the
computer to UT to avoid have to mess with keypad settings every 6 months.  I
did so and can control the mount using the keypad.

I then tried configuring my observatory location, but when I connected the
mount to SkyTools and did a slew to the Sun this afternoon, the scope tried
to aim into the ground on the southwest side of the pier.  I need to know
how to set my location in SkyTools now that the mount and computer are set
to UT.  I am in the Central US time zone.

I would appreciate feedback on this as I would hate to have to go back to
setting the computer and AP keypad to the current local time.

Yours truly,

Jack Huerkamp









-- 
This email has been checked for viruses by AVG.
https://www.avg.com








Model priority APPM vs TSX Tpoint

Shailesh Trivedi
 

If you have an APPM model and a Tpoint model in The SkyX and use TSX as the planetarium of choice, what takes precedence? And is there any way to force one or the other?

Shailesh


Re: Tracking ISS with Horizons #APCC #Mach2GTO

Ray Gralak
 

David,

 

If you attached a large file, it probably was stripped. To get the logs, please use the APCC log zipper utility (not the AP V2 Log zipper) and include all APCC and AP V2 Logs for the last day.

 

If you would tell me the approximate time you observed the Mach2 slowdown that would help narrow down where to look in the log files.

 

Lastly, because of the size of the zipped file, you should provide a link to the zip file through a service like dropbox, google, or one-drive.

 

-Ray

 

From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of David Johnson
Sent: Tuesday, March 16, 2021 8:37 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Tracking ISS with Horizons #APCC #Mach2GTO

 

Is this what you need?  I can see that changing the system clock could make debugging more confusing.  I can try it in "real time" one of these nights when the ISS makes a pass.  Thanks.


Re: AP1100 past the meridian question

Shailesh Trivedi
 

Thank you Eric and Peter,

I was able to image past the meridian overnight with my FSQ 106 (short scope).

Shailesh


Re: Tracking ISS with Horizons #APCC #Mach2GTO

David Johnson
 

Is this what you need?  I can see that changing the system clock could make debugging more confusing.  I can try it in "real time" one of these nights when the ISS makes a pass.  Thanks.


Re: AP 1600, Universal Time and Connecting to Auxiliary Astronomy Programs for Control

Jack Huerkamp
 

Dale,

I got this link from George at Astro-Physics in which it says for a
dedicated observatory PC, to set its clock to UT along with the hand
controller being set to UT:

https://astro-physics.info/tech_support/mounts/keypad/keypad-setting-gmt-utc
.pdf

But it sounds like you are saying to set the observatory PC to local time
and the hand controller to UT, since SkyTools in my case is looking to the
computer time to locate targets.

If so, I will go to the observatory today and set the computer back to local
time, set SkyTools as well and see what happens.

Yours truly,

Jack

Jack Huerkamp
Jack's Astro Accessories, LLC
38388 Pine Street
Pearl River, LA 70452-5192
985-445-5063
mallincamusa@gmail.com
www.mallincamusa.com
30.37N 89.76W

All of us get lost in the darkness.
Dreamers learn to steer by the stars.
..............Neil Peart

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Dale Ghent
Sent: Tuesday, March 16, 2021 8:58 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] AP 1600, Universal Time and Connecting to Auxiliary
Astronomy Programs for Control


So here's the deal: the mount CP deals only in UTC. All calculations
involving positions of objects in the sky are done UTC. For the purposes of
a mount's internal operations, UTC is the only thing that matters.

When you set the timezone on the keypad, you are essentially just
configuring the keypad's display and input of UTC time as local time. The
mount itself doesn't care that your offset from GMT is now -5 instead of -6.
That factors into none of its operations and calculations. What it does
factor into is how your keypad displays time, and how it converts time that
you input to and from UTC. The former - displaying the same time as your
local time - is just for convenience. The latter - inputting your local time
- is critical for the mount to derive the proper UTC time if you were to
program the mount's clock using the keypad. So if your local time is
18:45:00 and you were to program your mount's clock using the keypad today,
it would definitely need to know your current offset from GMT so that the
proper conversion to UTC can take place (that it would be 23:45:00 UTC).

The reason why you have to manually set the GMT offset in your keypad every
time DST begins or ends (or if you move to a different timezone altogether)
is because the keypad lacks its own timezone database that it can use to do
this automatically. You might ask "well how hard would it be for the keypad
to have one so that I don't need to do this". It's a valid question, but the
reasons are fairly basic. The timezone database is large and would occupy a
non-trivial amount of the keypad's very finite amount of static memory. It
also changes quite often as various countries and locales change their DST
observances or, in rare cases, which timezone(s) they are in. This would
demand that A-P issue several firmware updates a year in order to keep up
with these changes.

As for the computer and accessing the mount through the ASCOM driver, this
changes the situation in terms of mount time management. In this case, it is
presumed that your computer's clock is reasonably accurate as any modern OS
will automatically sync the computer's clock to an internet time source at
least once a week or more often, assuming it has internet access. There is a
setting in the A-P ASCOM driver to sync the computer's clock to the mount.
This should always be on if your computer's clock is reasonably accurate.
The ASCOM driver itself will then program the mount in UTC time directly in
this case. Despite your computer's timezone being set to US/Central, the OS
itself still operates in UTC internally. Because your OS does have a
maintained timezone database, it can do the display and input conversions
between your timezone and its internal clock, which runs in UTC.

So, the only reason why you would want to run your computer in UTC is if you
prefer viewing time that way. Even if you set the display of time on your PC
to be in your local timezone, the mount is still going to get programmed
with the proper time in UTC. It makes no difference to the mount.

As for the keypad, you can also just leave it with a timezone offset of 0 so
that it displays and takes input in UTC. However if you want it do display
and take time input in terms of your local time, you will need to manually
set the proper GMT offset whenever DST starts and ends.


On Mar 16, 2021, at 09:13, Jack Huerkamp <Mallincamusa@gmail.com> wrote:

I use SkyTools 3 and SkyTools 4 to control my AP1600 mount using the ASCOM
driver. But every 6 months, I was having to switch the AP keypad from
standard time to daylight savings time and then back again 6 months later.
It was suggested to me to set the AP keypad to UT and also setting the
computer to UT to avoid have to mess with keypad settings every 6 months. I
did so and can control the mount using the keypad.

I then tried configuring my observatory location, but when I connected the
mount to SkyTools and did a slew to the Sun this afternoon, the scope tried
to aim into the ground on the southwest side of the pier. I need to know
how to set my location in SkyTools now that the mount and computer are set
to UT. I am in the Central US time zone.

I would appreciate feedback on this as I would hate to have to go back to
setting the computer and AP keypad to the current local time.

Yours truly,

Jack Huerkamp







--
This email has been checked for viruses by AVG.
https://www.avg.com


Re: Tracking ISS with Horizons #APCC #Mach2GTO

Ray Gralak
 

Hi David,

I would need to see the APCC and AP V2 driver logs to see what happened. One possibility is that the computer could not send commands fast enough, but I don't know why any of the rates would go below sidereal unless a limit was hit.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of David Johnson
Sent: Tuesday, March 16, 2021 7:27 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Tracking ISS with Horizons #APCC #Mach2GTO

Thanks for the info. Here's what I tried next. I did as you suggested and was able to get 1 hour's worth of data at
1-sec intervals, bounding the time where the ISS would be above the horizon here. I then reset my computer's
clock to be very close to the time of the data that I'm using for test tracking, so the telescope would be pointing
roughly where it should be. I also verified that the mount time was also set to this time. The initial pointing this time
was fine.

What happened was that I still had problems with RA keeping up. The RA custom rate started out okay, and the RA
Delta was okay, but RA started slowing down quickly and even dropped below sidereal rate. Naturally, the RA Delta
went way up. It was pushing 2h when I stopped. Certainly, the tracking should have been well within the Mach2's
slewing capability. I tried it a couple of times, and the same thing happened.


Re: Tracking ISS with Horizons #APCC #Mach2GTO

David Johnson
 

Here’s what happens.  You may even be able to hear the mount slow down in the background.


Re: Tracking ISS with Horizons #APCC #Mach2GTO

David Johnson
 

Thanks for the info.  Here's what I tried next.  I did as you suggested and was able to get 1 hour's worth of data at 1-sec intervals, bounding the time where the ISS would be above the horizon here.  I then reset my computer's clock to be very close to the time of the data that I'm using for test tracking, so the telescope would be pointing roughly where it should be.  I also verified that the mount time was also set to this time.  The initial pointing this time was fine.

What happened was that I still had problems with RA keeping up.  The RA custom rate started out okay, and the RA Delta was okay, but RA started slowing down quickly and even dropped below sidereal rate.  Naturally, the RA Delta went way up.  It was pushing 2h when I stopped. Certainly, the tracking should have been well within the Mach2's slewing capability.  I tried it a couple of times, and the same thing happened.


Re: AP 1600, Universal Time and Connecting to Auxiliary Astronomy Programs for Control

Dale Ghent
 

So here's the deal: the mount CP deals only in UTC. All calculations involving positions of objects in the sky are done UTC. For the purposes of a mount's internal operations, UTC is the only thing that matters.

When you set the timezone on the keypad, you are essentially just configuring the keypad's display and input of UTC time as local time. The mount itself doesn't care that your offset from GMT is now -5 instead of -6. That factors into none of its operations and calculations. What it does factor into is how your keypad displays time, and how it converts time that you input to and from UTC. The former - displaying the same time as your local time - is just for convenience. The latter - inputting your local time - is critical for the mount to derive the proper UTC time if you were to program the mount's clock using the keypad. So if your local time is 18:45:00 and you were to program your mount's clock using the keypad today, it would definitely need to know your current offset from GMT so that the proper conversion to UTC can take place (that it would be 23:45:00 UTC).

The reason why you have to manually set the GMT offset in your keypad every time DST begins or ends (or if you move to a different timezone altogether) is because the keypad lacks its own timezone database that it can use to do this automatically. You might ask "well how hard would it be for the keypad to have one so that I don't need to do this". It's a valid question, but the reasons are fairly basic. The timezone database is large and would occupy a non-trivial amount of the keypad's very finite amount of static memory. It also changes quite often as various countries and locales change their DST observances or, in rare cases, which timezone(s) they are in. This would demand that A-P issue several firmware updates a year in order to keep up with these changes.

As for the computer and accessing the mount through the ASCOM driver, this changes the situation in terms of mount time management. In this case, it is presumed that your computer's clock is reasonably accurate as any modern OS will automatically sync the computer's clock to an internet time source at least once a week or more often, assuming it has internet access. There is a setting in the A-P ASCOM driver to sync the computer's clock to the mount. This should always be on if your computer's clock is reasonably accurate. The ASCOM driver itself will then program the mount in UTC time directly in this case. Despite your computer's timezone being set to US/Central, the OS itself still operates in UTC internally. Because your OS does have a maintained timezone database, it can do the display and input conversions between your timezone and its internal clock, which runs in UTC.

So, the only reason why you would want to run your computer in UTC is if you prefer viewing time that way. Even if you set the display of time on your PC to be in your local timezone, the mount is still going to get programmed with the proper time in UTC. It makes no difference to the mount.

As for the keypad, you can also just leave it with a timezone offset of 0 so that it displays and takes input in UTC. However if you want it do display and take time input in terms of your local time, you will need to manually set the proper GMT offset whenever DST starts and ends.

On Mar 16, 2021, at 09:13, Jack Huerkamp <Mallincamusa@gmail.com> wrote:

I use SkyTools 3 and SkyTools 4 to control my AP1600 mount using the ASCOM driver. But every 6 months, I was having to switch the AP keypad from standard time to daylight savings time and then back again 6 months later. It was suggested to me to set the AP keypad to UT and also setting the computer to UT to avoid have to mess with keypad settings every 6 months. I did so and can control the mount using the keypad.

I then tried configuring my observatory location, but when I connected the mount to SkyTools and did a slew to the Sun this afternoon, the scope tried to aim into the ground on the southwest side of the pier. I need to know how to set my location in SkyTools now that the mount and computer are set to UT. I am in the Central US time zone.

I would appreciate feedback on this as I would hate to have to go back to setting the computer and AP keypad to the current local time.

Yours truly,

Jack Huerkamp


Re: Which GTOCP* connection do you use?

Konstantin von Poschinger
 

Hi,

if you can use only USB connections than have a look at the Ultimate Powerbox v2:



I use it and I think it is quite useful and reduce lots of cables.

Konstantin


Konstantin v. Poschinger

Hammerichstr. 5
22605 Hamburg
040/8805747
0171 1983476

Am 16.03.2021 um 14:32 schrieb Patrick Spencer <patrick.spencer2@...>:

Eric,

That power and data distribution box is amazing! I wish a product like that were available commercially, for those of us who don't have your skills.

Patrick Spencer


Re: Which GTOCP* connection do you use?

Eric Dreher
 

Thank you, Patrick.  This isn't as difficult as it seems, nor did it turn out to be as inexpensive as I originally thought it might be.  Due to the expense of the internal cables, I think it totaled to about $400 when I was done, but the convenience of having it cuts down my portable astrophotography setup time on my driveway to about 20 minutes.

I tried to find the original CN post wherein a friend of mine in California, A-P family member Glenn Diekmann, inspired the construction with his similar results.  It all starts with the front panel design from https://www.frontpanelexpress.com/.  They have free downloadable software you use to place your design, connectors, etc. to suit your needs.  Have a look-see and decide if that's what you'd like to do.

Or...you could just buy a Pegasus Astro Ultimate Powerbox for about $200 more.  An excellent product, it came out just a couple of months after I finished my distribution box.  That's what I'd do now, though the satisfaction and fun in building what I have was enjoyable.

Eric


Re: Which GTOCP* connection do you use?

Patrick Spencer
 

Eric,

That power and data distribution box is amazing! I wish a product like that were available commercially, for those of us who don't have your skills.

Patrick Spencer


AP 1600, Universal Time and Connecting to Auxiliary Astronomy Programs for Control

Jack Huerkamp
 

I use SkyTools 3 and SkyTools 4 to control my AP1600 mount using the ASCOM driver.  But every 6 months, I was having to switch the AP keypad from standard time to daylight savings time and then back again 6 months later.  It was suggested to me to set the AP keypad to UT and also setting the computer to UT to avoid have to mess with keypad settings every 6 months.  I did so and can control the mount using the keypad.  

I then tried configuring my observatory location, but when I connected the mount to SkyTools and did a slew to the Sun this afternoon, the scope tried to aim into the ground on the southwest side of the pier.  I need to know how to set my location in SkyTools now that the mount and computer are set to UT.  I am in the Central US time zone.

I would appreciate feedback on this as I would hate to have to go back to setting the computer and AP keypad to the current local time.

Yours truly,

Jack Huerkamp


Re: AP1100 past the meridian question

Eric Claeys
 

There’s a declination where my C11 can do a 360, and other declinations where it only goes an hour past the meridian.  One of the great things about APCC is that it has per-declination meridian limits.  It’s actually fairly easy to set them up, and can be done inside as long as the scope/mount/tripod is set up as it will be in the field, which is easy to do.

And unless you change something, the limits don’t need to be redone.

 

Eric


Re: APPM cannot connect to camera via SGP

Luca Marinelli
 

It may be as Eric mentioned that the latest beta had some issues or the new QHY ASCOM driver. I was running APPM with SGP 64bit v4.657 on the other system (Mach2) without any problems. I’ll do more testing and see if v4.657 works with the QHY camera. 

Thanks,

Luca

On Mar 15, 2021, at 11:01 PM, Brian Valente via groups.io <bvalente@...> wrote:


I connect to camera via SGP all the time, i have not noticed any problems with port number changes

On Mon, Mar 15, 2021 at 6:38 PM Ray Gralak <iogroups@...> wrote:
Hi Luca,

I've not heard of any connect problems. Maybe the TCP port number has changed?

-Ray

> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Luca Marinelli
> Sent: Monday, March 15, 2021 4:48 PM
> To: main@ap-gto.groups.io
> Subject: [ap-gto] APPM cannot connect to camera via SGP
>
> Hi Ray,
>
> I was trying to build a new model for my AP1100 tonight with APCC Pro v1.8.8.17 via SGP v4.661 and a QHY 268M
> camera and APPM was giving an error message "Failed to connect to Camera: cannot Connect: Please make sure
> the camera is connected in Sequence Generator Pro". The camera is connected in SGP, as you can see in the
> screenshot via the QHY ASCOM driver (ASCOM v6.5 SP1). Incidentally on the screen on the left you can see
> APPM running on the other system (Mach2 with ZWO ASI6200MM camera) without any problems. Do you know
> what might be the issue or how to troubleshoot it further?
>
> Thanks,
>
> Luca
>








--
Brian 



Brian Valente


Re: APPM cannot connect to camera via SGP

 

I connect to camera via SGP all the time, i have not noticed any problems with port number changes


On Mon, Mar 15, 2021 at 6:38 PM Ray Gralak <iogroups@...> wrote:
Hi Luca,

I've not heard of any connect problems. Maybe the TCP port number has changed?

-Ray

> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Luca Marinelli
> Sent: Monday, March 15, 2021 4:48 PM
> To: main@ap-gto.groups.io
> Subject: [ap-gto] APPM cannot connect to camera via SGP
>
> Hi Ray,
>
> I was trying to build a new model for my AP1100 tonight with APCC Pro v1.8.8.17 via SGP v4.661 and a QHY 268M
> camera and APPM was giving an error message "Failed to connect to Camera: cannot Connect: Please make sure
> the camera is connected in Sequence Generator Pro". The camera is connected in SGP, as you can see in the
> screenshot via the QHY ASCOM driver (ASCOM v6.5 SP1). Incidentally on the screen on the left you can see
> APPM running on the other system (Mach2 with ZWO ASI6200MM camera) without any problems. Do you know
> what might be the issue or how to troubleshoot it further?
>
> Thanks,
>
> Luca
>








--
Brian 



Brian Valente

2721 - 2740 of 79778