Centering not working after changing telescope

I had no problems with plate solving and centering when using my AVX Celestron mount with my Orion 800 mm 8 inch astrograph. I have recently changed to a celestron8 inch Edge HD and Plate solving has become incredibly slow (or fails) and when it does work I cannot get the centering error down to 60 pixels. In fact every time it tries to centre, the error increases. All my drivers are OK and I have the correct Focal length, image scale etc in SGP.
Any advice would be appreciated

What solver are you using? Logs would also be helpful. Please see here:

Jared

Thanks. I use Plate Solve 2 and having never had problems with my other scope. How do I get a copy of the log?

Hi
Just a hint: Make sure that you set the telescope focal length properly in the Equipment profile manager; Attached image: setting at the bottom right.
And ensure that you applied the correct equipment profile to your sequence.
Failing to do so inevitably leads to plate solving errors.
I struggled with that a long time ago…

image

Is your mirror bolted down well? A floppy mirror can mess up platesolving.

Please ensure that the new equipment profile you are using has an accurate 1x1 scale set in the camera tab.

More information is here: How to report issues or ask for help - Announcements - Main Sequence Software

Thanks I do have the right Focal length set

Mr Mostafa Metwally MD, FRCOG
Consultant Gynaecologist
Subspecialist in Reproductive Medicine and Surgery
The Jessop Wing and Royal Hallamshire Hospital
Sheffield Teaching Hospitals
Sheffield, UK
Secretary NHS 01142 268092
Private 0114 267 4477

Please Help

First thanks for all the comments. I have checked all of them and I have the right FL, image scale, bolted down mirror, good focus etc. I even deleted and re setup the profile. It plate solves now but I just CANNOT get it to within 50 pixels of the target whenever I try to centre. It is usually In The range of 150pixels. Even more frustrating is that the error increases with every attempt. I have even reset my HC to factory settings (I use a Celestron AVX mount) just to make sure that there is nothing there messing up the model. I have also rebalance my scope. I am extremely frustrated as I had absolutely no roblemos when I was using the fast orion astrograph and have really run out of Options. I include a copy of my logsg_logfile_20190630012929.txt (632.1 KB)

Looking over your log it appears maybe you were trying to solve close to the celestial pole and those appeared to be the ones that failed? When the mount was moved away from the celestial pole it appears you were getting the plate solve to solve? I’m not real good at reading the logs so I could be wrong in what I was seeing. I never try solving around the celestial pole but what I’ve seen in other posts, solving around the pole is problematic.
The other issue about trying to hit centering to within 50 pixels might be a challenge with the AVX mount and a image scale of 0.8. I have a CGE-Pro and a CGEM as well as a C8 and a HD11 scopes with image scales of approximately 0.77 I found 85 pixels seems to work very well, usually centers withing 2 to 3 iterations. For an image scale of 0.8"/pixel and at 150 pixels centering only puts you off of your target of 2 arc minutes. that is still really close. Folks with high end mounts can get within 25 pixels and lower but for mid range mounts, I think something between 75 and 200, depending on one’s image scale, is maybe to best one can hope for. Also, I have this same issue where the error seems to increase at times. I think that has a lot to do with the point accuracy, repeatability, as well as what part of the sky the mount is pointing may make things worse. the same holds true for centering, there are certain parts of the sky where my mounts will center within 25 pixels but there are other parts it struggles to hit my 85 pixel target.
Since this appears to be a new mount/scope I would suggest if centering is working at 150 pixels, use that and as you use it see how it performs over time and make minor adjustments until you hone in on what works best for your setup.

Hope this helps,
Mark

OK, I have been following this topic because I too have an AVX mount with the same issue. Only I differ in magnitude of pixel error. With 731 mm FL (image scale 1.53 arcsec/pix), my limit seems to be about 33 pixels. This is of course livable but annoying. Particularly when I (unfairly) compare this performance to my G11 mount. On the G11 with image scale of 0.68 arcsec/pix, I set max error to 28 - rarely hit the first pass, but the second pass is typically about 20 pix error.

