Date   

Re: About APCC and ISS tracking and PC Time

Woody Schlom
 

Christopher,

 

Thanks for that insight on GPS clock accuracy.  I realized it took several minutes for greatest geographical accuracy (often called 3D by GPS makers), but didn’t realize that the clock accuracy could take as long as 20 minutes.

 

Woody

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Christopher Erickson
Sent: Wednesday, April 7, 2021 7:13 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] About APCC and ISS tracking and PC Time

 

Only FWIW, SharpCap can access the GPS chip in my QHY174M-GPS cams and sync the PC clock to them.

 

I always run GPS's for at least 20 minutes on-sky before I attempt to sync a PC to them before I capture an occultation. I have seen GPS time being up to 20 seconds off from a GPS until they get a full ephemeris update from the satellites.

 

I hope this helps.


-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

 

On Wed, Apr 7, 2021, 3:50 PM Dale Ghent <daleg@...> wrote:


Ugh. Windows' built-in time client has been a pain to deal with and performed sadly only until recently, and even still it requires some tweaks in order to keep host clock drift reasonably in check. One of the time server vendors I've used in the past has a decent series of KB articles regarding this:

https://kb.meinbergglobal.com/kb/time_sync/timekeeping_on_windows/accurate_time_in_windows

As for using a GPS to sync the signal timecode to the host, I do this now using a $15 USB GPS dongle from Amazon and the NMEATime2 app from VisualGPS: http://visualgps.net/#nmeatime2-content

NMEATime2 does it right, including calibrating for the delay between the signal being emitted, received, and working its way through the OS to the app. This delay calibration is key for any app that's used to keep time with any signal source and why you can't just read the GPS sentences as they come off the serial port and write that time to the OS clock. It's pretty good for $20 and change, and a total solution for under $40 if you include the cost of any USB GPS dongle.

/dale


> On Apr 7, 2021, at 21:08, W Hilmo <y.groups@...> wrote:
>
> Your computer should be able to sync time with NIST, as long as you have an internet connection.  APCC can then update the mount’s time with the computer’s time.  This doesn’t require a new feature.
>
>
>
> The new feature that I would like to see is for APCC to have an option to update the computer time from a GPS receiver.  I do a fair amount of imaging from sites with no internet.  Right now, I have a 3rd party piece of software that I use to sync the computer clock from the GPS, but it would be nice to have an option to do this right from APCC.
>
>
>
> From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of drgert1 via groups.io
> Sent: Wednesday, April 7, 2021 2:02 PM
> To: main@ap-gto.groups.io
> Subject: [ap-gto] About APCC and ISS tracking and PC Time
>
>
>
> Hello All,
>
> There was a nice ISS pass yesterday. I tried to follow it with APCC horizon utility.
> I see the PC time as the most tricky parameter. In my case the mount was trailing the ISS by a bit.
> Obviously my PC time wasn't spot-on. Now for folks like me who are getting forgetful maybe it's an opportunity for Ray to put some automated NIST time sync into APCC just as a helpful measure. Maybe with a little popup 'OK' button.
>
> The tracking feature is just great. I like the way it is organized sending the custom tracking speeds to the mount (which you can see in the driver UI)
>
> My one improvement request would be to have the hand controller buttons 'N E S W' able to overlay the motion of the tracking. When I pushed the buttons during the ISS flyover the mount moved but 'something was fighting' the motion and pushed the ISS back to the edge of the field of view.
>
> Maybe even have an option for a USB joystick to control the mount motion. (This would be even a cool thing outside off ISS tracking) :-)
>
> Of course a great shout-out to Ray for the excellent work.
>
> Cheers,
> Gert
>
>
>






Re: APCC / APPM Frustration

Ray Gralak
 

Hi Marty,

 

You are probably overcomplicating things. There is an option to auto-configure the driver in APCC. There is also a button in APCC to do a one-time configuration of the ASCOM driver.

 

To simplify things, always start APCC first and connect to the mount, then connect your other applications.

 

Now, to fix your problem:

 

1. With just APCC connected to the mount (no AP V2 ASCOM driver), define Virtual ports 1 and 2 and connect to them on the Virtual Ports tab.

2. Click the tiny "Now" button in APCC's "AP V2 Driver" Group box. This will configure the AP V2 ASCOM driver. There will be several pop-up windows to which you will need to click "OK". Afterwards the AP V2 driver will be configured correctly.

3. For future sessions enable the three checkboxes in this screen shot:

 

 

After doing this the driver and APCC will be configured correctly for use with APPM.

 

-Ray

 

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

> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of mjb87 via groups.io

> Sent: Wednesday, April 7, 2021 5:54 PM

> To: main@ap-gto.groups.io

> Subject: [ap-gto] APCC / APPM Frustration

>

> [Edited Message Follows]

>

> I am trying to get APPM to work with my 1100 mount. For reference, I have had success it getting it to work (different

> software installation, different computer) with my Mach2 mount. There must be something wrong with my sequence

> and setup.

>

> First, I start APCC and connect successfully (via IP) to the mount. Note that I have the "create virtual ports first" box

