Error on Centering has grown significantly

Sequence Generator Plate Solving
81

Has anyone taken the time to contact their hardware creator about this? Just wondering what their explanation would be. We can sit here and assume a lot of things but at the end of the day we’re asking them to slew to a location and they’re not moving. Seems like there is some bad behavior there.

This would be like if I had a gps that was always 2 blocks off. Sure it’s precise but not accurate. And having one of those is not very useful and doesn’t get me where I want to be. I guess I should just remember that I need to always walk 2 blocks east and blame the car for not getting me to the right place even after I tell the gps precisely where I am :slight_smile:

Jared

82

I had. Unfortunately, I have no ASCOM logs to document the error and the SGP logs where not sufficient. Have to wait for clear skies to redo the test and go there again.

In the meantime, I would like to understand if the issue affects just one mount type or is a general one.

Regards,
Horia

83

I have a cge-pro with the latest celestron driver. The behavior I describe follows from discussions I had with the firmware writer in the teamcelestron forum. I am puzzled that people would be surprised that a mount could very quickly slew to an exact encoder position, while swinging large weights around the sky.

Celestron mounts use to have a feature called “calibrate GoTo” that would account for different payloads in the timing needed to do a slew accurately - but the firmware has changed and I don’t think it is supported.

I always use a mount model based on about 6 total stars - because it is very accurate and allows pointing across the sky with about 3-5’ accuracy. Given that the accuracy is not perfect, it is somewhat acceptable to allow some error in the SlewToCoordinates, in terms of the final ra/dec encoder values not matching the intended target. The net impact on GoTo accuracy is small compared to the mount model accuracy across the sky.

In some sense none of these details matter. A human looking at centering logs for my mount and many others will show the initial slew to have error, and the second slew has much less - but it does not improve after that. I have seen that many times for many reasons.

The obvious thing a human would suggest is - why not just aim a little down and to the right so that it hits the target? That is a few lines of code and it makes many issues go away for many mounts - and removes the need for sync. But if you want to sync you still can.

Frank

84

Frank, you lost me. From your description, I get that you do not have a centering issue when your mount has an active pointing model. Is this correct?

Regards,
Horia

85

I think everyone is having trouble understanding me because what I’m saying is so obvious it is hard to explain. Forget the pointing model. The mount is asked to go to x, y - and it lands at x+dx, y+dy - according to its own model and its own encoders. It knows it made a mistake in the end - but it’s hard to do it accurately.

Imagine a missile with extremely accurate - perfect - gps. You fire it at a target location and it misses by 10 meters to the right and 10 meters down. In its last moments it knew it was in the wrong place - but it was too late.

If you are saying the mount is bad or dumb - keep in mind it is not intended for 10" accuracy in a goto. It is intended to point accurately across the sky - and since it is ultimately limited by the mount model to 3-5’, some amount of landing error is in the tolerance.

Keep in mind that from the mount’s perspective, software that can’t adjust for this tiny little matter - either by nudging or the few lines of code I suggest - is the thing that is broken. The mount is performing to its spec very well. The software is designed to center targets very accurately using plate solves - and indeed it could - but it doesn’t because it makes a particular demand of the mount that is unnecessary. And it insists on syncing, which is also problematic and unnecessary.

Frank

86

No, I completely understand what you’re saying. And even agree with you for 95% of it. Where we differ is who is responsible for keeping this “offset”. My argument is that it belongs in the ASCOM driver on in the mount. I’m not talking about slewing 60 degrees and ending up within 2 arcseconds, I think we can all agree that with the hardware we have today that will never be accurate no matter how it’s done. So for me the “long trip” ends up in the wash…it doesn’t matter, it will never be at subarcminute accuracy, and that’s ok!

The problematic piece is when you’re 1 arcminute away from your target and the software tells the mount its location the mount then ignores this as it believes it knows better, for what ever reason, then when the mount gets a slew it thinks it’s already there so it doesn’t bother moving.

