Plate Solve Accuracy

Hi, I’m an SGP beginner and trying to decide whether to purchase. The plate solving aspect is very important to my final decision. I have tried as many of the features as I can - with varying degrees of success - before my trial expired. My question is this :

Given an image taken on a previous night, will SGP slew to the exact image position having solved the image or just use the image as a hint and expect you to manually select the final image position?

I could select a previous image which then displayed a library image and I had to draw the image area onto it manually. Is this the only way to use your own images or am I missing a trick?

Andy

SGP will solve and slew your mount within sub-arcsecond precision of the center of the reference image. However it’s unlikely that your mount can slew with this level of accuracy so you’ll probably end up (at best) within a couple of arcseconds of the target. SGP can be set to run the Auto Center process multiple times so that you can get closer to the target by syncing very close to it. However you still usually won’t get it “dead on” as most mounts have some level of backlash. So I guess the question is, what do you consider “exact”?

You can use a previous image as a reference for the target location. See here:
http://www.mainsequencesoftware.com/Content/SGPHelp/LocationToolsPlateSolving.html

Thanks,
Jared

Thank you Jared. That is exact enough for me.

With my cge-pro the centering accuracy is I think around 30-45" in a few tests I have done. This is limited by the accuracy of the slew itself - not the plate solve. Other mounts may be different - but the key is that since the final position depends on the mount landing exactly where it was told to go - which is hard to do - the plate solve and sync are only part of the operation.

At around 0.5" per pixel, that is 60-90 pixels.

I think this accuracy is independent of using RA/Dec coords or using an image as the target. I believe SGP simply plate solves the image to find the RA/Dec - then tells the mount to go there. So in my case the location could be offset 60-90 pixels from the reference image.

Frank

I was using the Mosaic and Framing Wizard and not the Target Settings dialogue as Jared suggested. So I think I was approaching the problem from the wrong angle.

That said - I thought the slew was refined by re-imaging and re-solving an offset. If not isn’t the final accuracy defined by the sky model which in turn is dependant on model calibration re-syncing accuracy. I was particularly interested in primarily using solving to avoid having to perform multi-star calibration.

Andy

Yes that is all true and if you sync near the target, then slew to it - you will land very accurately. But it requires that the mount actually go to exactly where it was told to land. For my mount the slew operation doesn’t exactly land where it should - and repeated solves and syncs nearby don’t get it closer. But 0.5-1.0 arc-minutes is probably fine for most people - so it may not be an issue. In my case I need it accurately located because I am using OAG and a rotator to find specific guidestars.

A high end mount should be able to land very accurately, but for other mounts I expect this small amount of ‘miss’ in the slew will be the dominant error in centering accuracy. In SGP when you do a Center operation you can specify the desired accuracy and number of retries - and that is where you would need to know the accuracy you can expect to achieve with your mount based on how it slews.

Frank

Some mounts account for backlash during the model creation phase while others allow you to set backlash independently of creating a mount. I would guess that backlash in the gears could very easily account for a handful of arcseconds when attempting to iteratively slew to a target. Also it depends on how the mount handles this slew. Some will slowly encroach on the target while others will slew many degrees off target (likely to remove backlash) and then slew to the target.

I guess all that is to say that it really depends on how your mount handles the slew on how accurately you can get pointed.

Jared

Backlash shouldn’t play a role because all calibrations and slews with a celestron mount are in the same direction - and that is done specifically to remove the impact of backlash. But in talking to celestron engineers, the slew is designed to be fast and consistent - but it is not designed to be exact because doing so for different mount configurations and loads would be complicated - in terms of the exact timing and sequence of speeds required to land at the right place at the right time. The goal instead is to have the accuracy of the slew be much smaller than the goto error itself - which is maybe 3-5’. So 1/2-1’ error in the slew itself is not a big problem - but it does show here when you are trying to center an image on a specific ra/dec location.

I don’t know how other mounts work when they do a slew - but getting the motors to go quickly to the right place at the right time isn’t trivial - especially if it is done quickly. High end mounts and ones with high res encoders should do it at the arc-second level - but I’m not sure about mid-range mounts.

Frank

The slew error with the Celestron mounts is very consistent so it should be possible for them to make the slew better, at least in terms of the position reached being closer to the target position. As Frank says, at present it’s about 1 arc minute out, almost all in Ra.

But at present we can’t even get them to look at bugs in their software that can run the OTA into the mount so the chance of getting something like this fixed is pretty slim.

I think I’m misunderstanding what SGP is able to do. I thought the process would be…

  1. Solve user image.
  2. Slew to model co-ordinates.
  3. Take new image.
  4. Solve new image.
  5. Calculate required offset.
  6. Slew to current+offset co-ordinates.
  7. Take new image.
  8. Solve new image.
  9. Calculate required offset and if not within required tolerance goto 6.

