Pier crash while #APPM paused -


Seb@stro
 
Edited

Hi,

I started a dummy modeling APPM run indoor last night using the NASA Skyview camera and the Mach2. Platesolving wasn’t especially great at those Nasa Skyview images and so slow that at some point, I just hit “Pause” in APPM RUN tab and went to bed, not noticing the mount was still tracking (my bad, should have checked APCC before leaving everything there)...

This morning, the scope was obviously upside-down and camera against one of my tripod’s leg. That was expected since I have no limits set anywhere.

What I didn’t expect was that the motor didn’t stall. It was still pushing the OTA/camera against the leg and I was hearing a low-pitched rattling sound (that kinda woke me up) like if the motor belt was slipping or something.

My questions are :

- Is this normal behavior in this kind of situation? Shouldn't the motor stall under a "tracking" pier crash ?
- Could this cause damage to the mount ?
- Is it normal that the platesolving (w/ASTAP) is very slow with NASA skyview images ? (I suppose it is as it seemed to fail "near" solving for each image and always fell back to "all-sky" solving before going to the next, just to solve a few in the end).
- Is it to be expected to get so little successfully solved images with Skyview Images or am I just doing something wrong and dumb ?

Sébastien

Logs here: https://www.carpe-noctem.space/cms/wp-content/uploads/2021/08/ApccZip-Sebastien_Dore-2021-08-22-133536.zip


Ray Gralak
 

- Is it normal that the platesolving (w/ASTAP) is very slow with NASA skyview images ?
That's a matter of the performance of your computer and the plate-solver.

- Is it to be expected to get so little successfully solved images with Skyview Images
or am I just doing something wrong and dumb ?
If you were using SkyX, PinPoint, or PlateSolve2, I would be surprised.

If it's ASTAP, it's likely the plate-solver settings. I found that although ASTAP was the fastest of the plate-solvers, it often failed to solve if its settings are not set correctly. Particularly, increasing the "Max Number of Stars" would sometimes help. If you can't get ASTAP to solve, try posting the images to the ASTAP forum so the author can research the issue.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Seb@stro
Sent: Sunday, August 22, 2021 6:59 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] Pier crash while #APPM paused -

[Edited Message Follows]
[Reason: Added link to logs]

Hi,

I started a dummy modeling APPM run indoor last night using the NASA Skyview camera and the Mach2.
Platesolving wasn’t especially great at those Nasa Skyview images and so slow that at some point, I just hit “Pause”
in APPM RUN tab and went to bed, not noticing the mount was still tracking (my bad, should have checked APCC
before leaving everything there)...

This morning, the scope was obviously upside-down and camera against one of my tripod’s leg. That was expected
since I have no limits set anywhere.

What I didn’t expect was that the motor didn’t stall. It was still pushing the OTA/camera against the leg and I was
hearing a low-pitched rattling sound (that kinda woke me up) like if the motor belt was slipping or something.

My questions are :

- Is this normal behavior in this kind of situation? Shouldn't the motor stall under a "tracking" pier crash ?
- Could this cause damage to the mount ?
- Is it normal that the platesolving (w/ASTAP) is very slow with NASA skyview images ? (I suppose it is as it seemed
to fail "near" solving for each image and always fell back to "all-sky" solving before going to the next, just to solve a
few in the end).
- Is it to be expected to get so little successfully solved images with Skyview Images or am I just doing something
wrong and dumb ?

Sébastien

Logs here: https://www.carpe-noctem.space/cms/wp-content/uploads/2021/08/ApccZip-Sebastien_Dore-2021-08-
22-133536.zip




ap@CaptivePhotons.com
 

Ray said:

If it's ASTAP, it's likely the plate-solver settings. I found that although ASTAP was the fastest of the plate-solvers, it often failed to solve if its settings are not set correctly. Particularly, increasing the "Max Number of Stars" would sometimes help. If you can't get ASTAP to solve, try posting the images to the ASTAP forum so the author can research the issue.
Especially if you had it loaded for a while, it is also important to check you have a database that matches the image scale. See

https://www.hnsky.org/astap.htm

H17 doesn't work well at very small field of views. If I recall you have to both install and switch to it if another was in use, two steps.

I also had trouble with sky survey images when I did my first tests, and did not really figure out why. I also tried solving them in ASTAP directly so confirmed it was not a APPM issue, or NINA; I also tried TSX's image link and had them fail. Only astronometry.net would work.

It seemed odd that sky survey images would not solve, but as soon as I used real images taken myself, it all worked great and fast.

