|
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:
--
|
|
|
|
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
|
|
|
|
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-----
|
|
|
|
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.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.
|
|
|
|
Tony Flores
If ASCOM 6.5 has a problem why is it still on the website. Why not remove it until it is fixed?
|
|
|
|
Ray Gralak
Hi Mike,
toggle quoted messageShow quoted text
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-----
|
|
|
|
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
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-----
|
|
|
|
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-----
|
|
|
|
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:
|
|
|
|
Re: 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.
toggle quoted messageShow quoted text
On Sep 22, 2020, at 9:51 PM, uncarollo2 <chris1011@...> via groups.io <chris1011@...> wrote:
|
|
|
|
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
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.
|
|
|