> checked and two ports get created.

> Second, I start APPM and try to connect to the mount. I get an error message telling me to start APCC (it WAS

> started) and connect the driver through APCC. Fine.

>

>

>

>

> When I go back to APCC and try to connect to the AP V2 driver, I get this error telling me to create the virtual ports

> first.

>

>

>

> But the virtual ports ARE created. In any case, I tried about 20 times to delete the virtual ports and then recreate

> them -- all without success in starting APPM. I restarted the computer several times as well. No success.

>

> What am I doing wrong? The sky was perfect for running APPM and now I have rain in the forecast.

>

> Marty


Re: About APCC and ISS tracking and PC Time

Dale Ghent
 

Yep. 

The hows and whys are covered by the NMEATime author here:


On Apr 7, 2021, at 10:13 PM, Christopher Erickson <christopher.k.erickson@...> wrote:


Only FWIW, SharpCap can access the GPS chip in my QHY174M-GPS cams and sync the PC clock to them.

I always run GPS's for at least 20 minutes on-sky before I attempt to sync a PC to them before I capture an occultation. I have seen GPS time being up to 20 seconds off from a GPS until they get a full ephemeris update from the satellites.

I hope this helps.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

On Wed, Apr 7, 2021, 3:50 PM Dale Ghent <daleg@...> wrote:

Ugh. Windows' built-in time client has been a pain to deal with and performed sadly only until recently, and even still it requires some tweaks in order to keep host clock drift reasonably in check. One of the time server vendors I've used in the past has a decent series of KB articles regarding this:

https://kb.meinbergglobal.com/kb/time_sync/timekeeping_on_windows/accurate_time_in_windows

As for using a GPS to sync the signal timecode to the host, I do this now using a $15 USB GPS dongle from Amazon and the NMEATime2 app from VisualGPS: http://visualgps.net/#nmeatime2-content

NMEATime2 does it right, including calibrating for the delay between the signal being emitted, received, and working its way through the OS to the app. This delay calibration is key for any app that's used to keep time with any signal source and why you can't just read the GPS sentences as they come off the serial port and write that time to the OS clock. It's pretty good for $20 and change, and a total solution for under $40 if you include the cost of any USB GPS dongle.

/dale


> On Apr 7, 2021, at 21:08, W Hilmo <y.groups@...> wrote:
>
> Your computer should be able to sync time with NIST, as long as you have an internet connection.  APCC can then update the mount’s time with the computer’s time.  This doesn’t require a new feature.
>
>
>
> The new feature that I would like to see is for APCC to have an option to update the computer time from a GPS receiver.  I do a fair amount of imaging from sites with no internet.  Right now, I have a 3rd party piece of software that I use to sync the computer clock from the GPS, but it would be nice to have an option to do this right from APCC.
>
>
>
> From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of drgert1 via groups.io
> Sent: Wednesday, April 7, 2021 2:02 PM
> To: main@ap-gto.groups.io
> Subject: [ap-gto] About APCC and ISS tracking and PC Time
>
>
>
> Hello All,
>
> There was a nice ISS pass yesterday. I tried to follow it with APCC horizon utility.
> I see the PC time as the most tricky parameter. In my case the mount was trailing the ISS by a bit.
> Obviously my PC time wasn't spot-on. Now for folks like me who are getting forgetful maybe it's an opportunity for Ray to put some automated NIST time sync into APCC just as a helpful measure. Maybe with a little popup 'OK' button.
>
> The tracking feature is just great. I like the way it is organized sending the custom tracking speeds to the mount (which you can see in the driver UI)
>
> My one improvement request would be to have the hand controller buttons 'N E S W' able to overlay the motion of the tracking. When I pushed the buttons during the ISS flyover the mount moved but 'something was fighting' the motion and pushed the ISS back to the edge of the field of view.
>
> Maybe even have an option for a USB joystick to control the mount motion. (This would be even a cool thing outside off ISS tracking) :-)
>
> Of course a great shout-out to Ray for the excellent work.
>
> Cheers,
> Gert
>
>
>







Re: About APCC and ISS tracking and PC Time

Christopher Erickson
 

Only FWIW, SharpCap can access the GPS chip in my QHY174M-GPS cams and sync the PC clock to them.

I always run GPS's for at least 20 minutes on-sky before I attempt to sync a PC to them before I capture an occultation. I have seen GPS time being up to 20 seconds off from a GPS until they get a full ephemeris update from the satellites.

I hope this helps.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   


On Wed, Apr 7, 2021, 3:50 PM Dale Ghent <daleg@...> wrote:

Ugh. Windows' built-in time client has been a pain to deal with and performed sadly only until recently, and even still it requires some tweaks in order to keep host clock drift reasonably in check. One of the time server vendors I've used in the past has a decent series of KB articles regarding this:

https://kb.meinbergglobal.com/kb/time_sync/timekeeping_on_windows/accurate_time_in_windows

As for using a GPS to sync the signal timecode to the host, I do this now using a $15 USB GPS dongle from Amazon and the NMEATime2 app from VisualGPS: http://visualgps.net/#nmeatime2-content

