Please see this post:
Thanks,
Jared
I would like to point out that I had the same issue with my CEM60. The problem was caused by iOptron changing their firmware so that it passes the mount alignment model between the mount and the any software connected to the ASCOM driver. The result was that the iOptron firmware was overwriting mount corrections being sent by SGP. Once I cleared the mount alignment model using the hand-controller, SGP was centering within 5 pixels every time.
Iām not sure if this is your problem, but if you are plate solving OK and the mount is not moving, this may be something to look into.
Fred
Hi Jared, finally had a clearing! Please see attached log.
SlewError.txt (50.1 KB)
I did not read trough the complete message thread ā¦
But when I saw this it was related to pointing model being build, so best is that when SGP solves and sync, the mount software does not add it to itās pointing model, this sounds counter intuitive but believe me, with plate solve you donāt want pointing model anymore ā¦
If this is already been discussed sorry ā¦
(I had this with eqmod, I could never reach accurate framing anymore, until I set the pointing model to manual and not automatic)
/Yves
I have a Paramount MX - presently Iām using TPoint and not using centering, though I have in the past used the automatic centering without any issues - centering to within a few pixels in one iteration.
As soon as I get a clear night I will disable TPoint, disable sync inhibit in the ASCOM driver and try for myself. Since the driver and software are identical to the OP, it should highlight if there is underlying issue. Iāll tryi with Pinpoint 6 and Platesolve 2.
Thank you, Jared. I decided to wait until the next time I am out there getting the same error I am talking about. I have too many logs and I donāt want to get confused and send you the wrong one so I will wait to get better documentation of the error. Thanks for your help!
As I expected it looks like we issue a slew but the mount just doesnāt get there. As others have mentioned it could be the model, backlash, or something else. For the most part it looks like the mount just refuses to slew. The error is always pretty constant around 1245 pixels.
Maybe try just a single star alignment? Disabling any sync based model building and see what happens.
Thanks,
Jared
Hi Jared,
I donāt suspect mechanical (backlash) issues because I did get single digit
centering at one time. The mechanicals are unchanged.
I think it has to do something with the mount model as others have
mentioned. I will clear the model and try building a new one with just one
star. This will allow me to use the G11 hand controller to get reasonably
close to bright stars for focusing.
Iām curious how the mount model might affect the centering algorithm. I
assumed the overall algorithm isā¦
- Take a picture of where the scope is pointing now.
- Compare to the reference picture (produced from the stored reference RA
and DEC). - Calculate the differential to slew the scope.
I believe the mount model corrects an absolute RA/DEC coming in. But if
everything is done with differentials, I would suspect the mount model
correction would have no effect.
Ya, I would think the same. But I not knowing how the mount modelling is performed in the hardware and not knowing what theyāre abstracting from us is the mystery.
With the Gemini you can likely try a couple different things:
- Turn on āSync Performs Additional Alignā with a model in place.
- Disable āSync Performs Additional Alignā and do a Cold Start to clear the model.
1 will essentially allow you to build and redefine the model as you go. 2 completely disregards the model.
Also itās probably worth turning on the āMount expects JNowā (canāt exactly recall what it isā¦but I believe itās something like that. If I remember correctly the Gemini controller ALWAYS returns JNow but if that option is disabled then it will assume J2000 for the sync and slew. SGP will query the mount and ask what format itās expectingā¦but ASCOM only allows for a single epoch and it seems that the Gemini can potentially allow 2 epochs (one for sending and one for receiving)
Thanks,
Jared
I am not sure how other manufacturers handle their mount model, but iOptron changed their handling of the model during their most recent firmware update for the CEM60. They placed the following note in their firmware update history file.
Alignment model will roam between the hand controller, RS-232 port connection and Wi-Fi connection now. If you want to use any pointing enhancement software, such as T-Point, make sure there is no alignment model in the system!
Prior to this update, I did not have any problems with SGP Centering with a one or two star model in the hand-controller. After the update, I had to delete the any alignment model in order to get the mount to respond to SGP centering moves.
Fred
Hi Jared,
Understood. Please see attached for the state of the G11 after performing a
āReset Modelā.
-
Iām thinking if the model is affecting centering, then I should keep a
āzeroāā model as shown in G11-3 and use SGP centering for everything. Or,
just model one star and occasionally align and/or sync (?) to that same
star when something moves. -
For #1 above, do not select āSync perfoms Additional Alignā in G11-2.
This will help prevent updating the one-star model. -
In G11-2, do you recommend selecting āGemini expects J2000 co-ordinatesā
?
I think if you keep it like that and just do an initial āBlind Solve and Syncā (do this well away from the Pole FYI) then you should be good to go. I believe that will keep the model at āZeroā.
No, leave that off. When off it should talk JNow on both sides. Alternatively if you keep having about the same amount of error try enabling that 
Interested to hear your results. I never bother with a model on my G11 Gemini 1. At first I did when I setup my obs but I get so little time out there now I donāt even bother with a model. Just slew and go, Auto Center FTW!
Jared
As I have described before - having a mount remove backlash is easy and I expect all would. Certainly my cge-pro does. But having a mount go to a specific ra/dec value at a specific time - quickly - involves timing and dead reckoning - at least for some mounts.
Iām not talking about the true ra/dec values - but the ra/dec values of the mountās encoders, or where it thinks it is. This is easy to check by telling a mount to go to a particular ra/dec value - and after the slew you ask the mount where it thinks it is. If there is any error there - it will also be there in the sync/slew process used by sgp. And it has nothing to do with backlash - and repeated syncs/slews will not improve anything.
Unfortunately right now I canāt test my mount but I will when I can. Anyone can check this with a mount. Use its handcontroller or something and tell it to go to a specific ra/dec value - probably not too far from the equator so there is no dec. issue. Once it gets there read the ra/dec value where it is. Any error there will be a problem for sync/slew centering.
That is why I suggested adding log info for where the mount thinks it lands after a slew - and before the sync is applied.
If you do see an error - the next question is if you can adjust the target ra/dec value by correcting for that error. Again - this is NOT backlash. As long as the error is repeatable, sgp could measure it and correct for it - without doing a sync at all. This should work for all mount models and for mounts that donāt land exactly where they are told to go.
Right now this is a big problem for me - and I am not alone in having the mount fail to reach a given centering tolerance because it just gets stuck some distance away - and stops converging. My only recourse is to make the tolerance large.
Frank
Just tried it on a PMX with TPoint disabled and synch inhibit disabled in the ASCOM driver - that is, similar to the OPās MyT.
Was within a pixel in a single iteration. Tried slew and center and then center here, with equal excellent results using PinPoint.
With Platesolve 2 - a repeated experiment was within 7 pixels on one iteration.
(pixel scale 0.56"/pixel)
Hello Jared,
Having a āzeroā model inside the mount completely fixes the problem. I am
now seeing centering to single-digit pixel error.
Iām guessing that any errors in a non-zero model add to the centering
error. This may explain why I saw centering error increase over time for an
old model. A āzeroā mount model appears optimal for centering.
I did not try adding one star to the mount model. I agree with you that the
mount model is not needed with SGPās centering algorithm. I simply add my
focus stars as targets and center on them. Thereās no need to use the hand
controller.
Maybe someday this behavior can be explained. For now, Iām very happy to
learn that SGPās centering algorithm is capable of single-digit pixel
errors when the mount model is cleared (zeroed).
Best regards,
KG
Excellent! Glad to hear!
Weāve always recommended NOT having a model. This just helps to enforce that. I donāt really understand this behavior either as it shouldnāt matter but apparently something inside the driver thinks itās where it should be when it isnāt.
I feel you have 2 options:
- Use the mount model and use slew rather than center. This is probably the best option if you use a very complete model like T.Point or similar.
- Use no model and use Auto Center. This assumes that the telescope doesnāt know how to get precisely where you want.
I prefer 2. Folks that do surveys generally prefer 1 as the time for Auto Center is too much.
Thanks,
Jared
The explanation is quite simpel, the model will correct the Ra/Dec coordinates, so only in the case there is absolute no backlash, orthogonal, polar errors etc ā¦ the model will NOT work, thatās why I recommended āno modelā.
As soon as these errors exists the model will try to correct for those and they will skew the slew, it sounds counter intuitive and it even makes you wonder why a model works ā¦ wel the issue is that if you gather to much sync points in a very close manner, the equation will have unforeseen convergence errors ā¦ a model works best with lots of points all over the sky but not to close to each other ā¦ EQMOD mention this, and I guess all other softwares that build models, never really tested with model points a few pixels away from each other ā¦ hence their formula goes crazy ā¦
/Yves
As this thread and other threads have suggested, the method that SGP uses for plate solving/centering can be problematic. By doing a sync of the mount, SGP is changing the mountās sky model which is not a desirable side effect. What SGP is doing is telling the mount āthis is really where you are pointingā and then doing another slew which in effect is doing a delta RA/Dec slew. As others have suggested, it might be better for SGP to calculate a delta RA/Dec rather than depending on the mount to do it. By skipping the sync, SGP would avoid interfering with any pointing model.
The current method seems to work well for many mounts so changing it has to be approached with caution. If @Jared where to create an experimental SGP version that used a delta RA/Dec approach, Iām sure many of us would be willing to test it with different mounts. It would require a significant body of successful tests before making the change permanent. We would not want to be solving one problem while creating other problems.
Do we know that there are any mounts for which the current SGP approach is not working well, assuming the mount does not have a pointing model? If that is in fact, true, then why would anyone want to use a pointing model? My Gemini 2 has always done an amazing job of putting me within 2-10 pixels with usually 2 slews, sometimes 3. This has been true even if it started being off several degrees like when I manually move it around, perhaps for balancing. After the first plate solve and sync, it is right on for the next slew, well within 50 pixels. I have never used a pointing model.
I think in fact a lot of people PAID for that feature in their mounts and now donāt want to abandon it. This of course is just conjecture on my sideā¦
. I can understand their point of view but whether or not it justifies changing (adding other options) to what works really well just now, will of course be a final decision by the developers. For that to happen I am sure they will need to see the justification for putting the work into it. From my side, I can can better understand @jmacon saying that using a pointing model with SGP seems rather pointless (pun intended ) really.
My TAK mount has NO pointing model and SGP (with astrometry.net & PS2) does a fantastic job for meā¦as I am sure it does for a majority of users.