Reliance on the accuracy of the model stops at 3. by slewing to calculated offset co-ordinates rather than a solved destination.

Apart from not using the user-image in the way I first described, I though this is the process the Mosaic and Framing Wizard added to the sequence.

Jared - Is there any way I can extend my trial license to allow me to conduct more testing?

The process is more:

  1. Slew to target position
  2. Collect image
  3. Plate solve the image to get the centre position
  4. Sync the mount to this position.
  5. Slew to the same target position as in 1.
  6. Collect image
  7. Plate solve image
    8, Check the difference between the target position and the plate solved position. If greater than the allowed tolerance go to 4.

The difference is that SGP does not apply any offset to the target position. It sends a Sync command to the mount. This may not be a good thing because the mount model may be modified using the single sync position. In most cases pointing should be better close to the sync position but can be expected to be worse elsewhere.

Chris

I have similar questions/problems with the plate solve process and this looks like a good place to ask.

I’ve set SGP up to try 3 times to within 50 pixels on a solve and center operation and it seems to get “stuck.”

This happens both when I use a previous night’s image as a reference or even after a meridian flip.

I can feed in a previous night’s image. SGP solves just fine, but it will slew to within something like a 145px error of the desired position and each of the 3 attempts gets it no closer. It’s almost as if the mount does not get moved at all with each attempt.

Based on the conversation above, is it possible it has to do with the scale - on my setup at 1x1 binning that is 0.57" per pixel?

I’m using a Paramount MyT with the ASCOM driver for TheSkyX. I have the “prevent sync” checkbox enabled to preserve the T-Point model. Is the fact that the plate solve can’t sync the mount the cause?

This happens even after a meridian flip. Things are great before the flip. SGP takes the image before, does the flip, then the process of solving/slewing to the pre-flip coordinates gets stuck about 145 pixels away and fails.

I’ve been getting around this by disconnecting the camera in SGP, going in to TheSkyX and doing some image linking/slewing to get pointed where I want, then going back into SGP and letting the sequence continue without doing a slew/center.

I’m brand new to all of this, so I am entirely sure I’m just not doing something correctly. Thanks for any advice!

Yes. SGP uses Sync. If Sync is disabed then no amount of plate solving will help.

Some people uncheck that box so allowing Sync. They claim that it doesn’t upset the TPoint model. I’m not convinced this is the case but if you do all your fine positioning with solve and sync it probably doesn’t matter much. Responsibility for pointing accuracy has been handed over to SGP’s solve and sync rather than TPoint.

Chris

Thank you, Chris. That makes sense and I will try that the next time the weather cooperates.

This is a case where if you could do a sync on the mount - everything would probably work well because for that mount the slew would probably land nearly exactly where it is supposed to. But if you can’t sync, the slew will always miss by the small amount of error in the mount’s pointing model.

For a celestron mount - and likely others - you can go ahead and sync, but the slew won’t be exact even if the model has been corrected by the sync.

In both cases, doing a plate solve then direct nudges to the target should solve the problem.

Frank

It will be “darn close” even with a bad or no model since the sync is very close to the target position after an iteration or two.

Jared

For my mount - and probably others - the goto accuracy with no sync is about 3-5’. So that is what you get with a direct slew and no solve or anything. All sky pointing accuracy.

If you solve nearby and sync - then slew to the target - the final accuracy will be 1/2-1’ approximately - limited by the slew accuracy. Repeated iterations will have no benefit at all. I’m not sure if what I have been saying has been fully understood.

I don’t know what the goto accuracy of a typical MyT is with a good TPoint model - but I guess 30" or so. Whatever it is - that would determine the accuracy of a slew if you can’t do a sync.

So - yes - this kind of accuracy may be fine for many applications - but it isn’t at the arc-second level. It’s more like on the arc-minute level. Syncing a celestron mount nearby will remove the goto error - but it won’t remove the inherent slew error. And many people don’t want to sync a TPoint model. That is two separate classes of users who are limited by the current implementation - and would benefit from nudging to the target.

Frank

I guess an alternate approach to avoid nudging and still use slews - but no sync - would be:

  1. Slew to target RA/Dec
  2. Plate solve and find dRA, dDec
  3. Slew to RA-dRA, Dec-dDec
  4. repeat until within tolerance

So in this case you are constantly comparing where you landed with where you were trying to land - and making a correction every time you slew. As long as the slew error is repeatable - which I think it is for my mount - I think this would work well - and there are no syncs involved at all.

Frank

Helo its accurate i think… i use the eq6 ,g2-8300,on an SW8"PDS .
i set the accuracy at 25 px…it normaly takes 2-3 “runs”…its in 2x2binning by an 2,22 scale…
so its avbout 50x60"?right