Date   

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@CaptivePhotons.com
<ap@CaptivePhotons.com>
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@CaptivePhotons.com <ap@CaptivePhotons.com>
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


Re: Slight Slop in Dec Axis of Mach2 Mount

mjb87@...
 

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.


Re: Slight Slop in Dec Axis of Mach2 Mount

Roland Christen
 

Slight mesh issue can be caused by a couple of things. In the Dec axis we set the spring tension to be very minimal to avoid stiction (static friction). Stiction is the main cause of poor guiding in Dec because it results in retrograde motion which is common in almost every mount that has spring loaded worm mesh. If the mesh is not 100% in a non-encoder mount it causes backlash delay when reversing, but encoder mounts don't have backlash even if the worm mesh is not 100%.

However, the problem of stiction is much worse for both encoder and non-encoder mounts. Retrograde motion means that when reversing, if the star error is slightly above the zero line it will first go further above the line before finally heading towards zero point. If it would stay there, that would be fine, but it usually overshoots at that point (release of static friction) and the whole cycle repeats in the opposite direction. It results in what control theory calls limit cycling and is a type of oscillation instability that is contained within boundaries.

Therefore to prevent stiction, we purposely set the Dec spring pressure low so as not to get into that possibility ever. We let the encoder eliminate the backlash delay if there is slight de-mesh between worm and worm wheel teeth. The mounts go out with the Dec axis tested for proper mesh, but possibly during shipping and later use with heavy loads the adjustment of the spring pressure is not enough for full mesh. The spring pressure can be increased, and I found that after a number of weeks of steady use, the problem of stiction is reduced considerably just from the worm and worm wheel polishing themselves thru use.

If you want to do a preliminary adjustment I would recommend checking the pivot bolt first before adjusting the spring pressure:

Your pivot bolt might be too tight which is preventing the worm from pivoting fully into mesh. It's an easy adjustment.
Remove the outer motor box cover and set it aside with its 4 screws.
Remove the 4 screws that hold the inner cover and put those screws aside in another place, but do not mix them with the outer screws!
Now slide the inner cover back and out of the way to expose the worm assembly. You don't need to remove it entirely.

First make sure that the 3 Allen screws that hold the motor assembly to the RA axis are fully tight. If they are, then proceed with the next step:

Referring to the image below, loosen the locking screw #1 (5/64 Allen Key). Then with a 1/4" Allen key loosen the pivot bolt #2 about 1/2 turn ccw while gently pushing on the scope. Gently! not with guerilla force please. It should stiffen up as the worm mates with the worm wheel teeth. Once it is in full mesh, tighten the pivot bolt a small amount and again feel the axis to make sure that it is meshed. You can then push down on the top back of the motor to bring the worm slightly out of mesh, then let go to allow the springs to pop the worm teeth back into mesh. The motor assembly should be able to rotate slightly in and out of mesh when you apply force to the back of the motor.

If everything feels right, re-tighten the locking screw. Then replace the inner motor cover with the shorter 4 screws (very important that you do not use the outer cover screws!!) Finish by replacing the outer cover.

Roland Christen
Astro-Physics Inc.







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

Thanks, Roland.

I certainly did not notice any impact on imaging -- getting excellent unguided results. I'll leave it alone for the time being.

Marty

--
Roland Christen
Astro-Physics


Re: Slight Slop in Dec Axis of Mach2 Mount

mjb87@...
 

Thanks, Roland.

I certainly did not notice any impact on imaging -- getting excellent unguided results. I'll leave it alone for the time being.

Marty


Re: Slight Slop in Dec Axis of Mach2 Mount

Roland Christen
 

Won't affect you imaging at all but if you want, go ahead and adjust.

Roland

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

My Mach2 has a bit of slop in the Dec axis. With clutches tight I can move the axis a very small amount. The RA axis, in contrast, is rock solid.

Another individual posted a similar problem regarding slop in the RA axis of his Mach 2: https://ap-gto.groups.io/g/main/message/81162

Do I need to follow the same process, in this case on my Dec axis?

Marty

--
Roland Christen
Astro-Physics


Slight Slop in Dec Axis of Mach2 Mount

mjb87@...
 

My Mach2 has a bit of slop in the Dec axis. With clutches tight I can move the axis a very small amount. The RA axis, in contrast, is rock solid.

Another individual posted a similar problem regarding slop in the RA axis of his Mach 2: https://ap-gto.groups.io/g/main/message/81162

Do I need to follow the same process, in this case on my Dec axis?

Marty


Re: Smart Meridian Flip with NINA #APCC

Joseph Beyer
 

Not sure yet.  I got APCC working again with CdC and NINA yesterday but haven't run another sequence yet due to overcast skies.  The .mlm file I was using during the last sequencer run with the errant smart meridian flip is posted here:

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


Re: APCC - APPM - and ASTAP