I wonder if it is because sky surveys are mosaics and when you pick an arbitrary point the simulated image is including pieces of several images, and their blending is not perfect (or more precisely whatever they do to blend is not the equivalent distortion of a single image at that point). That's speculation.

It all worked great when I stopped simulating.

Linwood


Dale Ghent
 

Coming from supporting ASTAP with NINA users, the #1 pitfall we see is that the wrong (or inappropriate, to use another word) star database is used.

Han supplies a bunch of different star databases that ASTAP can use, the two main ones being the H17 and H18 databases. The number refers to the limiting magnitude of the stars present in the database. This of course means that the H17 database is a subset of the H18 one. We always recommend that the H18 database be used when the focal length is > 1m, as that starts getting into a constricted-enough FOV where the H17 database might not define enough stars for ASTAP to find a solution with.

The difference between the two databases is size - the H18 db is 1GB and H17 is half that size, so one can roll with the H18 database even if they don't really /need/ those extra stars if they don't mind burning the 500MB extra drive space for it.

ASTAP will insert any warnings or errors it encountered into the .wcs file it generates for each solve attempt. It'll do this with a "WARNING" or "ERROR" FITS keyword, with the fault message being a string. If ASTAP complains about finding an insufficient number of stars and you have the H17 db installed, then it's quite likely that the user will need the H18 db instead. In NINA, we'll extract any WARNING or ERROR keyword from the .wcs file and bubble it up to the user as a notification.

On Aug 22, 2021, at 22:40, Ray Gralak <iogroups@siriusimaging.com> wrote:

- Is it normal that the platesolving (w/ASTAP) is very slow with NASA skyview images ?
That's a matter of the performance of your computer and the plate-solver.

- Is it to be expected to get so little successfully solved images with Skyview Images
or am I just doing something wrong and dumb ?
If you were using SkyX, PinPoint, or PlateSolve2, I would be surprised.

If it's ASTAP, it's likely the plate-solver settings. I found that although ASTAP was the fastest of the plate-solvers, it often failed to solve if its settings are not set correctly. Particularly, increasing the "Max Number of Stars" would sometimes help. If you can't get ASTAP to solve, try posting the images to the ASTAP forum so the author can research the issue.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Seb@stro
Sent: Sunday, August 22, 2021 6:59 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] Pier crash while #APPM paused -

[Edited Message Follows]
[Reason: Added link to logs]

Hi,

I started a dummy modeling APPM run indoor last night using the NASA Skyview camera and the Mach2.
Platesolving wasn’t especially great at those Nasa Skyview images and so slow that at some point, I just hit “Pause”
in APPM RUN tab and went to bed, not noticing the mount was still tracking (my bad, should have checked APCC
before leaving everything there)...

This morning, the scope was obviously upside-down and camera against one of my tripod’s leg. That was expected
since I have no limits set anywhere.

What I didn’t expect was that the motor didn’t stall. It was still pushing the OTA/camera against the leg and I was
hearing a low-pitched rattling sound (that kinda woke me up) like if the motor belt was slipping or something.

My questions are :

- Is this normal behavior in this kind of situation? Shouldn't the motor stall under a "tracking" pier crash ?
- Could this cause damage to the mount ?
- Is it normal that the platesolving (w/ASTAP) is very slow with NASA skyview images ? (I suppose it is as it seemed
to fail "near" solving for each image and always fell back to "all-sky" solving before going to the next, just to solve a
few in the end).
- Is it to be expected to get so little successfully solved images with Skyview Images or am I just doing something
wrong and dumb ?

Sébastien

Logs here: https://www.carpe-noctem.space/cms/wp-content/uploads/2021/08/ApccZip-Sebastien_Dore-2021-08-
22-133536.zip









Andrea Lucchetti
 

Thank you Dale, I am going to try Nina soon and this is good info.
One thing I don’t get, I wonder what could be the difference using plate solve images that are 4 seconds and binning 2x2. If the difference between H17 and H18 is the magnitude it shouldn’t make much difference.
By the way my fov will be bigger than 1 deg and will install the H18 as suggested.
Thank you,
Andrea 

Il giorno lun 23 ago 2021 alle 14:46 Dale Ghent <daleg@...> ha scritto:


Coming from supporting ASTAP with NINA users, the #1 pitfall we see is that the wrong (or inappropriate, to use another word) star database is used.

Han supplies a bunch of different star databases that ASTAP can use, the two main ones being the H17 and H18 databases. The number refers to the limiting magnitude of the stars present in the database. This of course means that the H17 database is a subset of the H18 one. We always recommend that the H18 database be used when the focal length is > 1m, as that starts getting into a constricted-enough FOV where the H17 database might not define enough stars for ASTAP to find a solution with.