So I agree with Mark that centering results can be impacted by a number of things (as he indicated). I think image scale is high on the list. Mostafa went from 800 mm FL to 2032 mm. I can’t see in the thread what Mostafa was getting for centering accuracy at 800 mm, but I would bet that going to 2032 mm would mean his centering error would increase by a factor of about 2.54. I say this, because the I am thinking that the mount performance is the main impact here I think this is what Mark is also implying.

My theory is that backlash uncertainty is the root cause. Backlash issues will manifest in arc seconds, not pixels. So when image scale goes up (reduced arcSec/pix), centering error in pixels goes up. In my case, my centering error floor is always in DEC. I attribute this to the fact I set my mount east side heavy thereby negating detrimental impact of backlash in RA. I can’t do much about DEC other than tune my mount (which have done). I also think that setting a backlash value in the AVX mount settings for DEC might exacerbate position uncertainty - I have mine at zero (both RA and DEC). We know that the AVX mount oversteps the target position and always approaches the target from one direction. This might seem like is should address the issue, but DEC balance can be impacted differently at different positions in the sky. We also know that AVX DEC backlash is in the range of tens of arc minutes. So even a 1% backlash uncertainty would be into the tens of arc seconds. I suspect SGP is maybe overcompensating when it sees a new center position unexpectedly unusual one way or the other.

So I don’t have a lot of evidence at this point to support my theory. I have not really looked into my issue very seriously since it is livable but perhaps a bit annoying. But now I may try to look into my logs or Mostafa’s to see if this theory is supported or refuted by them. Certainly see if this thread progresses any further.

If it is the mount Backlash that is the major contributor to this issue, then Marks suggestion of setting a error tolerance that the mount can achieve is the quick solution. The alternative may be to tune the mount or upgrade to a more capable mount (with upgrade being probably a more disagreeable alternative).

Just my Theory, but I would love to see this issue adequately explained.

Jim Thommes

Thanks very much to everyone. I was also suspecting this was a problem with image scale.
How about if I plate solve at bin1x1 rather than 2x2. My image scale at 1x1 is only 0.39.

Jim, i was getting to below 50 pixels with my 800 mm FL scope
Also how do I adjust backlash tolerance on the AVX mount?

Thanks

Mostafa,
OK. Here are my thoughts. But the forum moderator may want us to move to PM or email since this topic is veering away from SGP issues…

“…How about if I plate solve at bin1x1 rather than 2x2. My image scale at 1x1 is only 0.39…”
I am pretty sure that centering error in pixels is always provided as that of native 1x1 regardless of what binning you specify for a centering image. Plus, perhaps you miss my point - it is the mount accuracy relative to native image scale. Native image scale is fixed by your FL and sensor dimensions. So any binning you do does not impact the relationship between mount accuracy and native image scale.

“…i was getting to below 50 pixels with my 800 mm FL scope…”
Well, this sounds like information that does not support my theory. Maybe there are additional factors at play. Is your typical 150 pixel error comprised mainly of RA? or DEC? or pretty much shared between the two axes? I guess I should overcome my laziness and check your log.

“…Also how do I adjust backlash tolerance on the AVX mount…”
Take your gear covers off (DEC is easiest if you want to start there - particularly if DEC contributes to most of your error). Loosen the motor shaft gear and remove. Adjust the worm gear so it is snug against the hat gear. Make this as snug as you can without binding. You probably have to check the full 360 degrees of the hat gear. You can wiggle the DEC axis shaft to see if you have minimized any play there. Reinstall the motor gear and adjust the motor mounting as close as you can to the worm so that the two gears mesh as closely as possible. (again without binding) Then reassemble the cover. There is still the matter of the motor gears within the motor housing. Nothing you can do about those.

Jim T.

Mostafa,
OK I just took a look at your log. I am not real good at reading logs, but it seems pretty clear to me at first glance that the problem doesn’t seem to be what I was thinking at all. So I would hold off trying to do something with your mount mechanics for now.

