Most GOTO mounts have some sort of pointing model. When you do a 1,2, or 3 star alignment of a mount, you are creating a simple pointing model. It does not require something like TPOINT for this issue to arise. Depending on the mount when you do a sync you may be changing the model (alignment). Thus the safest thing for SGP to do would be to avoid the sync. I too have good success with the current implementation. But, I suspect that if SGP calculated a delta RA/Dec and used that to slew that it would work equally as well without messing with the pointing model.
The way SGP works now is effectively a delta slew but it is using the mountâs sync to calculate it.
I donât think this would work well at all. If my initial mount position is off by 5 degrees and SGP doesnât do the sync after the first plate solve, then will it not be off by 5 degrees on every new target slew after that? This assumes SGP is doing a delta RA/Dec slew for successive slews when centering. Maybe it does a mount absolute slew for all of them. Do we really know how this works?
I would think the easiest way to implement this is to always do absolute slews. If SGP does a sync with each one, then mount positioning successively improves.
Sorry for the confusion about what I am suggesting. Of course, any mount slew is absolute RA/Dec. So the point is to slew to the initial coordinates and take a picture. Then calculate the delta between the plate solve and the initial coordinates. Then add that delta to the initial coordinates and slew again. On a well behaved mount this should converge as quickly as the sync because both methods are doing about the same math.
@Kinch, both the current method and the method I am proposing would get your scope pointing where it needs to be. The mount alignment helps get the initial slew closer to the target but is not required to do the final centering. The method I am proposing will appear to work as it does now except for people that have a sophisticated pointing model. It wonât screw up their model and for everyone else it will function the same.
If SGP does not actually sync my mount then âŚeven though it has done the maths correctly (using your method) and puts the mount right on the position requiredâŚwill I not then have incorrect RA & Dec in my headers?
I may be reading your proposal wrongâŚbut for me, having it sync the mount is an integral part of what I am trying to achieve. I start each night from the previous park position (which the mount âremembersâ). From that position I do not do any alignment or model to reaffirm the mount position. When I want it to go to a target it slews to the location (never to the actual spot). At this stage I need the plate solve & sync to then determine what its needed to get it on the spot.
If at this point it does not sync the mount but just uses deltas, as you suggest to move the mount to the required spot, then I am pretty sure, as stated above, Iâll be on the spot but with wrong positioning information in the mount (be it a very small error or otherwise). For me, I believe the sync is a necessity.
The above I think should illustrate where my concerns lie with your proposalâŚif I understand it correctly.
The chance that we will implement this âDelta slewâ is pretty small. Itâs really just masking a problem with the mount or the model and that is where it should be addressed. At some point we have to rely on the hardware to do as itâs asked and adding âworkaroundsâ like this just complicates SGP and leaves the ASCOM driver in a broken state. Itâs not that the delta slew is a bad idea, itâs not, quite contrary actually. But it belongs in the ASCOM driver rather than sgp.
I wonder how many have contacted their mount mfg or their ASCOM maintainer about this problem? I realize that it surfaces in SGP but weâve more than proven that the problem isnât within SGP.
The method I have been talking about is described here as a feature request:
It is written as a method for centering that should solve the problem I have - and the problem many other people have who find that the synch/slew approach gets close and then stops converging. It is stuck very repeatably at some location from the target.
The approach described should work whether you do a sync after each solve or not.
In my case the mount model could be perfect - but if the mount is told to go to ra/dec and it lands slightly away from it - the ra/dec values do reflect the true values - but they are off from where it was told to go. As a result syncing has no effect - because it is already exactly where it thinks it is - but it is not where it was told to go. This is not backlash - it is overshoot or undershoot while dead reckoning. If it were backlash, the encoders would have the correct values, but the pointing would be away from that location.
Syncing is bad for two reasons: it alters the mount model, which for some mounts is problematic, and it may make pointing in other parts of the sky worse. But it is good because it will improve goto accuracy in a region of the sky - and it will improve the ra/dec values reported by the mount and put in the fits header. But a plate solve should insert much more accurate values anyway - if each image is solved.
So I can see the merits of having an option to sync or not. But it would only slightly alter the logic of having sgp track the error when going to a target and compensate for it.
Unless an approach like this is taken - my pointing accuracy will never improve - and people with particular sync methods in their mounts will report problems centering.
If you simply want to support high end mounts that can point reliably - there is no need for centering at all. Just require that the mount point accurately on a single slew. In this case I think there is a simple approach that would work for everyone - with a few lines of code. And for most people - it would have advantages in speed and simplicity.
Letâs suppose we have a mount with a very simple ASCOM driver. This Mount understands two commands:
GoToCoordinates(RA, DEC) â the mount computes the difference between the actual coordinates and the goto coordinates and issues the necessary stepping commands for the RA and DEC motors in order to cover the computed distance. After the slew, the mount knows its actual coordinates are RA and DEC. This knowledge might be (and normally is) more or less wrong.
SYNC (RA, DEC) â this tells the mount to replace the actual coordinates it thinks it is pointing to with the new coordinates and nothing more.
This mount should work perfectly with the SGP centering algorithm.
Now, the most interesting thing is that we have no way to know if the mount assumes a perfectly linear relationship between RA/DEC coordinates and motor steps (this would be a âzeroâ pointing model) or if a complex net of anchor points is used to compensate for system nonlinearities. In other words, the existence and functionality of a pointing model is completely transparent.
If the SGP centering algorithm only works reliably when no pointing model is active, then we have a problem. Either:
The pointing model is defective and is not transparent.
The SGP centering is defective and uses information from the mount or makes assumptions about the mount which are dependent on the workings of the pointing model.
The mount has an unexpected implementation for the GoToCoordinates and/or SYNC commands. They react differently when the pointing model is active.
I do not like the idea that SGP centering works only when the pointing model is disabled. This should not be the case. The pointing model should do nothing more than increasing the pointing precision of the mount and should not interfere with the centering (it should actually accelerate it). A âdelta slewâ algorithm should not be necessary and, if implemented, it would just cover the real problem. The system (SGP + Mount software) is flawed.
It is 1 or 3 and may be different for different mounts. We donât care about the pointing model nor do we know if one exists. We sync at highly precise coordinates And slew to highly precise coordinates. Everything else is up to the mount.
If you want to blame the mount for its imperfections - then you donât need any centering algorithm. Just do a slew and if it lands in the wrong place - blame the mount because the problem is the mount. High end mounts with an elaborate pointing model should point within a few arc-seconds - if you spend enough.
What is missed here is that for mid-range mounts you want the slew to be FAST and PRETTY ACCURATE - but there is little need for sub 1â accuracy. So for some mounts the encoders are not tracked during the slew - and some dead reckoning is involved so that the mount lands on the target at exactly the right time. This is not trivial to do - especially when done quickly and with unknown payloads.
The SGP centering routine is fine in theory - but it makes the key assumptions that 1) syncing works in a particular way to readjust the coordinate system locally with one call - and many mounts do not work that way with sync. 2) It assumes that when a mount is told to go to a particular ra/dec - it will land there exactly according to the mountâs current encoder values and sync state. My mount is fine with (1) but many mounts are not. My mount is not fine with (2) - and it limits the accuracy of the sgp approach.
The approach I describe does not require elaborate state to be tracked. It only applies per target and once the target is centered the state can be forgotten.
@Kinch, SGP is writing the fit headers so it can write the RA/Dec values from the plate solve rather than what the mount says. I donât know exactly how SGP does it now but the sync does not guarantee the right RA/Dec values. It only (potentially) matches the mount values to the plate solve but then SGP does a correction slew so the mount RA/Dec values no longer matches the plate solve. So the sync does not assure the right mount values in any case. It is an interesting point you raise. With either method, SGP has to do some work to get the right RA/Dec values in the fitâs header.
There seems to be some misunderstanding about what I am proposing.
Currently, SGP does:
Slew to desired location; take a picture; do a plate solve
Sync the mount to the plate solve location and again slew the mount to the desired location.
Within the mount, the second slew has the effect of slewing to the delta between the plate solve and the desired location.
What I am proposing is:
Slew to desired location; take a picture; do a plate solve
Within SGP calculate the delta between the plate solve and the desired location. Add that delta to the current mount position and slew to that location.
Except for math differences, the second slew goes to the same location, however, the mount has not been syncâed.
What I donât know is whether in some mounts the sync does some magic to account for built in mount errors. That is why I propose testing on different mounts to uncover any such issues. Ultimately, Jared and Ken will have to determine what priority they attach to the sync problem on some mounts and whether it is worth fixing.
If this the case â and I very much suspect it is â then the ASCOM people should take a stand on this and closer specify and test the conformity of the SYNC behavior.
Ugh - this has nothing to do with ascom or sync behavior. The sync is working fine - it just has no benefit at all when there is inherent overshoot hitting a target. That is precisely why I and others see the centering routine stop improving and get stuck at a location slightly away from the object. That error is NOT due to sync or the pointing model or ascom or anything. It indicates that the mount did not land at the ra/dec values it was aiming at. The mount model is fine, ascom is fine, sync is fine.
The mount is also fine - it is just aimed to land VERY CLOSE to the destination ra/dec values - but not perfectly.
For other mounts - sync behaves differently from what sgp expects. And some mounts should not be syncâd at all.
Rather than just blame the mounts - there is a simple and elegant solution that I think would work for everyone - and it could still allow sync if you want it. Simple, elegant - and the result is good performance for everyone at a low price - with no requirement for high end mount behavior.
Frank
[edit] Oh I see you are talking specifically about different sync behavior. Yes I guess that could land in what ascom requires sync to do. But there are good reasons to have it behave differently from what sgp wants - and some mounts allow different settings.
For me sync is ok but there is error in landing - that is repeatable.
I was caught up in using the mount model on my G11. But SGPâs centering process is so much more sophisticated and precise (fast, single-digit pixel pointing accuracy anywhere in the sky). Itâs not something the mount could do. IMHO, mount models were designed for convenient hand-controller use. Just zero it out and enjoy SGPâs centering.
For the moment I canât be 100% sure on #2 but I believe that to be correct (I cannot check with the mount just now). But, in any case, that was the basis of me saying I needed it to be like this. In this situation, my mount is accurately synced to the sky and although another move (or two) will be required to get on the spotâŚthose moves will be extremely small. Although you are correct in saying that the mount is no longer actually synced (once moved), the error now will be inconsequentialâŚnot like the error after moving across from the parked position. Bottom line for me is that I still think the way that SGP goes about this part of the routine, suits my situation and I donât have any problem centering on target. @freestar8n seems to have a particular problem with centering that may or may not be widespread. I would be interested in knowing if others have that same issue, (and if so, they should speak up), because I feel genuinely sorry that this fantastic part of SGP is not available to him/them âŚfor whatever reason!
As I understand this, when the pointing model was active on your G11 mount, you had problems with the centering. After disabling it, centering works perfect. If this is correct, what ASCOM driver are you using? Is the pointing model integrated?
This is exactly what happened to me with the EQMOD software. It implements both the ASCOM driver and the pointing model.
Correct. Pointing model is stored inside the G11 mount. ASCOM 6.1.1.2627 drivers are on my PC. After disabling (zeroing) the pointing model in the mount, SGP centering worked perfectly.
Any errors in mount model are apparently added to centering. When the mount model is zero, there are no errors added.
@freestar8n seems to have a particular problem with centering that may or may not be widespread. I would be interested in knowing if others have that same issue, (and if so, they should speak up), because I feel genuinely sorry that this fantastic part of SGP is not available to him/them âŚfor whatever reason!
Thanks - yes it is frustrating to see the center routine improve things on the first step - and then get stuck some distance away. I know that other people have encountered this, but for different reasons. But I think all of the reasons for this happening could be fixed by making a small change - and optionally syncing the mount during the centering process. I think sync should be treated with more care and not forced on people in the first place. The main places it is used are in centering a target, and before doing a slew from A to B. I donât think it is essential in either case - and it could be bad.
I expect that my problem is one that almost every mount has - but to varying degrees. It is easy to check - if you tell the mount to go to a given ra/dec - then check the mountâs own ra/dec values after the slew. Is it exact? A few arc-seconds off? An arc-minute? Any error there will affect sgpâs ability to center with sync/slew - and that error can easily be corrected for. And if you correct for it, there is no need to sync - but you still can if you want.
Unfortunately my equipment is out of commission right now so I canât test some things - but I hope to be back up soon.
Frank, is your mount also having this problem only when you have an active pointing model?
What mount and ASCOM driver are you using? Is the pointing model integrated in the ASCOM driver?