Date   

Re: Keypad : some buttons not responding too well

M Hambrick
 

How long can we expect the keypad battery to last ? I have had mine since 2017 and never replaced the battery.

Mike


Re: APPM + ASTAP - Inaccurate FOV

Ray Gralak
 

The log message is slightly misleading, as APPM can generate that message even if NAXIS1 and NAXIS2 are correctly retrieved. The other way for APPM to log that message is if the image scale for X and Y are zero, because APPM multiplies the image scale (arc-sec/pixel) by each axis dimension. That is, the error message is presented if the multiplication of (image scale * NAXISx) in either axis is 0.

So, I would need an unmodified FITS image to see what the problem was.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@...
Sent: Tuesday, October 5, 2021 8:24 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

Ray wrote:



* FOCALLEN, XPIXSZ, and XBINNING are used to calculate approximate image scale. NAXIS1 and
NAXIS2 are used to get the image dimensions and to calculate the field of view.



Ok. So here's the log from my brief test last night (I stopped it after two successful solves in 7).



https://drive.google.com/file/d/1Jnqlr46jc0JaMS_ngvt9ZGuNpfvXuMlE/view?usp=sharing



The APPM log ending in 846 was a plate-solve-and-recal, so may be less of interest, but it does include the
correct fov. Included but ignore for the moment since you say it has a different calculation approach.



The APPM log ending in 734 has two plate solves from a RUN session, which has the astap command with
fov set to zero (auto). Which appeared to be causing the issue reported (though it succeeds). The images for
them are also in the log (almost identical file name but very slightly different RA values in the name).



In that log this error appears from APPM prior to calling ASTAP:



ASTAP Plate Solve, Failed to get FITS dimensions (NAXIS1/NAXIS2)



However, I am looking in the FITS header, and it shows:



NAXIS = 2 / Dimensionality

NAXIS1 = 4784 /

NAXIS2 = 3194 /



Does this imply there is some formatting issue in the FITS header that APPM is unable to extract these
properly?



That they are absent from the wcs output file is a bit of a puzzle, but they are absent there even if fov is
provided, and more relevant if I run ASTAP GUI and load the file, it properly shows them in the fits header,
and the alignment tab shows the right calculated field of view (begging the question why the command line
doesn’t do the same calculation and override the -fov 0).



But back to the original issue -- any chance you could see what exactly caused APPM to fail to get the
dimensions from the header? Is it formatting in the header? Or something in APPM?



Thanks for hanging in there. This would only pick up a few seconds per solve, but with thousands of users,
hundreds of points each... think of all the time we save collectively. 😊



Linwood


Re: APPM + ASTAP - Inaccurate FOV

ap@CaptivePhotons.com
 

Ray wrote:

 

  • FOCALLEN, XPIXSZ, and XBINNING are used to calculate approximate image scale. NAXIS1 and NAXIS2 are used to get the image dimensions and to calculate the field of view.

 

Ok.  So here's the log from my brief test last night (I stopped it after two successful solves in 7).

 

https://drive.google.com/file/d/1Jnqlr46jc0JaMS_ngvt9ZGuNpfvXuMlE/view?usp=sharing

 

The APPM log ending in 846 was a plate-solve-and-recal, so may be less of interest, but it does include the correct fov.  Included but ignore for the moment since you say it has a different calculation approach.

 

The APPM log ending in 734 has two plate solves from a RUN session, which has the astap command with fov set to zero (auto).  Which appeared to be causing the issue reported (though it succeeds).  The images for them are also in the log (almost identical file name but very slightly different RA values in the name).

 

In that log this error appears from APPM prior to calling ASTAP:

 

     ASTAP Plate Solve, Failed to get FITS dimensions (NAXIS1/NAXIS2)

 

However, I am looking in the FITS header, and it shows:

 

    NAXIS   =                    2 / Dimensionality

    NAXIS1  =                 4784 /

    NAXIS2  =                 3194 /

 

Does this imply there is some formatting issue in the FITS header that APPM is unable to extract these properly?

 

That they are absent from the wcs output file is a bit of a puzzle, but they are absent there even if fov is provided, and more relevant if I run ASTAP GUI and load the file, it properly shows them in the fits header, and the alignment tab shows the right calculated field of view (begging the question why the command line doesn’t do the same calculation and override the -fov 0).

 

But back to the original issue -- any chance you could see what exactly caused APPM to fail to get the dimensions from the header?  Is it formatting in the header?   Or something in APPM?

 

Thanks for hanging in there.  This would only pick up a few seconds per solve, but with thousands of users, hundreds of points each... think of all the time we save collectively.  😊

 

Linwood


Re: APPM + ASTAP - Inaccurate FOV

Ray Gralak
 

Hi Linwood,

> The FITS headers from NINA do not contain FOV in any case, but they contain the FOCCALLEN and
XPIXSZ/YPIXSZ which allow calculation of image scale (which is also not there explicitly), and with image
dimensions you can calculate field of view.
FOCALLEN, XPIXSZ, and XBINNING are used to calculate approximate image scale. NAXIS1 and NAXIS2 are used to get the image dimensions
and to calculate the field of view.

-Ray


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@...
Sent: Monday, October 4, 2021 10:28 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV


Ray wrote:

For historical reasons, Plate Solve and recal uses the image scale set on the plate solve tab.
When doing an APPM run, the image scale is calculated from the values in the FITS image.
I realize they are all related but let me pin down the terminology a bit. He was asking about field of view, the -
fov parameter to astap.

The FITS headers from NINA do not contain FOV in any case, but they contain the FOCCALLEN and
XPIXSZ/YPIXSZ which allow calculation of image scale (which is also not there explicitly), and with image
dimensions you can calculate field of view.

But both image scale and field of view have to be calculated from the fits headers, they are not present in it,
right?

Or maybe you are expecting them there.

Can you tell us what specific FITS keys you are expecting to calculate the FOV that is being passed to
ASTAP in the run?




Re: APPM + ASTAP - Inaccurate FOV

ap@CaptivePhotons.com
 

Ray wrote:

