Date   

Re: DEC delay in reversal

Suresh Mohan
 

I just now re meshed the dec gear box . Let me test in the evening 
Suresh


On 04-Mar-2018, at 9:35 AM, Suresh Mohan Neelmegh <drsureshmohan@...> wrote:

On Phd with this gear box for backlash I got a message saying I should guide only in one direction ; while calibrating it goes north quite easily and does not move south for the guiding speed at 1 x I think 
Suresh 


On 04-Mar-2018, at 9:30 AM, Suresh Mohan Neelmegh <drsureshmohan@...> wrote:

Matthew ,
       I doubt a collision would do anything ; mine is the worst as I travel often Indi China border , im sure though its extremely well packed , the boxes are thrown from 2-3 feet ( maybe I’m exaggerating  ) by cargo people .
           Roland I tightened the worm shaft bearing retention screw ; still the same problem . Two nights ago I swapped the gear boxes as I found the original DEC worm give a better RAW  PE ; i noticed that RA gear box flat spring that holds the two adjustment screws having less tension as compared to DEC .
              I think I should go back ?
Suresh 


On 04-Mar-2018, at 8:19 AM, Matthew Hughes matthughes77@... [ap-gto] <ap-gto@...> wrote:

 

Hi Andy,

Yes you did not say that. My bad. Just has the collision and put two and two together without proper analysis.

Matt

On 4 Mar 2018, at 13:17, Andy Galasso andy.galasso@... [ap-gto] <ap-gto@...> wrote:

 

>> Matt wrote:
>> Andy from PHD says that it is a delayed reaction from the DEC axis then overcorrecting.

Matt, sorry for the apparent misunderstanding but I did not say that! Based on what you showed me I don't even think you can definitively say the guiding problem is caused by the mount until you run some experiments to rule out various things, like for example a problem with the camera driver buffering frames. I have seen cases where a faulty camera driver buffered data and that resulted in oscillation in guiding.

Andy


Re: PemPro Polar Alignment differs East to West

Suresh Mohan
 

To overcome this problem i use a star at 45 degrees or slightly above as I live on a hot sea coast where atmosphere sizzles . It might take a little longer but it gets accurate ( however I use a refractor )


On 04-Mar-2018, at 2:01 AM, 'Joseph Zeglinski' J.Zeglinski@... [ap-gto] <ap-gto@...> wrote:

 

Hi Rolando,
 
    I too have seen that PemPro curve results discrepancy on runs east vs. west side of the mount.
I REALLY like your explanation, on the cause – even if the results might sometimes be slight. They could be further exaggerating with poor seeing, besides the atmospheric component adding to the discrepancy.
 
    Yes - if you run PemPro with the “standard” setting of 5 minutes  (deg ?) looking toward the east of PM, the OTA is “rising” and the atmospheric refraction is “actually improving”, all during the hour long RAW data sampling.
 
    On the flip side, running with exactly the same PemPro meridian target offset, the atmospheric refraction  can ONLY  “degrade” steadily for the entire western sky target  run.
 
    So, you have the worst of both situations. You can either trust the optimum raw data when PemPro runs from the west side of the pier on eastern targets, or the twice as bad situation with “STEADILY declining”  target Altitude ... when running with the scope on the east side (looking west).
 
    I brought this up, on this Group probably more than a couple of years ago, suggesting that PemPro could be run twice, and the two raw data curves averaged – or their samples interleaved – to come to some averaged curve result. Requires some further thinking, whether the results “should be weighted” more toward eastern targets, Something for Ray to consider, based on your premise.
 
    Anyway, Rolando, thanks for this explanation of what has been frustrating me about my own PemPro results ... for a VERY long time. Unfortunately, in the short term, we just have to live with this minor discrepancy.
 
Joe


Re: DEC delay in reversal

Suresh Mohan
 

On Phd with this gear box for backlash I got a message saying I should guide only in one direction ; while calibrating it goes north quite easily and does not move south for the guiding speed at 1 x I think 
Suresh 


On 04-Mar-2018, at 9:30 AM, Suresh Mohan Neelmegh <drsureshmohan@...> wrote:

Matthew ,
       I doubt a collision would do anything ; mine is the worst as I travel often Indi China border , im sure though its extremely well packed , the boxes are thrown from 2-3 feet ( maybe I’m exaggerating  ) by cargo people .
           Roland I tightened the worm shaft bearing retention screw ; still the same problem . Two nights ago I swapped the gear boxes as I found the original DEC worm give a better RAW  PE ; i noticed that RA gear box flat spring that holds the two adjustment screws having less tension as compared to DEC .
              I think I should go back ?
Suresh 


On 04-Mar-2018, at 8:19 AM, Matthew Hughes matthughes77@... [ap-gto] <ap-gto@...> wrote:

 

Hi Andy,

Yes you did not say that. My bad. Just has the collision and put two and two together without proper analysis.

Matt

On 4 Mar 2018, at 13:17, Andy Galasso andy.galasso@... [ap-gto] <ap-gto@...> wrote:

 

