Bad X scale?


 

After having good luck with APPM, the Mach1, and the Traveler, I've moved on this week to trying it with the 1100GTO and AP180.

The longer focal length and long moment arms certainly make it less forgiving.

I'm doing a small point map of 23 points. I'm accustomed to them all succeeding with the Mach1/Traveler.

This is my second night to make a point map with the AP180/1100GTO, and two plates failed with a timeout. I'm wondering if these might be explained by being dense Milky Way points, while trying to solve on a somewhat slow and old PC. I'm using the ANSRV local astronomy.net solver.

But two other points didn't exactly "fail," that is, they weren't logged as having failed by APPM. But they did record "Bad X Scale" in the point log, and left yellow in the point diagram, and had no RA/Dec deltas.

I'm still getting pretty good results with pointing and tracking.

Mojo


Worsel
 


 

Thanks Bryan! I think I'll bump my tolerance by a percent and see what happens. :)

On 7/11/2020 10:17 PM, Worsel via groups.io wrote:
Mojo

https://ap-gto.groups.io/g/main/message/71258

Bryan



Ray Gralak
 

Thanks Bryan! I think I'll bump my tolerance by a percent and see what happens. :)
Morris, raising the tolerance might be okay if you don't know image scale exactly, but not if the image scale is already known.

When you see "Bad X-scale" that means even though the plate solve was successful, the image scale (and RA/Dec coordinates) were probably wrong. That is, it was a bad solution and should not be included in the model.

-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 Mojo Jones
Sent: Saturday, July 11, 2020 10:44 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Bad X scale?

Thanks Bryan! I think I'll bump my tolerance by a percent and see what happens. :)


On 7/11/2020 10:17 PM, Worsel via groups.io wrote:


Mojo

https://ap-gto.groups.io/g/main/message/71258

Bryan



--
Morris Jones, Monrovia, CA
BridgeMojo <http://bridgemojo.com>
Old Town Sidewalk Astronomers <http://otastro.org>
Mojo's Blog <http://mojo.whiteoaks.com>


 

Thanks Ray, that's a point, but in fact I may not know my image scale exactly. I can get a number from successful plate solves. Maybe that actually is exact enough. The measurement from PEMPro using star trails has a little uncertainty to it.

I understand that a "Bad X scale" is a sanity check for a "successful" plate solve that is most likely wrong.

Right now I'm getting different success rates from the local ANSRV server and the online Astronomy.net version. I haven't yet tried using the online instance for collecting a point model, so that will be my next test. The failed solves that are not "Bad X scale" are all timeouts. I'm attributing that to an under-performing field laptop.

As I see it, the main trade-off between local solves and online solves is the bandwidth and transmission time required to upload the images to the server. In my case it might be offset by the lousy compute performance of my local machine. My net connection from near home will be a cell phone hot spot, and from my desert location it's WiFi to satellite internet (I think).

Does anyone have suggestions that might make the local plate solver more viable on busy fields? I haven't had much luck using settings to reduce the number of objects processed -- in fact it seems to fail more quickly.

Best regards,
Mojo

On 7/12/20 9:49 AM, Ray Gralak wrote:
Thanks Bryan! I think I'll bump my tolerance by a percent and see what happens. :)
Morris, raising the tolerance might be okay if you don't know image scale exactly, but not if the image scale is already known.

When you see "Bad X-scale" that means even though the plate solve was successful, the image scale (and RA/Dec coordinates) were probably wrong. That is, it was a bad solution and should not be included in the model.

-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 Mojo Jones
Sent: Saturday, July 11, 2020 10:44 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Bad X scale?

Thanks Bryan! I think I'll bump my tolerance by a percent and see what happens. :)


On 7/11/2020 10:17 PM, Worsel via groups.io wrote:


	Mojo

	https://ap-gto.groups.io/g/main/message/71258

	Bryan



--
Morris Jones, Monrovia, CA
BridgeMojo <http://bridgemojo.com>
Old Town Sidewalk Astronomers <http://otastro.org>
Mojo's Blog <http://mojo.whiteoaks.com>







Worsel
 

Mojo

For ANSVR, the most important factor is setting the field of view.  For other solvers, like ASTAP, there are other factors, but I use ANSVR almost exclusively; although ASTAP may be faster.  Search the forum for ASTAP or plate solve.

Here is my entry in the Additional Solve-field arguments      --no-plots --scale-low 40 --scale-high 90 --scale-units arcminwidth


Bryan


Worsel
 

Also, try increasing the Downsample parameter to 2 or 4

Bryan


 

Good stuff, thank you! I'll see if I dig out the failed plates and try them out.

On 7/12/20 1:36 PM, Worsel via groups.io wrote:
Also, try increasing the Downsample parameter to 2 or 4

Bryan



 

I had some good luck this afternoon following the hints below and writing my own set of options for the solve-field program that drives ANSVR.

I set my own values for field width to 25 min and 100 max which covers the range of my two telescopes. Then I found that it actually runs really quickly with the --guess-scale option, since SGP does a pretty good job of populating the FITS file with pixel data.

The root of my problem appears to be that I needed many more index files for smaller fields of view. The recommendation I had overlooked (or didn't understand) on the index downloader was "20% of your smallest field." After adding about three more layers of indexes, it appears that all of my failed solves from last night run pretty quickly.

When I was solving plates from the Traveler, I actually had about the right set of indexes on hand. On moving to the long AP180, I find that I need a lot more of the smaller field of view indexes.

Thanks so much for the hints and tips!

Mojo

On 7/12/2020 1:35 PM, Worsel via groups.io wrote:
Mojo

For ANSVR, the most important factor is setting the field of view.  For other solvers, like ASTAP, there are other factors, but I use ANSVR almost exclusively; although ASTAP may be faster.  Search the forum for ASTAP or plate solve.

Here is my entry in the Additional Solve-field arguments      --no-plots --scale-low 40 --scale-high 90 --scale-units arcminwidth


Bryan



Howard Hedlund
 

I would NOT try to use the same settings for both instruments.  Have a scale and FoV for each.