For historical reasons, Plate Solve and recal uses the image scale set on the plate solve tab.
When doing an APPM run, the image scale is calculated from the values in the FITS image.
I realize they are all related but let me pin down the terminology a bit. He was asking about field of view, the -fov parameter to astap.

The FITS headers from NINA do not contain FOV in any case, but they contain the FOCCALLEN and XPIXSZ/YPIXSZ which allow calculation of image scale (which is also not there explicitly), and with image dimensions you can calculate field of view.

But both image scale and field of view have to be calculated from the fits headers, they are not present in it, right?

Or maybe you are expecting them there.

Can you tell us what specific FITS keys you are expecting to calculate the FOV that is being passed to ASTAP in the run?


Re: APPM + ASTAP - Inaccurate FOV

Ray Gralak
 

For historical reasons, Plate Solve and recal uses the image scale set on the plate solve tab.

When doing an APPM run, the image scale is calculated from the values in the FITS image.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Seb@stro
Sent: Monday, October 4, 2021 9:38 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

that's interesting... I guess we'll have to let Ray and Dale sort this one out.

BTW, my solves are successful too, only they are slower, by about 4-5 seconds per solved point (vs about 1-
2 sec) because of this "-fov 0" thing. I have no problem directly in Nina or APT or ASTAP. Always super fast.

If you can't tell the difference, I suppose it might be due to more horsepower in your PC than mine.

just try to solve one of the files APPM was able to solve but using the command line and append "-log". take
a look at the log file (same dir as the solved file), you'll see what ASTAP does try a bunch of preset fov
internally, whereas it does not when the correct Fov is specified or when the -fov switch is omitted.


________________________________

De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@...
<ap@...>
Envoyé : 5 octobre 2021 00:14
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV


Seb@stro wrote :



* but in the FITS header of the WCS file (that came along the same image fits file), I only see this:



* NAXIS = 0 / Dimensionality



For what it is worth, the wcs files from nina to astap (internally, not involving APPM) also have 0 here.



That part that confuses me about this is why APPM’s call to ASTAP has fov 0 for a run, and the correct fov
for a “plate solve and recal”, since both originate from NINA in (presumably) the same path when NINA
controls the camera.



Incidentally: The NAXIS for both the solve-now and the run both have zero, indeed the data from NINA looks
the same to my eye.



It would appear (speculating) that APPM is using the header to calculate FOV (it has pixel and focal length) for
the solve now, but not the regular points in a run?



Now why despite FOV=0 mine works and yours doesn’t…




Re: APPM + ASTAP - Inaccurate FOV

Sébastien Doré
 

that's interesting... I guess we'll have to let Ray and Dale sort this one out.

BTW, my solves are successful too, only they are slower, by about 4-5 seconds per solved point (vs about 1-2 sec) because of this "-fov 0" thing. I have no problem directly in Nina or APT or ASTAP. Always super fast.

If you can't tell the difference, I suppose it might be due to more horsepower in your PC than mine. 

just try to solve one of the files APPM was able to solve but using the command line and append "-log". take a look at the log file (same dir as the solved file), you'll see what ASTAP does try a bunch of preset fov internally, whereas it does not when the correct Fov is specified or when the -fov switch is omitted.
 


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@... <ap@...>
Envoyé : 5 octobre 2021 00:14
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
 

Seb@stro wrote :

 

  • but in the FITS header of the WCS file (that came along the same image fits file), I only see this:

 

  • NAXIS   =                    0 / Dimensionality

 

For what it is worth, the wcs files from nina to astap (internally, not involving APPM) also have 0 here.

 

That part that confuses me about this is why APPM’s call to ASTAP has fov 0 for a run, and the correct fov for a “plate solve and recal”, since both originate from NINA in (presumably) the same path when NINA controls the camera.

 

Incidentally: The NAXIS for both the solve-now and the run both have zero, indeed the data from NINA looks the same to my eye. 

 

It would appear (speculating) that APPM is using the header to calculate FOV (it has pixel and focal length) for the solve now, but not the regular points in a run?

 

Now why despite FOV=0 mine works and yours doesn’t…

 


Re: APPM + ASTAP - Inaccurate FOV

ap@CaptivePhotons.com
 

Seb@stro wrote :

 

  • but in the FITS header of the WCS file (that came along the same image fits file), I only see this:

 

  • NAXIS   =                    0 / Dimensionality

 

For what it is worth, the wcs files from nina to astap (internally, not involving APPM) also have 0 here.

 

That part that confuses me about this is why APPM’s call to ASTAP has fov 0 for a run, and the correct fov for a “plate solve and recal”, since both originate from NINA in (presumably) the same path when NINA controls the camera.

 

Incidentally: The NAXIS for both the solve-now and the run both have zero, indeed the data from NINA looks the same to my eye. 

 

It would appear (speculating) that APPM is using the header to calculate FOV (it has pixel and focal length) for the solve now, but not the regular points in a run?

 

Now why despite FOV=0 mine works and yours doesn’t…

 


Re: APPM + ASTAP - Inaccurate FOV

Sébastien Doré
 

Just for disambiguation and because it is confusing in my case is that my image scale is 0.4 (arc-sec/px) and my fov is also 0.4 (degrees).

So, note to self:

image scale = px sz / FL * 206.265 = 0.4"/px
fov (deg) = image scale * sensor height (px) / 3600 = 0.4 deg

That said, I think I just found the problem. Not sure if it originates from NINA or APPM though. 

In the FITS header of the FITS file, I see the following, which is required for the fov calculation :

NAXIS   =                    2 / Dimensionality                                
NAXIS1  =                 5208 /                                                
NAXIS2  =                 3476 /  

but in the FITS header of the WCS file (that came along the same image fits file), I only see this:

NAXIS   =                    0 / Dimensionality

The sensor size if missing, so it would be impossible to compute the correct FOV.

So my guess is the issue is related to that...

Sébastien

De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Seb@stro <sebastiendore1@...>
Envoyé : 4 octobre 2021 23:09
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
 
Hi Ray,

AFAIK there is no "image scale setting" in NINA so to speak, only pixel size and FL which are both set to the correct values of course.