The difference between the two databases is size - the H18 db is 1GB and H17 is half that size, so one can roll with the H18 database even if they don't really /need/ those extra stars if they don't mind burning the 500MB extra drive space for it.

ASTAP will insert any warnings or errors it encountered into the .wcs file it generates for each solve attempt. It'll do this with a "WARNING" or "ERROR" FITS keyword, with the fault message being a string. If ASTAP complains about finding an insufficient number of stars and you have the H17 db installed, then it's quite likely that the user will need the H18 db instead. In NINA, we'll extract any WARNING or ERROR keyword from the .wcs file and bubble it up to the user as a notification.

> On Aug 22, 2021, at 22:40, Ray Gralak <iogroups@...> wrote:
>
>> - Is it normal that the platesolving (w/ASTAP) is very slow with NASA skyview images ?
>
> That's a matter of the performance of your computer and the plate-solver.
>
>> - Is it to be expected to get so little successfully solved images with Skyview Images
>> or am I just doing something wrong and dumb ?
>
> If you were using SkyX, PinPoint, or PlateSolve2, I would be surprised.
>
> If it's ASTAP, it's likely the plate-solver settings. I found that although ASTAP was the fastest of the plate-solvers, it often failed to solve if its settings are not set correctly. Particularly, increasing the "Max Number of Stars" would sometimes help. If you can't get ASTAP to solve, try posting the images to the ASTAP forum so the author can research the issue.
>
> -Ray
>
>> -----Original Message-----
>> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Seb@stro
>> Sent: Sunday, August 22, 2021 6:59 PM
>> To: main@ap-gto.groups.io
>> Subject: [ap-gto] Pier crash while #APPM paused -
>>
>> [Edited Message Follows]
>> [Reason: Added link to logs]
>>
>> Hi,
>>
>> I started a dummy modeling APPM run indoor last night using the NASA Skyview camera and the Mach2.
>> Platesolving wasn’t especially great at those Nasa Skyview images and so slow that at some point, I just hit “Pause”
>> in APPM RUN tab and went to bed, not noticing the mount was still tracking (my bad, should have checked APCC
>> before leaving everything there)...
>>
>> This morning, the scope was obviously upside-down and camera against one of my tripod’s leg. That was expected
>> since I have no limits set anywhere.
>>
>> What I didn’t expect was that the motor didn’t stall. It was still pushing the OTA/camera against the leg and I was
>> hearing a low-pitched rattling sound (that kinda woke me up) like if the motor belt was slipping or something.
>>
>> My questions are :
>>
>> - Is this normal behavior in this kind of situation? Shouldn't the motor stall under a "tracking" pier crash ?
>> - Could this cause damage to the mount ?
>> - Is it normal that the platesolving (w/ASTAP) is very slow with NASA skyview images ? (I suppose it is as it seemed
>> to fail "near" solving for each image and always fell back to "all-sky" solving before going to the next, just to solve a
>> few in the end).
>> - Is it to be expected to get so little successfully solved images with Skyview Images or am I just doing something
>> wrong and dumb ?
>>
>> Sébastien
>>
>> Logs here: https://www.carpe-noctem.space/cms/wp-content/uploads/2021/08/ApccZip-Sebastien_Dore-2021-08-
>> 22-133536.zip
>>
>>
>>
>>
>
>
>
>
>
>
>







Dale Ghent
 

Which database you need to use when operating in a realm that can overlap the H17 and H18 ones is a big "it depends". FOVs that are larger than 1 degree will /likely/ be ok with V17 or H17.

It will not only depend on your fov, but also your exposure time, which is related to your focal ratio, and there are other influences such as if one bins their plate solve exposures (which is not a bad universal suggestion.) This is why my advice is to use H18 if your focal length is > 1m. I prefer to make this simple rule instead of playing games with 5 different parameters to answer what is a very simple question. The only casualty is 500MB extra disk space.

Han has written an extensive section in the ASTAP documentation if one really wants to get into the details around which database is most appropriate. You can find it here: http://www.hnsky.org/astap.htm#database_usability

On Aug 23, 2021, at 08:58, Andrea Lucchetti <andlucchett@gmail.com> wrote:

Thank you Dale, I am going to try Nina soon and this is good info.
One thing I don’t get, I wonder what could be the difference using plate solve images that are 4 seconds and binning 2x2. If the difference between H17 and H18 is the magnitude it shouldn’t make much difference.
By the way my fov will be bigger than 1 deg and will install the H18 as suggested.
Thank you,
Andrea
Il giorno lun 23 ago 2021 alle 14:46 Dale Ghent <daleg@elemental.org> ha scritto:


