Date   

Re: Question about ASTAP plate solve

 

afaik ASTAP (and other solvers) do not have a direct mount interface. you have to use an intermediary piece of software (typically the imaging/control program like maxim, SGP, etc.) to do that. And then the interface is between Maxim and the mount, which is well traveled


On Thu, Sep 24, 2020 at 3:43 PM uncarollo2 <chris1011@...> via groups.io <chris1011=aol.com@groups.io> wrote:
Does anyone know what format ASTAP uses to signify the RA/Dec position of your solved image? Can it send the RA/Dec to the mount via ASCOM format if it is queried by the mount?

Rolando



--
Brian 



Brian Valente


Question about ASTAP plate solve

Roland Christen
 

Does anyone know what format ASTAP uses to signify the RA/Dec position of your solved image? Can it send the RA/Dec to the mount via ASCOM format if it is queried by the mount?

Rolando


locked Re: #APCC APCC/APPM blocking issue with AP1100GTOAE #APCC

Ray Gralak
 

If ASCOM 6.5 has a problem why is it still on the website. Why not remove it until it is fixed?
ASCOM is an independent group. We don't have control of what they put up on their web site. :-)

That said, there is nothing new in 6.5 that is needed for proper operation, so there is no rush (i.e., if it ain't broken!).

When I can test under clear skies I will hopefully track down the problem with 6.5; however, I don't think this is the only issue. I have seen others post problems with some devices under 6.5, so I think it is best to wait a while before updating.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
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 Tony Flores via groups.io
Sent: Thursday, September 24, 2020 11:17 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] #APCC APCC/APPM blocking issue with AP1100GTOAE

If ASCOM 6.5 has a problem why is it still on the website. Why not remove it until it is fixed?


locked Re: #APCC APCC/APPM blocking issue with AP1100GTOAE #APCC

Marcelo Figueroa
 
Edited

On Thu, Sep 24, 2020 at 10:58 AM, Ray Gralak wrote:
APPM does not (yet) directly support ASTAP, but APPM should be able to use any plate solver that SGPro uses.

That said, APPM just uses the generic SGPro plate solver interface. If ASTAP is intermittently failing, it is probably for some reason in SGPro or ASTAP.
Last week I ran a medium modeling using SGP/ASTAP without any problem, everything worked perfectly (ASCOM 6.4).

Edit:

Make sure that in APPM  > Plate Solving Settings  > SGP Pro Plate Solve Settings > Use FITS Header for RA, Dec and Image Scale  is selected.
 

 

 


locked Re: #APCC APCC/APPM blocking issue with AP1100GTOAE #APCC

Tony Flores
 

If ASCOM 6.5 has a problem why is it still on the website. Why not remove it until it is fixed?


locked Re: #APCC APCC/APPM blocking issue with AP1100GTOAE #APCC

Ray Gralak
 

Hi Mike,

APPM does not (yet) directly support ASTAP, but APPM should be able to use any plate solver that SGPro uses.

That said, APPM just uses the generic SGPro plate solver interface. If ASTAP is intermittently failing, it is probably for some reason in SGPro or ASTAP.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
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 Michael 'Mikey' Mangieri
Sent: Thursday, September 24, 2020 8:32 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] #APCC APCC/APPM blocking issue with AP1100GTOAE

Finally got a long string of clear skies. ASCOM 6.4 solved the issue with the errors in APMM. Thanks.
Now I'm having issues with ASTAP - had to revert back to PlateSolve2. After a few successful solves, ASTAP
stops working with a File error message (can't retrieve the file). If I manually close ASTAP and let APMM continue
it works for the next few solves then fails again. Not sure if this is an ASTAP issue or APMM (or for that matter,
SGP) issue.


locked Re: #APCC APCC/APPM blocking issue with AP1100GTOAE #APCC

Michael 'Mikey' Mangieri
 

Finally got a long string of clear skies.  ASCOM 6.4 solved the issue with the errors in APMM. Thanks.  
Now I'm having issues with ASTAP - had to revert back to PlateSolve2.  After a few successful solves, ASTAP stops working with a File error message (can't retrieve the file).  If I manually close ASTAP and let APMM continue it works for the next few solves then fails again.  Not sure if this is an ASTAP issue or APMM (or for that matter, SGP) issue.