See WCS file attached (from APPM folder) for an example of fits header from tonight's run. I can't see any specific XSCALE/YSCALE populated field anywhere, but FL and PXSZ are there.

Thanks,

Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Ray Gralak <iogroups@...>
Envoyé : 4 octobre 2021 22:21
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
 
Hi Sebastien,

Do you have image scale set correctly in NINA? APPM will try to read the image scale from the FITS header.

-Ray

> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Seb@stro
> Sent: Monday, October 4, 2021 6:51 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
> I am using Nina camera too.
>
> Same here with Nina, which uses the correct FOV:
>
> COMMENT 7  Solved in 1.1 sec. Offset was 5.4". Mount offset RA=3.5", DEC=4.3"
> COMMENT cmdline:"C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\AppData
> COMMENT \Local\NINA\PlateSolver\ylpoww5s.otd.fits" -fov 0.403196 -z 0 -s 500 -r
> COMMENT 30 -ra 20.581111 -spd 150.153611
>
>
> ________________________________
>
> De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@...
> <ap@...>
> Envoyé : 4 octobre 2021 21:34
> À : main@ap-gto.groups.io <main@ap-gto.groups.io>
> Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
> You are correct.  I’m hopefully waiting for clouds to clear on my target, so I ran again as a real run, and it does
> say fov 0.
>
>
> But it also solved in 2 seconds.
>
>
>
> I’m using NINA as the camera, ASTAP as the solver, I do have “refine image” checked but that was the first
> image (assuming it does not remember between sessions).
>
>
>
> NINA’s own plate solve looks like the below (under this section from APPM) (different target).
>
>
>
>
>
> 0000222 2021-10-04 21:28:26.723:       Info, ASTAP Plate Solve, StartSolve: arguments: -f
> "C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-
> DEC_26.570.fit" -ra 21.1306311460545 -spd 116.479817874596 -fov 0 -s 1000 -r 5
>
> 0000223 2021-10-04 21:28:26.793:       Info,   State Machine, Entering State=PlateSolveWait
>
> 0000224 2021-10-04 21:28:26.797:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000225 2021-10-04 21:28:27.002:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000226 2021-10-04 21:28:27.206:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000227 2021-10-04 21:28:27.408:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000228 2021-10-04 21:28:27.616:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000229 2021-10-04 21:28:27.831:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000230 2021-10-04 21:28:28.035:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000231 2021-10-04 21:28:28.238:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000232 2021-10-04 21:28:28.442:       Info, ASTAP Plate Solve, ASTAP has exited.
>
> 0000233 2021-10-04 21:28:28.444:       Info,   ASTAP Results, Results Filename =
> C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-
> DEC_26.570.ini
>
> 0000234 2021-10-04 21:28:28.444:       Info,   ASTAP Results, PLTSOLVD=T
>
>
>
>
>
> NINA:
>
>
>
> 2021-10-04T20:00:07.1982|DEBUG|CLISolver.cs|StartCLI|119|Starting process 'C:\Program
> Files\astap\astap.exe' with args '-f "C:\Users\ferguson\AppData\Local\NINA\PlateSolver\i1s5wsdg.jii.fits" -fov
> 2.548482 -z 4 -s 500 -r 10 -ra 21.680652 -spd 175.109725'
>
> 2021-10-04T20:00:11.0662|INFO|ImageSolver.cs|Solve|54|Platesolve successful: Coordinates: RA: 21:50:32;
> Dec: 85° 08' 04"; Epoch: J2000
>
>
>
> From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
> Sent: Monday, October 4, 2021 9:26 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
>
> I think the "platesolve and recal" or even "platesolve" does it differently than the real run. Not sure why...
>
>
>
> Here's what I get with it :
>
>
>
> CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-
> Physics\APPM\SolveNow-2021-08-31-224233.fit" -ra 2.63827777777778 -spd 179.999194444444 -fov
> 0.402802441751637 -s 1000 -r 5 -t 0.007
>
>
>
> Which would do the trick too in the real run. Unfortunately, it doesn't.
>
>
>
> ________________________________
>
> De : main@ap-gto.groups.io <mailto:main@ap-gto.groups.io>  <main@ap-gto.groups.io> de la part de
> ap@... <ap@...>
> Envoyé : 4 octobre 2021 21:16
> À : main@ap-gto.groups.io <main@ap-gto.groups.io>
> Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
>
> What camera settings do you have?  I just looked at mine (from a plate solve and recal) and APPM did this:
>
> Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-
> Physics\APPM\SyncNow-2021-10-04-201900.fit" -ra 19.8928444444444 -spd 91.07325 -fov 2.46918855501098 -
> s 1000 -r 5
>
>
>
> I assume it’s calculating it from the image scale and pixel dimensions since it’s not entered. At a guess.
>
>
>
>
>
> From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
> Sent: Monday, October 4, 2021 9:07 PM
> To: main@ap-gto.groups.io
> Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
>
> Hello,
>
>
>
> I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...
>
>
>
> When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I
> am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file
> created along each solve, for every point :
>
>
>
> WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm
>
>
>
> I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.
>
>
>
> When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is
> always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate
> Solve Settings :
>
>
>
>
>
>
>
> CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-
> APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -
> fov 0 -s 500 -r 5 -m 1 -t 0.007
>
>
>
>
>
>
>
> From ASTAP documentation:
>
>
>
> If the FOV (image height in degrees)  is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP
> will use the FOV as set in the program, stack menu, tab alignment.
>
>
>
>
>
> Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV  is already
> correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?
>
>
>
> When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP
> solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the
> same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).
>
>
>
> Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.
>
>
>
> Sébastien
>
>







Re: APPM + ASTAP - Inaccurate FOV

Sébastien Doré
 

Hi Ray,

AFAIK there is no "image scale setting" in NINA so to speak, only pixel size and FL which are both set to the correct values of course.

See WCS file attached (from APPM folder) for an example of fits header from tonight's run. I can't see any specific XSCALE/YSCALE populated field anywhere, but FL and PXSZ are there.

Thanks,

Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Ray Gralak <iogroups@...>
Envoyé : 4 octobre 2021 22:21
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
 
Hi Sebastien,