Coming from supporting ASTAP with NINA users, the #1 pitfall we see is that the wrong (or inappropriate, to use another word) star database is used.

Han supplies a bunch of different star databases that ASTAP can use, the two main ones being the H17 and H18 databases. The number refers to the limiting magnitude of the stars present in the database. This of course means that the H17 database is a subset of the H18 one. We always recommend that the H18 database be used when the focal length is > 1m, as that starts getting into a constricted-enough FOV where the H17 database might not define enough stars for ASTAP to find a solution with.

The difference between the two databases is size - the H18 db is 1GB and H17 is half that size, so one can roll with the H18 database even if they don't really /need/ those extra stars if they don't mind burning the 500MB extra drive space for it.

ASTAP will insert any warnings or errors it encountered into the .wcs file it generates for each solve attempt. It'll do this with a "WARNING" or "ERROR" FITS keyword, with the fault message being a string. If ASTAP complains about finding an insufficient number of stars and you have the H17 db installed, then it's quite likely that the user will need the H18 db instead. In NINA, we'll extract any WARNING or ERROR keyword from the .wcs file and bubble it up to the user as a notification.

On Aug 22, 2021, at 22:40, Ray Gralak <iogroups@siriusimaging.com> wrote:

- Is it normal that the platesolving (w/ASTAP) is very slow with NASA skyview images ?
That's a matter of the performance of your computer and the plate-solver.

- Is it to be expected to get so little successfully solved images with Skyview Images
or am I just doing something wrong and dumb ?
If you were using SkyX, PinPoint, or PlateSolve2, I would be surprised.

If it's ASTAP, it's likely the plate-solver settings. I found that although ASTAP was the fastest of the plate-solvers, it often failed to solve if its settings are not set correctly. Particularly, increasing the "Max Number of Stars" would sometimes help. If you can't get ASTAP to solve, try posting the images to the ASTAP forum so the author can research the issue.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Seb@stro
Sent: Sunday, August 22, 2021 6:59 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] Pier crash while #APPM paused -

[Edited Message Follows]
[Reason: Added link to logs]

Hi,

I started a dummy modeling APPM run indoor last night using the NASA Skyview camera and the Mach2.
Platesolving wasn’t especially great at those Nasa Skyview images and so slow that at some point, I just hit “Pause”
in APPM RUN tab and went to bed, not noticing the mount was still tracking (my bad, should have checked APCC
before leaving everything there)...

This morning, the scope was obviously upside-down and camera against one of my tripod’s leg. That was expected
since I have no limits set anywhere.

What I didn’t expect was that the motor didn’t stall. It was still pushing the OTA/camera against the leg and I was
hearing a low-pitched rattling sound (that kinda woke me up) like if the motor belt was slipping or something.

My questions are :

- Is this normal behavior in this kind of situation? Shouldn't the motor stall under a "tracking" pier crash ?
- Could this cause damage to the mount ?
- Is it normal that the platesolving (w/ASTAP) is very slow with NASA skyview images ? (I suppose it is as it seemed
to fail "near" solving for each image and always fell back to "all-sky" solving before going to the next, just to solve a
few in the end).
- Is it to be expected to get so little successfully solved images with Skyview Images or am I just doing something
wrong and dumb ?

Sébastien

Logs here: https://www.carpe-noctem.space/cms/wp-content/uploads/2021/08/ApccZip-Sebastien_Dore-2021-08-
22-133536.zip














Seb@stro
 

That's good information indeed.

In my case I really don't think it has something to do with my computer performance as when I use ASTAP directly I am able to solve almost anything in less than 2 seconds.

Also since I use an SCT at more than 2000mm FL and a 300mm FL refractor, I have been using all available database (V17, G17, H17 an H18) from the start, so I don't think it's related to that either. Unless I should remove the oldest V17 and G17 and only use the H1x ? I always have the H18 selected in ASTAP but sometimes it seem to choose H17 first anyway and fall back to H18 if it doesn't find a solution.

Han has written an extensive section in the ASTAP documentation if one really wants to get into the details around which database is most appropriate. You can find it here: http://www.hnsky.org/astap.htm#database_usability

Thanks for the link, I think I already went through it rapidly at some point. Will try to get to the finest details to see if I can find something interesting that could help.

 In NINA, we'll extract any WARNING or ERROR keyword from the .wcs file and bubble it up to the user as a notification.
That's definitely going to be useful to help troubleshoot such issues.