Re: Cannot set new meridian delay

Ray Gralak
 

Hi Steve,

 

> But now I can't clear the +2 setting! 

 

Just to be clear, the driver does not accept a "+" before a number. The background of the control will turn blue to indicate wrong input, and the "Set Meridian Delay" button will become disabled. Here is a screenshot of this:

 

 

If the problem is not the “+” sign, it also could be the mount is not responding or a model dialog box is present somewhere that you need to dismiss.

 

-Ray Gralak

Author of PEMPro

Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro

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 Steven Panish

> Sent: Wednesday, September 23, 2020 7:14 PM

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

> Subject: [ap-gto] Cannot set new meridian delay

>

> Hi All,

>

> Using a 1200 with CP3, V2 chip, ASCOM V2 driver 5.30.10 with multiple apps running (SharpCap does the

> initialization, PHD2, Cartes du Ciel, Stellarium).  A couple nights ago I set a +2 meridian delay using the driver

> interface.  The delay works properly.  But now I can't clear the +2 setting!  The button to disable the delay turns it off

> as it should, but I want to enter a different delay and the interface won't take it, the +2 just stays there.  Same

> behavior if the delay is enabled or disabled.  I have not tried to use the handbox to reset it, but I want to be able to

> do it from the driver interface in any case.  I looked (quickly) at the log and to my inexpert eye there was no

> command issued that looked like a time change or meridian delay.

>

> Has anyone seen this behavior and (I hope) made it go away?

>

> thanks,

>

> Steve


Re: Two instances of AP ASCOM driver on same computer

Luca Marinelli
 

Thank you all for the ideas. It sounds like I'll be sticking with two separate computers and will figure out a robust way to pass SkyAlert information from one computer to the other so both imaging systems are using the same safety monitor data.

Best,

Luca


Cannot set new meridian delay

Steven Panish
 

Hi All,

Using a 1200 with CP3, V2 chip, ASCOM V2 driver 5.30.10 with multiple apps running (SharpCap does the initialization, PHD2, Cartes du Ciel, Stellarium).  A couple nights ago I set a +2 meridian delay using the driver interface.  The delay works properly.  But now I can't clear the +2 setting!  The button to disable the delay turns it off as it should, but I want to enter a different delay and the interface won't take it, the +2 just stays there.  Same behavior if the delay is enabled or disabled.  I have not tried to use the handbox to reset it, but I want to be able to do it from the driver interface in any case.  I looked (quickly) at the log and to my inexpert eye there was no command issued that looked like a time change or meridian delay.

Has anyone seen this behavior and (I hope) made it go away?

thanks,

Steve


Re: Two instances of AP ASCOM driver on same computer

Astronut
 

Interesting...
vmWare really does seem to have the best USB support, and it really does work, but, there can be considerable speed degradation in the guest's usb performance, regardless of the host's horsepower and performance. For a mount it won't matter, but with high bandwidth usb3 cameras, you will definately notice a performance difference when imaging with multiple camera's from a virtual machine compared to even a reasonably modest physical pc.

There ARE some really usb 'friendly' features in the more recent versions of vmWorkstation Pro, that allow you to choose a target guest vm when you connect a usb device, and the target guest can be remembered, so that each time the usb device connects, it is automatically passed through to the previously chosen guest for instance.

In fact, in spite of the potential usb performance degradation, there are the other 'standard' virtualization benefits to a vm environment for astro/observatory, such as fast, easy recovery of a virtual pc's operating system and all other installed software that has been carefully tuned and configured that connot be achieved without the equivalent of hard disk cloning. New software can be tested reasonably safely, without the fear of having to redo the os in the event of unforseen issues. 

