Hi, Using my C14 and 0.8x reducer for the first time last night, having upgraded from a C11 which used the same reducer. I have always used the ANSVR and Platesolve2 combination and it worked pretty well apart from the pesky dialog closure delay in PS2.
So I thought I’d give ASTAP a go last night, but in five attempts in three different areas of sky, ASTAP would not solve. Moreover, ANSVR as the failover would not solve. ANSVR works fine, but only if I use it first - here’s a typical sequence of events for each of the five ASTAP attempts:
Blind Solve with ANSVR - worked
Immediately followed by an ASTAP solve attempt which fails
ANSVR as failover - fails
So it looks like something odd is happening when ANSVR follows an ASTAP attempt. I appreciate n=5 so not much to go on.
As you can see with a C14 set up with a 0.8x reducer, it’s intended as a galaxy imager and the field is quite small. Can ASTAP deal with small fields?
Is there any thing I can try in ASTAP settings?
Anyone else using a small field configuration with ASTAP?
Perhaps using a different star catalogue would help? One with more stars in to compensate for the small field?
I’ve included some of last night’s data below, from an ANSVR successful solve which shows the index used, field size etc:
Field 1: solved with index index-4206-02.fits.
Field 1 solved: writing to file ./stars.solved to indicate this.
Field: stars.fit
Field center: (RA,Dec) = (239.4, 29.68) deg.
Field center: (RA H:M:S, Dec D:M:S) = (15:57:44.460, +29:40:31.509).
Field size: 20.5796 x 15.5243 arcminutes
thanks Keith, yes I bin at 2x2, but I tried 1x1 too. I think the G18 catalogue should solve the problem as the density of stars will be greater in my small field of view.
I hope to get a clear night soon to try again, but the last few years I’ve had about 10 clear nights between September and March, so see how it goes…
Paul
How long do you expose for solving? I assume 10 seconds should be sufficient. It should show about 30 stars minimum but more is better.
Can you share an short exposure image for testing? I noticed in the past that long focal lengths could result in unsharp stars due to seeing. Increasing the quad tolerance could help.
I must say I am much happier with ASTAP than with platesolve2!! ASTAP is lightening fast in solving. However, there are two issues I have encountered with ASTAP:
1- It does not center the scope as precisely as platesolve2 does;
2- if the stars show a bit of trailing because the mount has not fully stabilize after the slew it will fail.
I am not sure how I can improve the precision other than increase the number of attempts at centering.
The star trails issue is a wait period issue which I increased. But there is still the odd times when it will fail after a flip and SGP is not capable of recognizing the failure and take another image to plate solve. That means I have to stick around to make sure the flip is successful.
The accuracy of ASTAP is as good or better then PS2. All solvers give a solution better then a pixel distance and typical less then 1 arc second. Below the test result of solvers against the online solver nova.astrometry.net, I did a few weeks ago for 10micron users.
ASTAP is less good then Astrometry.net with images showing star streaks. But in all cases the telescopes should be settled. You should set the settling time enough for the telescope to stabilize. For my HEQ5 I have to set it at about 15 seconds. Sometimes a few second but the time required is very random depending on the gear position so you have to set long enough.
Also you should set the retry higher then one.
Binning should bet typical at 2 or 1.
EQASCOM. For most applications “append on sync” should be off in EQascom/eqmod unless the mount is fixed and never mechanical unlocked. But for most users I would recommend no model use in EQMOD and clear any existing model points. This model gives only problems with every sync action.
I had done all this already except I had the settling time at 12 sec instead than 15 sec.
I still think ASTAP/SGP combo is not as precise as platesolve2/SGP in getting the scope pointing at the precise point I want. I have to re-center it manually after every slew to intended target. It is not far but not where I want it to be.
Hi Stefan,
my camera plate size in pixels is provided by the manufacturer SBIG as 3326 x 2504
I ask SGP to centre up to two times until error is less than 50 pixels. It always manages to get within this limit, but I guess it is tight and I might relax it to 100 pixels.
What error margin do you use in your centreing?
My mount is a mesu 200. I have only been using ASTAP to solve fairly recently, but aprt from the solve failures I’ve had (which are now resolved), I haven’t noticed any difference between the centreing provided by PS2 compared with ASTAP.
best wishes
Paul
Hi Paul
I am using a ZWO 1600MM. The centering is set at 50 px with 5 tries. My mount is an EQ6-R. I am decidedly seeing a difference in the accuracy when using ASTAP. It gets me real close but I have to finish centering manually. I’ll try 100 px next time.
It sounds like if you try 100px your centreing will just be further out Stephan. Interesting difference between the number of tries we use. Does your system need the 5 tries or does it centre in fewer? Not that it matters really - if you have experimentally verified there is a difference between positioning using ASTAP and PS2, then that’s it. It’s just down to what’s causing the difference. It will be interesting to see if others identify the same problem and if they do, what if anything is common. A nice test would be to use the same object on the same night and centre it say times with ASTAP and 5 times with PS2 and see if you get consistent differences. Perhaps you’ve already done that though from what you’ve said.
Also I find it’s not easy to investigate things these days as there is so little clear sky - you just want to get on and image stuff.
I’ll post again when I get some clear sky with my centering findings from a larger number of cases.
Stephan, do you have EQASCOM as an interface program with out EQ6 mount and are you sure you don’t have an automatic build mount model in EQASCOM spoiling the targeting? See my previous mail.
Just to come back on this centreing with ASTAP Vs PS2. I am now in agreement with Stephan that Centreing does not work as effectively when using ASTAP. Tonight, I could not ‘centre now’ using ASTAP. Centreing got close - within about 20 pixels of the 50 I specify, but repeatedly it would not centre to within 50 pixels. I switched to PS2 and in just two iterations (as normal for me with PS2), centreing was complete.
An easy way around this for me would be to increase my error margin, which would have worked for this particular Target - NGC 6946.
If there’s anything I can do to help investigate, please let me know.
I have run SGP and ASTAP together with “Sky simulator for ASCOM”. SGP centers correctly on the target withing a few pixels. I have tried twenty or so targets and it never fails. So I could not find anything wrong with the SGP control loop and positions exchanged.
So at the moment it is difficult to find an explanation. Something is not repeatable. It is also difficult to understand that the solver would makes small mistakes. It solves or it doesn´t solve. There are normally no small errors, only major errors and they are not repeatable for an other slightly different position.
Normal explanation would be the mount or rounding errors. But we could check the images. While SGP is open it stores al images to solve at:
C:\Users\h\AppData\Local\SequenceGenerator\Temp
Where h is your username. If it happens again save all files before you exit SGP. The image solutions are in the .apm and .ini files and solving can be repeated with Astrometry.net to compare the solutions.
An other thing to check is set the repeat not at 3 retries but at 10 or even 20. Then watch how the error develops. Is it steady, is it oscillating? Is the oscillating repeatable due to a rounding error. Is it in RA or DEC ?
An other thing to check if increasing the mount settling time has an influence. If solving is fast, the mount gears have less time to settle. Increase it temporary to see if it makes a difference.
The mount settling time is under Equipment profile manager, Telescope
thanks Han, When we get some more clear sky, I’ll try again. It is odd as you say. A solve is a solve and the mount should be moved by an amount equal to the offset I guess ( I am no expert and my ASCOM knowledge is limited to writing a dome driver, which I suspect is relatively easy…).
With PS2 over four years, it has completed centreing in two iterations to get within 50 pixels. It always takes two. BUT, as you know there’s the dreaded 10 second delay with PS2 and I wonder if that’s giving settling time for the mounts.
My mount is MESU 200 - no gears, but I’ll try according to your suggestions and see what I can find. It may be some time before I’m back looking at the weather forecast for U.K.
!