>> Matt wrote:
>> Andy from PHD says that it is a delayed reaction from the DEC axis then overcorrecting.

Matt, sorry for the apparent misunderstanding but I did not say that! Based on what you showed me I don't even think you can definitively say the guiding problem is caused by the mount until you run some experiments to rule out various things, like for example a problem with the camera driver buffering frames. I have seen cases where a faulty camera driver buffered data and that resulted in oscillation in guiding.

Andy


Re: DEC delay in reversal

Suresh Mohan
 

Matthew ,
       I doubt a collision would do anything ; mine is the worst as I travel often Indi China border , im sure though its extremely well packed , the boxes are thrown from 2-3 feet ( maybe I’m exaggerating  ) by cargo people .
           Roland I tightened the worm shaft bearing retention screw ; still the same problem . Two nights ago I swapped the gear boxes as I found the original DEC worm give a better RAW  PE ; i noticed that RA gear box flat spring that holds the two adjustment screws having less tension as compared to DEC .
              I think I should go back ?
Suresh 


On 04-Mar-2018, at 8:19 AM, Matthew Hughes matthughes77@... [ap-gto] <ap-gto@...> wrote:

 

Hi Andy,

Yes you did not say that. My bad. Just has the collision and put two and two together without proper analysis.

Matt

On 4 Mar 2018, at 13:17, Andy Galasso andy.galasso@... [ap-gto] <ap-gto@...> wrote:

 

>> Matt wrote:
>> Andy from PHD says that it is a delayed reaction from the DEC axis then overcorrecting.

Matt, sorry for the apparent misunderstanding but I did not say that! Based on what you showed me I don't even think you can definitively say the guiding problem is caused by the mount until you run some experiments to rule out various things, like for example a problem with the camera driver buffering frames. I have seen cases where a faulty camera driver buffered data and that resulted in oscillation in guiding.

Andy


Re: DEC delay in reversal

Matthew Hughes
 

Hi Andy,
Yes you did not say that. My bad. Just has the collision and put two and two together without proper analysis.

Matt

On 4 Mar 2018, at 13:17, Andy Galasso andy.galasso@... [ap-gto] <ap-gto@...> wrote:

 

>> Matt wrote:
>> Andy from PHD says that it is a delayed reaction from the DEC axis then overcorrecting.

Matt, sorry for the apparent misunderstanding but I did not say that! Based on what you showed me I don't even think you can definitively say the guiding problem is caused by the mount until you run some experiments to rule out various things, like for example a problem with the camera driver buffering frames. I have seen cases where a faulty camera driver buffered data and that resulted in oscillation in guiding.

Andy


Re: DEC delay in reversal

Andy Galasso
 

>> Matt wrote:
>> Andy from PHD says that it is a delayed reaction from the DEC axis then overcorrecting.

Matt, sorry for the apparent misunderstanding but I did not say that! Based on what you showed me I don't even think you can definitively say the guiding problem is caused by the mount until you run some experiments to rule out various things, like for example a problem with the camera driver buffering frames. I have seen cases where a faulty camera driver buffered data and that resulted in oscillation in guiding.

Andy


Re: DEC delay in reversal

Matthew Hughes
 


Hi Rolando,

I have the same issue, I think. Last night I had an abrupt pier collision. I wont go into too much detail but is was my fault.
Anyway consequently my guiding in DEC looks like this:


https://groups.yahoo.com/neo/groups/ap-gto/files/Dec%20guiding%20issue/


Andy from PHD says that it is a delayed reaction from the DEC axis then overcorrecting. It starts off ok for about 5 or 6 samples then does this repeatable pattern.
I think its from the collision because guiding was fine before hand.

Also in the same folder there is a picture of the small round access hole I think you were talking about?
How do I get a wrench in there? Do I need a tools to get into the two small holes as a way to adjust the retaining nut?

Some help would be appreciated.

I hope I haven't done too much damage. RA axis looks fine.

Blue encoder lights are still on.


Any other fault finding tips would be appreciated.


Yours in "stress"


Matt



Re: APPM and Pinpoint

W Hilmo
 

I have the image scale set correctly in the settings in APPM. When the dialog comes up with the Solve button, it correctly says 1.62 on my screen. I was very careful to make sure that all of the settings were correct.



That said, there is something strange going on. I switched APPM to use TheSkyX for solving and it solved all of my test images very quickly (never more than 5 seconds). When I switched back to Pinpoint, APPM was able to solve it through Pinpoint, and it still can and I can’t reproduce the failure anymore.



I have no idea what changed, but now it works fine. I even switched to some images with a very different image scale and it solves those fine (with the appropriate changes to sigma and max magnitude).



Thanks for taking a look, though. My feature request, if possible, would be to get APPM’s test image link to log the same kinds of details that Visual Pinpoint does (I assume that Visual Pinpoint is using the same API to the solving engine that is available to APPM). In particular, reporting the number of stars detected and the number of catalog stars would be useful, since those are the main settings that you would adjust for a given scope/camera combination.