There is also a 'Unity mode' which could let you configure say, two vm's, one for each mount, for instance, and then effectively have two programs that normally can't run on the same physical machine's desktop, 'appear' to be running in the same single desktop, and actually be running on each seperate virtual machine.

Astronut Tim
(just another vm advocate)


Re: Strange behavior doing center here SGP and APCC/Meridian Zones #APCC

Ray Gralak
 

I've been having a strange problem when using the meridian limits and trying to plate solve on an object.
Are you using a pointing model?

Can you post a screenshot of your meridian limits tab?

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
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 Michael 'Mikey' Mangieri
Sent: Tuesday, September 22, 2020 6:11 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] Strange behavior doing center here SGP and APCC/Meridian Zones #APCC

I've been having a strange problem when using the meridian limits and trying to plate solve on an object. I am using
SGP, Stellarium and Stellarium Scope to pick and goto objects. I have horizon points set and meridian safe zones
set in APCC. I slew to a location in the east. The scope identifies the location as being a safe location and slews
with CW up. So far so good. Now, after taking a frame and focus I see that the object is not centered. To rectify, I
use the SGP 'center here' function (which has always worked for me). When I do, the mount flips the OTA to the
other side of the pier. Once there, it does a plate solve, and when it fails (usually does the first time after a flip) the
scope is flipped again back to the CW up position. This pendulum action continues until I manually stop the mount.
This only happens when my initial starting location is close to a safe zone boundary or near the meridian. I've
successfully been able to start CW up in other cases.


Re: Two instances of AP ASCOM driver on same computer

Ray Gralak
 

Could run a VM for the second instance.
Assuming you plan on using both for imaging, you may or may not be able to do that, as some virtual machines do not support USB
devices, like cameras, very well. VMWare Workstation seems to have the best support for USB devices.

Even so, some manufacturers' drivers may not support two of the same device on the same physical computer, or it may be hard to
distinguish which device is which.

Also, consider that you may need an additional license for APCC and other applications, just as if you had installed on multiple
physical computers.

-Ray Gralak
Author of PEMPro
Author of APCC (Astro-Physics Command Center): https://www.astro-physics.com/apcc-pro
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: Wednesday, September 23, 2020 5:43 AM
To: Luca Marinelli; main@ap-gto.groups.io
Subject: Re: [ap-gto] Two instances of AP ASCOM driver on same computer

Could run a VM for the second instance.

________________________________

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Luca Marinelli <photo@lucamarinelli.com>
Sent: Wednesday, September 23, 2020 5:32 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: [ap-gto] Two instances of AP ASCOM driver on same computer

I have two piers in the observatory with a Mach1GTO and AP 1100GTO mounts. Currently, the two mounts and
respective imaging equipment are connected to two separate computers. One of these computers will need to be
replaced soon and given that the newer one is significantly more powerful I am wondering if it is possible to run both
mounts from the same computer with two separate instances of the AP ASCOM driver and APPC or if this is likely
to end up causing trouble.

Thanks,

Luca


Re: Two instances of AP ASCOM driver on same computer

Bill Long
 

Could run a VM for the second instance.


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Luca Marinelli <photo@...>
Sent: Wednesday, September 23, 2020 5:32 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: [ap-gto] Two instances of AP ASCOM driver on same computer
 
I have two piers in the observatory with a Mach1GTO and AP 1100GTO mounts. Currently, the two mounts and respective imaging equipment are connected to two separate computers. One of these computers will need to be replaced soon and given that the newer one is significantly more powerful I am wondering if it is possible to run both mounts from the same computer with two separate instances of the AP ASCOM driver and APPC or if this is likely to end up causing trouble.  

Thanks,

Luca


Two instances of AP ASCOM driver on same computer

Luca Marinelli
 