Do you have image scale set correctly in NINA? APPM will try to read the image scale from the FITS header.

-Ray

> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Seb@stro
> Sent: Monday, October 4, 2021 6:51 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
> I am using Nina camera too.
>
> Same here with Nina, which uses the correct FOV:
>
> COMMENT 7  Solved in 1.1 sec. Offset was 5.4". Mount offset RA=3.5", DEC=4.3"
> COMMENT cmdline:"C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\AppData
> COMMENT \Local\NINA\PlateSolver\ylpoww5s.otd.fits" -fov 0.403196 -z 0 -s 500 -r
> COMMENT 30 -ra 20.581111 -spd 150.153611
>
>
> ________________________________
>
> De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@...
> <ap@...>
> Envoyé : 4 octobre 2021 21:34
> À : main@ap-gto.groups.io <main@ap-gto.groups.io>
> Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
> You are correct.  I’m hopefully waiting for clouds to clear on my target, so I ran again as a real run, and it does
> say fov 0.
>
>
> But it also solved in 2 seconds.
>
>
>
> I’m using NINA as the camera, ASTAP as the solver, I do have “refine image” checked but that was the first
> image (assuming it does not remember between sessions).
>
>
>
> NINA’s own plate solve looks like the below (under this section from APPM) (different target).
>
>
>
>
>
> 0000222 2021-10-04 21:28:26.723:       Info, ASTAP Plate Solve, StartSolve: arguments: -f
> "C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-
> DEC_26.570.fit" -ra 21.1306311460545 -spd 116.479817874596 -fov 0 -s 1000 -r 5
>
> 0000223 2021-10-04 21:28:26.793:       Info,   State Machine, Entering State=PlateSolveWait
>
> 0000224 2021-10-04 21:28:26.797:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000225 2021-10-04 21:28:27.002:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000226 2021-10-04 21:28:27.206:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000227 2021-10-04 21:28:27.408:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000228 2021-10-04 21:28:27.616:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000229 2021-10-04 21:28:27.831:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000230 2021-10-04 21:28:28.035:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000231 2021-10-04 21:28:28.238:       Info, ASTAP Plate Solve, ASTAP is still running.
>
> 0000232 2021-10-04 21:28:28.442:       Info, ASTAP Plate Solve, ASTAP has exited.
>
> 0000233 2021-10-04 21:28:28.444:       Info,   ASTAP Results, Results Filename =
> C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-
> DEC_26.570.ini
>
> 0000234 2021-10-04 21:28:28.444:       Info,   ASTAP Results, PLTSOLVD=T
>
>
>
>
>
> NINA:
>
>
>
> 2021-10-04T20:00:07.1982|DEBUG|CLISolver.cs|StartCLI|119|Starting process 'C:\Program
> Files\astap\astap.exe' with args '-f "C:\Users\ferguson\AppData\Local\NINA\PlateSolver\i1s5wsdg.jii.fits" -fov
> 2.548482 -z 4 -s 500 -r 10 -ra 21.680652 -spd 175.109725'
>
> 2021-10-04T20:00:11.0662|INFO|ImageSolver.cs|Solve|54|Platesolve successful: Coordinates: RA: 21:50:32;
> Dec: 85° 08' 04"; Epoch: J2000
>
>
>
> From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
> Sent: Monday, October 4, 2021 9:26 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
>
> I think the "platesolve and recal" or even "platesolve" does it differently than the real run. Not sure why...
>
>
>
> Here's what I get with it :
>
>
>
> CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-
> Physics\APPM\SolveNow-2021-08-31-224233.fit" -ra 2.63827777777778 -spd 179.999194444444 -fov
> 0.402802441751637 -s 1000 -r 5 -t 0.007
>
>
>
> Which would do the trick too in the real run. Unfortunately, it doesn't.
>
>
>
> ________________________________
>
> De : main@ap-gto.groups.io <mailto:main@ap-gto.groups.io>  <main@ap-gto.groups.io> de la part de
> ap@... <ap@...>
> Envoyé : 4 octobre 2021 21:16
> À : main@ap-gto.groups.io <main@ap-gto.groups.io>
> Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
>
> What camera settings do you have?  I just looked at mine (from a plate solve and recal) and APPM did this:
>
> Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-
> Physics\APPM\SyncNow-2021-10-04-201900.fit" -ra 19.8928444444444 -spd 91.07325 -fov 2.46918855501098 -
> s 1000 -r 5
>
>
>
> I assume it’s calculating it from the image scale and pixel dimensions since it’s not entered. At a guess.
>
>
>
>
>
> From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
> Sent: Monday, October 4, 2021 9:07 PM
> To: main@ap-gto.groups.io
> Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV
>
>
>
> Hello,
>
>
>
> I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...
>
>
>
> When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I
> am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file
> created along each solve, for every point :
>
>
>
> WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm
>
>
>
> I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.
>
>
>
> When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is
> always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate
> Solve Settings :
>
>
>
>
>
>
>
> CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-
> APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -
> fov 0 -s 500 -r 5 -m 1 -t 0.007
>
>
>
>
>
>
>
> From ASTAP documentation:
>
>
>
> If the FOV (image height in degrees)  is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP
> will use the FOV as set in the program, stack menu, tab alignment.
>
>
>
>
>
> Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV  is already
> correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?
>
>
>
> When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP
> solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the
> same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).
>
>
>
> Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.
>
>
>
> Sébastien
>
>







Re: APPM + ASTAP - Inaccurate FOV

Ray Gralak
 

Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV is already
correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?
When "Refine image scale" is enabled, APPM uses the result of each plate-solve to set the image scale for the next image.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Seb@stro
Sent: Monday, October 4, 2021 6:07 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV

Hello,

I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...

When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I
am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file
created along each solve, for every point :

WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm


I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.

When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is
always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate
Solve Settings :





CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-
APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -
fov 0 -s 500 -r 5 -m 1 -t 0.007




From ASTAP documentation:

If the FOV (image height in degrees) is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP
will use the FOV as set in the program, stack menu, tab alignment.



Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV is already
correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?

When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP
solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the
same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).

Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.

Sébastien