Thanks again,

-Wade



From: ap-gto@... [mailto:ap-gto@...]
Sent: Saturday, March 3, 2018 3:40 PM
To: ap-gto@...
Subject: RE: [ap-gto] APPM and Pinpoint





Wade,

That is very odd as APPM plate solved almost instantly. I'll send you a screen shot. (BTW, there is a typo in the
above link -- an extra period before ".fit")
The problem may be that the image scale is set wrong in APPM. The image doesn't appear to have an image scale value so APPM will use whatever value was set in APPM. If that image scale is not within the tolerance the plate solve won't work.

(BTW, the plate scale is about 1.62 arc-sec/pixel for your image).

Best regards,

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma

-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...]
Sent: Saturday, March 3, 2018 2:43 PM
To: ap-gto@...
Subject: RE: [ap-gto] APPM and Pinpoint



Wade,

https://www.faintfuzzy.net/2018/cone-1x1800-ha..fit.
That is very odd as APPM plate solved almost instantly. I'll send you a screen shot. (BTW, there is a typo in the
above link -- an extra period before ".fit")

Best regard,

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma

-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...]
Sent: Saturday, March 3, 2018 11:13 AM
To: ap-gto@...
Subject: RE: [ap-gto] APPM and Pinpoint



I looked at the APPM log file, and it doesn’t have any additional information as to what happened with the plate
solve.
Actually, it considers the solve successful, which it was not (unless success is defined as “done”). Here is an
excerpt:

---------------

0000034 2018-03-03 09:06:18.360: Info, PinPoint Test Solve, File = C:&#92;Users&#92;wadeh&#92;Desktop&#92;Cone-1x1800-Ha.fit

0000035 2018-03-03 09:06:18.360: Info, PinPoint Test Solve, RA/Dec = 6.66811666666667 / 9.64386944444444

0000036 2018-03-03 09:06:18.360: Info, PinPoint Test Solve, Use FITS for Hints = True, X/Y Scale = 1.62 / 1.62

0000037 2018-03-03 09:06:18.360: Info, PinPoint Test Solve, AllSky = False

0000038 2018-03-03 09:06:18.360: Info, PinPoint Test Solve, Timeout = 120

0000039 2018-03-03 09:08:27.650: Info, PinPoint Test Solve, Solve Successful

0000040 2018-03-03 09:08:31.421: Exception, Plate Solving, User Clicked Cancel or Close

---------------

Regarding a sample image, I don’t have a Dropbox account, but you can download a FITS file from
https://www.faintfuzzy.net/2018/cone-1x1800-ha..fit. This is a wide field setup, so there are lots of stars. To solve
it
efficiently in Visual Pinpoint with USNO A2.0, I am using Min sigma of 8 and Max magnitude of 10. This one took
22
seconds when I tried it right now.. My 2x2 binned images off the same system take about 5 or 6 seconds. Here is
the
output from Visual Pinpoint for this image and the above settings:

---------------

Plate-solve run at 3/3/2018 11:07:45 AM

Use File/Save As to save this file

&#92;&#92;xxx&#92;Cone-1x1800-Ha.fit:

3751 image stars found.

(doing spiral search...)

172 catalog stars found.

Solved using 50 of max 500, RMS residual is 0.50 arcsec, order =4

Solution took 22.8 seconds

Centerpoint RA = 06h 41m 03.766s Dec = 09° 37' 25.91"

Pointing error 0.3 arc minutes

WCS: Roll = -0.48 HScale = -1.622 VScale = -1.623

PA = 0.485°

FWHM = 6.39 arcsec

ZeroPoint = 16.44 (1 sec.)

---------------

Thanks,

-Wade

From: ap-gto@... [mailto:ap-gto@...]
Sent: Saturday, March 3, 2018 10:38 AM
To: ap-gto@...
Subject: RE: [ap-gto] APPM and Pinpoint

Is there any way to get either a more complete error message, or enable logging to get more details as to the
progress of the attempt?

Yes, you can look at the APPM log file.

-Ray Gralak

Author of APCC (Astro-Physics Command Center): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc

Author of PEMPro: <http://www.ccdware.com/> http://www.ccdware.com

Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver

Author of PulseGuide: http://www.pulseguide.com <http://www.pulseguide.com/>

Author of Sigma: http://www..gralak.com/sigma <http://www.gralak.com/sigma>

From: ap-gto@... [mailto:ap-gto@...]
Sent: Saturday, March 3, 2018 9:49 AM
To: ap-gto@...
Subject: [ap-gto] APPM and Pinpoint

I am using APCC Pro (version 1.6.0.3) and have been using Pinpoint v6 as the plate solver for APPM. This has
been
working reasonably well for me with the GSC 1.1 catalog. Still, I do get some occasional plate solve failures,
perhaps
about 5% of the time. I have had it on my "to do" list for a while to switch to the USNO A2.0 catalog, and today is
the
day that I'm playing with it.

The problem that I am having is that APPM's Image Link Test fails all attempts at solving with this catalog.