If I were to hazard a guess I would assume that the mount doesn’t want to shift its model if a sync comes in which has an error < X arcminutes (maybe 2, 5, 10…who knows) from the mount’s current position. Effectively throwing away the sync as the mount says “Hey, I’m close enough”. Likely this is a hold over from when plate solving was less popular and iterative plate solving and centering wasn’t “a thing”.

So…all that to say yes it would be great if something held an offset (or whatever) it needs to accurately and precisely slew to a location when a small slew is issued. I just think that ‘thing’ should be the ASCOM driver or the actual mount hardware since they have all the information we have and SUBSTANTIALLY more about the pointing model.

Also having 1 thing control the actual pointing model is always preferred. Sharing this concern across multiple systems would not be great and could cause problems and creeping errors. I would think slews would actually tend to bounce back and forth.

However, I’m not against trying things out. So, below is a version of SGP that implement’s @freestar8n’s Sync/Slew offset which will NEVER sync the actual mount (keep that last part in mind, I would recommend performing a local sync initially or actually building a model otherwise your error will be fairly large and likely highly inaccurate!)

So if some folks could try this out and let me know how things work (with SGP logs) I would appreciate it. This BY NO MEANS indicates that this will make it into a release. This is just some experimentation

As I don’t believe this is even beta worthy at the moment I’m not going to bother even creating an installer. Just replace your “Sequence Generator.exe” with the one below (you should backup your old one and rename this one). Also don’t be too surprised if this fails completely, there has been about 2 minutes of testing with this, just enough to know it generally works with the sims.

https://dl.dropboxusercontent.com/u/25320932/Sequence%20Generator%20-%20Sync%20Offsets.exe

Have fun :wink:
Jared

87

Thank you - that is very cool and I appreciate it. I just wish I could try it now but I will be delayed some days. But other mounts should benefit - such as Bisque mounts I guess - that have specific pointing models - from what I hear.

Your description of the problem is different from what I have been saying - and what I hear from the firmware designers. But unfortunately I cannot confirm anything right now until my equipment is back up. I do know that the mount keeps being sync’d by sgp - and it keeps re-slewing off by that amount - and many mounts do that - from reports in this forum.

I know it is common to blame ascom for things like this - but I have no reason to doubt ascom is simply a middle man here handing coordinates back and forth. And for the mount to eschew the suggestion from outside to do a sync when it is small - that is odd because they would need to have implemented code for that - and there would be no reason to. The encoders are read to 0.1" or so.

I think that what is ignored is that real time slewing of a heavy payload to within arc-seconds at a very specific moment in time is non-trivial - especially when done quickly. So to me a small landing error is not surprising, and it is acceptable - as long as the mount performs to spec for its intended purpose - which it does.

Whatever the cause - I really appreciate your offering this test - and if it works for my mount it will be a big leap in capability - that will go well with the excellent focus I have been getting.

So I look forward to trying it when I can - and to any reports others provide.

Thanks again,
Frank

88

I can say I have helped several people with this problem that never posted to this forum …
It is an issue, period … now we can debate if it’s a mount problem or SGP …
I would just like to see an option in SGP to do just a slew without sync, in software like carte du ciel you manually need to add a sync point after you confirm, SGP should enable such a workflow, slew and sync, or just slew …
Now what I do is to instruct eqmod to only add manually points, but that is a workaround … and if your mount has no such option you are really depending on how well the formula can cope with lots of points some pixels away …

/Yves

89

Just another quick question - as a matter of interest: what accuracy are you looking for? I tell SGP to get me within 20 pixels. I feel that this is close enough, given that I will be dithering between frames all night anyway. SGP does this with no problem with one or sometimes two moves after the initial slew.
Is there any chance that you are aiming for Zero?.. which is indeed asking a lot of some (or perhaps most) mounts.

90

Hi Jared,

