I’m not pointing fingers, just stating how things are. It’s completely up to SB to create their hardware and software the way they see fit.
It’s unlikely we’ll go down this route unless we have an actual mount to do this work against. Unfortunately “customer need” can’t always drive decisions like this. Implementing native support “blind” would be horrible and not something we’re interested in. We’ll likely continue with the ASCOM implementation and, for the time being, Paramount customers may just have to suffer with lack of features as the ASCOM device doesn’t support certain things. A
But, as I understand it, you can likely mitigate that by building a hefty model with TPoint and relying only on slew to get you accurately pointed.
In theory yes but you need to build a huge pointing model to achieve good accuracy, not practical for non permanent setups, and plate solved slews still more accurate.
In practice this is not the case. The SB simulator behaves significantly differently to the SB mounts. The documentation is not good enough to be able to write drivers without hardware. Believe me on this, I’ve tried.
Lucky for me, I ONLY use TSX as an interface so that SGP can work with my MX+. I don’t need any of the other features and as long as it continues to work with the older version (10.3.0) I will continue to use it as such. If, for some reason, my Paramount will no longer work with that version then I’ll need to figure it out. TSX is not an automation program, it handles basic functions but cannot put them all together very well. I am quite happy with the function of the mount and I love SGP, although I’m a little dismayed by SB’s attitude towards the ASCOM standard and other software. But it works quite well as is, and guiding with PHD2 has never been easier. If I knew then what I know now I might have gotten an AP1100 instead. Oh well. I only brought this up to see if there was a way to make SGP work with the newer TSX versions but I didn’t realize that SB had made a change that prevents it. Sorry to touch off the firestorm. I’ll bring it up with SB to consider allowing sync to go through.
Thanks for a great product and keep up the good work!
I have asked SB to confirm and express hope it is an accidental omission, based on the fact that they also moved the star sync feature within TSX in the latest daily build. As you say, TSX is not an automation program and I wonder how the others cope (ACP/CCDAutopilot/CCDCommander) etc.
I do hope SB realise that their mount is part of a wider system, which is ignored at their peril.
For instance MaxPilote is very well integrated with paramounts and it uses offsets to center objects. I guess the software you mentioned uses a similar strategy.
I wouldn’t mind to stick with SB suite for imaging but it is incomplete, not stable and the interface is horrible, ah! and it doesn’t have any automation functionality!
Wow, this makes me glad I have not updated TSX in over a year and may never do so again. They just lost my annual subscription and may lose me as a mount customer altogether if this is true. Who do they think they are, Apple?! Have not posted here in a long time but I am glad I read this thread and will avoid updating TSX. In fact, I am still running 2.4.X SGP and an older PhD. Nothing I can see has been added to either that would make my imaging easier so it it is not broke (and so far it is not), I will not fix it!
I may try newer versions of SGP and Phd on a test PC but TSX is gonna stay as is until I am sure SB did not F this up for SGP users!
My experience has been that they have a “my way or the highway” “Apple attitude”. Very sad and if carried much further, would cause me to get another mount. SGP works so well for me that I would abandon equipment before I would abandon it.
This is obviously a touchy subject and this is an SGP forum after all. I fully support SGP and the two developers as they are willing to consider new ideas and discuss and explain direction with their customers, though, as we have seen, being too proactive is not sustainable, even with a substantially smaller user group. It has to be that way too - they are a little fish in a big pond and being nimble is one way to grow rapidly.
That is certainly harder for the bigger companies. Quality has to come first. They need a strong sense of direction and control to remain in business. With their larger customer base, sorting the real issues from the customer errors is a daunting task. We all can recognize that customers get confused with too many options and it may well be that they believe the user experience is more robust by removing features that conflict with core competencies (TPoint). That being said, there is no obvious reason why that cannot be handled conditionally behind the scenes or adequately documented.
Lets avoid a slanging match. It serves no useful purpose. Yes, I have had some recent niggles but in the scheme of things, these are minor compared to the reliability and performance of TSX and my PMX.
I hope they respond positively to my request to re-instate the feature.
In the short term the best bet is for users :
Roll back to older builds.
Request SB put this function back in there daily build.
Only failing that should be for SGP for to develop work around for a non ASCOM compliant mount.
Btw, CCDautopilot took three tries to get high accuracy plate solving without sync. SGP does it in one with sync.
Well, I do see your point but it is a bit hard to not be upset when someone who you have paid a lot of money to does something that breaks the way you have successfully been doing things. It is worse if that breakage is intentional (that has yet to be determined if I read things correctly). I have generally liked the Paramount ME and generally liked TheSkyX but sooner or later I will probably buy another mount just to get something more modern (this is my 4th of this size in 20 years). Lack of interest in pleasing customers that use ASCOM and 3rd party software would be enough to convince me to buy something from a company that is more flexible. I think that most other users would feel the same way.
I am kinda reminded of Apple’s apparent decision to get rid of the audio jack in the next iPhone. Although I use a Nexus, I have to wonder if that would make me think twice about an iPhone.
As others have said, I hope this is just an error or oversight on the part of SB. Time will tell and I will monitor this thread to see how this plays out.
It is hard to imagine SB removed sync by accident. One would hope that requests to re-instate it from a large number of users would be sufficient to get it done but there is clearly doubt about that. To me the bigger question is the attitude that SB seems to have about forcing SB mount owners to use TSX whether they want to or not.
What about the idea that all the SB mount owners using SGP simply get together to fund the development of a fully compliant ASCOM driver for the SB series of mounts? This would be a long term solution that makes using the SB mounts independent of TSX. I would think that “Chris R” might consider such a project or would know someone to do it. Compared to the investment in mounts, cameras, and personal time, the cost to develop an ASCOM driver seems pretty reasonable. I don’t suggest this is a weekend’s worth of work but the developer would have a ready supply of motivated beta testers!
I know this topic is about TheSkyX and SGP but I want to mention that SGP and Astro-Physics mounts (CP3 and CP4 controllers) with A-P V2 ASCOM driver works perfectly regarding to SYNC.
As a Paramount owner and an ardent SGP user, I would be extremely displeased if 3rd party applications like SGP and PHD2 were removed / disabled from TSX. I certainly will not be updating my TSX installation until this issue has been resolved.
I have added my comments and concerns over at the SB Forum. And thanks to the SGP community for raising this topic before I made a mistake by updating TSX.
By ASCOM driver you mean a control program that talks directly to the mount and remove theskyx dependency altogether? That’s not possible, not for technical reasons but SB will not allow you to reverse engineer their communication protocols with their mounts.
I don’t see why people are so upset. The only issue is support of sync and sync is not needed for anything that sgp needs to do. Sgp has an elaborate centering procedure implemented with a lot of code and gui work and it advertises centering to within pixels. It happens to require sync in that process but there is no need to at all.