I have two piers in the observatory with a Mach1GTO and AP 1100GTO mounts. Currently, the two mounts and respective imaging equipment are connected to two separate computers. One of these computers will need to be replaced soon and given that the newer one is significantly more powerful I am wondering if it is possible to run both mounts from the same computer with two separate instances of the AP ASCOM driver and APPC or if this is likely to end up causing trouble.  

Thanks,

Luca


Re: Olympus Mons with the Mak 10

Worsel
 

Thanks!

Bryan


Re: Strange behavior doing center here SGP and APCC/Meridian Zones #APCC

Roland Christen
 


I believe SGP sends new coordinates. 
Probably. MaximDL does this also and I have been fooled by it more than once.

Realistically, a centering move command should never be done via new coordinates. It prevents doing a proper sync or recal because if you center via coordinate command, the sync will simply use the new coordinates instead of defining the new position as the original object coordinate. Centering can be done quickly at sidereal rate for small distances, after all it moves 15 arc sec per second. If that's not fast enough, 12x or even 64x can be commanded by the external software. Why this is not used in 3rd party software is beyond me.

Rolando


-----Original Message-----
From: Michael 'Mikey' Mangieri <mjmangieri@...>
To: main@ap-gto.groups.io
Sent: Tue, Sep 22, 2020 9:03 pm
Subject: Re: [ap-gto] Strange behavior doing center here SGP and APCC/Meridian Zones #APCC

Thanks for the info. I had concluded myself that this might be the case. I believe SGP sends new coordinates. 


On Sep 22, 2020, at 9:51 PM, uncarollo2 <chris1011@...> via groups.io <chris1011@...> wrote:


There is an interaction between safe zone and slewing within the counterweight up position for centering. It depends how the centering command is done. It can be done two ways, either with a timed move at 1x sidereal or by issuing a new coordinate. If it is done via a timed move, similar to the way guiding software does it, then there is no issue and the mount will move directly to the new position. If it is done via a commanded co-ordinate move, the mount will do a safe slew procedure, which first brings it to a counterweight down position before moving to the new commanded position.

At this time we have no way to distinguish between a commanded goto for centering and one for slewing to a new object. Therefore all commanded moves using coordinate slew methods will cause this back and forth motion, in and out of the safe zone.

Roland Christen



-----Original Message-----
From: Michael 'Mikey' Mangieri <mjmangieri@...>
To: main@ap-gto.groups.io
Sent: Tue, Sep 22, 2020 8:10 pm
Subject: [ap-gto] Strange behavior doing center here SGP and APCC/Meridian Zones #APCC

I've been having a strange problem when using the meridian limits and trying to plate solve on an object. I am using SGP, Stellarium and Stellarium Scope to pick and goto objects. I have horizon points set and meridian safe zones set in APCC.  I slew to a location in the east. The scope identifies the location as being a safe location and slews with CW up.  So far so good.  Now, after taking a frame and focus I see that the object is not centered. To rectify, I use the SGP 'center here' function (which has always worked for me). When I do, the mount flips the OTA to the other side of the pier. Once there, it does a plate solve, and when it fails (usually does the first time after a flip) the scope is flipped again back to the CW up position. This pendulum action continues until I manually stop the mount. This only happens when my initial starting location is close to a safe zone boundary or near the meridian.  I've successfully been able to start CW up in other cases.


Re: Strange behavior doing center here SGP and APCC/Meridian Zones #APCC

Michael 'Mikey' Mangieri
 

Thanks for the info. I had concluded myself that this might be the case. I believe SGP sends new coordinates. 


On Sep 22, 2020, at 9:51 PM, uncarollo2 <chris1011@...> via groups.io <chris1011@...> wrote:


There is an interaction between safe zone and slewing within the counterweight up position for centering. It depends how the centering command is done. It can be done two ways, either with a timed move at 1x sidereal or by issuing a new coordinate. If it is done via a timed move, similar to the way guiding software does it, then there is no issue and the mount will move directly to the new position. If it is done via a commanded co-ordinate move, the mount will do a safe slew procedure, which first brings it to a counterweight down position before moving to the new commanded position.