NMEATime2 does it right, including calibrating for the delay between the signal being emitted, received, and working its way through the OS to the app. This delay calibration is key for any app that's used to keep time with any signal source and why you can't just read the GPS sentences as they come off the serial port and write that time to the OS clock. It's pretty good for $20 and change, and a total solution for under $40 if you include the cost of any USB GPS dongle.

/dale


> On Apr 7, 2021, at 21:08, W Hilmo <y.groups@...> wrote:
>
> Your computer should be able to sync time with NIST, as long as you have an internet connection.  APCC can then update the mount’s time with the computer’s time.  This doesn’t require a new feature.
>
>
>
> The new feature that I would like to see is for APCC to have an option to update the computer time from a GPS receiver.  I do a fair amount of imaging from sites with no internet.  Right now, I have a 3rd party piece of software that I use to sync the computer clock from the GPS, but it would be nice to have an option to do this right from APCC.
>
>
>
> From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of drgert1 via groups.io
> Sent: Wednesday, April 7, 2021 2:02 PM
> To: main@ap-gto.groups.io
> Subject: [ap-gto] About APCC and ISS tracking and PC Time
>
>
>
> Hello All,
>
> There was a nice ISS pass yesterday. I tried to follow it with APCC horizon utility.
> I see the PC time as the most tricky parameter. In my case the mount was trailing the ISS by a bit.
> Obviously my PC time wasn't spot-on. Now for folks like me who are getting forgetful maybe it's an opportunity for Ray to put some automated NIST time sync into APCC just as a helpful measure. Maybe with a little popup 'OK' button.
>
> The tracking feature is just great. I like the way it is organized sending the custom tracking speeds to the mount (which you can see in the driver UI)
>
> My one improvement request would be to have the hand controller buttons 'N E S W' able to overlay the motion of the tracking. When I pushed the buttons during the ISS flyover the mount moved but 'something was fighting' the motion and pushed the ISS back to the edge of the field of view.
>
> Maybe even have an option for a USB joystick to control the mount motion. (This would be even a cool thing outside off ISS tracking) :-)
>
> Of course a great shout-out to Ray for the excellent work.
>
> Cheers,
> Gert
>
>
>







Re: About APCC and ISS tracking and PC Time

Dale Ghent
 

Ugh. Windows' built-in time client has been a pain to deal with and performed sadly only until recently, and even still it requires some tweaks in order to keep host clock drift reasonably in check. One of the time server vendors I've used in the past has a decent series of KB articles regarding this:

https://kb.meinbergglobal.com/kb/time_sync/timekeeping_on_windows/accurate_time_in_windows

As for using a GPS to sync the signal timecode to the host, I do this now using a $15 USB GPS dongle from Amazon and the NMEATime2 app from VisualGPS: http://visualgps.net/#nmeatime2-content

NMEATime2 does it right, including calibrating for the delay between the signal being emitted, received, and working its way through the OS to the app. This delay calibration is key for any app that's used to keep time with any signal source and why you can't just read the GPS sentences as they come off the serial port and write that time to the OS clock. It's pretty good for $20 and change, and a total solution for under $40 if you include the cost of any USB GPS dongle.

/dale

On Apr 7, 2021, at 21:08, W Hilmo <y.groups@hilmo.net> wrote:

Your computer should be able to sync time with NIST, as long as you have an internet connection. APCC can then update the mount’s time with the computer’s time. This doesn’t require a new feature.



The new feature that I would like to see is for APCC to have an option to update the computer time from a GPS receiver. I do a fair amount of imaging from sites with no internet. Right now, I have a 3rd party piece of software that I use to sync the computer clock from the GPS, but it would be nice to have an option to do this right from APCC.



From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of drgert1 via groups.io
Sent: Wednesday, April 7, 2021 2:02 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] About APCC and ISS tracking and PC Time



Hello All,

There was a nice ISS pass yesterday. I tried to follow it with APCC horizon utility.
I see the PC time as the most tricky parameter. In my case the mount was trailing the ISS by a bit.
Obviously my PC time wasn't spot-on. Now for folks like me who are getting forgetful maybe it's an opportunity for Ray to put some automated NIST time sync into APCC just as a helpful measure. Maybe with a little popup 'OK' button.

The tracking feature is just great. I like the way it is organized sending the custom tracking speeds to the mount (which you can see in the driver UI)

My one improvement request would be to have the hand controller buttons 'N E S W' able to overlay the motion of the tracking. When I pushed the buttons during the ISS flyover the mount moved but 'something was fighting' the motion and pushed the ISS back to the edge of the field of view.

Maybe even have an option for a USB joystick to control the mount motion. (This would be even a cool thing outside off ISS tracking) :-)

Of course a great shout-out to Ray for the excellent work.

Cheers,
Gert



Re: About APCC and ISS tracking and PC Time

W Hilmo
 

Your computer should be able to sync time with NIST, as long as you have an internet connection.  APCC can then update the mount’s time with the computer’s time.  This doesn’t require a new feature.

 

