As someone who can’t imagine imaging without SGP, I am reading this thread with more than a little interest. I just retired and was seriously considering buying a MYT. With nothing but time on my hands now, I fully intended to learn TSX, but to have no option to use SGP and it’s plate solving may be a deal breaker. I really hope this issue can be solved, as I have to make a decision within a few months.
Dean
I don’t follow the Paramount world too closely, but if they have removed the ability for third party connections to sync the mount to a location in the sky, to me this means that SB prefers you use their modeling system. In this case, you should probably, for all targets, turn centering off and just leave the “slew” option on. This should, depending on the accuracy of your TSX model, get you where you want to be.
That’s all well and good but in my limited experience with TSX, plate solving with SGP is much more accurate for centering my target. I have made several pointing models with high numbers of points but when using a scope with a moveable mirror, the pointing is off when I meridian flip. TSX may be a good piece of software but it is not for automation. SGP fills this role extremely well and I plan to keep using it. If it means I have to stay on an old version of TSX, I will. Plate solving just works and I don’t have make new pointing models every time I change the OTA or conditions change.
TSX does have the “closed loop slew” which to my eye does exactly the same thing in that it plate solves and adjusts the position. Maybe there is a way to call this function? I do realize that Paramount users are probably a small minority of SGP users so figuring out a way to get around the problem is not high on the list of priorities.
Sorry for my ignorance, but I guess I don’t understand why SGP syncs during the centering process. Couldn’t it do the same thing and just not issue the sync or does that cause a problem? When I try with the sync inhibited in the ASCOM driver, the initial slew works fine but it is unable to fine tune the pointing. It gets to a point, usually 100-200 pixels off and won’t get closer.
Thanks for a great product and keep up the good work,
Chris
It is the reason you are able to enjoy the accuracy you speak of… Without sync:
Slew to position A, mount slews with error, but thinks it’s where it should be. Plate solve shows it is not where it thinks it is (need to sync here to introduce the delta between actual position and position A, but in this scenario we we don’t), we issue the slew command again, mount does nothing because it thinks it’s already where it should be.
To be 100% honest, we don’t have a huge interest in refactoring the centering process to work with mounts that don’t allow us to sync (not saying we won’t do it either). A syncless slew can certainly be done if we take the burden of nudging the mount around, but nudge does not work for all scopes either. If this becomes the number one chief complaint (or at least is high in the list), we can always consider it…
There is no need to nudge at all. I have provided code and done extensive tests to demonstrate accurate centering with just slews and plate solves. It is trivial to implement and does not add state to be tracked. It has many advantages over the sync approach and no disadvantages I can see.
I can provide a link to the thread but Jared should know about it.
There is no fundamental need to associate syncing with centering. It just happens to be the way sgp implemted it.
Frank
As you know by now, we cannot solicit or accept code from our user base… ideas or code coming from published, publicly available sources are just fine.
That said, I have not seen the code you wrote, but I do know that the mount thinks its somewhere it’s supposed to be and it’s not. Would you not need to implement a function that asks the mount to perform “fake/corrective slews” to a position equal, but opposite to the error, essentially temporarily adjusting the target’s position (also known as Kentucky windage…)? Either the target’s position or the scope’s position must be made aware of the error, if you are not going to make the scope aware of it, I assume you move the target temporarily to fake it?
Either way, it is a change I’d prefer not to make if at all possible. We’ve got a lot of other stuff on the radar and, unless this becomes a chief complaint, probably will not be visited in the near future.
Hi,
I think not only paramounts will benefit from a sycnless centering. This feature will work for:
– Any mount run by the sky.
– Celestron mounts. When I had my CGE pro I never manage to get super accurate centering, I have to increase the threshold quite a bit.
– Mounts with complex sky modeling. For instance when imaging with my Atlas and EQMOD the mount never was very accurate when full sky model was enable, it perform much better without any model at all.
The other advantage I see about syncless centering are:
– more robust “center here” functionality, last time I tried it was broken.
– You cannot pollute the mount’s sky model i.e. it is safer cause is harder to confuse the mount’s safety limits (if any)
And you guessed right, I do have a Paramount and I love SGP and I want to keep using this combo.
Cheers,
Jose
Thank you Jose. Yes this problem affects my cge pro for a different reason and I cannot use centering or multi target sequences as a result. I have been pro actively explaining this and doing tests in many threads. First I did it with words. Then pseudocode. Then manual tests. And finally with Python code. The performance with my cge pro was dramatically better, with convergence to arc second level in two or three tries.
All it requires is solve and slew. Sync is not needed but can be performed at the end as an option.
If there are still questions on how and why it works I can explain it yet again. But anyone with questions please review my posts and test reports and logs first. It really really should not be hard to understand.
Frank
One key point to add. For my cge pro the mount knows exactly where it is after it syncs. It is essentially perfect. But it is imperfect in landing where it was told to go.
Despite this goto error the mount is operating fine in terms of its goto specs. It is not specd to perform exactly as sgp wants it to - so it has no obligation to perform the way sgp expects.
Other mounts don’t have this goto issue but they do have an issue with sync. It is similar that the mount does not want sgp to use sync like that.
Frank
I think the incompatibility between SGP and the current version of TSX may
eventually preclude using SGP for full automation with TSX. Can get around
the issue for now by using a previous version of TSX but the full install
of TSX will catch up with the daily builds and older versions will no
longer be available. The newer version of TSX has features and
improvements that are not part of the full install version. Pointing
without plate solving in SGP is probably not good enough - at least for my
system. If resources are not available, I can certainly respect the
decision by SGP to not address this issue. However, I am disappointed
since I really like SGP and would have preferred to continue using it.
Kwas
Adding my vote for “please help the paramount owners center” movement
We can ask SB to put back the sync functionality, but I genuinely think that syncless centering has some advantages.
Cheers,
Jose
Right… like I said above, this is something we would prefer not to visit, but I did not say it was something we refuse to do. This weekend, it will occupy a spot on the “features voting poll”. Make sure you give it your support there and it will weigh into our considerations when prioritizing the backlog.
I know we are just “SGPro” and SB is an 800 lb gorilla, but you have paid them a lot of money for a mount and might want to discuss the options or reasoning on their forums. Regardless of our decision to refactor centering or not, I am still hearing that TSX does not want 3rd party connections attempting to sync the mount. This is OK and is their prerogative. This means that they want you to use their (untainted) modeling system for precise movements. Also OK. BUT then I hear that people are not achieving acceptable results doing this. So… again, regardless of our decisions around centering it might be a discussion that TSX / Paramount users want to have.
Sb is not alone in wanting limited use of sync. The use of sync is causing problems with several mounts for different reasons. You have already added a lot of functionality to make mounts center with accuracy beyond their native performance - and it just happens to use sync - but there is no need to. I would avoid syncing entirely in all sgp operations unless a user specifically requests it.
If this were a major change involving a lot of added state to track this would be a big deal. But I don’t think it is. You can center without syncing and you can plate solve without syncing.
Frank
Seems at this point it would be easy to put it in an ASCOM driver that wraps an ASCOM driver and handles the sync offset in the outer wrapper. Similar to POTH.
The main issue we have is that we should be able to rely on the ASCOM contract. If other manufacturers are not wanting to adhere to that contract then it makes it a mine field to support their drivers. Minimally they should be returning false for “CanSync” and we should respect that (which we do).
So if the driver reports false for CanSync then we won’t actually sync the mount at ANY time, even during the centering process. And yes, centering will still work, although without sync it may never converge since the mount’s idea about it’s location is plumb wrong.
Unfortunately it sounds like the driver is saying “true” for CanSync but then throwing an exception when we attempt to sync it. Which is bad. If the driver doesn’t support sync it should just tell us and we won’t sync. Simple as that. This behavior has been in SGP for a while now.
To me it sounds like the driver needs to be fixed…but maybe I’m missing something?
This is totally fine provided that the driver reports false for CanSync. They can limit it all they want and even limit it in specific situations if they so desire (close to the pole, etc). But if the driver reports that it can be synced…then we should have the expectation that we can sync it.
Jared
Here’s some info. I just did a quick test of the TSX ASCOM driver. I used POTH to see what functions are being used. When the “inhibit sync to protect model” box is unchecked, POTH shows that CanSync is true (a check mark). When inhibit sync is enable/checked, CanSync changes to false (unchecked in POTH). And that’s where the problem arises, centering never converges without the sync. So if I understand you correctly, you are not sending a sync command in that instance anyway and therefore the parts of the discussion referring to centering with or without a sync are somewhat moot.
So at baseline, ASCOM driver for TSX is functioning as you expect, and it works fine. The change in functionality is one that SB made and seems to be in TSX itself and changes CanSync to false regardless of the ASCOM driver setting. And unfortunately, TSX must be running for a Paramount to function.
So I think a better direction for the discussion is can SGP’s centering be made to converge as expected without the sync command, because you aren’t sending it anyway if CanSync is false? In the meantime, I’ll just continue to use TSX 10.3.0 which works fine with SGP. 
Thanks for your time and consideration,
Chris
Eh… We’ll see. I hate to keep repeating myself, but we’ll see where it falls on the priority list based on user popularity. If you don’t mind please resist the urge to tell us how hard or simple something is to implement at face value. We understand the algorithms are simplistic, but you are wholly unaware of the architecture in which these algorithms exist.
That’s about it. SB changed from allowing sync through their scripting to not allowing it. No notification to developers, no change to documentation.
I wrote the ASCOM to TSX driver for SB and this is one of the things that caused me to write to them formally saying that I was not prepared to continue to support it. It’s like building a house on sand. It’s time they dog fooded their scripting.
Part of the problem is that there are no capability properties in the SB scripting so no way to tell what is or isn’t available other than to try it and see what happens. That’s why there are so many options with the ASCOM driver. I hate it but there’s nothing I could do other than to dump the mess on the user and hope they can sort it out.
Chris R
Hi,
This is not the place to complain about SB but I’ve been very disappointed since I bought my MX+, the source of frustration comes from their support and snob attitude. They don’t care much about interoperability of their equipment so even if you decide to implement the syncless centering there is no warranty that your implementation will work with future releases of SB software.
To me is clear that an ASCOM compliant mount should work with your current approach. I see some benefits from avoiding syncs, specially for mounts that run complex sky models.
Instead of pointing fingers, I think you need to decide if you are going to support Paramounts (theSkyX controlled mounts), the same way you do with Sbig and QSI (non ascom cameras). A good way to decide is with your current user base along with the feature request poll.
Cheers,
Jose
I have no programming knowledge and do not understand the details of how
these programs communicate so please forgive me if this is a naive question:
Would it be possible for SGP to issue a command to TSX for a closed loop
slew when starting a target or at the meridian flip?
Is this something that could be added to feature requests?
Kwas