Is there any chance that a checkbox could be added to not issue a sync command after a successful plate solve?
I love to use ProTrack (T-Point) with my MyT mount. It allows me to do unguided imaging or if I add a guider, it makes guiding much smoother as it corrects proactively. But I can’t use “center” as it does a sync command after the plate solve which throws an exception. Using “slew to” is almost as good - with T-Point the slews are corrected and are almost on point. But only “almost”! It would be great to being able to use “center” for final/small corrections.
This may already be resolved in an unreleased version. Essentially we’re now checking if the mount allows sync before it is issued which is likely the sour e of the exception.
Think we have been round this loop before, can you confirm the version of the ‘ASCOM Telescope Driver for TheSkyX’ you are using and what options you have ticked? and also which version of the SkyX, should be using the latest daily build 8908 released May 22nd.
I use V 6.0.5391.19493 of the ASCOM driver and have a full 150 point model with Pro Track enabled, center here works fine and syncs back into the model with no issues, I am not the only one doing it this way so know it works ???
The error you are getting is thrown by the ASCOM driver, I am guessing that you have inhibit Sync check box ticked which is why the error is thrown, is that how you have it configured ?
I cant test with my setup due to constant cloud and even if it did clear everything is broken down while I commission my new observatory but I allow sync into the model, it only aligns the model and does not touch the rest of the terms, have you tried it with allowing sync?
Mark - please share a screen grab of your Ascom driver settings for TSX. I do not experience the issues you are describing. I suspect you have disabled sync - which then will throw an exception. thanks
AIUI if you do a sync on top of a TPoint mount model then at least part of the TPoint model, derived from multiple positions over the whole sky, is replaced by the sync data, generated from a single position. This can give good pointing locally but at the expense of all sky pointing.
I don’t think that you can’t have two applications that are responsible for telescope pointing; either use SGP’s solve and sync or TPoint.
The point here is you can sync into a model and as you you it only affects the local point state, all other terms and unaffected to pro track will still still be effective.
Mark, have you tried running without inhibit ticked? I think you will find this all works fine.
Chris - yes you are correct - but that is not the point (pun intended). The solve and center in SGP gets us to within 2 pixels anyway - but it appears that the Protrac tracking software is unaffected - which is based on angular trends and multiple parameters, including refractive ones. Trevor and I could be completely wrong but we both “feel” that the autoguiding goes easier when we do this. I guess the only way to confirm if that is true would be to turn Protrack on / off / on again and compare the magnitude, trend and noise of the autoguider corrections.
It might be worth raising this on the Software Bisque forum. Patrick Wallace developed TPoint and ProTrack and is a world expert on this. He will be able to provide a reliable opinion on how much sync could affect ProTrack.
My guess is that ProTrack may not be greatly affected if the changes induced by a sync is small but pointing will be affected. That’s really what I’m suggesting, you can either use TPoint to give you good pointing or have SGP handle this using solve and sync, but not both.
I raised it in the forum and also talked to one of the developers directly.
They all discouraged very strongly against any external sync commands when
using TPoint and ProTrack.
But as Jared said, this might already be fixed in a next version.
Yes, we just won’t sync the mount if it says it can’t sync. However this could still get you into a bad place if your mount model isn’t accurate enough. Essentially if your mount can’t sync (for whatever reason) YOU REALLY SHOULD NOT USE AUTO CENTER.
Here’s an outline of what could happen if your model isn’t accurate enough and you’re using Auto Center with a mount that doesn’t support Sync:
Auto center runs
SGP tells the mount to slew to 0,0 (let’s just use pixels here…)
SGP solves the image and finds that it’s located at 10, 5 (that gives us a pixel error around 11.2, Pythagorean’s Theorem)
Now if 11.2 pixels is within the tolerance everything is happy…if it’s not…
SGP will again tell the mount to slew to 0,0
The mount will likely not move as it thinks it’s at 0,0
SGP will solve and again get 10,5 with an error of 11.2…rinse and repeat
Eventually SGP will fail out because we couldn’t get you within your tolerance.
So…again, while suppressing the sync will not cause your mount to throw an exception you should really not use Auto Center if your mount can’t sync as this could still cause things to fail in a new and exciting manner
This is more theory over reality, as I have said a few time before I have a full model that I did mainly for pro-track (helps with PA as well) and I sync into my model.
I don’t really care if the sync upsets my slew accuracy, not that is seems to as always within 25px or less,as I am letting SGP centre here function deal with that, just let SGP sync into the model - it will normally get within my 5px tolerance with one adjustment.
So letting SGP sync in the model works and does not in practice mess the model, you get the advantages of pro-track and the accurate polar align.
You can listen to all the ‘you should not do that stuff’ or try not listening to the perceived wisdom and and try just enabling sync and see what happens, you may be pleasantly supervised.
Addition to the above, I guide so do not know what effect the sync will have on the unguided attempts - don’t really understand while you would want to be able to do 10min unguided when guiding is so easy to configure.