Prior to testing with APPM, I worked with Visual Pinpoint to verify that the catalog works correctly. It is able to
solve
my test images in about 5 to 6 seconds. To get it working efficiently, I needed to tune the Min Sigma and Max
Magnitude settings in Visual Pinpoint.

< p>I have matched these settings in the Sigma Above Mean and Catalog Max Mag settings in APPM. I have also
verified that the coordinates and image scale from the FITS headers are correct when Image Link Test reports
them.

The issue is that Image Link Test times out nearly 100% of the time on my test images. I bumped the Max Solve
Time
up to 120 seconds and it still times out. I have seen a couple of tests fail at about the 90 second point with an
error that
no stars were matched.

Is there any way to get either a more complete error message, or enable logging to get more details as to the
progress
of the attempt? In particular, Visual Pinpoint reports the number of image stars detected and the number of
catalog
stars found on both failed and successful solves. This would be very valuable information in troubleshooting this.

I'm also open to any other suggestions.

Thanks,

-Wade

[Non-text portions of this message have been removed]









[Non-text portions of this message have been removed]


Re: APPM and Pinpoint

Ray Gralak
 

Wade,

That is very odd as APPM plate solved almost instantly. I'll send you a screen shot. (BTW, there is a typo in the
above link -- an extra period before ".fit")
The problem may be that the image scale is set wrong in APPM. The image doesn't appear to have an image scale value so APPM will use whatever value was set in APPM. If that image scale is not within the tolerance the plate solve won't work.

(BTW, the plate scale is about 1.62 arc-sec/pixel for your image).

Best regards,

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma


-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...]
Sent: Saturday, March 3, 2018 2:43 PM
To: ap-gto@...
Subject: RE: [ap-gto] APPM and Pinpoint



Wade,

https://www.faintfuzzy.net/2018/cone-1x1800-ha..fit.
That is very odd as APPM plate solved almost instantly. I'll send you a screen shot. (BTW, there is a typo in the
above link -- an extra period before ".fit")

Best regard,

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma

-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...]
Sent: Saturday, March 3, 2018 11:13 AM
To: ap-gto@...
Subject: RE: [ap-gto] APPM and Pinpoint



I looked at the APPM log file, and it doesn’t have any additional information as to what happened with the plate
solve.
Actually, it considers the solve successful, which it was not (unless success is defined as “done”). Here is an
excerpt:

---------------

0000034 2018-03-03 09:06:18.360: Info, PinPoint Test Solve, File = C:&#92;Users&#92;wadeh&#92;Desktop&#92;Cone-1x1800-Ha.fit

0000035 2018-03-03 09:06:18.360: Info, PinPoint Test Solve, RA/Dec = 6.66811666666667 / 9.64386944444444

0000036 2018-03-03 09:06:18.360: Info, PinPoint Test Solve, Use FITS for Hints = True, X/Y Scale = 1.62 / 1.62

0000037 2018-03-03 09:06:18.360: Info, PinPoint Test Solve, AllSky = False

0000038 2018-03-03 09:06:18.360: Info, PinPoint Test Solve, Timeout = 120

0000039 2018-03-03 09:08:27.650: Info, PinPoint Test Solve, Solve Successful

0000040 2018-03-03 09:08:31.421: Exception, Plate Solving, User Clicked Cancel or Close

---------------

Regarding a sample image, I don’t have a Dropbox account, but you can download a FITS file from
https://www.faintfuzzy.net/2018/cone-1x1800-ha..fit. This is a wide field setup, so there are lots of stars. To solve
it
efficiently in Visual Pinpoint with USNO A2.0, I am using Min sigma of 8 and Max magnitude of 10. This one took
22
seconds when I tried it right now.. My 2x2 binned images off the same system take about 5 or 6 seconds. Here is
the
output from Visual Pinpoint for this image and the above settings:

---------------

Plate-solve run at 3/3/2018 11:07:45 AM

Use File/Save As to save this file

&#92;&#92;xxx&#92;Cone-1x1800-Ha.fit:

3751 image stars found.

(doing spiral search...)

172 catalog stars found.

Solved using 50 of max 500, RMS residual is 0.50 arcsec, order =4

Solution took 22.8 seconds

Centerpoint RA = 06h 41m 03.766s Dec = 09° 37' 25.91"

Pointing error 0.3 arc minutes

WCS: Roll = -0.48 HScale = -1.622 VScale = -1.623

PA = 0.485°

FWHM = 6.39 arcsec

ZeroPoint = 16.44 (1 sec.)

---------------

Thanks,

-Wade

From: ap-gto@... [mailto:ap-gto@...]
Sent: Saturday, March 3, 2018 10:38 AM
To: ap-gto@...
Subject: RE: [ap-gto] APPM and Pinpoint

Is there any way to get either a more complete error message, or enable logging to get more details as to the
progress of the attempt?

Yes, you can look at the APPM log file.

-Ray Gralak

Author of APCC (Astro-Physics Command Center): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc

Author of PEMPro: <http://www.ccdware.com/> http://www.ccdware.com

Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver

Author of PulseGuide: http://www.pulseguide.com <http://www.pulseguide.com/>

Author of Sigma: http://www..gralak.com/sigma <http://www.gralak.com/sigma>

From: ap-gto@... [mailto:ap-gto@...]
Sent: Saturday, March 3, 2018 9:49 AM
To: ap-gto@...
Subject: [ap-gto] APPM and Pinpoint

I am using APCC Pro (version 1.6.0.3) and have been using Pinpoint v6 as the plate solver for APPM. This has
been
working reasonably well for me with the GSC 1.1 catalog. Still, I do get some occasional plate solve failures,
perhaps
about 5% of the time. I have had it on my "to do" list for a while to switch to the USNO A2.0 catalog, and today is
the
day that I'm playing with it.

The problem that I am having is that APPM's Image Link Test fails all attempts at solving with this catalog.

Prior to testing with APPM, I worked with Visual Pinpoint to verify that the catalog works correctly. It is able to
solve
my test images in about 5 to 6 seconds. To get it working efficiently, I needed to tune the Min Sigma and Max
Magnitude settings in Visual Pinpoint.

< p>I have matched these settings in the Sigma Above Mean and Catalog Max Mag settings in APPM. I have also
verified that the coordinates and image scale from the FITS headers are correct when Image Link Test reports
them.

The issue is that Image Link Test times out nearly 100% of the time on my test images. I bumped the Max Solve
Time
up to 120 seconds and it still times out. I have seen a couple of tests fail at about the 90 second point with an
error that
no stars were matched.

Is there any way to get either a more complete error message, or enable logging to get more details as to the
progress
of the attempt? In particular, Visual Pinpoint reports the number of image stars detected and the number of
catalog
stars found on both failed and successful solves. This would be very valuable information in troubleshooting this.

I'm also open to any other suggestions.

Thanks,

-Wade

[Non-text portions of this message have been removed]






Re: PemPro Polar Alignment differs East to West

Ray Gralak
 

Ray, why we are on the topic of PEMPro, I wanted to mention another issue I had last night. I kept getting an error last
night when running step 3 of the Polar Alignment Wizard. Frustratingly it was always while taking the 3rd image in the
series. The error message was "Error creating bitmap Min/Max 729/419. Parameter is not valid."

Any idea what might be causing this error? I got it both when my ATIK 16200 was connected via ASCOM directly to
PEMPro and when connected via SGPro. I have never seen this error before when using SGP by itself. The only thing
that seemed to allow me to get past it was to shut everything down, reboot, and then try and run it again.
I think you should check that the .Net Framework 4.x is up to date. That error can only happen when creating a normal 32-bit Bitmap in the .Net Framework.

Also make sure you have binning set to 1 on step 2 just in case a binned image might be causing a problem.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma


-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...]
Sent: Saturday, March 3, 2018 2:05 PM
To: ap-gto@...
Subject: [ap-gto] Re: PemPro Polar Alignment differs East to West



Ray, why we are on the topic of PEMPro, I wanted to mention another issue I had last night. I kept getting an error last
night when running step 3 of the Polar Alignment Wizard. Frustratingly it was always while taking the 3rd image in the
series. The error message was "Error creating bitmap Min/Max 729/419. Parameter is not valid."

Any idea what might be causing this error? I got it both when my ATIK 16200 was connected via ASCOM directly to
PEMPro and when connected via SGPro. I have never seen this error before when using SGP by itself. The only thing
that seemed to allow me to get past it was to shut everything down, reboot, and then try and run it again.

If you need me to send you the log files or anything else to help investigate let me know.

Thanks for your never wavering support.

Andrew J


Re: PemPro Polar Alignment differs East to West

Joe Zeglinski
 

Andrew,
 
    I don’t think it matters which pier side you start from.
As it is written now, PemPro does a continuous run, with no way of splitting it into two parts, so that we could do a half on each side, and merge the two sample files together to make say, a total 6 cycle file of raw data.
   
    Ideally, the span of cycles should be equal on both sides, since when you are finally CCD imaging, the BEST photos result from a “span” of exposures, taken either side of  the PM. You would be taking your Blue exposures before the prime meridian, and the Red ones after, where the blue in the sky diffusion tails off in the denser air. Thus, the best imaging is achieved through “planning exposures”,  that span the PM.
 
    Would be nice if the PEC curve an average matching both sides, as well. Then,  your curve accounts not only for the somewhat stochastic pattern from the small spur gears inside the gearbox, it also includes a span of the worm and worm wheel contact irregularities,  in the collected curve. End result is that it would account for  more than just the gearbox effect, in the generated PEC curve.
 
    However, another problem would arise if I were to do a PemPro run, “right through” the meridian.
