Jared,
I never used slew on the basis that I thought it was just that, it will not use plate solve to get within the specified pixel margin one has defined.
So if slew will get us within the margin we have specified and uses plate solve to get there then I guess noting needs to be done on SGP side as this gives us a way to plate solve without sync … but I was always under the impression slew, was just slew …
Thanks,
Yves
In my case I want to center a target accurately enough to place a specific guidestar safely on an oag sensor. This requires setting a specific oag angle and centering the target to match the FOVI layout.
I think my current accuracy with the sgp centering is slightly less than 1’, but I can’t set the tolerance too small because it may never reach it.
But for me and others with similar issues, the repeatability of the attempt at centering is very good - I think a few arc-seconds. If the centering were working as well as possible, it wouldn’t get stuck a bit off from the target - it would zero in on it and start to miss by a small amount randomly around the target location. When that happens you know you are limited by the repeatability of the mechanics and not something that software could fix.
I am all for reporting everyting in arc-seconds - especially HFR for star sizes and errors in centering. It is much more natural to me and although it may not be natural for other people - I think it is to their benefit to think in arc-seconds for guiding, star size - etc. because it is a fundamental unit that translates to different systems. If you get a ‘feel’ for things in terms of pixels - it only applies to your setup and will be off if you change something.
I realize pointing more accurately than 1’ is asking a lot - but I am very much in the spirit of using smart software to get the most out of given equipment - rather than keeping things very simple and accepting adequate performance. I would not want to do something very elaborate that involves a lot of code and modeling - but in this case I think it is pretty simple and would be a win in many ways. If it does somehow unravel and causes crazy new centering problems - that would be unfortunate and it might need to be abandoned - but I wouldn’t expect that to happen.
I just wish I could try it now but that will be delayed some days.
Frank
As for ‘sync’ and what it does - it sounds to me like the ascom sync command invokes the mount’s sync command - and that does whatever the mount maker wants it to do. And there are two very different things that seem to be happening:
Sync’ing in this way should greatly improve pointing near the sync location - but it will probably make pointing worse in other parts of the sky.
For a celestron mount the sky model is unchanged - but this sync offset is added to every location. It’s a delta on top of the sky model. For my mount sync would improve local pointing accuracy from about 3-5’ to about 1’.
But for many mounts that sync like (2), there may be a setting that converts the sync mode to be like (1). But many users aren’t aware of this and need to figure out how to change this setting. And once you change it - you lose the benefit of this all sky improvement to the sky model. So it might be better in that case to leave the sync mode as-is - but just not sync while centering.
That’s my interpretation of things from what I’ve read from users here.
Frank
EQMOD has two distinct interpretations for SYNC.
The user is responsible to select the right mode in the setup, depending on what he/she wants to do.
Other ASCOM Software implementations are using this strategy (e. g. TheSkyX) and it seems that this is a necessity, once the author of the Software wants to automate the creation of a pointing model. For this reason, I think ASCOM should extend the interface and specify something like “SyncToModel” and restrain the acceptable implementation of the “sync” command to set the actual RA/DEC.
Regards
Horia
Hi Jared,
I don’t believe SGP’s Slew does a plate solve/delta correction. I’m thinking it just sends the absolute target RA/DEC to the mount?
As we discussed, it doesn’t make sense for Centering to not work if it’s just sending the delta between the plate-solved reference and the plate-solved scope image. I think sending a SYNC to the mount is messing it up.
When there’s no mount model it’s not a problem because I suspect most mounts will ignore SYNC.
When there is a model, that’s where the fun begins. A SYNC can add a bias to the mount model, depending on the manufacturer.
Best,
KG
Yes - I don’t think the word sync should be used for (2) at all. It should just be AddToSkyModel or something. Sync means Sync - not “Include this as another point in the model and adjust the model slightly.”
If the mount maker doesn’t want to allow a sync of type (1) then the ascom driver could keep track of the sync offset itself - and do the sync for the mount. Then there could be a separate call for AddToSkyModel - and only some mounts would support it.
But none of this helps with my mount issue because I think the sync is fine for me. It’s the landing accuracy that’s the problem - I think.
If the new code Jared provided works - then all these issues would be swept under the rug - I hope. The mount is just a black box and if for whatever reason it doesn’t land at the intended coordinates after a slew - this should handle the problem.
One thing I didn’t mention is that for people who do want the mount to sync when centering, it could happen at the very end when the position is within tolerance, and after the last move. It would only need to be done once - and then the ra/dec values in fits would be correct - etc.
Frank
I think you have a good point here. If the sync was only done once at the end of the center, it should not mess up a sky model because it does represent the true location on the sky (within a tolerance). When SGP does a sync after each plate solve (before convergence) it could be adding multiple close by points to a model which is not desirable. I think that this discussion concludes that multiple sync’s as now done by SGP is not a good thing. SGP is effectively using the mount to calculate RA/Dec offsets. It remains to be seen whether a final sync should be done. It might not be harmful but is it useful?
We shouldn’t have to care. If we have a specific implementation against specific hardware then we would have to care. But since we are talking through an interface we should be able to expect the exact same behavior for all devices. I love ascom, but my biggest complaint is the standards are too loose. If they weren’t we wouldn’t be having this conversation.
Jared
The way I think of it is that SGP has taken over control of the mount positioning. It’s difficult to work for two masters so if your mount also has a pointing model then the two can fight about how positions are determined.
If there are places where you think the standards could be improved then please let the ASCOM developers know. Changes to the documentation are easy, it’s all in the sources and if, for example, the documentation for the Sync command can be improved this can be done.
Changes to the specification are more difficult but are possible and we pay attention to driver and application developers who have concrete reasons for things that they need and are going to use. The Observing conditions standard came about as a result of discussions here.
But there are some issues:
There are a couple of elephants in the room:
However:
We are putting a bit more in Conform to check how Sync behaves. It will check:
Both of these are positions as reported, not where the scope is actually looking.
The current documentation for Sync says:
Matches the scope’s equatorial coordinates to the given
equatorial coordinates.
And
This must be implemented if the CanSync property is
True. Raises an error if matching fails. Raises an error if AtPark AtPark is
True, or if Tracking is False.
The way that Sync is implemented is mount dependent and it should only be relied
on to improve pointing for positions close to the position at which the sync is
done.
I’m not sure if this can be made much clearer (and IIRC I did change it fairly recently).
Chris
Correct the TPoint models for a Paramount do not like additional syncing (the ASCOM driver has the ability to disable syncs reaching the mount) and using a delta is potentially a benefit.
In reality, however, if you have a TPoint model, these mounts are capable of a RMS pointing error of 10 arc seconds or less- so a slew to target is sufficient and centering is not practically required. If the system is not stable and pointing error is worse, disable TPoint entirely and use slew and center and enjoy the ride.
Have you tried this?
I have an MI250 with a Gemini2 controller and it does about the same as your mount with a 6 point model.
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.
Since switching to SGP I have never used any modeling at all as plate solving and syncing gives even better results - 99% of the time it’s better than 10 pixels on the first centering attempt @ 1.75 arc/sec per pixel. I know you use much longer focal length so your results may be different.
The Gemini2 and the Ascom driver have 2 options for synching -
Sync -
a) Rotates the default ‘perfect’ model to the coordinates reported when no ‘built’ model is present.
b) Rotates the ‘built’ model to the coordinates reported when one has been created.
Sync performs additional align - Adds an additional point to the existing model.
Most of the people having issues seem to be using 1b) or 2. Both involve the ‘built’ model.
SGP currently works perfectly on my setup and, it seems, many others with 1a) .
Does option 1a) cause problems with your setup?
Clear Skies
Mick
There are many things I can try to confirm and check my system behavior - but I will be delayed doing it. But people seem remarkably surprised that a mount would not be perfect in making a move to a specific alt/az position quickly - and land at exactly the right time and angles. Celestron mounts have a specific routine to correct for this as a function of payload - and I heard from the firmware writer that some error remains - yet the overall result is in spec for the goto accuracy. It was not spec’d for perfect behavior in a sync/slew operation.
For any mount some simple things to check are:
I hope to try these things with my mount when I can - but others can try them, too.
Frank
The current ASCOM Conform application does the slew tests that Frank suggests, here’s an example:
10:10:21.481 SlewToCoordinates INFO Slewed to within 00:00:03.14 HH:MM:SS of expected RA co-ordinate: 00:44:06.97
10:10:21.481 SlewToCoordinates INFO Slewed to within 00:00:13.33 DD:MM:SS of expected DEC co-ordinate: 01:00:00.00
10:11:14.234 SlewToCoordinatesAsync INFO Slewed to within 00:00:02.01 HH:MM:SS of expected RA co-ordinate: 23:44:40.37
10:11:14.234 SlewToCoordinatesAsync INFO Slewed to within 00:00:14.12 DD:MM:SS of expected DEC co-ordinate: 02:00:00.00
10:11:27.578 SlewToTarget INFO Slewed to within 00:00:03.32 HH:MM:SS of expected RA co-ordinate: 22:45:33.27
10:11:27.578 SlewToTarget INFO Slewed to within 00:00:13.61 DD:MM:SS of expected DEC co-ordinate: 03:00:00.00
10:11:39.235 SlewToTargetAsync INFO Slewed to within 00:00:03.33 HH:MM:SS of expected RA co-ordinate: 21:45:46.63
10:11:39.235 SlewToTargetAsync INFO Slewed to within 00:00:13.33 DD:MM:SS of expected DEC co-ordinate: 04:00:00.00
I’ve been trying a beta version that tests Sync and here’s what it gives:
10:13:20.318 SyncToCoordinates OK Synced to sync position within 1.3 arc seconds of expected RA: 22:42:57.21, actual RA: 22:42:57.30
10:13:20.318 SyncToCoordinates OK Synced to sync position within 0.1 arc seconds of expected DEC: 24:48:20.50, actual DEC: 24:48:20.57
10:13:29.803 SyncToCoordinates OK Synced to reversed sync position within 1.4 arc seconds of expected RA: 22:50:57.21, actual RA: 22:50:57.30
10:13:29.803 SyncToCoordinates OK Synced to reversed sync position within 0.1 arc seconds of expected DEC: 26:48:20.50, actual DEC: 26:48:20.43
10:13:46.694 SyncToTarget OK Synced to sync position within 1.4 arc seconds of expected RA: 22:43:57.26, actual RA: 22:43:57.35
10:13:46.694 SyncToTarget OK Synced to sync position within 0.1 arc seconds of expected DEC: 24:48:20.50, actual DEC: 24:48:20.41
10:13:56.179 SyncToTarget OK Synced to reversed sync position within 1.3 arc seconds of expected RA: 22:51:57.26, actual RA: 22:51:57.34
10:13:56.179 SyncToTarget OK Synced to reversed sync position within 0.1 arc seconds of expected DEC: 26:48:20.50, actual DEC: 26:48:20.43
That’s for an AVX but I think that all the Celestron GEMs will be similar.
As you can see syncs are very close but slews are out by about 12 arc sec in Dec and something like 30 to 50 arc sec in Ra.
The AVX with the StarSense HC is similar, so is the SkyWatcher.
That’s what these low to mid range mounts seem to deliver.
Chris
last night was a clear night and I was able to do “Slew To” and “Center Now” testing without a mount model. My setup is a CGEM-DX mount with StarSense. I powered up the mount and only did a “Quick Align”, no mount model. Slewed to my target, Draco galaxy group specifically NGC 5982 by using the StarSense hand controller. From there I started SGPro up. I have “Slew To” and “Center Now” checked. It did the slew and the first center was 202 pixels off. after the 2nd it was 98 pixels off. and the 3 to 10 keep hitting between 80 and 85 pixels. Given my image scale of 0.69 arc-sec/pixel this gives me a consistent miss of approximately 55 to 60 arc-seconds. for my setup and from past experience with using “Center Now” with a mount model I see no difference with my system between having a mount model or not have one. My setup seems to be able to repeatedly land to within 55 and 60 arc-seconds. Sync does not seem to negatively impact my setup nor does it seem to help. This might be because of what Chris R mentioned in that for the StarSense Sync is broken. Anyway, I take this test to mean for my image scale I can’t expect my pointing to be much better then 80 pixels.
Hope this helps out the discussion.
Regards,
mahaffm
Which version did you test? Was this with the current release of SGP or the test version I attached somewhere in this thread?
Thanks,
Jared
I was using 2.5.1.14
mahaffm
This is all consistent with what I expected - so now we just need to know if Jared’s recent change will help - and it is unfortunate timing that I can’t test it just yet.
Chris’s conform test is good info and it helps convey that only a few “seconds” of error in RA (which corresponds to clock time) gets multiplied by 15 to become arc-seconds of error in the sky. His results show less error in dec. than RA - and that is consistent with the challenge of landing at the right encoder values at the right time because the sky is moving. It’s like a missile with perfect gps hitting a moving target.
Unfortunately both reports from Chris and mahaffm don’t show how repeatedly it misses by the exact same amount in ra and dec - but I think that for my mount it is fairly consistent. This isn’t a criticism of conform or anything - because it is doing its job well. It’s just that to know if Jared’s change has a chance to work - the actual miss value in both ra and dec would need to be fairly repeatable. But I think it is for my mount.
Frank
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:
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.
Hope this helps, I’ve put enough time into it.
Chris
I think you are in good company missing the point of what I am talking about. The issue isn’t accuracy at all - and my mount is like many others in very repeatedly missing by the same amount in a sync/slew operation. My mount behavior is extremely precise - and inaccurate by a consistent amount. The sgp centering results capture that - but conform does not.
It is also odd that you would assume that all mid-range mounts behave mechanically as well as an avx.
None of this really matters since I never thought this was an ascom or sync problem - for my mount anyway. If things do end up pointing that way then I will need to look more into that as a factor.
Frank
I don’t think I am missing any point, You are talking about the mount being commanded to slew to ine position but actually reaching one that’s a little different. So am I. I suggest that you re read what I posted.
Conform reports the difference between where the slew is commanded and where it reaches. That’s the difference you are talking about. It also reports the two values. If you re read the Conform data I posted you will see this. Or collect some data of your own.
Or have you failed to explain what it is that you see happening? That it is not that a slew to a target position actually finishes at a slightly different position and that the difference between the target and the actual position is consistent. If so I suggest that you start again and explain exactly what you are talking about. I find that using numerical examples helps a lot.
Chris