Not sure if this helps, but here’s what I see with the G11…

  1. If the G11 has no model, centering works perfectly. I can consistently center on any object in the sky to < 10 pixels within 3 iterations. This is < 6" for my setup. This accuracy is nothing short of unbelievable with a 30 lb payload.

  2. When the G11 has a model, centering inherits the error in the model. If the model is good for that object, centering is good for that object. If the model is bad, centering is bad. But with a model, I will NEVER be able to achieve < 6" pointing accuracy. The model is just not that good.

In other words, I believe the ASCOM driver and mount firmware are correctly processing your slew and sync commands. It’s just that the much less precise mount model is still in the equation.

I suspect this also applies for add-on (computer resident) mount models, like that used by MaxPoint and others.

Best,

KG

91

Forgive my understanding on this but I thought I would share my experience I have with centering. I have celestron CGEM-DX mount and use a 8" SCT… May camera is a ATIK 8300 OSC. My image scale is 0.69 pixels. The best centering I can ever get is 78 pixels. Typically it takes around 8 maybe 9 tries to get there. Usually I tell the mount, via hand controller, to move to my target before starting my sequence. From there I let SGPro do the rest. What I see is that my first center is always low 80 pixels off. Then for each centering attempt it just seems to bounce around between 80 and like 95 pixels. Finally after maybe 8 or 9 attempts it lands on something less then the 78 pixels and the sequence can continue on. What I notice is that the further away the centering error is form my requested 78 pixels the higher chance on the next try it will reach it. It’s acting just like some folks here are saying in that it never converges but just a random chance that I hits the 78 pixels. I’ve never seen anything less then 70 pixels with my system and it never converges.

Just thought I would share my experience.
mahaffm

92

I’m going to put a few comments in here, if it doesn’t come out right sorry.

The ASCOM Sync command can be expected to cause the mount to report the current position as the sync position and that a slew to a position near that position will be more accurate. It says nothing about how this is achieved.

Sync can’t be expected to improve pointing globally, and it could easily make things worse.

Sync is usually done in the mount. Early Celestron HCs didn’t have a sync command so I applied an offset in the driver, much as Jared is trying. It works well.

It’s difficult to work for two masters and that is what is happening if SGP is aligning using solve and sync and the mount is pointing using a mount model.

I think that all reports of pointing errors that do not have quantitative information about positions should be ignored. This also applies to offsets in pixels if they don’t specify the pixel scale. It’s almost impossible to do anything but speculate without hard information. Pixel scales can vary hugely so an offset in pixels tells us almost nothing.

As a feature request, could SGP specify the offset errors that it uses to reject or accept positions in arc seconds, not pixels. That would help to make the magnitude of the error that we are talking about clear.

Are people’s expectations unrealistic? A 50 pixel error with a pixel scale of 0.5 arc seconds a pixel is less than half an arc minute. That may be less than the manufacturer’s specification for repeatability for a mid level mount. Would only getting a mount to a position within an arc minute or so be a great hardship?

There isn’t anything in the ASCOM Conform application that tests the sync accuracy, just that the sync command works with no errors reported. I’ve suggested that it be expanded to include something that emulates the solve and sync process and checks the accuracy of the numbers.
(Update, I’ve had a reply and it could be in there fairly soon.)

When you get down to it not using a mount model with SGP works well and for a portable setup saves time. I will put the mount down on the previously set tripod positions, do a quick align, and rely on SGP with it’s solve and sync process to control the mount pointing. The only thing missing is polar align and that’s only an issue if your mount has this in its mount model.

But if I had a high end mount that has a good mount model that will give all sky pointing to significantly better than an arc minute then I’d trust the mount model and not use solve and sync at all.

I wrote most of this a few hours ago and there have been some more comments - I’m really thinking that in some cases people’s expectations are at least close to unrealistic. Getting a mid range mount to significantly less than an arc minute seems to me to be a big ask.

But if you think there is a problem with your mount then you should be talking with your mount manufacturer. Expecting SGP to work round this seems unfair, even if Jared is prepared to be responsive.