If the scope is “TOO perfectly” balanced, there may be some very minor worm tooth “gear play” during the transition ...  causing a slight lag as the mount passes PM. Or, there could be a “loading change” on the worm/worm wheel,  and the gears in the box, if the OTA is (purposely)  slightly biased, off-balance. Either one could (perhaps)  cause PEC curve inaccuracies depending on which side of the pier you are shooting from.
 
    It would be ideal to actually perform a Meridian Flip after half the number of cycles – then have PemPro “Resume” the remaining raw data collection cycles. But, that is not possible with the present program method.
Either way – running right through PM, or “resuming” after a flip, would produce data that may be closer to a true “average cycle” for the ideally used CCD imaging span,  across the PM.
 
    Next time, I think I will go for the continuous PemPro right across the PM, and “trust” that this provides better results.
 
Joe


Re: APPM and Pinpoint

Ray Gralak
 

Wade,

https://www.faintfuzzy.net/2018/cone-1x1800-ha..fit.
That is very odd as APPM plate solved almost instantly. I'll send you a screen shot. (BTW, there is a typo in the above link -- an extra period before ".fit")

Best regard,

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma


-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...]
Sent: Saturday, March 3, 2018 11:13 AM
To: ap-gto@...
Subject: RE: [ap-gto] APPM and Pinpoint



I looked at the APPM log file, and it doesn’t have any additional information as to what happened with the plate solve.
Actually, it considers the solve successful, which it was not (unless success is defined as “done”). Here is an excerpt:

---------------

0000034 2018-03-03 09:06:18.360: Info, PinPoint Test Solve, File = C:&#92;Users&#92;wadeh&#92;Desktop&#92;Cone-1x1800-Ha.fit

0000035 2018-03-03 09:06:18.360: Info, PinPoint Test Solve, RA/Dec = 6.66811666666667 / 9.64386944444444

0000036 2018-03-03 09:06:18.360: Info, PinPoint Test Solve, Use FITS for Hints = True, X/Y Scale = 1.62 / 1.62

0000037 2018-03-03 09:06:18.360: Info, PinPoint Test Solve, AllSky = False

0000038 2018-03-03 09:06:18.360: Info, PinPoint Test Solve, Timeout = 120

0000039 2018-03-03 09:08:27.650: Info, PinPoint Test Solve, Solve Successful

0000040 2018-03-03 09:08:31.421: Exception, Plate Solving, User Clicked Cancel or Close

---------------

Regarding a sample image, I don’t have a Dropbox account, but you can download a FITS file from
https://www.faintfuzzy.net/2018/cone-1x1800-ha..fit. This is a wide field setup, so there are lots of stars. To solve it
efficiently in Visual Pinpoint with USNO A2.0, I am using Min sigma of 8 and Max magnitude of 10. This one took 22
seconds when I tried it right now.. My 2x2 binned images off the same system take about 5 or 6 seconds. Here is the
output from Visual Pinpoint for this image and the above settings:

---------------

Plate-solve run at 3/3/2018 11:07:45 AM

Use File/Save As to save this file

&#92;&#92;xxx&#92;Cone-1x1800-Ha.fit:

3751 image stars found.

(doing spiral search...)

172 catalog stars found.

Solved using 50 of max 500, RMS residual is 0.50 arcsec, order =4

Solution took 22.8 seconds

Centerpoint RA = 06h 41m 03.766s Dec = 09° 37' 25.91"

Pointing error 0.3 arc minutes

WCS: Roll = -0.48 HScale = -1.622 VScale = -1.623

PA = 0.485°

FWHM = 6.39 arcsec

ZeroPoint = 16.44 (1 sec.)

---------------

Thanks,

-Wade

From: ap-gto@... [mailto:ap-gto@...]
Sent: Saturday, March 3, 2018 10:38 AM
To: ap-gto@...
Subject: RE: [ap-gto] APPM and Pinpoint

Is there any way to get either a more complete error message, or enable logging to get more details as to the
progress of the attempt?

Yes, you can look at the APPM log file.

-Ray Gralak

Author of APCC (Astro-Physics Command Center): http://www.astro-
physics.com/index.htm?products/accessories/software/apcc/apcc

Author of PEMPro: <http://www.ccdware.com/> http://www.ccdware.com

Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver

Author of PulseGuide: http://www.pulseguide.com <http://www.pulseguide.com/>

Author of Sigma: http://www..gralak.com/sigma <http://www.gralak.com/sigma>

From: ap-gto@... [mailto:ap-gto@...]
Sent: Saturday, March 3, 2018 9:49 AM
To: ap-gto@...
Subject: [ap-gto] APPM and Pinpoint

I am using APCC Pro (version 1.6.0.3) and have been using Pinpoint v6 as the plate solver for APPM. This has been
working reasonably well for me with the GSC 1.1 catalog. Still, I do get some occasional plate solve failures, perhaps
about 5% of the time. I have had it on my "to do" list for a while to switch to the USNO A2.0 catalog, and today is the
day that I'm playing with it.

The problem that I am having is that APPM's Image Link Test fails all attempts at solving with this catalog.

