What the Conform checks show is that there is no problem with Sync. It's causing the reported position to be the same as the sync position to within an arc sec or so.
However slews are not and there is a systematic error, particularly in Ra. Conform does multiple slews - there are four in the example I posted above and when slews around the sync checks are taken account of there are 10. That's enough to get an idea of the average error. For the AVX with StarSense I'm testing at the moment I'm seeing 43.7 arc sec in Ra and 13 arc sec in Dec based on 10 slews.
What all this tells us is that Sync is not the problem - at least on the Celestron and SkyWatcher mounts. This may not be the case for other mounts but you need to collect data for your mount to demonstrate this.
What is happening is that slews are not as accurate as people would like. Much of the offset always seems to be the same. This means that no amount of retrying the solve, sync and slew process will help. The mount will continue to slew to the same position and this will continue to have the same offset. The only solution that is available to you is to increase the tolerance in position - or buy a better mount.
Getting Jared to calculate and apply an offset in SGP as an alternative to doing a sync will not work because the problem is in the slew, not the sync. Jared's offset won't help because the problem is with where the mount slews to compared with where it's commanded.
Some of you will ask "couldn't you fix this in the driver?" and yes, systematic errors in where the mount slews could be worked round.
But, after considerable thought, I'm not going to do so, for a number of reasons:
- Doing so would mean that I'm taking some responsibility for the quality of the mount, something over which I have no control.
- Trying to work round this sort of thing when you have no control over the mount or how it's used is a nightmare.
- No matter how well the corrections are made the random errors are large enough that some people won't be satisfied.
- I have tried it. I worked round the problems with Sync in the StarSense, and this was used by Celestron to justify not fixing it. They said that I was the only one reporting there was a problem. The fact that this was because I had hidden the problem for everyone else didn't matter.
As I say, I've tried it. Even with a naked mount - no OTA, no counterweights, just the mount head, I'm still seeing some errors of 20 to 30 arc seconds. What it would be like in the field is anyone's guess. I'm not prepared to cope with the "I've tried your mount corrections and it doesn't work." messages.
When you get down to it these mounts are slewing to within an arc minute of where they are commanded and that's pretty good.
- The mount manufacturer is best placed to change this, and the user is the best person to let them know. I expect the manufacturers will say that this is within specification, none the less it is worth letting them know.
- I have done what I can as an ASCOM driver developer. But Celestron in particular treat me and my requests as a single fussy user. Maybe multiple support requests to them will help. I doubt it but you never know.
- I've also reported this to SkyWatcher. They seems more responsive, but again multiple support requests from users will do no harm.
- Similarly for other mounts, tell the manufacturer. This is a pretty technical thing and it won't be easy to get across that you are comparing the position commanded and the position reached, not something to do with the pointing model.
- ASCOM can't dictate mount performance requirements to the manufacturer.
Hope this helps, I've put enough time into it.
Chris