The new feature that I would like to see is for APCC to have an option to update the computer time from a GPS receiver.  I do a fair amount of imaging from sites with no internet.  Right now, I have a 3rd party piece of software that I use to sync the computer clock from the GPS, but it would be nice to have an option to do this right from APCC.

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of drgert1 via groups.io
Sent: Wednesday, April 7, 2021 2:02 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] About APCC and ISS tracking and PC Time

 

Hello All,

There was a nice ISS pass yesterday. I tried to follow it with APCC horizon utility.
I see the PC time as the most tricky parameter. In my case the mount was trailing the ISS by a bit.
Obviously my PC time wasn't spot-on. Now for folks like me who are getting forgetful maybe it's an opportunity for Ray to put some automated NIST time sync into APCC just as a helpful measure. Maybe with a little popup 'OK' button.

The tracking feature is just great. I like the way it is organized sending the custom tracking speeds to the mount (which you can see in the driver UI)

My one improvement request would be to have the hand controller buttons 'N E S W' able to overlay the motion of the tracking. When I pushed the buttons during the ISS flyover the mount moved but 'something was fighting' the motion and pushed the ISS back to the edge of the field of view.

Maybe even have an option for a USB joystick to control the mount motion. (This would be even a cool thing outside off ISS tracking) :-)

Of course a great shout-out to Ray for the excellent work.

Cheers,
Gert


APCC / APPM Frustration

mjb87@...
 
Edited

I am trying to get APPM to work with my 1100 mount. For reference, I have had success it getting it to work (different software installation, different computer) with my Mach2 mount. There must be something wrong with my sequence and setup.

First, I start APCC and connect successfully (via IP) to the mount. Note that I have the "create virtual ports first" box checked and two ports get created.
Second, I start APPM and try to connect to the mount. I get an error message telling me to start APCC (it WAS started) and connect the driver through APCC. Fine.




When I go back to APCC and try to connect to the AP V2 driver, I get this error telling me to create the virtual ports first.



But the virtual ports ARE created. In any case, I tried about 20 times to delete the virtual ports and then recreate them -- all without success in starting APPM. I restarted the computer several times as well. No success.

What am I doing wrong? The sky was perfect for running APPM and now I have rain in the forecast.

Marty


About APCC and ISS tracking and PC Time

drgert1
 

Hello All,

There was a nice ISS pass yesterday. I tried to follow it with APCC horizon utility.
I see the PC time as the most tricky parameter. In my case the mount was trailing the ISS by a bit.
Obviously my PC time wasn't spot-on. Now for folks like me who are getting forgetful maybe it's an opportunity for Ray to put some automated NIST time sync into APCC just as a helpful measure. Maybe with a little popup 'OK' button.

The tracking feature is just great. I like the way it is organized sending the custom tracking speeds to the mount (which you can see in the driver UI)

My one improvement request would be to have the hand controller buttons 'N E S W' able to overlay the motion of the tracking. When I pushed the buttons during the ISS flyover the mount moved but 'something was fighting' the motion and pushed the ISS back to the edge of the field of view.

Maybe even have an option for a USB joystick to control the mount motion. (This would be even a cool thing outside off ISS tracking) :-)

Of course a great shout-out to Ray for the excellent work.

Cheers,
Gert


Re: Mach2 Slew Speed, Power, and Voltage Question #Mach2GTO

Greg McCall
 