Prior to testing with APPM, I worked with Visual Pinpoint to verify that the catalog works correctly. It is able to solve
my test images in about 5 to 6 seconds. To get it working efficiently, I needed to tune the Min Sigma and Max
Magnitude settings in Visual Pinpoint.

< p>I have matched these settings in the Sigma Above Mean and Catalog Max Mag settings in APPM. I have also
verified that the coordinates and image scale from the FITS headers are correct when Image Link Test reports them.

The issue is that Image Link Test times out nearly 100% of the time on my test images. I bumped the Max Solve Time
up to 120 seconds and it still times out. I have seen a couple of tests fail at about the 90 second point with an error that
no stars were matched.

Is there any way to get either a more complete error message, or enable logging to get more details as to the progress
of the attempt? In particular, Visual Pinpoint reports the number of image stars detected and the number of catalog
stars found on both failed and successful solves. This would be very valuable information in troubleshooting this.

I'm also open to any other suggestions.

Thanks,

-Wade

[Non-text portions of this message have been removed]




Re: PemPro Polar Alignment differs East to West

Ray Gralak
 

Hi Andrew,

Hi Ray. It was pretty much the same for both Alt and Az. I ran it a couple of times and some runs it showed up to a 7
arc mins difference in Az, but pretty much stayed in the 3-5 arc min range for Alt.
That may be a problem then for the refraction theory. By default PEMPro tries to account for refraction, but an East/West difference should not be evident for the Azimuth measurement. That's because the elevation of the star hardly changes during the Azimuth measurement (on East or West) and thus the refraction contribution is too small to make that much difference.

If there was a difference in the East/West refraction contribution it would most likely be in the Altitude measurement because it is usually farther away from the meridian and thus the visual elevation of the star will usually change much faster.

-Ray Gralak
Author of APCC (Astro-Physics Command Center): http://www.astro-physics.com/index.htm?products/accessories/software/apcc/apcc
Author of PEMPro: http://www.ccdware.com
Author of Astro-Physics V2 ASCOM Driver: http://www.gralak.com/apdriver
Author of PulseGuide: http://www.pulseguide.com
Author of Sigma: http://www.gralak.com/sigma


-----Original Message-----
From: ap-gto@... [mailto:ap-gto@...]
Sent: Saturday, March 3, 2018 1:25 PM
To: ap-gto@...
Subject: [ap-gto] Re: PemPro Polar Alignment differs East to West



Hi Ray. It was pretty much the same for both Alt and Az. I ran it a couple of times and some runs it showed up to a 7
arc mins difference in Az, but pretty much stayed in the 3-5 arc min range for Alt.


Re: PemPro Polar Alignment differs East to West

Andrew Jones
 

Ray, why we are on the topic of PEMPro, I wanted to mention another issue I had last night. I kept getting an error last night when running step 3 of the Polar Alignment Wizard. Frustratingly it was always while taking the 3rd image in the series. The error message was "Error creating bitmap Min/Max 729/419. Parameter is not valid."

Any idea what might be causing this error? I got it both when my ATIK 16200 was connected via ASCOM directly to PEMPro and when connected via SGPro. I have never seen this error before when using SGP by itself. The only thing that seemed to allow me to get past it was to shut everything down, reboot, and then try and run it again.

If you need me to send you the log files or anything else to help investigate let me know.

Thanks for your never wavering support.

Andrew J


Re: PemPro Polar Alignment differs East to West

Andrew Jones
 

Joe. Thanks for the great info. What was strange in my situation is that I actually got my best results with the scope on the East side of the Pier looking West. It was not until I switched the scope to the West side of the Pier looking East that I started to notice a much larger discrepancy.

Would you recommend starting on one side of the pier vs the other or is it a matter of just having to get both sides about the same? I am targeting to stay below 3 arc mins on both sides if possible as I seem to remember reading somewhere that 3 arc mins is kind of the minimum for long exposures. Not sure how factual that information is thou as I think it may have been something I read on CN.

Andrew J


Re: PemPro Polar Alignment differs East to West

Andrew Jones
 

Thanks Rolando. I appreciate the detailed reply. It is comforting to know I am in good company with this issue. :D Next chance I get I will follow your advice and split the difference in the drift between the East and West side.

Andrew J


Re: PemPro Polar Alignment differs East to West

Andrew Jones
 

Hi Ray. It was pretty much the same for both Alt and Az. I ran it a couple of times and some runs it showed up to a 7 arc mins difference in Az, but pretty much stayed in the 3-5 arc min range for Alt.


Re: PemPro Polar Alignment differs East to West

Joe Zeglinski
 

