Re: Pier crash while #APPM paused -


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@...> 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.

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













Join main@ap-gto.groups.io to automatically receive all group messages.