At this time we have no way to distinguish between a commanded goto for centering and one for slewing to a new object. Therefore all commanded moves using coordinate slew methods will cause this back and forth motion, in and out of the safe zone.

Roland Christen



-----Original Message-----
From: Michael 'Mikey' Mangieri <mjmangieri@...>
To: main@ap-gto.groups.io
Sent: Tue, Sep 22, 2020 8:10 pm
Subject: [ap-gto] Strange behavior doing center here SGP and APCC/Meridian Zones #APCC

I've been having a strange problem when using the meridian limits and trying to plate solve on an object. I am using SGP, Stellarium and Stellarium Scope to pick and goto objects. I have horizon points set and meridian safe zones set in APCC.  I slew to a location in the east. The scope identifies the location as being a safe location and slews with CW up.  So far so good.  Now, after taking a frame and focus I see that the object is not centered. To rectify, I use the SGP 'center here' function (which has always worked for me). When I do, the mount flips the OTA to the other side of the pier. Once there, it does a plate solve, and when it fails (usually does the first time after a flip) the scope is flipped again back to the CW up position. This pendulum action continues until I manually stop the mount. This only happens when my initial starting location is close to a safe zone boundary or near the meridian.  I've successfully been able to start CW up in other cases.


Re: Strange behavior doing center here SGP and APCC/Meridian Zones #APCC

Roland Christen
 

There is an interaction between safe zone and slewing within the counterweight up position for centering. It depends how the centering command is done. It can be done two ways, either with a timed move at 1x sidereal or by issuing a new coordinate. If it is done via a timed move, similar to the way guiding software does it, then there is no issue and the mount will move directly to the new position. If it is done via a commanded co-ordinate move, the mount will do a safe slew procedure, which first brings it to a counterweight down position before moving to the new commanded position.

At this time we have no way to distinguish between a commanded goto for centering and one for slewing to a new object. Therefore all commanded moves using coordinate slew methods will cause this back and forth motion, in and out of the safe zone.

Roland Christen



-----Original Message-----
From: Michael 'Mikey' Mangieri <mjmangieri@...>
To: main@ap-gto.groups.io
Sent: Tue, Sep 22, 2020 8:10 pm
Subject: [ap-gto] Strange behavior doing center here SGP and APCC/Meridian Zones #APCC

I've been having a strange problem when using the meridian limits and trying to plate solve on an object. I am using SGP, Stellarium and Stellarium Scope to pick and goto objects. I have horizon points set and meridian safe zones set in APCC.  I slew to a location in the east. The scope identifies the location as being a safe location and slews with CW up.  So far so good.  Now, after taking a frame and focus I see that the object is not centered. To rectify, I use the SGP 'center here' function (which has always worked for me). When I do, the mount flips the OTA to the other side of the pier. Once there, it does a plate solve, and when it fails (usually does the first time after a flip) the scope is flipped again back to the CW up position. This pendulum action continues until I manually stop the mount. This only happens when my initial starting location is close to a safe zone boundary or near the meridian.  I've successfully been able to start CW up in other cases.


Strange behavior doing center here SGP and APCC/Meridian Zones #APCC

Michael 'Mikey' Mangieri
 

I've been having a strange problem when using the meridian limits and trying to plate solve on an object. I am using SGP, Stellarium and Stellarium Scope to pick and goto objects. I have horizon points set and meridian safe zones set in APCC.  I slew to a location in the east. The scope identifies the location as being a safe location and slews with CW up.  So far so good.  Now, after taking a frame and focus I see that the object is not centered. To rectify, I use the SGP 'center here' function (which has always worked for me). When I do, the mount flips the OTA to the other side of the pier. Once there, it does a plate solve, and when it fails (usually does the first time after a flip) the scope is flipped again back to the CW up position. This pendulum action continues until I manually stop the mount. This only happens when my initial starting location is close to a safe zone boundary or near the meridian.  I've successfully been able to start CW up in other cases.

13041 - 13060 of 86432