Rolando,
 
    I think I have found the solution to solving the east-west PemPro curve difference. Simple really.
 
    Atmospheric refraction is ALREADY being taken into account by Ray’s PemPro algorithm, so it really should not be an issue here. However, if there is even some slight variation, during the target run, greater in the western part of the sky, one could very easily produce an “Averaged East-West Pier side” curve by the following procedure:
 
    Rather than settling on doing a raw data sample run for say 6 cycles – Either on one side of the pier, or on the flip side - (and ... further, assuming there are no obstructions for a “reasonable”  span on the prime meridian) – lets start pointing toward the eastern sky, by HALF the suggested (or chosen) offset angle, and let PemPro run past the meridian ending at the same offset half-angle on the western sky, to finish its LAST 3 cycles.
 
    Doing PemPro this way, the target has the SAME amount of EVER decreasing & then increasing atmospheric refraction, for the same number of cycles, split between the two sides of the pier.
 
    What might make this easier, would be if PemPro could make a note of the “actual” pre-meridian offset angle – since the user may have caused some angle delay in preparation of the run, such as the required Calibration wizardry,  and run the other HALF of the cycles until the same post-meridian angle is reached. At that point,  PemPro automatically ends itself,  in preparation for the resulting raw data curve  analysis phase.
 
    The option screen may need to be changed from choosing the number of cycles, or duration – to time or angle ahead and after crossing the meridian.
 
    I think this would be ideal.
Joe Z.


Re: PemPro Polar Alignment differs East to West

Roland Christen
 

Hi Joe,

Thanks for your thoughts.

One could try the zenith to see if the drift in Dec is the same on either side.

By the way, I got to thinking about your daytime polar alignment routine and decided to modify it for our new mounts that have the 90 degree engraving marks on the axes. You must have the pier or tripod level for this to work. All you have to do is line up the RA and Dec engraved marks with the scope pointing to Park3 position (Home position) and tighten both sets of clutches. Then send the mount to either Park1 or Park4 and level the telescope tube assembly using the altitude adjuster.
That's it, and now all you need to adjust is the azimuth angle and that can be done by sending the scope to the Sun (with proper filter or use the ring shadow method). Turn the azimuth until the Sun lines up with the scope. You may have to move the RA axis a small amount using the E-W buttons if your keypad time is off, then press Recal. Now you are ready to slew to other bright planets or stars.

Rolando



-----Original Message-----
From: 'Joseph Zeglinski' J.Zeglinski@... [ap-gto] <ap-gto@...>
To: ap-gto
Sent: Sat, Mar 3, 2018 2:32 pm
Subject: Re: [ap-gto] PemPro Polar Alignment differs East to West



Hi Rolando,
 
    I too have seen that PemPro curve results discrepancy on runs east vs. west side of the mount.
I REALLY like your explanation, on the cause – even if the results might sometimes be slight. They could be further exaggerating with poor seeing, besides the atmospheric component adding to the discrepancy.
 
    Yes - if you run PemPro with the “standard” setting of 5 minutes  (deg ?) looking toward the east of PM, the OTA is “rising” and the atmospheric refraction is “actually improving”, all during the hour long RAW data sampling.
 
    On the flip side, running with exactly the same PemPro meridian target offset, the atmospheric refraction  can ONLY  “degrade” steadily for the entire western sky target  run.
 
    So, you have the worst of both situations. You can either trust the optimum raw data when PemPro runs from the west side of the pier on eastern targets, or the twice as bad situation with “STEADILY declining”  target Altitude ... when running with the scope on the east side (looking west).
 
    I brought this up, on this Group probably more than a couple of years ago, suggesting that PemPro could be run twice, and the two raw data curves averaged – or their samples interleaved – to come to some averaged curve result. Requires some further thinking, whether the results “should be weighted” more toward eastern targets, Something for Ray to consider, based on your premise.
 
    Anyway, Rolando, thanks for this explanation of what has been frustrating me about my own PemPro results ... for a VERY long time. Unfortunately, in the short term, we just have to live with this minor discrepancy.
 
Joe



Re: PemPro Polar Alignment differs East to West

Joe Zeglinski
 

Hi Rolando,
 
    I too have seen that PemPro curve results discrepancy on runs east vs. west side of the mount.
I REALLY like your explanation, on the cause – even if the results might sometimes be slight. They could be further exaggerating with poor seeing, besides the atmospheric component adding to the discrepancy.
 
    Yes - if you run PemPro with the “standard” setting of 5 minutes  (deg ?) looking toward the east of PM, the OTA is “rising” and the atmospheric refraction is “actually improving”, all during the hour long RAW data sampling.
 
    On the flip side, running with exactly the same PemPro meridian target offset, the atmospheric refraction  can ONLY  “degrade” steadily for the entire western sky target  run.
 
    So, you have the worst of both situations. You can either trust the optimum raw data when PemPro runs from the west side of the pier on eastern targets, or the twice as bad situation with “STEADILY declining”  target Altitude ... when running with the scope on the east side (looking west).
 
    I brought this up, on this Group probably more than a couple of years ago, suggesting that PemPro could be run twice, and the two raw data curves averaged – or their samples interleaved – to come to some averaged curve result. Requires some further thinking, whether the results “should be weighted” more toward eastern targets, Something for Ray to consider, based on your premise.
 
    Anyway, Rolando, thanks for this explanation of what has been frustrating me about my own PemPro results ... for a VERY long time. Unfortunately, in the short term, we just have to live with this minor discrepancy.
 
Joe