Rolando,
You don't charge a 24v battery at 24v.
Just checking one battery spec at https://enerdrive.com.au/product/epower-b-tec-24v-100ah-lithium-battery/
It can be 28.8v-29.2v for charging and 27-27.6v as a float voltage 
(that's for a lithium battery, specifically, LiFePO4 often used in astro setups, camping, RV industry)
24v is a nominal voltage with the operating range being 22v to 29v 
While I've not been given a specification for the allowed voltages, the discussion so far has indicated these voltages are not suitable for the Mach2

Contrary to what has been said in this message thread (and a similar thread), are saying I can use a 24v battery on the Mach2 while charging?
I just see no specification and now mixed messages.


Re: Mach2 - Elongated stars

M Hambrick
 

Hi Yanzhe

Regarding the possibility of vibration coming from the camera I have a SBIG STXL16200 camera and I have found that when the cooler output exceeds about 78% for a period of time, the camera fan kicks into a high speed mode. There is quite a lot of vibration when this happens, and I have seen it degrade my images. I am not sure if this is the root cause of your problem, but I suggest that you try one of the following:

  1. Run your cooler setpoint so that the cooler output does not exceed about 75% at steady state.
  2. If you are using MaxIm DL to image, you can switch the fan to manual mode so that it runs at a fixed speed. You can do this from the Expose Tab using the Options menu.
Mike


Re: Mach2 - Elongated stars

Roland Christen
 


One issue I am facing with Mach2 guiding is that I am not quite sure why my RA correction is mostly one direction. I can understand DEC correction in one direction due to polar alignment error, but RA should be random. Is this normal?
If your guiding is in one direction it simply means that you either have not perfect polar alignment or you are guiding in that part of the sky where the stars are moving slower than sidereal. This is caused by atmospheric refraction, and it is quite normal.

Rolando

-----Original Message-----
From: yanzhe liu <liuyanzhe@...>
To: main@ap-gto.groups.io
Sent: Sat, Mar 27, 2021 11:51 pm
Subject: Re: [ap-gto] Mach2 - Elongated stars

Rolando,

I am still digging into why my stars are elongated, currently I am focusing on collimation and possible fan noise. When I looked carefully into my old subs (with another mount), I got elongated stars too, but because the stars were larger (ie, guiding performance was not as good as Mach2) it looked rounder.

One issue I am facing with Mach2 guiding is that I am not quite sure why my RA correction is mostly one direction. I can understand DEC correction in one direction due to polar alignment error, but RA should be random. Is this normal?
Screen Shot 2021-03-27 at 9.48.16 PM.png

Yanzhe

On Fri, Mar 12, 2021 at 3:41 PM Bill Long <bill@...> wrote:
I did have my scope well-balanced in both axis. I guided it for a short while as a test for a 5 min sub (image below) then turned it off and went unguided and noticed the stars were of identical quality, so I went unguided for the evening instead.




From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of yanzhe liu <liuyanzhe@...>
Sent: Friday, March 12, 2021 2:41 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Mach2 - Elongated stars
 
I have been using mach1 and 1100 prior to mach2. I knew I changed mount to mach2 in ascom driver.

Let me try again with balanced DEC, as suggested by Roland, to see if the issue is going away.  

On Thu, Mar 11, 2021 at 7:38 AM Ray Gralak <iogroups@...> wrote:
Yanzhe,

> I am able to run "AP Log Zipper", there are 2 files shown in the app: ap.ini and Setting.apdb, however both were dated
> 12/29/2018. Maybe I did not enable ASCOM log.

Hmmm... that is not the default. Did you happen to use this computer with another A-P mount in the past?

Since it is probably a small file, please attach that zip file to a post. It's worth checking the settings to see if anything stands out as an incorrect setting.

BTW, can you also provide a dropbox or google drive link to one of the single raw FITS images with the elongated stars? It's important that it is an unprocessed image and not a jpeg or stacked with other images.

Thanks,

-Ray

> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of yanzhe liu
> Sent: Wednesday, March 10, 2021 10:36 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] Mach2 - Elongated stars
>
> Ray,
>
> I am able to run "AP Log Zipper", there are 2 files shown in the app: ap.ini and Setting.apdb, however both were dated
> 12/29/2018. Maybe I did not enable ASCOM log.
>
> Yanzhe
>
> On Sun, Mar 7, 2021 at 7:37 PM Ray Gralak <iogroups@...> wrote:
>
>
>       Yanhze,
>
>       > Where is ASCOM driver log? I dont use APCC, I use SGPro.
>
>       The AP V2 ASCOM driver, which you must use with SGPro, comes with a log zipper utility called "AP Log
> Zipper". You should be able to find it from the Windows start menu by typing that name. The utility will grab the log files
> for X number of days in the past. If you can't find it, you probably didn't install it when you installed the AP V2 driver. In
> that case, just reinstall the AP V2 driver and select the option to install it.
>
>       BTW, you can use APCC with SGPro. In fact, it is recommended. An APCC Pro license comes with your
> Mach2 mount, but you must contact A-P to get it.
>
>       -Ray
>
>
>       > -----Original Message-----
>       > From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of yanzhe liu
>       > Sent: Sunday, March 7, 2021 4:19 PM
>       > To: main@ap-gto.groups.io
>       > Subject: Re: [ap-gto] Mach2 - Elongated stars
>       >
>       > Ray,
>       >
>       > Where is ASCOM driver log? I dont use APCC, I use SGPro.
>       >
>       > Yanzhe
>       >
>       > On Sun, Mar 7, 2021 at 10:45 AM Ray Gralak <iogroups@...> wrote:
>       >
>       >
>       >       Hi Yanzhe,
>       >
>       >       Can you zip and post your PHD2 logs, as well as APCC/AP V2 ASCOM driver logs?
>       >
>       >       There might be something useful there.
>       >
>       >       -Ray
>       >
>       >       > -----Original Message-----
>       >       > From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of yanzhe liu
>       >       > Sent: Sunday, March 7, 2021 10:12 AM
>       >       > To: main@ap-gto.groups.io
>       >       > Subject: Re: [ap-gto] Mach2 - Elongated stars
>       >       >
>       >       > Roland,
>       >       >
>       >       > I will check my mount serial number later as I just packed everything due to rain forecast.
>       >       >
>       >       > My camera's orientation was 0/180 degree, so I assume top to bottom elongation would be DEC.
>       >       >
>       >       > I dont have any picture of my setup, I just tore it down since it will be rainy this week. My setup is
>       >       > FSQ106+OAG+16803, image scale is 3.5".
>       >       > I was imaging Rosetta Nebula, after it was just past meridian for 2-3 hours.
>       >       >
>       >       > I used PHD2 drift for PA, it reported <5' PA error, I am waiting for polemaster adapter so I can confirm I
> get
>       > good PA
>       >       > next time.
>       >       >
>       >       > DEC was out of balance because my setup was rear end heavy, if it was in balance position then I
> could
>       > not rotate
>       >       > my CCD in all directions. My guess is that the DEC balance was off by less than 1lb. In the next test, I
> can
>       > balance
>       >       > DEC to see if the issue still exists.
>       >       >
>       >       > My suspicion is that if DEC balance is off, then DEC might creep under gravity, even PA is perfect. So
> you
>       > might
>       >       > see DEC continually drift  then gets corrected by PHD2 periodically.
>       >       >
>       >       > Yanzhe
>       >       >
>       >       > On Sun, Mar 7, 2021 at 9:35 AM Roland Christen via groups.io <chris1011=aol.com@groups.io> wrote:
>       >       >
>       >       >
>       >       >       Couple of questions:
>       >       >
>       >       >
>       >       >       1 - what's the mount's serial number
>       >       >       2 - which axis is the elongation
>       >       >       3 - which direction was the scope pointing (RA-Dec)
>       >       >       4 - what scope and focal length or what is the arc sec per pixel.
>       >       >       5 - do you have a picture of your setup?
>       >       >
>       >       >
>       >       >
>       >       >       One comment about balance - it should be easy for you to completely balance the scope with the
>       > clutches
>       >       > loose. Can you estimate how many lb out of balance your scope is in Dec? Normally i would not think
> this
>       > would
>       >       > have any effect, but doesn't hurt to check this.
>       >       >
>       >       >
>       >       >
>       >       >       Roland Christen
>       >       >       Astro-Physics Inc.
>       >       >
>       >       >
>       >       >
>       >       >
>       >       >       -----Original Message-----
>       >       >       From: yanzhe liu <liuyanzhe@...>
>       >       >       To: mailto:main@ap-gto.groups.io
>       >       >       Sent: Sun, Mar 7, 2021 12:44 am
>       >       >       Subject: [ap-gto] Mach2 - Elongated stars
>       >       >
>       >       >
>       >       >       Testing new mach2 for a couple of nights. It works great out of the box and I am very pleased.
>       >       >
>       >       >       One issue bothering me is that I got slightly elongated stars across the entire image (15min Ha sub).
>       >       >       The exact same telescope/CCD were used with another mount and stars were round, I am
> wondering
>       > what I
>       >       > should check (I think there was due to some setup issue, but I could not figure it out).
>       >       >       - Used OAG for guiding, so there should not be any flexure.
>       >       >       - CCD orientation was 0/180 degree. The stars were elongated top to bottom.
>       >       >       -  I did polar alignment with PHD2 drift align. PA error should be < 5'. The field rotation of each sub
> is
>       > ~0.01
>       >       > degree, much larger than the other system (but elongated stars do not look like field rotation, they were
>       > same
>       >       > across the image)
>       >       >       - Both RA and DEC guiding curves looked smooth, had similar RMS. DEC correction was mainly to
>       > one
>       >       > direction.
>       >       >       - DEC balance was slightly off, camera heavy. Is Mach2 DEC sensitive to this? Will the
> guiding/image
>       > be
>       >       > affected?
>       >       >
>       >       >       I dont think any of the above is of particular concern, except DEC balance. Any comment/help is
>       > appreciated.
>       >       >
>       >       >       --
>       >       >       Roland Christen
>       >       >       Astro-Physics
>       >       >
>       >       >
>       >       >
>       >       >
>       >       >
>       >       >
>       >
>       >
>       >
>       >
>       >
>       >
>       >
>       >
>       >
>
>
>
>
>
>
>
>
>