Re: APPM + ASTAP - Inaccurate FOV

Ray Gralak
 

Hi Sebastien,

Do you have image scale set correctly in NINA? APPM will try to read the image scale from the FITS header.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Seb@stro
Sent: Monday, October 4, 2021 6:51 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

I am using Nina camera too.

Same here with Nina, which uses the correct FOV:

COMMENT 7 Solved in 1.1 sec. Offset was 5.4". Mount offset RA=3.5", DEC=4.3"
COMMENT cmdline:"C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\AppData
COMMENT \Local\NINA\PlateSolver\ylpoww5s.otd.fits" -fov 0.403196 -z 0 -s 500 -r
COMMENT 30 -ra 20.581111 -spd 150.153611


________________________________

De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@...
<ap@...>
Envoyé : 4 octobre 2021 21:34
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV


You are correct. I’m hopefully waiting for clouds to clear on my target, so I ran again as a real run, and it does
say fov 0.


But it also solved in 2 seconds.



I’m using NINA as the camera, ASTAP as the solver, I do have “refine image” checked but that was the first
image (assuming it does not remember between sessions).



NINA’s own plate solve looks like the below (under this section from APPM) (different target).





0000222 2021-10-04 21:28:26.723: Info, ASTAP Plate Solve, StartSolve: arguments: -f
"C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-
DEC_26.570.fit" -ra 21.1306311460545 -spd 116.479817874596 -fov 0 -s 1000 -r 5

0000223 2021-10-04 21:28:26.793: Info, State Machine, Entering State=PlateSolveWait

0000224 2021-10-04 21:28:26.797: Info, ASTAP Plate Solve, ASTAP is still running.

0000225 2021-10-04 21:28:27.002: Info, ASTAP Plate Solve, ASTAP is still running.

0000226 2021-10-04 21:28:27.206: Info, ASTAP Plate Solve, ASTAP is still running.

0000227 2021-10-04 21:28:27.408: Info, ASTAP Plate Solve, ASTAP is still running.

0000228 2021-10-04 21:28:27.616: Info, ASTAP Plate Solve, ASTAP is still running.

0000229 2021-10-04 21:28:27.831: Info, ASTAP Plate Solve, ASTAP is still running.

0000230 2021-10-04 21:28:28.035: Info, ASTAP Plate Solve, ASTAP is still running.

0000231 2021-10-04 21:28:28.238: Info, ASTAP Plate Solve, ASTAP is still running.

0000232 2021-10-04 21:28:28.442: Info, ASTAP Plate Solve, ASTAP has exited.

0000233 2021-10-04 21:28:28.444: Info, ASTAP Results, Results Filename =
C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-
DEC_26.570.ini

0000234 2021-10-04 21:28:28.444: Info, ASTAP Results, PLTSOLVD=T





NINA:



2021-10-04T20:00:07.1982|DEBUG|CLISolver.cs|StartCLI|119|Starting process 'C:\Program
Files\astap\astap.exe' with args '-f "C:\Users\ferguson\AppData\Local\NINA\PlateSolver\i1s5wsdg.jii.fits" -fov
2.548482 -z 4 -s 500 -r 10 -ra 21.680652 -spd 175.109725'

2021-10-04T20:00:11.0662|INFO|ImageSolver.cs|Solve|54|Platesolve successful: Coordinates: RA: 21:50:32;
Dec: 85° 08' 04"; Epoch: J2000



From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:26 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV



I think the "platesolve and recal" or even "platesolve" does it differently than the real run. Not sure why...



Here's what I get with it :



CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-
Physics\APPM\SolveNow-2021-08-31-224233.fit" -ra 2.63827777777778 -spd 179.999194444444 -fov
0.402802441751637 -s 1000 -r 5 -t 0.007



Which would do the trick too in the real run. Unfortunately, it doesn't.



________________________________

De : main@ap-gto.groups.io <mailto:main@ap-gto.groups.io> <main@ap-gto.groups.io> de la part de
ap@... <ap@...>
Envoyé : 4 octobre 2021 21:16
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV



What camera settings do you have? I just looked at mine (from a plate solve and recal) and APPM did this:

Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-
Physics\APPM\SyncNow-2021-10-04-201900.fit" -ra 19.8928444444444 -spd 91.07325 -fov 2.46918855501098 -
s 1000 -r 5



I assume it’s calculating it from the image scale and pixel dimensions since it’s not entered. At a guess.





From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:07 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV



Hello,



I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...



When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I
am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file
created along each solve, for every point :



WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm



I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.



When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is
always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate
Solve Settings :







CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-
APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -
fov 0 -s 500 -r 5 -m 1 -t 0.007







From ASTAP documentation:



If the FOV (image height in degrees) is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP
will use the FOV as set in the program, stack menu, tab alignment.





Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV is already
correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?



When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP
solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the
same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).



Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.



Sébastien


Re: APPM + ASTAP - Inaccurate FOV

Sébastien Doré
 

I am using Nina camera too.

Same here with Nina, which uses the correct FOV:

COMMENT 7  Solved in 1.1 sec. Offset was 5.4". Mount offset RA=3.5", DEC=4.3"
COMMENT cmdline:"C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\AppData
COMMENT \Local\NINA\PlateSolver\ylpoww5s.otd.fits" -fov 0.403196 -z 0 -s 500 -r
COMMENT 30 -ra 20.581111 -spd 150.153611


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@... <ap@...>
Envoyé : 4 octobre 2021 21:34
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
 

You are correct.  I’m hopefully waiting for clouds to clear on my target, so I ran again as a real run, and it does say fov 0.


But it also solved in 2 seconds.

 

I’m using NINA as the camera, ASTAP as the solver, I do have “refine image” checked but that was the first image (assuming it does not remember between sessions).

 

NINA’s own plate solve looks like the below (under this section from APPM) (different target).

 

 

0000222 2021-10-04 21:28:26.723:       Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-DEC_26.570.fit" -ra 21.1306311460545 -spd 116.479817874596 -fov 0 -s 1000 -r 5

0000223 2021-10-04 21:28:26.793:       Info,   State Machine, Entering State=PlateSolveWait