Jack Huerkamp
 

I was not running the mount at all.  I was inside my house running ASTAP in stand alone mode on my home computer to become familiar with it.  According to the ASTAP site, it is possible to solve images by feeding them directly into the program.  That is what I was trying to do, and no matter what image I fed into the program, it failed to solve.  That is when I contacted Han at hnsky.org and he provided things to try to get the images to solve – and they did. 

 

Once I am out in the observatory and running ASTAP with APPM on my mount, scope and camera, hopefully all will work as designed.

 

Yours truly,

 

Jack

 

Jack Huerkamp

Jack's Astro Accessories, LLC

38388 Pine Street

Pearl River, LA 70452-5192

985-445-5063

mallincamusa@...

www.mallincamusa.com

30.37N  89.76W

 

All of us get lost in the darkness.
Dreamers learn to steer by the stars.

………………………………….Neil Peart

 

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of ap@...
Sent: Monday, October 04, 2021 12:24 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC - APPM - and ASTAP

 

Jack Huerkamp wrote:

 

  • Mainly image scale, but putting a rough RA and Dec into the boxes so that the program did not have to search the entire sky helped a lot.  I assume that when running APPM with ASTAP, I will see the target RA and Dec and then I will be able to input them into ASTAP to help refine the plate solving.  I will find out once the skies clear here in SE Louisiana.

 

No,  you should not need to, the RA/DEC should be provided by the connection to your mount and/or by the FITS headers (not completely sure which, they both provide it).

 

If you were doing this running the simulator you should also connect to the same simulator in APPM and NINA.  Both NINA and APPM should have a connection to the (same) mount.

 


Virus-free. www.avg.com


Re: APCC - APPM - and ASTAP

Jack Huerkamp
 

Roland,

 

I was not trying to run the mount during the day using APCC.  I was attempting to learn how ASTAP works by feeding into it previously captured images and solving for them in the program.  Initially every solve I attempted failed and I contacted Han at hnsky.org.  He was able to make suggestions on things to set up in ASTAP and once I did so, the images I fed into the program did solve.

 

Now that I know that ASTAP works with images produced with my scope/camera combo, I will try doing a APPM run as soon as it clears.

 

Yours truly,

 

Jack

 

Jack Huerkamp

Jack's Astro Accessories, LLC

38388 Pine Street

Pearl River, LA 70452-5192

985-445-5063

mallincamusa@...

www.mallincamusa.com

30.37N  89.76W

 

All of us get lost in the darkness.
Dreamers learn to steer by the stars.

………………………………….Neil Peart

 

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Roland Christen via groups.io
Sent: Monday, October 04, 2021 12:31 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC - APPM - and ASTAP

 

During simulation is the mount actually pointing to the object? How would you know if it was done indoors during the day?

 

Roland

 

 

-----Original Message-----
From: ap@... <ap@...>
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Sent: Mon, Oct 4, 2021 12:23 pm
Subject: Re: [ap-gto] APCC - APPM - and ASTAP

Jack Huerkamp wrote:

 

  • Mainly image scale, but putting a rough RA and Dec into the boxes so that the program did not have to search the entire sky helped a lot.  I assume that when running APPM with ASTAP, I will see the target RA and Dec and then I will be able to input them into ASTAP to help refine the plate solving.  I will find out once the skies clear here in SE Louisiana.

 

No,  you should not need to, the RA/DEC should be provided by the connection to your mount and/or by the FITS headers (not completely sure which, they both provide it).

 

If you were doing this running the simulator you should also connect to the same simulator in APPM and NINA.  Both NINA and APPM should have a connection to the (same) mount.

 


--
Roland Christen
Astro-Physics


Virus-free. www.avg.com


Re: RA Mesh adjustment for 2104 model Mach 1 GTO

nicholas
 

yes I can absolutely do these. It is supposed to be clear tomorrow night. 


Re: APCC - APPM - and ASTAP

ap@CaptivePhotons.com
 

Roland Christen wrote:

 

  • During simulation is the mount actually pointing to the object? How would you know if it was done indoors during the day?

 

 

When I do it, I use the real mount and a camera simulator that downloads sky surveys.   I pick objects current “out” in daylight, so no time shenanigans.

 

The mount actually slews, etc. does everything as usual (with or without an OTA, usually without).

 

The sky survey download is generated based on the coordinates the mount shows, and you can set a tolerance (e.g. tell it to be off by 50” or whatever).  This lets you throw a bit of error into the mix, however it prevents you from reliably syncing since it then consistently stays off about that much.

 

I THINK that the ASCOM telescope simulator will all do the same, but have not tried that.

 

I’ve had very good luck debugging issues like meridian flips doing it all in daylight.  I generally avoid plate solving, an definitely avoid auto focus runs since the simulated images are always in focus.

 

Linwood

 

4641 - 4660 of 86432