--
Roland Christen
Astro-Physics


Re: Mach2 Slew Speed, Power, and Voltage Question #Mach2GTO

Roland Christen
 


Having a 24v system and not allowing for use of a 24v off the shelf battery (with charging) seems to be a poor design.
Where did you get this idea? You certainly can use a 24 volt battery with charging to power the Mach2.

Rolando


-----Original Message-----
From: Greg McCall <emailgregnow@...>
To: main@ap-gto.groups.io
Sent: Wed, Mar 31, 2021 8:22 pm
Subject: Re: [ap-gto] Mach2 Slew Speed, Power, and Voltage Question #Mach2GTO

I was more hoping by now a more specific answer was available as I've never seen a manufacturer not have an actual specification for their equipment.
Having a 24v system and not allowing for use of a 24v off the shelf battery (with charging) seems to be a poor design.
12v or 24v are usually nominal voltage based historically on a car or truck battery systems. (with an appropriate voltage range for charging and discharging batteries)
Using a mixture of batteries to get close to the voltage is just not practical. 

--
Roland Christen
Astro-Physics


Setting early flip in APCC

Wayne Hixson
 

I want to get an early meridian flip and I try to set it to +3. It keeps jumping right back to 0. I have Enable meridian limits checked. Also override ASCOM. I’ve tried different settings on the enable CW up E and W with no luck. I used to know how to do this...😳


Re: AP130GTX Imaging First Light

Jeff B
 

Impressive Wade!  I find an appealing, almost ghostly quality to it.