Chris

93

Jared,

I think this describes the behavior of my iOptron CEM60. I do not know exactly how iOptron handles a Sync command that comes through the ASCOM driver, but I do know they say you must delete the mount alignment model when using an external program which has its own pointing model. I assume plate solving must fall into this category.

In my experience with the model in the hand controller active the mount was exactly off by the same number of pixels on everyone one of ten attempts (>250 pixels). After I deleted the model using the hand-controller the mount falls within 2-5 pixels on the first iteration. Therefore, it is not a mechanical issue with the mount, but a software issue in the ASCOM driver or hand-controller firmware that is causing this behavior on my iOptron mount. Therefore, I agree with Jared that the issue needs to be addressed by the mount manufacturer or ASCOM developer.

Fred

94

Going back to what Chris has said, given my setup with my image scale of 0.69 at 78 pixels would give me approximately and error of 54 arc-seconds. Hope I did the math correctly. To me now knowing this I wouldn’t expect anything more form my setup/mount. Maybe it is like Chris has suggested in that we need to understand our image scale first and given the quality of the mount one may be able reasonably estimate what would be reasonably expected. May problem is that I did not know what to expect. Putting everything in arc-seconds made thing a lot clearer for me. Now, given my setup, anything less then 80 pixels, under a arc-minute error, and I’m a happy camper.

mahaffm

95

mahaffm, are you using a mount alignment model? If so, have you tried not using the model?

96

Hi folks,

I think the bottom line is be sure you have no model when using SGP centering. It just doesn’t make sense to use the old model technology when using the new plate solving centering technology.

Then SGP simply looks at where you’re pointing and sends the correction to the mount. Very simple. In fact, SYNC should do nothing because you have no model.

When you have a model, things are much more complex. Now SYNC is telling the model to make a correction based on a prior correction slew. This is normally used to compensate for unlocking the RA/DEC. The basic pointing model is unchanged, but now a bias is added to the entire model.

Now, if you take SYNC out of the equation, could centering work with a model? Intuitively I think yes.Looking forward to seeing those results. Then we might satisfy those that need to have a model for other purposes.

Best,

KG

97

This already exists. Just use “Slew” rather than “Center” on the target settings.

I guess that depends on what you consider a “pointing model”. SGP has no “sky knowledge” like a mount would. It knows where it’s pointing (via a solve) and where it wants to go. It doesn’t create a software model like TPoint or EQMOD. It completely relies on the mount to get to the location requested.

Those should be getting reported roght next to the pixel error in the table.

Easy to test. Just right click Slew on the target multiple times and see how well you do. Sgp won’t give you any metric but you could always use a bright star as a reference and gauge for yourself.

Jared

98

I have always used mount model, specifically I use StareSense. No I have never tried centering without a mount model. Up until now I didn’t know it was possible. Next clear night, forecast for Monday, I’ll give it try and will report back.

mahaffm

99

StarSense has been using an offset based “Sync” in the driver because the sync in the StarSense HC is badly broken for syncs when the mount has tracked past the meridian.
A Quick Align, starting with the mount at the index position, should be enough and you will save the two minutes that StarSense takes to do its alignment dance.

I was really thinking that the error in the Control Panel PlateSolve window could be specified in arcsec instead of pixels.

Chris

100

Ah, maybe. But I think pixels is probably best here when talking about a single user’s gear. It keeps the overall “frame error” consistent across different setups and makes it fairly intuitive to think about. “50 pixels” would mean different things for different scopes and cameras BUT it keeps a constant level of framing error and makes you think about less math. I can easily figure out what “50 pixels” means to me when looking at a frame. I can’t figure out what 1’40" means when looking at the same frame without scratching my head (both are equivalent at my 2 arcseconds per pixel scale)

I can see how it could be useful. But I think pixels are likely the right value for that particular field.

Jared

1 Like