Cerro Torre,

I believe the code you are looking for is in Ekos/Align.cpp. and is in the method calculateFOV, though it might be someplace else too.

Interesting! But now the real question: Why on Earth would the scale be different? Both images where acquired with the same camera, same exact exposure setting, i.e. same Capture file, same Scheduler file, same filter (Halpha), same target (same exact position), same telescope (NOTHING was touched). The only difference is the time at which they were acquired.

What would have led to the difference in the scale????? Kstars recorded that scale, not me.

PS: Just to clarify: What do you mean with 'first image'? 010 or 215? Because 010 did not solve for me, 215 did!

Greg,

Jasem also mentioned to me that this is the nightly stellarsolver build:

www.google.com/url?q=https://code.launch...jeynXHjYhhooqFA1n6_A

El Corazon, that is a really good question indeed. I don't know the answer, but it is worth investigating. At the moment I am very much focused on getting StellarSovler perfected in KStars, but I can mention it to Jasem.

Thanks, Rob!

I think I found the problem, but I cannot explain it!

In the FITS header for file 010, the one that did not solve for me, the focal length and aperture parameters for my GUIDE SCOPE was recorded, NOT for my imaging scope!!!

Image 215 has the focal length and aperture of my imaging scope recorded correctly and that one solved.

That explains the difference in the scale and the failure.

But that does not change the question:

How is that possible? Needless to say, I did not change the parameters in the mount setup profile for my imaging/guide cam configuration. The pixel dimensions are recorded correctly. Yet somehow Kstars switched to my guide cam specifications during capture without changing to that camera (which would have been an ASI120MM-S, so very different sensor and pixel dimensions).

Jo

I just let Jasem know, that's pretty crazy!!

So its a good thing you are testing my solver, because you probably wouldn't have found this issue otherwise.

Thanks Rob. I built StellarSolver from source and it got kstars to build. Alas, kstars segfaults when I connect to any equipment now, including the sims. Not sure if this is the thread to troubleshoot that tho, or if I should just wait for the next commit to master.

Greg

HI Greg,

Yes that sounds unrelated to StellarSolver. Probably start a new thread for that or see if anybody else has already had that problem.

Thanks,

Rob

Jo,

Jasem said he thinks you might have selected the guide scope in the Align Module. It is under "Solution Coordinates." is that possible?

Thanks,

Rob

I think that the problem reported by Jo it's a real one. I've seen it before. Some times I use the align module with the guide scope and then, when I change to the main telescope to generate accurate WCS entries on the main image, so I can fine tunning the framing of a target. When I latter select again the guider, sometimes the FL on the final images is from the guidescope,

Jo, do you remember if you have been changing between guidescope and main telescope?

I've pulled down three hours ago, but nothing new was on the repo.

The reported scale range remains between 0.638705 to 0.780639 arcsec/pixel though I found in align.cpp the function definition

void Align::calculateFOV()

where I changed the values from 0.9 to 0.7 and from 1.1 to 1.3

if (opsAstrometry->kcfg_AstrometryUseImageScale->isChecked())
{
// code
else
{
opsAstrometry->kcfg_AstrometryImageScaleLow->setValue(fov_pixscale * 0.7);
opsAstrometry->kcfg_AstrometryImageScaleHigh->setValue(fov_pixscale * 1.3);

// 10% boundary
Options::setAstrometryImageScaleLow(fov_pixscale * 0.7);
Options::setAstrometryImageScaleHigh(fov_pixscale * 1.3);
}

Is it possible to give the user the option to extend the range instead of hardcoding those (arbitrary?) values? Or better: is it possible to calculate the range before the solver runs?