Well done.

Jeff 

On Tue, Apr 6, 2021 at 5:07 PM W Hilmo <y.groups@...> wrote:
I was planning to use my new AP130GTX just for visual observing through the springtime, so that I could capture galaxies with my SCT, but it didn't work out that way.

Part of it is impatience on my part to get imaging with the scope, and part of it is weather.  In terms of imaging, I suspect that my site is not going to be great for very high resolution imaging.  Since we're on the leeward side of the Cascade mountains, the seeing is quite a bit softer than what I was used to on the west side of the mountains.  Because of that, imaging at 0.3 arc seconds per pixel doesn't give awesome results.  My QSI camera on the AP130GTX is just about 0.8 arc seconds per pixel, which works out better.  The second weather impact is that visual observing at this time of year is less than pleasant.  We're in the mid to low 30s at night, which isn't bad in itself, but combine that with 30mph winds, and it gets really cold, really fast.  So with all of that, I moved the camera gear from the SCT to the new scope.

I'm posting here, instead of AP-UG, since the thing that I am blown away by is the performance of my AP1600 with absolute encoders.  I've known all along that I've been fighting with mirror shift and flex with my SCT, but I had no idea how much - until now.

The weather conditions last night were pretty poor.  The sky was cloudless, but that was the only good thing.  The transparency was marginal, the seeing was poor, and it was windy.  The winds were about 25mph to 30mph for most of the night.  There were gusts that rattled the windows (unfortunately, this is not uncommon here).  When I was exercising each part of the system, I ran for a while with my OAG and PHD2.  The best I could get was about 1.2 arc seconds RMS, with the scatter plot pretty much random within about a 3 arc second circle.  I went ahead and built an APCC Pro pointing model with about 180 points and then did some more testing.

The pointing accuracy was striking, as compared to what I am used to with the SCT.  It was pretty much putting any target I selected right at the center of the field, no matter where in the sky.  But what really impressed me was the unguided performance.  After creating the pointing and tracking models, I ran a sequence in NINA of 10 minute exposures for the rest of the night, unguided.  Even with the gusty wind, the subs looked great (even if soft from the seeing).  When I processed the image, there were no subs that needed to be tossed, so I kept them all.

To say that I am happy would be a huge understatement.  Even though I've been using Astro-Physics mounts for almost 10 years, I am simply amazed at what they can do when you put a top shelf scope on them.  Wow.  The biggest downside is that the data is so good, that my processing skills are well short of taking advantage.

Speaking of processing, the processing of this data was minimal.  After calibration/integration, I spent between 25 and 30 minutes processing the combined channels.  I did not do any noise reduction (except for MureDenoise) and sharpening, since I wanted to show the quality of the data from the system.

The full resolution image and capture details are available at: https://www.astrobin.com/lsn8uv/



Thanks,
-Wade


AP130GTX Imaging First Light

W Hilmo
 

I was planning to use my new AP130GTX just for visual observing through the springtime, so that I could capture galaxies with my SCT, but it didn't work out that way.

Part of it is impatience on my part to get imaging with the scope, and part of it is weather.  In terms of imaging, I suspect that my site is not going to be great for very high resolution imaging.  Since we're on the leeward side of the Cascade mountains, the seeing is quite a bit softer than what I was used to on the west side of the mountains.  Because of that, imaging at 0.3 arc seconds per pixel doesn't give awesome results.  My QSI camera on the AP130GTX is just about 0.8 arc seconds per pixel, which works out better.  The second weather impact is that visual observing at this time of year is less than pleasant.  We're in the mid to low 30s at night, which isn't bad in itself, but combine that with 30mph winds, and it gets really cold, really fast.  So with all of that, I moved the camera gear from the SCT to the new scope.

I'm posting here, instead of AP-UG, since the thing that I am blown away by is the performance of my AP1600 with absolute encoders.  I've known all along that I've been fighting with mirror shift and flex with my SCT, but I had no idea how much - until now.

The weather conditions last night were pretty poor.  The sky was cloudless, but that was the only good thing.  The transparency was marginal, the seeing was poor, and it was windy.  The winds were about 25mph to 30mph for most of the night.  There were gusts that rattled the windows (unfortunately, this is not uncommon here).  When I was exercising each part of the system, I ran for a while with my OAG and PHD2.  The best I could get was about 1.2 arc seconds RMS, with the scatter plot pretty much random within about a 3 arc second circle.  I went ahead and built an APCC Pro pointing model with about 180 points and then did some more testing.

The pointing accuracy was striking, as compared to what I am used to with the SCT.  It was pretty much putting any target I selected right at the center of the field, no matter where in the sky.  But what really impressed me was the unguided performance.  After creating the pointing and tracking models, I ran a sequence in NINA of 10 minute exposures for the rest of the night, unguided.  Even with the gusty wind, the subs looked great (even if soft from the seeing).  When I processed the image, there were no subs that needed to be tossed, so I kept them all.

