kellimtai Asiair non pro.

According to the ASIAIR User's Manual, the original ASIAIR only supports Plate Solving for an FOV that is greater than 0.4º .

When you are just outside the 0.4º range, it may sometimes work and sometime not work, depending on the number of asterisms that it finds in your camera's FOV. Sometimes, changing the camera angle will give it more asterisms to work with.

Unfortunately, you will need to either use the v2 ASIAIR, a reducer for your telescope, or a camera that has a larger sensor.

Chen

I have an 8se with a focal length of 2080. Plate solving works most of the time if the sky is clear. So the focal length is not a problem. I find that bin4 works well as it makes the stars smaller.

Rog

w7ay hi thx for the info.
Well I do some analyses and of course putting a reducer will more make trouble to my images. So I need to stay as much native as possible. The idea of a biger sensor is a solution. So the best will be to pass to the Asiair pro but what is the minimum FOR with it?
Then this could me my next item.

Kind regards

suttonrog I will try your proposition to see if it help.
Thx

Plate solving requires sharp round stars.. With such long focal lengths the stars can get bloated and cover many pixels. The software then rejects them as stars (DSS will also reject them). By binning, the star size is reduced and made sharper and any noise wont be mistaken as a star,
I notice that you are using full gain. Try dropping it to cut down on noise and false stars.

Rog

suttonrog oh good idea, didn't try that, an other option to try out.
Thx

The object I try to get is located at 12h26' +12°33'
So you will understand why I need native equipment.

kellimtai The object I try to get is located at 12h26' +12°33'
So you will understand why I need native equipment.

Yeah, the skies near NGC4388 has few stars to use for plate solving. Lots of small, dim galaxies in that region, but they cannot be used for plate solving (they are not even in star databases).

As a last resort, GOTO a part of the sky nearby that has more stars and do a plate solve there, then sync your mount before doing a blind goto to your final target. With good mounts, good polar alignment, and good leveling of the mount, you should end up quite close to your target.

As a really, really last resort, take an image and submit to astrometry.net to plate solve after doing an initial GOTO with ASIAIR. Then apply the difference in RA and Declination that is obtained from astrometry.net to the ASIAIR for a blind GOTO.

Good luck,
Chen

w7ay yes it was the idea to do it that way but unfortunately the wather conditions changed fir tonight so will have to do it a other day. In case I couldn't catch it with the RC I got the option to use my newton 200/1000 and try it with that it do open twice the size of opening.

elpajare hi
I shared 2 pics just above to show how many stars it get if I put my gain at max and the exposition time at 10sec.
In average I get in that configuration 180 stars if it is at a right place with a lot of stars but due of the little window i get with the RC it shrinks to get enough stars in a combination but what's strange is, it's before I got the possibility to catch the PA without problems still using the first gen Asiair.
But if the VW Asiair is more capable with a more little window of course it will be my next investment. But also consider I need ZWO to investigate in a little camera like the asi174 but with integrated GPS to do my work in asteroid ocultation. It need to be very precise at the frame per integrated time.
Well this is of course not for the RC it's more for a fast newton.
Actually I will test some proposition tonight the sky is a bit shitty but should be enough for testing.
If it runs well tomorrow I will get a good weather condition to try it again and do my work elsewhere I have to use the 200/1000 newton.

Thx to Chen and the other, I will replay my test later.

I am more concerned with the magnitude than the number of stars. It would be interesting to know what the limiting magnitude is for Asiair to take them into account.
I also have problems with platesolving and stacking.

To better understand each other, I am using an RC 203/1824 with the ASI294MC and my preview is 5 seconds with maximum gain.

elpajare I am more concerned with the magnitude than the number of stars. It would be interesting to know what the limiting magnitude is for Asiair to take them into account.

Like you, I do not have source code to look at. Its a shame, because many of the outstanding bugs would be found in a few hours by cloud sleuths.

However, from casual observations, the Detect Star tools and the Plate solve tools appear to use different number of stars. It makes sense because the former cannot use saturated stars to estimate the HFD (notice it leaves out saturated stars), while the latter has to admit every star to create the asterisms (check out astrometry.net's document; ASIAIR has to be using something similar).

Brighter star magnitudes are important of course, due to better signal to noise ratio. But there are other factors too, sensor read noise, sensor gain vs exposure time, sky background (SQM or Bortle), filters, tracking stability,...

I also suspect that it is better to have many stars with similar magnitudes, instead of a couple of very bright stars, and the rest too dim to use.

I don't know how ZWO picks stars to include in the ASIAIR plate solving database. If it were me, I will not pick a fixed magnitude to include in the database, but pick stars so that the star density (or more accurately, the density of asterisms) remains moderately constant (dimmer threshold in star-poor areas of the sky). This will keep the database small, while being less finicky with camera angles and where in the sky you are plate solving, and it may give a smaller FOV on average (why include as many stars in the middle of Cygnus, for example).

Chen

StevenEvan These are the plate solving files included in the ASIAIR Pro

Interesting that ASIAIR includes the 4204 through 4206 files from the 42xx series, while the 42xx series at astrometry.net goes from 4201 (smallest asterisms) to 4207 (largest asterisms).

I wonder if ASIAIR will automatically scan the folder for other series 4200 files (e.g., 4203 to support smaller FOV for example) if we add them to the folder.

The total size of the 4203 files is about 2.5 GB.

Chen

Nice work both.
A quick way to check you image is to download ASTAP onto your PC with its reference files and use this to check your image. I find that this works most of the time.
https://www.hnsky.org/astap.htm
Rog

StevenEvan The AAP installed index files are a total of 2.47GB in size and ZWO load all of these into memory and search "in parallel" to speed up the search. However, if you add another 2.5GB for the 4203 index files you don't have room in the RPI and you need to change the config file for sequential search on the SD card. This is much slower and can take many minutes to find a match.

Ah, so this is what prevents the FOVs in the original ASIAIR to be expanded for the long focal lengths.

Also, searching in parallel must mean that it is an I/O and memory bound problem and not a processor bound problem. A future release of Raspberry Pi might fix that.

This also explains why some of the plate solve threads stay around. Often, even after you abort a plate solve, it would, a few seconds later flash a window up to announce that plate solve has succeeded. All sorts of threads in ASIAIR not properly killed. (Not just in plate solving but especially noticeable in the Focus window; or when you switch cameras.)

One possibility with file size limitation to actually remove the files that you will not ever need (not for the faint hearted). If you are far enough in the northern hemisphere, you will never need too plate solve stars in the south. Ditto when you add the higher resolution files -- only add the files with the asterisms that you ever need. Even better, preprocess the files from astrometry.net to throw the unneeded asterisms away.

And the way to mitigate the memory size limitation is perhaps to edit the index files to remove unneeded stuff too.

I see a fun side project coming up -- a program to filter the asterisms from astrometry.net to produce files that matches a latitude (should speed up searches too, not that we really need any speedup when the plate scale is known), ha ha.

Chen