0000224 2021-10-04 21:28:26.797:       Info, ASTAP Plate Solve, ASTAP is still running.

0000225 2021-10-04 21:28:27.002:       Info, ASTAP Plate Solve, ASTAP is still running.

0000226 2021-10-04 21:28:27.206:       Info, ASTAP Plate Solve, ASTAP is still running.

0000227 2021-10-04 21:28:27.408:       Info, ASTAP Plate Solve, ASTAP is still running.

0000228 2021-10-04 21:28:27.616:       Info, ASTAP Plate Solve, ASTAP is still running.

0000229 2021-10-04 21:28:27.831:       Info, ASTAP Plate Solve, ASTAP is still running.

0000230 2021-10-04 21:28:28.035:       Info, ASTAP Plate Solve, ASTAP is still running.

0000231 2021-10-04 21:28:28.238:       Info, ASTAP Plate Solve, ASTAP is still running.

0000232 2021-10-04 21:28:28.442:       Info, ASTAP Plate Solve, ASTAP has exited.

0000233 2021-10-04 21:28:28.444:       Info,   ASTAP Results, Results Filename = C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-DEC_26.570.ini

0000234 2021-10-04 21:28:28.444:       Info,   ASTAP Results, PLTSOLVD=T

 

 

NINA:

 

2021-10-04T20:00:07.1982|DEBUG|CLISolver.cs|StartCLI|119|Starting process 'C:\Program Files\astap\astap.exe' with args '-f "C:\Users\ferguson\AppData\Local\NINA\PlateSolver\i1s5wsdg.jii.fits" -fov 2.548482 -z 4 -s 500 -r 10 -ra 21.680652 -spd 175.109725'

2021-10-04T20:00:11.0662|INFO|ImageSolver.cs|Solve|54|Platesolve successful: Coordinates: RA: 21:50:32; Dec: 85° 08' 04"; Epoch: J2000

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:26 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

I think the "platesolve and recal" or even "platesolve" does it differently than the real run. Not sure why...

 

Here's what I get with it : 

 

CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\SolveNow-2021-08-31-224233.fit" -ra 2.63827777777778 -spd 179.999194444444 -fov 0.402802441751637 -s 1000 -r 5 -t 0.007

 

Which would do the trick too in the real run. Unfortunately, it doesn't.

 


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@... <ap@...>
Envoyé : 4 octobre 2021 21:16
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

What camera settings do you have?  I just looked at mine (from a plate solve and recal) and APPM did this:

Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-Physics\APPM\SyncNow-2021-10-04-201900.fit" -ra 19.8928444444444 -spd 91.07325 -fov 2.46918855501098 -s 1000 -r 5

 

I assume it’s calculating it from the image scale and pixel dimensions since it’s not entered. At a guess.

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:07 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

Hello,

 

I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...

 

When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file created along each solve, for every point : 

 

WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm

 

I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.

 

When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate Solve Settings : 

 

 

CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -fov 0 -s 500 -r 5 -m 1 -t 0.007

 

 

 

From ASTAP documentation: 

 

If the FOV (image height in degrees)  is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP will use the FOV as set in the program, stack menu, tab alignment.

 

 

Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV  is already correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?

 

When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).

 

Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.

 

Sébastien


Re: APPM + ASTAP - Inaccurate FOV

ap@CaptivePhotons.com
 

You are correct.  I’m hopefully waiting for clouds to clear on my target, so I ran again as a real run, and it does say fov 0.


But it also solved in 2 seconds.

 

I’m using NINA as the camera, ASTAP as the solver, I do have “refine image” checked but that was the first image (assuming it does not remember between sessions).

 

NINA’s own plate solve looks like the below (under this section from APPM) (different target).

 

 

0000222 2021-10-04 21:28:26.723:       Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-DEC_26.570.fit" -ra 21.1306311460545 -spd 116.479817874596 -fov 0 -s 1000 -r 5

0000223 2021-10-04 21:28:26.793:       Info,   State Machine, Entering State=PlateSolveWait

0000224 2021-10-04 21:28:26.797:       Info, ASTAP Plate Solve, ASTAP is still running.

0000225 2021-10-04 21:28:27.002:       Info, ASTAP Plate Solve, ASTAP is still running.

0000226 2021-10-04 21:28:27.206:       Info, ASTAP Plate Solve, ASTAP is still running.

0000227 2021-10-04 21:28:27.408:       Info, ASTAP Plate Solve, ASTAP is still running.

0000228 2021-10-04 21:28:27.616:       Info, ASTAP Plate Solve, ASTAP is still running.

0000229 2021-10-04 21:28:27.831:       Info, ASTAP Plate Solve, ASTAP is still running.

0000230 2021-10-04 21:28:28.035:       Info, ASTAP Plate Solve, ASTAP is still running.

0000231 2021-10-04 21:28:28.238:       Info, ASTAP Plate Solve, ASTAP is still running.

0000232 2021-10-04 21:28:28.442:       Info, ASTAP Plate Solve, ASTAP has exited.

0000233 2021-10-04 21:28:28.444:       Info,   ASTAP Results, Results Filename = C:\Users\ferguson\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-212734.txt-0001-RA_21.146-DEC_26.570.ini

0000234 2021-10-04 21:28:28.444:       Info,   ASTAP Results, PLTSOLVD=T

 

 

NINA:

 

2021-10-04T20:00:07.1982|DEBUG|CLISolver.cs|StartCLI|119|Starting process 'C:\Program Files\astap\astap.exe' with args '-f "C:\Users\ferguson\AppData\Local\NINA\PlateSolver\i1s5wsdg.jii.fits" -fov 2.548482 -z 4 -s 500 -r 10 -ra 21.680652 -spd 175.109725'

2021-10-04T20:00:11.0662|INFO|ImageSolver.cs|Solve|54|Platesolve successful: Coordinates: RA: 21:50:32; Dec: 85° 08' 04"; Epoch: J2000

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:26 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

I think the "platesolve and recal" or even "platesolve" does it differently than the real run. Not sure why...

 

Here's what I get with it : 

 

CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\SolveNow-2021-08-31-224233.fit" -ra 2.63827777777778 -spd 179.999194444444 -fov 0.402802441751637 -s 1000 -r 5 -t 0.007

 

Which would do the trick too in the real run. Unfortunately, it doesn't.

 


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@... <ap@...>
Envoyé : 4 octobre 2021 21:16
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

What camera settings do you have?  I just looked at mine (from a plate solve and recal) and APPM did this:

Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-Physics\APPM\SyncNow-2021-10-04-201900.fit" -ra 19.8928444444444 -spd 91.07325 -fov 2.46918855501098 -s 1000 -r 5

 

I assume it’s calculating it from the image scale and pixel dimensions since it’s not entered. At a guess.

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:07 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

Hello,

 

I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...

 

When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file created along each solve, for every point : 

 

WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm

 

I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.

 

When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate Solve Settings : 

 

 

CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -fov 0 -s 500 -r 5 -m 1 -t 0.007

 

 

 

From ASTAP documentation: 

 

If the FOV (image height in degrees)  is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP will use the FOV as set in the program, stack menu, tab alignment.

 

 

Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV  is already correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?

 

When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).

 

Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.

 

Sébastien


Re: APPM + ASTAP - Inaccurate FOV

Sébastien Doré
 

I think the "platesolve and recal" or even "platesolve" does it differently than the real run. Not sure why...

Here's what I get with it : 

CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\SolveNow-2021-08-31-224233.fit" -ra 2.63827777777778 -spd 179.999194444444 -fov 0.402802441751637 -s 1000 -r 5 -t 0.007

Which would do the trick too in the real run. Unfortunately, it doesn't.


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de ap@... <ap@...>
Envoyé : 4 octobre 2021 21:16
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] APPM + ASTAP - Inaccurate FOV
 

What camera settings do you have?  I just looked at mine (from a plate solve and recal) and APPM did this:

Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-Physics\APPM\SyncNow-2021-10-04-201900.fit" -ra 19.8928444444444 -spd 91.07325 -fov 2.46918855501098 -s 1000 -r 5

 

I assume it’s calculating it from the image scale and pixel dimensions since it’s not entered. At a guess.

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:07 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

Hello,

 

I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...

 

When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file created along each solve, for every point : 

 

WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm

 

I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.

 

When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate Solve Settings : 

 

 

CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -fov 0 -s 500 -r 5 -m 1 -t 0.007

 

 

 

From ASTAP documentation: 

 

If the FOV (image height in degrees)  is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP will use the FOV as set in the program, stack menu, tab alignment.

 

 

Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV  is already correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?

 

When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).

 

Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.

 

Sébastien


Re: APPM + ASTAP - Inaccurate FOV

ap@CaptivePhotons.com
 

What camera settings do you have?  I just looked at mine (from a plate solve and recal) and APPM did this:

Info, ASTAP Plate Solve, StartSolve: arguments: -f "C:\Users\ferguson\Documents\Astro-Physics\APPM\SyncNow-2021-10-04-201900.fit" -ra 19.8928444444444 -spd 91.07325 -fov 2.46918855501098 -s 1000 -r 5

 

I assume it’s calculating it from the image scale and pixel dimensions since it’s not entered. At a guess.

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Seb@stro via groups.io
Sent: Monday, October 4, 2021 9:07 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM + ASTAP - Inaccurate FOV

 

Hello,

 

I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...

 

When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file created along each solve, for every point : 

 

WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm

 

I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.

 

When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate Solve Settings : 

 

 

CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -fov 0 -s 500 -r 5 -m 1 -t 0.007

 

 

 

From ASTAP documentation: 

 

If the FOV (image height in degrees)  is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP will use the FOV as set in the program, stack menu, tab alignment.

 

 

Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV  is already correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?

 

When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).

 

Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.

 

Sébastien


Re: Slight Wiggle in Dec Axis of Mach2 Mount

Roland Christen
 

cool! Smile



-----Original Message-----
From: Bill Long <bill@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Mon, Oct 4, 2021 7:56 pm
Subject: Re: [ap-gto] Slight Wiggle in Dec Axis of Mach2 Mount

Fixed. 🙂


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Roland Christen via groups.io <chris1011@...>
Sent: Monday, October 4, 2021 5:51 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Slight Slop in Dec Axis of Mach2 Mount
 
I do have one request, the heading of Slop in Dec axis is a huge turnoff for me. For 2 reasons.

First, it suggests sloppiness, both in design and execution. Our design engineer is 6ft 3" and built like Arnold and he would take unkindly to the design being sloppy ;^)). Both Dave and I assemble the mounts and we are very careful in making sure that everything works exactly as intended. In fact, the tolerances are so tight that we have to shrink the bearings in our deep freeze in order to set them in their housing.

But the second reason is a bit different. back when my hobby was off-road endurance racing, we had one event each summer in south-western Wisconsin that was about 65 miles in length. The course went thru many farmer's back woods in the hills of the Driftless area (Driftless = untouched by the ice sheets that scoured the rest of the Midwest). This is rugged country and ideal for all kinds of off-road events.

Normally the farmers are all eager to lend the enduro clubs their wood sections for these races, but one of the most desirable sections was owned by a farmer who made one stipulation: the race had to go thru his pig wallow before heading up into his hills. He would set up a comfy chair on the hill overlooking the wallow, beer in hand and watch the racers run thru his 1/2 acre of foul smelling muck. Some of the novice racers would inevitably slide out and do a head-first dive into the mud. I always managed to make it thru without sliding out, but the stench stayed with me the rest of the race. Some of us would load the bikes on the trailers and or pickup trucks and head for the nearest do-it-yourself carwash. Of course we would also spray ourselves down too. So, every time I see the word slop, it brings back those memories and the foul stench thereupon.

Rolando

-----Original Message-----
From: mjb87 via groups.io <mjb87@...>
To: main@ap-gto.groups.io
Sent: Mon, Oct 4, 2021 7:14 pm
Subject: Re: [ap-gto] Slight Slop in Dec Axis of Mach2 Mount

Thank you for the very detailed explanation. It is both very helpful -- and also enlightening as to the details you folks at AP apply in your engineering.