To say that I am happy would be a huge understatement.  Even though I've been using Astro-Physics mounts for almost 10 years, I am simply amazed at what they can do when you put a top shelf scope on them.  Wow.  The biggest downside is that the data is so good, that my processing skills are well short of taking advantage.

Speaking of processing, the processing of this data was minimal.  After calibration/integration, I spent between 25 and 30 minutes processing the combined channels.  I did not do any noise reduction (except for MureDenoise) and sharpening, since I wanted to show the quality of the data from the system.

The full resolution image and capture details are available at: https://www.astrobin.com/lsn8uv/



Thanks,
-Wade


Re: Quick Release Gearbox Modification for Older 3600GTO?

Christopher Erickson
 

I think releasing the clutches and using a fish scale works pretty well too.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

On Tue, Apr 6, 2021, 9:27 AM Karsten Schindler <karstenschindler@...> wrote:
3600GTO user here. We used to balance our scope by motor current measurements, which seemed a little bit more objective than doing it manually - the remaining friction with all clutches fully open is very large. But one day, when we eventually disengaged the gears to regrease them, it became immediately evident that our balancing was actually not that good as we thought. However, I think the 3600GTO is so beefy that it easily tolerates some imperfect balancing... Disengaging the gears is definitely the way to go for best balancing results but remeshing the gears is pretty tedious. Would very much love to see a quick release gearbox upgrade for the 3600GTO to make balancing a lot easier!

On a side note - the GTOCP4 controller should allow direct motor current measurements internally. Is there a way to read motor current values over the terminal? This could be a nice, free and in-situ tool to help balancing mounts with high friction clutches.

Best,
Karsten


Re: Quick Release Gearbox Modification for Older 3600GTO?

Karsten Schindler
 

3600GTO user here. We used to balance our scope by motor current measurements, which seemed a little bit more objective than doing it manually - the remaining friction with all clutches fully open is very large. But one day, when we eventually disengaged the gears to regrease them, it became immediately evident that our balancing was actually not that good as we thought. However, I think the 3600GTO is so beefy that it easily tolerates some imperfect balancing... Disengaging the gears is definitely the way to go for best balancing results but remeshing the gears is pretty tedious. Would very much love to see a quick release gearbox upgrade for the 3600GTO to make balancing a lot easier!

On a side note - the GTOCP4 controller should allow direct motor current measurements internally. Is there a way to read motor current values over the terminal? This could be a nice, free and in-situ tool to help balancing mounts with high friction clutches.

Best,
Karsten


Re: Setting RA/Dec Limits in a GTOCP4 on a 3600GTOPE?

Ray Gralak
 

Karsten,

You should give A-P a call or email for answers to this question.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Karsten Schindler
Sent: Tuesday, April 6, 2021 12:00 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] Setting RA/Dec Limits in a GTOCP4 on a 3600GTOPE?

Is it possible to define RA and Dec limits on the GTOCP4 controller side to limit the allowable slew range of a
3600GTOPE?

I do not mean horizon and meridian software limits defined in APCC. I also do not mean the Limit Switch System /
ELS on the 3600GTO which provides "hard stops" on the RA axis.

I would like to limit the allowable slew range from the controller side to something that makes sense at our location
in the northern hemisphere, particularly in declination. Due to roll-off roof building constraints, our setup is sitting
pretty low above floor level. Would provide an additional layer of safety.

The PDF help file speaks about "home and limits for non-encoder mounts" and mentions explicetely the 3600GTO,
so I thought it might be possible to define such limits for mounts that have no absolute encoders (ours has a
precision encoder, PE, on the RA axis).

The APCC help file shows a Homing/Limits tab that is not accessible when a 3600GTO is connected. The ELS tab
lists a mechanical position (I assume servo / encoder derived), and allows to establish or go to a home position.
However, I do not see any way to program an RA or Dec limit into the controller.

Thanks for your feedback!

Karsten


Setting RA/Dec Limits in a GTOCP4 on a 3600GTOPE?

Karsten Schindler
 

Is it possible to define RA and Dec limits on the GTOCP4 controller side to limit the allowable slew range of a 3600GTOPE?

I do not mean horizon and meridian software limits defined in APCC. I also do not mean the Limit Switch System / ELS on the 3600GTO which provides "hard stops" on the RA axis.

I would like to limit the allowable slew range from the controller side to something that makes sense at our location in the northern hemisphere, particularly in declination. Due to roll-off roof building constraints, our setup is sitting pretty low above floor level. Would provide an additional layer of safety.

The PDF help file speaks about "home and limits for non-encoder mounts" and mentions explicetely the 3600GTO, so I thought it might be possible to define such limits for mounts that have no absolute encoders (ours has a precision encoder, PE, on the RA axis).

The APCC help file shows a Homing/Limits tab that is not accessible when a 3600GTO is connected. The ELS tab lists a mechanical position (I assume servo / encoder derived), and allows to establish or go to a home position. However, I do not see any way to program an RA or Dec limit into the controller.

Thanks for your feedback!

Karsten


Re: Problem with Mach2 #Mach2GTO #APCC #Absolute_Encoders

David Johnson
 

Talked to Mike.  We’re working on it.

3541 - 3560 of 81139