Hi Bill, PEMPro V3 has been released and supports SGPro. Contact me offline if you need more information.
-Ray
Ray,
Thanks for providing this input to my questions. I was wondering if you could elaborate on why plate solved coordinates are ten times less accurate than drift alignment? Is it because you use regression of many points in the drift method to get a trend line vs taking instantaneous coordinates from a plate solved image? If that is the case would the plate solving method gain accuracy by adding more plate solved images (maybe 5-6 instead of 2) and then using a regression of those to determine the drift rate? I would have guessed that a single plate solved image is more accurate than the drift rate calculated by a small number of star centroid calculations based on observing how the trend line takes a while for the slope to settle. To me this suggests you need to drift for a reasonable period of time to get an accurate estimate of drift rate with that method.
Jared,
That’s a shame because the tools you refer to all require a view of the pole or are drift alignment based which is time consuming and eat into dark sky time. I’d like to understand which part of the routine required complicated math as from what I’ve seen the determination of the alignment error is quite straightforward. I’m going to test my calcs tonight and compare my calculated error to the result pempro reports.
Peter, pempro can be real quick. Give a try to the demo. And, sooner or later it will implement a rogue platesolving alignment
I should have clarified that the accuracy can be an order of magnitude higher with electronic drift alignment as alignment gets close to being correctly polar aligned.
The primary reason for the inaccuracy is that I’ve noticed that the plate solves themselves have limited accuracy, usually within a couple arc-seconds. So, if you have two data points and each can be off by a couple arc-seconds then there is a lot of potential “swing” in the drift calculation.
However, electronic drift alignment is measuring many points at the sub-arcsecond accuracy level, which is usually 1/10th to 1/20th of a pixel. It is extremely sensitive to any movement of the stars.
-Ray
It’s a shame SGP never implemented the polar alignment routine. I think it was a bad move potentially at the expense of losing customers. I used to be a SGP user, but i switched to Nina purely because of the polar alignment module in nina.
Whilst i love the layout of SGP, i’m not willing to pay an annual subscription for a product, especially when it has less features than a free product like Nina.
I just dont see the “value” in SGP any more, when there are so many other solutions out there, which seem far more active from a development perspective.
Unless SGP do something radical, i can only see their user base reducing year on year.
I am probably one of the rare people doing the opposite move.
As much as I love Nina’s excellent set of features, I prefer SGP’s interface and interactions.
There’s honestly not much missing for my daily use in SGP.
When the polar alignment module comes, I don’t see any reason to continue using NINA.
As for development it feels SGP is quite active and the support is good.
It’s not really a subscription… Once you pay for SGPro you can use it for life. Like almost any software, you only pay for new features and only if they are worth it to you.
Polar alignment routines seem to be a fairly popular request these days and is something we are looking into…
You are not rare here… Despite @Richard_Buckton s dire predictions SGPro has grown every year for the last 12 years. There is room for everyone here.
1 Like
Ken,
Please don’t get me wrong, i love SGP, especially for the interface layout, but i switched to a different platform as i felt that SGP was falling behind in terms of the “features that i wanted” such as the lack of polar alignment tool. Maybe in the future when some of the features in SGP catch up then i can return.
Please feel free to make those deficiencies known so that we can work on filling the gaps.