--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics


APPM + ASTAP - Inaccurate FOV

Sébastien Doré
 

Hello,

I've reported this already a few days after APCC 1.9 went out but am not sure if it went through...

When doing an APPM run, even if every point solves successfully, I find it is always taking more time than I am used to with ASTAP (maybe a 4-5 seconds per solve). I also always get the below message in the INI file created along each solve, for every point : 

WARNING=Warning scale was inaccurate! Set FOV=0.40d, scale=0.4", FL=2127mm

I think it is caused by ASTAP being in "learn mode" and trying to brute force the FOV value.

When inspecting the call initiated by APPM (still in the same INI file), I also realized that the -fov argument is always set to '0', even if "Refine image scale from next solved image" box is unchecked in APPM's Plate Solve Settings : 



CMDLINE="C:\Program Files\astap\astap.exe" -f "C:\Users\Seb4stro\Documents\Astro-Physics\APPM\Image-APPM-2021-10-04-200258.txt-0004-RA_23.465-DEC_59.000.fit" -ra 23.4479155432537 -spd 148.879202814283 -fov 0 -s 500 -r 5 -m 1 -t 0.007



From ASTAP documentation: 

If the FOV (image height in degrees)  is unspecified in the command-line for RAW, PNG, TIFF files, ASTAP will use the FOV as set in the program, stack menu, tab alignment.


Which is how I would expect it to work when unticking the "Refine image scale..." box (my FOV  is already correctly set to 0.40 in ASTAP). Unless I'm misunderstanding about its true purpose ?

When I run the same command above from a dos prompt, but with the -fov 0.4 argument for example, ASTAP solves the sub almost instantly and shows no attempt to brute force the FOV in ASTAP's log. I believe the same happens if I omit entirely the -fov argument, but I'll have to confirm (after my run's finished).

Anybody with something similar using APPM + ASTAP ? Any help would be appreciated.

Sébastien


Re: Slight Wiggle in Dec Axis of Mach2 Mount

Bill Long
 

Fixed. 🙂


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Roland Christen via groups.io <chris1011@...>
Sent: Monday, October 4, 2021 5:51 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] Slight Slop in Dec Axis of Mach2 Mount
 
I do have one request, the heading of Slop in Dec axis is a huge turnoff for me. For 2 reasons.

First, it suggests sloppiness, both in design and execution. Our design engineer is 6ft 3" and built like Arnold and he would take unkindly to the design being sloppy ;^)). Both Dave and I assemble the mounts and we are very careful in making sure that everything works exactly as intended. In fact, the tolerances are so tight that we have to shrink the bearings in our deep freeze in order to set them in their housing.

But the second reason is a bit different. back when my hobby was off-road endurance racing, we had one event each summer in south-western Wisconsin that was about 65 miles in length. The course went thru many farmer's back woods in the hills of the Driftless area (Driftless = untouched by the ice sheets that scoured the rest of the Midwest). This is rugged country and ideal for all kinds of off-road events.

Normally the farmers are all eager to lend the enduro clubs their wood sections for these races, but one of the most desirable sections was owned by a farmer who made one stipulation: the race had to go thru his pig wallow before heading up into his hills. He would set up a comfy chair on the hill overlooking the wallow, beer in hand and watch the racers run thru his 1/2 acre of foul smelling muck. Some of the novice racers would inevitably slide out and do a head-first dive into the mud. I always managed to make it thru without sliding out, but the stench stayed with me the rest of the race. Some of us would load the bikes on the trailers and or pickup trucks and head for the nearest do-it-yourself carwash. Of course we would also spray ourselves down too. So, every time I see the word slop, it brings back those memories and the foul stench thereupon.

Rolando

-----Original Message-----
From: mjb87 via groups.io <mjb87@...>
To: main@ap-gto.groups.io
Sent: Mon, Oct 4, 2021 7:14 pm
Subject: Re: [ap-gto] Slight Slop in Dec Axis of Mach2 Mount

Thank you for the very detailed explanation. It is both very helpful -- and also enlightening as to the details you folks at AP apply in your engineering.

--
Roland Christen
Astro-Physics


Re: Slight Slop in Dec Axis of Mach2 Mount

Roland Christen
 

I do have one request, the heading of Slop in Dec axis is a huge turnoff for me. For 2 reasons.

First, it suggests sloppiness, both in design and execution. Our design engineer is 6ft 3" and built like Arnold and he would take unkindly to the design being sloppy ;^)). Both Dave and I assemble the mounts and we are very careful in making sure that everything works exactly as intended. In fact, the tolerances are so tight that we have to shrink the bearings in our deep freeze in order to set them in their housing.

But the second reason is a bit different. back when my hobby was off-road endurance racing, we had one event each summer in south-western Wisconsin that was about 65 miles in length. The course went thru many farmer's back woods in the hills of the Driftless area (Driftless = untouched by the ice sheets that scoured the rest of the Midwest). This is rugged country and ideal for all kinds of off-road events.

Normally the farmers are all eager to lend the enduro clubs their wood sections for these races, but one of the most desirable sections was owned by a farmer who made one stipulation: the race had to go thru his pig wallow before heading up into his hills. He would set up a comfy chair on the hill overlooking the wallow, beer in hand and watch the racers run thru his 1/2 acre of foul smelling muck. Some of the novice racers would inevitably slide out and do a head-first dive into the mud. I always managed to make it thru without sliding out, but the stench stayed with me the rest of the race. Some of us would load the bikes on the trailers and or pickup trucks and head for the nearest do-it-yourself carwash. Of course we would also spray ourselves down too. So, every time I see the word slop, it brings back those memories and the foul stench thereupon.

Rolando

-----Original Message-----
From: mjb87 via groups.io <mjb87@...>
To: main@ap-gto.groups.io
Sent: Mon, Oct 4, 2021 7:14 pm
Subject: Re: [ap-gto] Slight Slop in Dec Axis of Mach2 Mount

Thank you for the very detailed explanation. It is both very helpful -- and also enlightening as to the details you folks at AP apply in your engineering.

--
Roland Christen
Astro-Physics

4941 - 4960 of 86742