Anyway, thanks for the good tips guys! I guess I'll wait for the real stars to get unclouded and see how it goes in real conditions to really assess what the issue might be / or if it still exists, as Linwood experienced.

Sébastien



De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Dale Ghent <daleg@...>
Envoyé : 23 août 2021 10:05
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] Pier crash while #APPM paused -
 

Which database you need to use when operating in a realm that can overlap the H17 and H18 ones is a big "it depends". FOVs that are larger than 1 degree will /likely/ be ok with V17 or H17.

It will not only depend on your fov, but also your exposure time, which is related to your focal ratio, and there are other influences such as if one bins their plate solve exposures (which is not a bad universal suggestion.) This is why my advice is to use H18 if your focal length is > 1m. I prefer to make this simple rule instead of playing games with 5 different parameters to answer what is a very simple question. The only casualty is 500MB extra disk space.

Han has written an extensive section in the ASTAP documentation if one really wants to get into the details around which database is most appropriate. You can find it here: http://www.hnsky.org/astap.htm#database_usability



> On Aug 23, 2021, at 08:58, Andrea Lucchetti <andlucchett@...> wrote:
>
> Thank you Dale, I am going to try Nina soon and this is good info.
> One thing I don’t get, I wonder what could be the difference using plate solve images that are 4 seconds and binning 2x2. If the difference between H17 and H18 is the magnitude it shouldn’t make much difference.
> By the way my fov will be bigger than 1 deg and will install the H18 as suggested.
> Thank you,
> Andrea
> Il giorno lun 23 ago 2021 alle 14:46 Dale Ghent <daleg@...> ha scritto:
>
>
> Coming from supporting ASTAP with NINA users, the #1 pitfall we see is that the wrong (or inappropriate, to use another word) star database is used.
>
> Han supplies a bunch of different star databases that ASTAP can use, the two main ones being the H17 and H18 databases. The number refers to the limiting magnitude of the stars present in the database. This of course means that the H17 database is a subset of the H18 one. We always recommend that the H18 database be used when the focal length is > 1m, as that starts getting into a constricted-enough FOV where the H17 database might not define enough stars for ASTAP to find a solution with.
>
> The difference between the two databases is size - the H18 db is 1GB and H17 is half that size, so one can roll with the H18 database even if they don't really /need/ those extra stars if they don't mind burning the 500MB extra drive space for it.
>
> ASTAP will insert any warnings or errors it encountered into the .wcs file it generates for each solve attempt. It'll do this with a "WARNING" or "ERROR" FITS keyword, with the fault message being a string. If ASTAP complains about finding an insufficient number of stars and you have the H17 db installed, then it's quite likely that the user will need the H18 db instead. In NINA, we'll extract any WARNING or ERROR keyword from the .wcs file and bubble it up to the user as a notification.



Ray Gralak
 

I also had trouble with sky survey images when I did my first tests, and did not really figure out why. I also tried
solving them in ASTAP directly so confirmed it was not a APPM issue, or NINA; I also tried TSX's image link and
had them fail. Only astronometry.net would work.
TSX and PinPoint should solve the images provided you have the image scale set correctly. Also, TSX requires some additional setup that is described in the APPM help's section.

I get fast solutions with SkyX, although I do have the TheSky Pro Database add-on.

ASTAP usually requires tinkering of the settings to get it to work consistently.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@CaptivePhotons.com
Sent: Monday, August 23, 2021 4:55 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Pier crash while #APPM paused -

Ray said:

If it's ASTAP, it's likely the plate-solver settings. I found that although ASTAP was the fastest of the plate-solvers,
it often failed to solve if its settings are not set correctly. Particularly, increasing the "Max Number of Stars" would
sometimes help. If you can't get ASTAP to solve, try posting the images to the ASTAP forum so the author can
research the issue.

Especially if you had it loaded for a while, it is also important to check you have a database that matches the image
scale. See

https://www.hnsky.org/astap.htm

H17 doesn't work well at very small field of views. If I recall you have to both install and switch to it if another was in
use, two steps.

I also had trouble with sky survey images when I did my first tests, and did not really figure out why. I also tried
solving them in ASTAP directly so confirmed it was not a APPM issue, or NINA; I also tried TSX's image link and
had them fail. Only astronometry.net would work.

It seemed odd that sky survey images would not solve, but as soon as I used real images taken myself, it all worked
great and fast.

I wonder if it is because sky surveys are mosaics and when you pick an arbitrary point the simulated image is
including pieces of several images, and their blending is not perfect (or more precisely whatever they do to blend is
not the equivalent distortion of a single image at that point). That's speculation.

It all worked great when I stopped simulating.

Linwood