Of the four slews you do, only the second error is different from the others by much at all - the three are very consistent - but I can’t be sure if the sign of the error is reported - because “within” suggests it is an absolute value. If the sign is the same in all errors then it looks like a very good match to what I expect - and that is for an avx where I would expect less repeatability. Even if one slew is a bit off from the others - it would still tend to converge as long as the errors are adjusted after each move. Either way there is an overall bias and a great deal of the error should be removable. For a cge-pro I expect it to be better. If you don’t remove the bias - it definitely won’t converge.
And the other report above said it “kept hitting between 80 and 85 pixels.” I can’t be sure that is the exact same offset in each attempt - but if so is very good repeatability - on the order of a few arc-seconds - which is what I recall from my centering attempts with cge-pro.
I guess the principle reason that slews don’t get there in the cheaper mounts is down to backlash. If the original slew error is an overshoot, then the correction may not be effective. Thinking aloud, is there a way to use syncs say like we do backlash control on focuser movements? So - if centering is enabled, the initial slew is split into two parts. A deliberate overshoot and partial correction - which takes up the backlash. The centering then corrects the remaining error without encountering backlash?
No it has nothing to do with cheap mounts and backlash …
It all has to do with building a model each and every time you center, this seems to throw off the model in such a way that the object never gets centred … turn off model and in 1,2 or max 3 attempts and it centres within a 30 arcsec …
/Yves
I think the main thing to realize is that - for whatever reason - some mounts do not go exactly where they tell themselves to go to. I don’t think a model or backlash is involved at all. That is why I keep emphasizing the view of a missile. If a missile misses a moving target - it may have a perfect model and no backlash - but the goal of reaching a certain point at a certain time quickly is not trivial. And that is why there used to be a thing called GoTo calibration in celestron mounts - and that is what the firmware designer has conveyed.
Backlash is easily removed by winding way back and then forward. That is how celestron mounts work - and I can’t imagine a mount that didn’t do that in a slew - except one with high res encoders.
The real reason you know it isn’t backlash is that backlash alone would give perfect encoder readings - but a physical offset in pointing direction. That’s because mounts like these have encoders on the motor shaft and before the gears. The encoders do not see the backlash. If the encoders are wrong - in terms of ra/dec - it is not backlash.
What we have are a set of mounts that - for some reason - do not goto exactly where they are told - and they miss by a consistent amount.
So is anyone able to try Jared’s recent code? I cannot - unfortunately - for some time. But if it works - it works - and people should be able to check.
There is a different set of mounts that have an issue with sync - and that is a separate problem that should also be fixed by Jared’s code. So people with those mounts - like EQMod - if you leave them in the sync mode where it doesn’t actually sync, but instead it adds a point to the model - does Jared’s code work for centering? It should work no matter how sync behaves because it doesn’t use sync in the first place - I think.
I will try it with my TPoint’d PMX as soon as I get some clear sky.
I had a lot of first hand fun and games with generating models with my prior mount system. It was almost impossible to do unless one was rigorous with the environmental and time parameters. I could see that introducing additional sync points close together can cause a problem as it introduces a small error, which extrapolates out.
I’ll be willing to give the new code a try that Jared posted but I’m unable to locate it. Can someone post a link to it? Also, might be a few days before the skies clear up here, but I’ll give the new code a try the first chance I get. BTW - should I test the new code with or without the mount pointing model or test both ways, with a pointing model and without?
Also, I don’t totally understanding everything that the folks on this topic are discussing but I am willing to help just let me know if there are any special instruction or test setups needed.
I think both would be interesting to test. But “with a model” may be the most telling. It would be most interesting to test the current release with a model, note your centering error and then test the linked version with the same model and also note the centering error.
OK, thanks Jared. I did see that post but didn’t realize it was the link to the test code. I’ll give it a try on the first clear night. As per the forecast It’s looking like it will be later next week before we get a clear night here in Ohio.
AIUI what you are doing is doing a plate solve and then, instead of sending the solve position to the mount using a Sync command you are reading the mount position from the mount, subtracting the solve position from this to get an offset in Ra and Dec and applying this offset to a subsequent slew. Keeping track of wraps round 360/0 or 24/0 and getting the signs right of course.
If that’s the case then I think that, for the Celestron and SkyWatcher scopes at least, I can make a prediction. It will make no difference. This is because the error is not in the sync process. It is in the slew and this will make no difference to the slew and it will still end up at a different position to what was commanded.
Let’s see what happens. I can’t test this easily because there’s been no clear skies for ages.
@buzz, the Celestron and SkyWatcher mounts already handle backlash in this way, by doing an initial fast slew to a position that’s offset from the target by the same amount every time and then doing a slow slew to the target that’s always in the same direction.
I think the error in Ra comes from not allowing for the time this slow slew takes - 3 to 4 seconds, which is about the same as the error.
thanks, and there was me thinking it was just wobble!
Just bought an iOptronEQ30 for going on vacation with- so this thread may become quite relevant when I try it out with centering. You will be pleased to know Chris that the folks on SB think your ASCOM driver is a better bet than TSX’s own.
Yes - the mount is missing in a slew by a repeatable amount for a given mount and a given payload. So compensating for it should work just fine. Precisely because the error is in the slew and not in the sync. Any error of any kind that is repeatable in a slew would be corrected by offsetting it - unless the mount is knowingly conspiring against it.
There is always a chance the ascom driver is doing something weird in all this - and I hope not. If I aim for a given position and it lands consistently off by 1 degree - then I aim for a position away from it by one degree - it should offset by one degree per my request. If it doesn’t - it would be hard to explain what is going on since we know from the logs it is very consistent in hitting a given target - with a precise offset.
But I don’t think ascom is involved at all here. Again - I sure hope not.
This is not handled in the test version of SGP. If these tests bear decent results we’ll do this right…but for now it’s not worth the time or effort to add that level of error handling…so stay away from the poles and meridian
What the Astronomical software community really needs is an Angle class that handles the arithmetic and logic around angles, something that knows that 350 is less than 10.
I agree with your assertion that errors in RA during a slew are often the result of not allowing for the continuing RA movement (15" / sec) during a slew. In a recent post on the AP group it was noted that the new AP controller (CP4) now “continues to track” while doing the slew making the slews more accurate. If a scope takes 10 seconds to slew to the specified target point, the sky will have moved 150 arc seconds west during that slew. So even if the telescope’s gearing were perfect the point where the scope stopped slewing would be 150 arc seconds off target. This error can be significant (for imaging) when a scope only slews at 3 degrees / second.
It is possible that some telescope controllers take “time to slew” into account when calculating the amount to slew but I have never seen that documented anywhere.
It is sort of like skeet shooting – you have to aim where the target will be; not where it was.
For celestron mounts the firmware designer has stated it is largely an issue of timing in landing the mount at the right place at the right time. You can read the documentation on “Calibrate GoTo” - it is designed to tune the GoTo timing for the given mount and payload to compensate for this variation. This would have explained and potentially solved the problem for celestron mounts - but unfortunately the firmware has changed so that this feature is not supported - in exchange for faster and more consistent slews.
If the miss is repeatable - for any mount and for any reason - there is good reason to think it can be compensated for in a subsequent slew. I see no reason not to expect this.
And if you are truly in a regime where the mount is missing the target randomly in successive slews - with no consistent offset - then you at least have a chance to hit very close after a few tries. It wouldn’t “converge” but it has a good chance to “eventually reach.”
But as it is - I expect it actually to converge rapidly and with less error - for any mount that for some reason shows a consistent offset in the sgp centering routine.
Isn’t there anyone who can try the new code? I cannot - unfortunately. Even without the code - as I described above you can ask a mount to goto a particular ra/dec a few times and note the offset. If it is consistent, tell it to go to a slightly different ra/dec to compensate - and see if it improves the final result. No ascom or sgp involved - just the mount doing its thing.
OK - although my cge-pro is not available I was able to do some handcontroller tests with an Edge8 on evolution.
This is an alt-az mount but I told it to be in eq mode for the test.
I aimed it at ra 0, dec 0 and read the ra/dec values after 3 slews. They were consistently off by -1.4 or -1.5s in RA and +5" in dec. The sign of the error was also constant. This corresponds to a fixed offset of the landing from the target - according to its own encoders. Multipying the ra error in seconds by 15 to get arc seconds, this is a miss of 23" - just based on the encoder landing error alone. Nothing about the goto accuracy or the model.
I then proceeded to follow the routine of the pseudocode I provided here long ago - to compensate for the previous error and keep trying.
I therefor aimed first for +1.4s, -5" instead of 0, 0 - and immediately landed at -0.6s, 0. This means the dec error was nulled completely and the ra error was more than cut in half - so the total miss is now 9" instead of being stuck at 23".
Repeated application of the routine kept the miss at 0 in dec, while the RA error varied a bit from a minimum of 1.5" to a maximum of 16.5" as it re-aimed at the target. So although it did not converge perfectly and exactly - it immediately removed the main bias - and after that was hitting on either side of the target with most hits within 10" of the target and as low as only 1.5".
This does not test the total sgp system including plate solve - but it does test the ability to offset the target goto location to remove most, and nearly all, of the error that causes the centering routine to get stuck at some location off the target. And this is with a fairly basic alt-az mount - as opposed to the much more accurate cge-pro.
Anyone can do this with a mount indoors as long as you can do goto’s to a particular ra/dec value and read the result.
Although @freestar8n results are interesting and as is pointed out, this information only suggests improvement under the skies with plate solve. The mount coordinates only roughly tell us what plate solve will produce,
This thread has wondered around considerably. It really does not matter how accurate a particular mount does a slew. What we want to know is if you do a delta slew can you get as good a result as doing a sync and slew.
So may I suggest limiting further posts to this thread to results comparing the released SGP with the test version that Jared provided. If it is as good, then the sync can be removed which will help those with sky models and not hurt those without models. We need under sky results from many mounts to validate this proposed change.
Charlie, I don’t think that’s something new with the A-P CP4 controller. The earlier A-P controllers all have had closed loop slewing to a RA/Dec target. I think the post to which you are referring was was probably about something different.
