Re: Mach2 Unguided testing continues
Roland Christen
It's called APCC Pro. ;^))
Rolando
-----Original Message-----
From: Max Mirot via groups.io <titansmoons@...> To: main@ap-gto.groups.io Sent: Wed, May 27, 2020 6:38 pm Subject: Re: [ap-gto] Mach2 Unguided testing continues This is great Roland.
Can either function be used by outside programs such as SGP and Voyager? I had an ASA mount that had a similar function to method 1. It worked great but was not compatible with other automation packages other than ASA's. I can't wait to try method 2 Max
|
|
Re: Mach2 Unguided testing continues
Worsel
Roland
Encoders are NOT required then...just a CP4 with updated firmware. I recognize this is not yet available. I also recall an earlier thread indicating the APCC Pro would be able to do the same, if a hand controller is not used. Bryan
|
|
Re: APCC Standard v1.8.2.0 and APCC Pro v1.8.2.1
Leon
Anyway, that's my question.. thanks. SO what I usually get hung up is at initial start up, I go to park 2 then turn on the scope, then pull up APCC, then connect, then I go to park screen and try to figure out what to do, So I'm parked now, do I unpark first, of course , then if so what tab, etc.......I'm usually OK when I'm closing up shop and go to park 2 and then park there. then shut down every thing. Any help or short cuts or understanding this a little better I would appreciate. While I defer to A-P and Ray Gralak, I think you may be overworking this. If you have got everything set in Settings-> Edit Initial Mount Settings along with the AP Driver, then you should be able to startup APCC and be ready to slew to a target. When you finish, you can just power down the mount; although I choose to Park 4 due to observatory roof clearance. Bryan
|
|
Re: Mach2 Unguided testing continues
Max Mirot
This is great Roland.
Can either function be used by outside programs such as SGP and Voyager? I had an ASA mount that had a similar function to method 1. It worked great but was not compatible with other automation packages other than ASA's. I can't wait to try method 2 Max
|
|
Re: APCC Standard v1.8.2.0 and APCC Pro v1.8.2.1
Leon Fasano
Thank you as always.
toggle quoted messageShow quoted text
On May 27, 2020, at 5:39 PM, Marj Christen <marj@...> wrote:
|
|
Re: APCC Standard v1.8.2.0 and APCC Pro v1.8.2.1
Ray,
toggle quoted messageShow quoted text
Thank you for all the work you did to prepare this new version and make it available over the holiday weekend in addition to the other tech support that you did. Your efforts are truly appreciated! Clear Skies, Marj Christen Astro-Physics, Inc 11250 Forest Hills Rd Machesney Park, IL 61115 Phone: 815-282-1513 Fax: 815-282-9847 www.astro-physics.com
-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Ray Gralak Sent: Monday, May 25, 2020 6:17 PM To: main@ap-gto.groups.io Subject: [ap-gto] APCC Standard v1.8.2.0 and APCC Pro v1.8.2.1 Hello All, I am announcing the availability of APCC Standard 1.8.2.0 and APCC Pro 1.8.2.1 (links below). Most of the changes are bug fixes and are itemized here: APCC - BUG Fix - Tracking rates were not working correctly for the GTOCP3 in 1.8.1.1. APCC - BUG FIX - Prevent Mach 2 from setting HOME to be anything other than Park 3. APCC - BUG FIX - The ASCOM driver can send values in exponential notation when the value is near zero. APCC was rejecting this exponential notation. APCC - BUG Fix - Commands starting with "G_" were rejected. APCC - BUG Fix - Clear flashing scope view when user clears all errors. APCC - BUG FIX - Settings were not always being correctly saved. APCC - BUG Fix - Prevent possible overflow in Meridian Limits Add Point dialog. APCC - BUG FIX - Horizons - some of the menus did nothing. APCC - BUG FIX - Horizons - Fixed a number of display bugs and made the displayed data more useful. APCC - BUG Fix - fixed an integer overflow error that would happen occasionally. APCC Pro - BUG FIX - APPM - Slew would sometimes fail to appear to complete thus stalling data mapping runs. APCC Pro - BUG Fix - tracking rate correction was not always saved correctly. APCC - Improvement - Moved virtual port handlers to their own threads to reduce latency when user interface elements are updated. APCC - Improvement - In the Meridian Tracking Limits Explorer dialog window, add a button to update Meridian Inclination. APCC Standard 1.8.2.0: http://www.apastrosoftware.com/apcc_download/APCC_Standard_Setup_1.8.2.0.exe APCC Pro 1.8.2.1: http://www.apastrosoftware.com/apcc_download/APCC_Pro_Setup_1.8.2.1.exe APCC Standard PDF: http://www.apastrosoftware.com/apcc_download/apcc-std.pdf APCC Pro PDF: http://www.apastrosoftware.com/apcc_download/apcc-pro.pdf -Ray Gralak Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro Author of PEMPro V3: https://www.ccdware.com Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver
|
|
Re: APCC Standard v1.8.2.0 and APCC Pro v1.8.2.1
Hello Leon,
The website has been updated with the new APCC versions and associated PDF files. Be sure to clear your browser cache if they don’t show up for you.
Clear Skies,
Marj Christen Astro-Physics, Inc 11250 Forest Hills Rd Machesney Park, IL 61115 Phone: 815-282-1513 Fax: 815-282-9847 www.astro-physics.com
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io]
On Behalf Of Leon via groups.io
Sent: Wednesday, May 27, 2020 3:06 PM To: main@ap-gto.groups.io Subject: Re: [ap-gto] APCC Standard v1.8.2.0 and APCC Pro v1.8.2.1
Ray, On Monday, May 25, 2020, 08:35:53 PM CDT, Ray Gralak <groups3@...> wrote:
> Thanks Ray. I dont usually have this problem, but APCC Pro cannot see that an update is available.
|
|
Re: Mach2 Unguided testing continues
Cheng-Yang Tan
I have CP4's on both, so I guess I'm good to go once the firmware update is available. cytan
On Wednesday, May 27, 2020, 03:32:14 PM CDT, uncarollo2 <chris1011@...> via groups.io <chris1011@...> wrote:
The apps require a CP4. That's where the memory space is that is needed for modeling.
Rolando
-----Original Message-----
From: Cheng-Yang Tan via groups.io <cytan299@...> To: main@ap-gto.groups.io <main@ap-gto.groups.io>; main@ap-ug.groups.io <main@ap-ug.groups.io> Sent: Wed, May 27, 2020 3:29 pm Subject: Re: [ap-gto] Mach2 Unguided testing continues Hi Rolando,
Very impressive! I don't have the Mach2 yet ... but I assume the update will also work with my Mach1GTO and AP1100AE?
Looking forward to unmothballing my keypad :)
cytan
On Wednesday, May 27, 2020, 03:15:51 PM CDT, uncarollo2 <chris1011@...> via groups.io <chris1011@...> wrote:
hello Astronuts,
We are getting about 1 day for every 7 when the skies clear enough for me to do final keypad testing. The keypad has two methods of modeling that allows unguided imaging. The first one does a limited pointing model along the path that the image will take during the night. The second method simply measures the drift rate of a star at or near the object to be imaged. This second method is what I did last night. For most applications one needs only to take a short drift measurement of any star in a frame at maybe 2 to 4 points along the path that the image will follow. One point every 1 to 2 hours RA along the path will produce a very accurate model for drift.
Below is a 15 minute UNGUIDED exposure I took
last night with the Mach2 mount, purposely NOT polar aligned, off to the point
where RA and Dec were drifting at 16 arc sec/hr and 88arcsec/hr
respectively. I took a single 5 min drift measurement at the beginning
of the exposure and used that to set the custom tracking rates for the
axes (all done automatically in the keypad). It was good for the next hour of unguided imaging. A second and
third drift measurement was added for 3 more hours, but clouds moved in.
With
a good model the accuracy is better, in my opinion, than guiding with
PHD2 or MaximDL. There is no jumping around, back and forth pushing and
pulling of the axes according to momentary guide star positions and sky
scintillation. It's a smooth motion, very accurate tracking under
precise encoder control. This is with a 160EDF refractor of 1200mm focal
length at .9 arc sec per pixel image scale.
The drift model resides in the mount controller, so actually doesn't need a laptop to store the data. The drift measurement can be done with a consumer digital camera, and then that camera can be used all night to gather images without ever having any guider attached.
Roland
|
|
Re: [ap-ug] Mach2 Unguided testing continues
Pete Lardizabal
Roland, Very interesting and impressive. Something even I could use! 😆 Pete
On May 27, 2020, at 4:15 PM, Roland Christen via groups.io <chris1011@...> wrote:
|
|
Re: Mach2 Unguided testing continues
Roland Christen
The apps require a CP4. That's where the memory space is that is needed for modeling.
Rolando
-----Original Message-----
From: Cheng-Yang Tan via groups.io <cytan299@...> To: main@ap-gto.groups.io <main@ap-gto.groups.io>; main@ap-ug.groups.io <main@ap-ug.groups.io> Sent: Wed, May 27, 2020 3:29 pm Subject: Re: [ap-gto] Mach2 Unguided testing continues Hi Rolando,
Very impressive! I don't have the Mach2 yet ... but I assume the update will also work with my Mach1GTO and AP1100AE?
Looking forward to unmothballing my keypad :)
cytan
On Wednesday, May 27, 2020, 03:15:51 PM CDT, uncarollo2 <chris1011@...> via groups.io <chris1011@...> wrote:
hello Astronuts,
We are getting about 1 day for every 7 when the skies clear enough for me to do final keypad testing. The keypad has two methods of modeling that allows unguided imaging. The first one does a limited pointing model along the path that the image will take during the night. The second method simply measures the drift rate of a star at or near the object to be imaged. This second method is what I did last night. For most applications one needs only to take a short drift measurement of any star in a frame at maybe 2 to 4 points along the path that the image will follow. One point every 1 to 2 hours RA along the path will produce a very accurate model for drift.
Below is a 15 minute UNGUIDED exposure I took
last night with the Mach2 mount, purposely NOT polar aligned, off to the point
where RA and Dec were drifting at 16 arc sec/hr and 88arcsec/hr
respectively. I took a single 5 min drift measurement at the beginning
of the exposure and used that to set the custom tracking rates for the
axes (all done automatically in the keypad). It was good for the next hour of unguided imaging. A second and
third drift measurement was added for 3 more hours, but clouds moved in.
With
a good model the accuracy is better, in my opinion, than guiding with
PHD2 or MaximDL. There is no jumping around, back and forth pushing and
pulling of the axes according to momentary guide star positions and sky
scintillation. It's a smooth motion, very accurate tracking under
precise encoder control. This is with a 160EDF refractor of 1200mm focal
length at .9 arc sec per pixel image scale.
The drift model resides in the mount controller, so actually doesn't need a laptop to store the data. The drift measurement can be done with a consumer digital camera, and then that camera can be used all night to gather images without ever having any guider attached.
Roland
|
|
Re: Mach2 Unguided testing continues
Cheng-Yang Tan
Hi Rolando, Very impressive! I don't have the Mach2 yet ... but I assume the update will also work with my Mach1GTO and AP1100AE? Looking forward to unmothballing my keypad :) cytan
On Wednesday, May 27, 2020, 03:15:51 PM CDT, uncarollo2 <chris1011@...> via groups.io <chris1011@...> wrote:
hello Astronuts,
We are getting about 1 day for every 7 when the skies clear enough for me to do final keypad testing. The keypad has two methods of modeling that allows unguided imaging. The first one does a limited pointing model along the path that the image will take during the night. The second method simply measures the drift rate of a star at or near the object to be imaged. This second method is what I did last night. For most applications one needs only to take a short drift measurement of any star in a frame at maybe 2 to 4 points along the path that the image will follow. One point every 1 to 2 hours RA along the path will produce a very accurate model for drift.
Below is a 15 minute UNGUIDED exposure I took
last night with the Mach2 mount, purposely NOT polar aligned, off to the point
where RA and Dec were drifting at 16 arc sec/hr and 88arcsec/hr
respectively. I took a single 5 min drift measurement at the beginning
of the exposure and used that to set the custom tracking rates for the
axes (all done automatically in the keypad). It was good for the next hour of unguided imaging. A second and
third drift measurement was added for 3 more hours, but clouds moved in.
With
a good model the accuracy is better, in my opinion, than guiding with
PHD2 or MaximDL. There is no jumping around, back and forth pushing and
pulling of the axes according to momentary guide star positions and sky
scintillation. It's a smooth motion, very accurate tracking under
precise encoder control. This is with a 160EDF refractor of 1200mm focal
length at .9 arc sec per pixel image scale.
The drift model resides in the mount controller, so actually doesn't need a laptop to store the data. The drift measurement can be done with a consumer digital camera, and then that camera can be used all night to gather images without ever having any guider attached.
Roland
|
|
Re: Strange behavior between CCDAP/APCC-AP Driver
#APCC
Roland Christen
Park2 is highly safe. We use this position also in our Chile remote observatory at Las Campanas for flat field measuring.
Rolando
-----Original Message-----
From: Jos� Joaqu�n P�rez Guy <cotejardinero@...> To: main@ap-gto.groups.io Sent: Wed, May 27, 2020 3:17 pm Subject: Re: [ap-gto] Strange behavior between CCDAP/APCC-AP Driver #APCC Yes Roland, thank you. So, to sumarize, to be sure for no discrepancies between the apps the safer positions are park 2 or park 3. Eduardo is now working to reinstall the flat panel to fit the telescope in Park2 position :>)
El mié., 27 may. 2020 a las 15:58, uncarollo2 <chris1011@...> via groups.io (<chris1011=aol.com@groups.io>) escribió:
-- José Joaquín Pérez
Rancagua_Chile http://www.astro-austral.cl http://www.eso.org/public/outreach/partnerships/photo-ambassadors.html#perez
|
|
Re: Strange behavior between CCDAP/APCC-AP Driver
#APCC
Jos� Joaqu�n P�rez Guy
Yes Roland, thank you. So, to sumarize, to be sure for no discrepancies between the apps the safer positions are park 2 or park 3. Eduardo is now working to reinstall the flat panel to fit the telescope in Park2 position :>)
El mié., 27 may. 2020 a las 15:58, uncarollo2 <chris1011@...> via groups.io (<chris1011=aol.com@groups.io>) escribió:
-- José Joaquín Pérez Rancagua_Chile http://www.astro-austral.cl http://www.eso.org/public/outreach/partnerships/photo-ambassadors.html#perez
|
|
Mach2 Unguided testing continues
Roland Christen
hello Astronuts,
We are getting about 1 day for every 7 when the skies clear enough for me to do final keypad testing. The keypad has two methods of modeling that allows unguided imaging. The first one does a limited pointing model along the path that the image will take during the night. The second method simply measures the drift rate of a star at or near the object to be imaged. This second method is what I did last night. For most applications one needs only to take a short drift measurement of any star in a frame at maybe 2 to 4 points along the path that the image will follow. One point every 1 to 2 hours RA along the path will produce a very accurate model for drift.
Below is a 15 minute UNGUIDED exposure I took
last night with the Mach2 mount, purposely NOT polar aligned, off to the point
where RA and Dec were drifting at 16 arc sec/hr and 88arcsec/hr
respectively. I took a single 5 min drift measurement at the beginning
of the exposure and used that to set the custom tracking rates for the
axes (all done automatically in the keypad). It was good for the next hour of unguided imaging. A second and
third drift measurement was added for 3 more hours, but clouds moved in.
With
a good model the accuracy is better, in my opinion, than guiding with
PHD2 or MaximDL. There is no jumping around, back and forth pushing and
pulling of the axes according to momentary guide star positions and sky
scintillation. It's a smooth motion, very accurate tracking under
precise encoder control. This is with a 160EDF refractor of 1200mm focal
length at .9 arc sec per pixel image scale.
The drift model resides in the mount controller, so actually doesn't need a laptop to store the data. The drift measurement can be done with a consumer digital camera, and then that camera can be used all night to gather images without ever having any guider attached.
Roland
|
|
Re: APCC Standard v1.8.2.0 and APCC Pro v1.8.2.1
Leon Fasano
Ray, I always watch the threads on all updates. When do you plan to update the website for the 1.8.2.1? Your attached email with the links does not work and I even tried the embedded links in the email and that didn't work. I think the only place I can download is from the Astro-physics website. that works fine. thanks. Also, if you have another moment to answer a very simple question, call it old age or anything else, but when using APCC, and I always get confused right off the bat regarding the tabs that are highlighted for use and the others that are grayed out....which is which? To me its like tornado watch and warning.......reason is I can never simply look and understand which is which and which is available when I am parked or not parked and seems its just not clear enough, don't know if any one has ever commented on this. What about obvious colors to use? Shaded and unshaded just doesn't get me to what i need to see. If they were colorized tabs , if they were Red and green, Red is not available to select, green is, I would know what to use but your tabs are shaded and unshaded, I know, i Know , geez what must one do to satisfy!!!! Anyway, that's my question.. thanks. SO what I usually get hung up is at initial start up, I go to park 2 then turn on the scope, then pull up APCC, then connect, then I go to park screen and try to figure out what to do, So I'm parked now, do I unpark first, of course , then if so what tab, etc.......I'm usually OK when I'm closing up shop and go to park 2 and then park there. then shut down every thing. Any help or short cuts or understanding this a little better I would appreciate. thanks. Leon Fasano
On Monday, May 25, 2020, 08:35:53 PM CDT, Ray Gralak <groups3@...> wrote: > Thanks Ray. I dont usually have this problem, but APCC Pro cannot see that an update is available. The download links are in the post. Some people wanted direct download links and an announcement when the updates are available. This is that! I'll update the download link in a few days. -Ray Gralak Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro Author of PEMPro V3: https://www.ccdware.com Author of Astro-Physics V2 ASCOM Driver: https://www.siriusimaging.com/apdriver > -----Original Message----- > From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Bill Long > Sent: Monday, May 25, 2020 5:41 PM > To: main@ap-gto.groups.io > Subject: Re: [ap-gto] APCC Standard v1.8.2.0 and APCC Pro v1.8.2.1 > > Thanks Ray. I dont usually have this problem, but APCC Pro cannot see that an update is available. > > ________________________________ > > From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak <groups3@...> > Sent: Monday, May 25, 2020 4:17 PM > To: main@ap-gto.groups.io <main@ap-gto.groups.io> > Subject: [ap-gto] APCC Standard v1.8.2.0 and APCC Pro v1.8.2.1 > > Hello All, > > I am announcing the availability of APCC Standard 1.8.2.0 and APCC Pro 1.8.2.1 (links below). > > Most of the changes are bug fixes and are itemized here: > > APCC - BUG Fix - Tracking rates were not working correctly for the GTOCP3 in 1.8.1.1. > > APCC - BUG FIX - Prevent Mach 2 from setting HOME to be anything other than Park 3. > > APCC - BUG FIX - The ASCOM driver can send values in exponential notation when the value is near zero. > APCC was rejecting this exponential notation. > > APCC - BUG Fix - Commands starting with "G_" were rejected. > > APCC - BUG Fix - Clear flashing scope view when user clears all errors. > > APCC - BUG FIX - Settings were not always being correctly saved. > > APCC - BUG Fix - Prevent possible overflow in Meridian Limits Add Point dialog. > > APCC - BUG FIX - Horizons - some of the menus did nothing. > > APCC - BUG FIX - Horizons - Fixed a number of display bugs and made the displayed data more useful. > > APCC - BUG Fix - fixed an integer overflow error that would happen occasionally. > > APCC Pro - BUG FIX - APPM - Slew would sometimes fail to appear to complete thus stalling data mapping > runs. > > APCC Pro - BUG Fix - tracking rate correction was not always saved correctly. > > APCC - Improvement - Moved virtual port handlers to their own threads to reduce latency when user interface > elements are updated. > > APCC - Improvement - In the Meridian Tracking Limits Explorer dialog window, add a button to update Meridian > Inclination. > > APCC Standard 1.8.2.0: > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apastrosoftware.com%2Fapcc_dow > nload%2FAPCC_Standard_Setup_1.8.2.0.exe&data=02%7C01%7C%7Cd3819656ab894ec5dd6c08d801 > 01be39%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637260454274942528&sdata=iRQL4P > Sfuk5q6ObBb7VLFU4H7Nuap3q3Q5xQjGhqzig%3D&reserved=0 > > APCC Pro 1.8.2.1: > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apastrosoftware.com%2Fapcc_dow > nload%2FAPCC_Pro_Setup_1.8.2.1.exe&data=02%7C01%7C%7Cd3819656ab894ec5dd6c08d80101be3 > 9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637260454274942528&sdata=ZFZA40sAdw > Ll0P3IIh2MduVrjLQeX%2F2%2FHeSEpFg7KyA%3D&reserved=0 > > APCC Standard PDF: > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apastrosoftware.com%2Fapcc_dow > nload%2Fapcc- > std.pdf&data=02%7C01%7C%7Cd3819656ab894ec5dd6c08d80101be39%7C84df9e7fe9f640afb435aaaa > aaaaaaaa%7C1%7C0%7C637260454274942528&sdata=YF3Oh6Ce%2Fh%2BwCQEe%2FUPZTKBhSgqj > uwlXCg6u9yMLOgM%3D&reserved=0 > > APCC Pro PDF: > https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apastrosoftware.com%2Fapcc_dow > nload%2Fapcc- > pro.pdf&data=02%7C01%7C%7Cd3819656ab894ec5dd6c08d80101be39%7C84df9e7fe9f640afb435aaaa > aaaaaaaa%7C1%7C0%7C637260454274942528&sdata=tFNKJyAPRawNeKLpibPWGR5EyCzJTaFYgG0 > VDkpEhNM%3D&reserved=0 > > -Ray Gralak > Author of APCC (Astro-Physics Command Center): > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.astro-physics.com%2Fapcc- > pro&data=02%7C01%7C%7Cd3819656ab894ec5dd6c08d80101be39%7C84df9e7fe9f640afb435aaaaaaa > aaaaa%7C1%7C0%7C637260454274942528&sdata=F6gvmHzFDNP%2BJAD%2B8jExUIswhl7kgBzojcS > M5WNKNIg%3D&reserved=0 > <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.astro-physics.com%2Fapcc- > pro&data=02%7C01%7C%7Cd3819656ab894ec5dd6c08d80101be39%7C84df9e7fe9f640afb435aaaaaaa > aaaaa%7C1%7C0%7C637260454274942528&sdata=F6gvmHzFDNP%2BJAD%2B8jExUIswhl7kgBzojcS > M5WNKNIg%3D&reserved=0> > Author of PEMPro V3: > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ccdware.com%2F&data=02% > 7C01%7C%7Cd3819656ab894ec5dd6c08d80101be39%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0 > %7C637260454274942528&sdata=58JmvmgtI3AsOGZrHjVqlbPyCxtFOIJJuIIApGt4EvY%3D&reserv > ed=0 > <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ccdware.com%2F&data=02 > %7C01%7C%7Cd3819656ab894ec5dd6c08d80101be39%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C > 0%7C637260454274942528&sdata=58JmvmgtI3AsOGZrHjVqlbPyCxtFOIJJuIIApGt4EvY%3D&reser > ved=0> > Author of Astro-Physics V2 ASCOM Driver: > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.siriusimaging.com%2Fapdriver&a > mp;data=02%7C01%7C%7Cd3819656ab894ec5dd6c08d80101be39%7C84df9e7fe9f640afb435aaaaaaaaaaa > a%7C1%7C0%7C637260454274952514&sdata=UWVzbzixhnJx7qAJrgP81PLJBLkl6dE%2B1oN4YO99uy > E%3D&reserved=0 > <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.siriusimaging.com%2Fapdriver& > amp;data=02%7C01%7C%7Cd3819656ab894ec5dd6c08d80101be39%7C84df9e7fe9f640afb435aaaaaaaaaa > aa%7C1%7C0%7C637260454274952514&sdata=UWVzbzixhnJx7qAJrgP81PLJBLkl6dE%2B1oN4YO99u > yE%3D&reserved=0> > > > > > >
|
|
Re: Strange behavior between CCDAP/APCC-AP Driver
#APCC
Roland Christen
Unparking has nothing to do with sending the scope to the wrong side. Parking with slight time discrepancies between 3rd party apps cause the scope to be either on the east or west side.
Did you read my explanation in my previous post?
Rolando
-----Original Message-----
From: Jos� Joaqu�n P�rez Guy <cotejardinero@...> To: main@ap-gto.groups.io Sent: Wed, May 27, 2020 2:47 pm Subject: Re: [ap-gto] Strange behavior between CCDAP/APCC-AP Driver #APCC That's correct, George. Unparking from.last park position
El mié., 27 de mayo de 2020 15:14, George <george@...> escribió:
|
|
Re: Strange behavior between CCDAP/APCC-AP Driver
#APCC
Jos� Joaqu�n P�rez Guy
That's correct, George. Unparking from.last park position
El mié., 27 de mayo de 2020 15:14, George <george@...> escribió:
|
|
Re: USB / Serial and WIFI connection
#Mach2GTO
Thanks George and Rolando,
All software connections work well via virtual ports since I did the modeling and I use a mapping software without worries. What happens is when I turn on the mount and it is not connected to the PC in USB / Serie, the WIFI network GTOGP5_Net_25 is active and appears in the list of networks on my smartphone (and on the PC ), but when I connect the mount to the PC, the GTOCP5_NET_25 network disappears.Perhaps there is a parameter to modify on the GTOCP5 by the Ethernet or WIFI connection if it is not connected to the PC?
|
|
Re: Strange behavior between CCDAP/APCC-AP Driver
#APCC
George
Jose,
And are you unparking from Last Parked (not Park 1)?
Regards,
George
George Whitney Astro-Physics, Inc. Phone: 815-282-1513 Email: george@...
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io]
On Behalf Of Jos? Joaqu?n P?rez Guy
Sent: Wednesday, May 27, 2020 1:24 PM To: main@ap-gto.groups.io Subject: Re: [ap-gto] Strange behaviour between CCDAP/APCC-AP Driver #APCC
Both, APCC and the driver has set the same position : Park 1
El mié., 27 de mayo de 2020 14:21, Ray Gralak <groups3@...> escribió:
|
|
Re: Strange behaviour between CCDAP/APCC-AP Driver
#APCC
Roland Christen
Park 1 is determined by time. It is set to approximately 5 hours 59 minutes 50 seconds past the meridian point. If the time in your CCDAP program is slightly different by 11 seconds or more, it will send the mount to 6hrs 00min 01 seconds past the meridian, which will of course set the scope on the east side of the pier.
Park1 is a problem because it is set at very nearly the flip point of the mount. So, if there is a slight time discrepancy between two applications, the mount may park the scope on the other side. Both positions are valid because both point the scope at the Northern/Southern horizon.
Park 2 and Park3 avoid this because both of those are 6 hours from the flip point. Park4 and 5 are also vulnerable to slight time discrepancies between various external apps. In order to be accurate, all apps used on the mount must have exactly the same time, down to 1 second.
Rolando
-----Original Message-----
From: Jos� Joaqu�n P�rez Guy <cotejardinero@...> To: main@ap-gto.groups.io Sent: Wed, May 27, 2020 1:24 pm Subject: Re: [ap-gto] Strange behaviour between CCDAP/APCC-AP Driver #APCC Both, APCC and the driver has set the same position : Park 1
El mié., 27 de mayo de 2020 14:21, Ray Gralak <groups3@...> escribió:
I am not sure if this is the problem but CCDAP uses the ASCOM driver to park the mount so the ASCOM driver's park position will be used, not the park position set in APCC.
|
|