Hi,
I was imaging M31 from my backyard friday evening.
Everything worked very well (auto center + plate solving achieved in 2 steps,autofocus, guiding etc…) until de mount started de meridian flip to continue to image the target after it crossed the meridian.
I checked the log file by my own. SGP, stopped guiding, take a picture to solve the target before the flip, perform the flip, and check again by plate solving for auto centering.
At this point it failed, indicating the object is over de limit of 50 pixel.
I checked the pictures captured during the plate solve post flip : the flip worked and the target was perfectly in the middle of sensor.
Any input to solve this problem ?
50 pixels isn’t a lot so your target might be well centered (but not perfect), but still outside the 50 pixel limit.
I think you should increasing the limit to 100 pixels.
If you can get within 50 pixels pixels consistently depends on your mount…i’m not sure which mount you have other than it being a Skywatcher.
Hi Xplode,
Thank you for your reply.
I checked carrefully the log file and saved picture of the plate solving process.
The plate solve before flip worked very well.
The flip worked well also but the mount was out of the target on the first round of centering / plate solving and already on target after the second. With the 3rd and 4th trial SGP plate solver cannot make better than around 70 pixel of error (still > 50 pixel allowed) leading to abort my acquisition sequence.
By inspecting the solve picture before the flip and after the flip (last picture before sequence aborting), I could observe that
The flip worked very well
The field was 100% on target
if I turn the picture post flip 180°, there is a major difference between the picture before flip. The post flip picture is rotated from few degrees compared to the picture before flip.
I was wondering if this rotation effect after the flip could explain the difficulty of the plate solver to center the picture as it was before the flip.
By reading a bit more on this on the net, this kind of field rotation might be linked to error cone or some sync event stored in Eqmod.
Does the error cone is something which has to be completely solved to get a proper centering process post meridian ?
Is there something to adjust in EqMod ?
Or does the fact to increase the error in the plate solve from 50 to 100 pixel will be enough to avoid this kind of error leading to sequence aborting. And then the rest of the work will be done during picture alignment and stacking…
Also images pre and post flip will always be 180° apart as the camera is rotating 180° with respect to the sky. This is true for all GEMs if you’re not using a rotator to counteract this. It is not a problem with plate solvers as SGP accounts for this as well.
I checked on the log the data post solving
The picture before MF and the the last before sequence aborting have a difference in angle of 181 degrees.
180 are coming are coming from the MF. The single degree remaining is the one which is clearly visible once I rotated the post MF picture 180 to compare with the reference picture before MF.
Does this difference of one degree explain the difficulty to plate solve ?
Hi Jared,
Do you think a cone error between OTA and the mount might be a possibility ?
I found a one degree acceptability ok, if SGP is able to be back on the field.
Does the error tolerance of 50 pixels is too low ?
The wierde thing here, is usually the plate solve (beginning of sequence) is performed in 2 or 3 round maximum. But here, the system was not able to reduce the error difference below 70 pixels after 4 rounds, leading to the sequence aborting.
No I don’t have a blind solve set up. How to do it ? What the difference between the plate solve performed after the MF ?
Will it save my sequence if the classic one is not working ?
Will it change something if the reference for the solving post MF would be the target coordinate populated at the beginning of the sequence rather than those from the picture solved before MF ?
Maybe, although i’d have to think about how this would manifest.
That depends, what is your pixel scale? A couple of arcminutes should be pretty achievable on most mounts. I’d adjust your pixel tolerance until your allowable error in arcminutes is around 2-3, or whatever makes sense for your FOV.
The blind solve certainly can save things if your primary fails. It doesn’t require hints and while it takes longer it almost always succeeds. If you want to try it without much setup you can just select the option to “Use Blind Solve Failover” and it will default to using the astrometry.net web service (internet required). If you need to be disconnected you may want to look at setting up ANSVR. I would eventually recommend ANSVR anyways…but it requires some setup where Astrometry.Net does not. ansvr - Astrometry.net Local Plate solver for Windows
Not sure I understand what you’re asking here. The meridian flip attempts to slew to your previous position prior to the flip.
I would have specified the error in arc seconds, I think it gives a better idea of the precision that people are expecting. As it is people are imaging at very high resolutions and expecting very high standards from mid level mounts.
Hi Jared and Chris,
My pixel size with my set up (Newton 200x800 and ZWO ASI1600MM) is 0.97 arcsec per pixel.
So with 50 pixel of tolerance it is just below of 1 arcmin. At 100 pixel is 1’40 arc min.
Having said that, my gear is able to plate solve with 50 pixels in 2-3 rounds to find the target from coordinate starting with the parked mount. But the mount was not able to make better that 70 pixel in 4 rounds after MF with the pre flip target solved picture as reference. Would it be different (better or worth…) if the plate solve hint post MF would be the coordinate from the beginning (copy paste from Stellarium from instance) rather than the picture before MF.
This is what I mean Jared ( with my french english )
Also, another interesting observation, during the aquisition before MF (2h40), the first and last frames were not translated or rotated. This one degree of rotation came only after MF.
One possibility also would be a kind of mechanical flexibity in my gear , with the help of gravity, leading to this rotation after MF. Even if everything looked tightly fixed. I can maybe pay more attention to that next time.
There are all sorts of errors that will be different after a meridian flip, Cone error - the amount by which the telescope pointing direction differs from the declination axis. It should be 90 degrees and if it’s say 89 then this will give an error of about 2 degrees. There is also the zero position of the declination axis and the amount by which the difference between hour angle and declination axes differs from 90 degrees.
The image is rotated by 180 degrees after the MF and this could make a difference.
And the mount can still be aligned to within 70 pixels or arc seconds. I think that’s pretty good for the sort of hardware we are using.
The exact image used as the reference should not make a difference becuse all that happens is the the image is plate solved and the position used. In any case if the mount is being guided the original position and the position found from the image taken just before the MF should be very close.
What happens if a sequence is started after the object has crossed the meridian? Does it align to within 50 pixels in 2 - 3 iterations as it does when this is done before crossing the meridian?
I had the same problem. Here is the solution. First in EQMOD the set up screen, go to the General Options section and check the “Show advanced Options” Click OK after. Connect the mount via EQMOD. Expand the window. On the far Right there is a section called “Other settings” Take the Goto Rate Limit slider and slide it all the way to the left so it says “No Limit” Now it should work the next time you need to flip. These 2 settings eluded me for a year. Someone mentioned it in a youtube video. Don’t recall who, but it works now flawlessly. Best of luck.
Only to try to understand:Any clue why this EQmod rate is involved is the poor reaction of the mount to center post MF and not before where it’s working great ?
)