What I did see is that the mount is told to go to a consistent RA/DEC each try. Re-syncs are made with each try (this is the part that is supposed to get your target closer and closer). I am wondering if your pointing model in the AVX is off and the sync just gets the pointing model further and further off. I assume you are doing a two star alignment to start and also a couple of additional alignment stars. If not, this could be an issue with the re-syncs.

Its late and I am tired - I may try to get back to logs tomorrow and see if I can see anything more.

Jim T.

I think that you are asking too much of what amounts to a consumer grade telescope. Your pointing errors are less than an arc minute and that’s actually pretty good.

If you want pointing that’s significantly better than that then get a high end mount.

I think this is the same issue I have reported previously that affects celestron and other mounts.

Backlash doesn’t come into play because the slew always comes from the same direction and backlash has been unwound.

The problem is simply that the mount does not land exactly where it sets out to land on the slew. This has nothing to do with plate solve or backlash issues. It’s very simple - the mount makes an effort to slew to ra/dec coordinates - by its own encoders - and ends up a little bit off - by its own encoders. For some reason people expect mounts to do exactly as they are told - but it isn’t trivial to get the timing and everything exactly right so it lands exactly at the intended ra/dec values - based on its own encoders.

The good news is that the miss error is very repeatable - so even these lower end mounts can do much better if this landing error is accounted for.

There was an effort by SGP some time ago to provide a slightly different kind of sync that would accommodate this landing error - and since people continue to report the issue I think there would many people would would benefit from the fix.

Frank

As I mentioned, after I reviewed Mostafa’s log, I see that my theory on backlash is not the case for Mostafa. I agree with Frank that this is likely not backlash - at least with regard to the magnitude of error Mostafa is seeing. But keep in mind that for DEC even though the backlash is unwound, there is no guarantee that the DEC stops where the mount intends - it could continue to slip forward into the backlash space - even if one thinks they have DEC well balanced.

However, after looking at Mostafa’s log, his issue is not predominantly DEC, but instead a combination of RA and DEC. I have reviewed some of my logs (AVX mount) where I am set for a 28 pixel error on 1.53 arcsec/pix image scale. I typically land 2nd try - sometimes it takes three tries. What I do notice is different between Mostafa’s log and mine is the I have a 3 sec post slew settling time before a verification image is taken. Looks to me like Mostafa has no settling time. This is just a correlational observation and I am not suggesting this is a cause, but it doesn’t take much effort to see if this helps.

I haven’t looked at the logs - but in many cases that have been reported related to this issue - including mounts that aren’t celestron - the centering logs show it making a good correction in the first one or two steps - and after that it keeps missing by nearly the same amount in ra and dec. That indicates the miss is quite repeatable and can be corrected with a corresponding adjustment in the slew target.

Someone in this thread describes an error that increases with each iteration - and I’m not sure what that is. But for the situation where the iterations keep missing by the same amount and never converge - it is likely this problem.

If you have a wide field OTA and it centers well to 30 pixels - but you switch the OTA to longer focal length, 30 pixels is now much smaller in terms of arc-seconds and the issue may appear. The issue was always there - but at shorter focal length the arc-second tolerance of 30 pixels is much larger and it is easier to center to that tolerance.

Frank

Thanks again everyone

Jim: i am not doing a star alignment with the mount , just syncing through SGP

Frank, when you are suggesting an adjustment to the slew target or adjusting the slew settling time, how do I do that?

I am Guessing I will just have to adjust SGP to centre at 150 pixels

Thanks again

This does not work for me. Meridian flip has a medium probability to fail for me without a two star alignment. I wish I could just sync, but it is not worth the risk of Meridian flip failure.

Also, slew settling time in set in the control panel>telescope>Mount Settling Time (lower right in the dialog box). Also, just above settling time is “sync behavior”. You might try “scope offset” or “target offset” rather than “sync”.

Jim T.

Hi Mostafa. The adjustment I’m talking about needs to be done within SGP as they calculate each slew to get closer to the target. You can’t really make the adjustment yourself. The slew calculation needs to factor in this landing error - or else that landing error will never go away.

Frank