I seem to remember talk of a pa routine…was this the case and is it still on the cards?
I seem to remember talk of a pa routine…was this the case and is it still on the cards?
It’s still tentatively planned for 2.4. It will not be out with the initial
beta for 2.4 though. If it does happen it will be coming later.
Co-Founder and Developer
Any thoughts on developing a polar alignment routine?
We actually started on one a while back but ran into issues along the way. We may pick it up again but it’s not likely to happen in the near future.
Thank you very much Jared.
It would be awesome to have a strong polar alignment routine built in SGP, though.
I don’t understand this desire to have SGP doing absolutely everything. Why not have a separate application to sort out polar alignment? Polar alignment and image acquisition are separate activities. I think that SGP should concentrate on it’s core functionality - handling the acquisition of astronomical image data.
I suggest don’t do polar alignment in SGP at all. Much better concentrate on something that affects many more people, for example getting a good, reliable auto focus that works with obstructed scopes.
Although I understand your point, SGP already has some key elements for polar alignment. That is, image acquisition and plate solving. Once you can get a few known points in the sky, some math will tell you the alignment error. All that remains is someway to adjust the scope. This is often done by offsetting the scope from a star and having the user manually bring the star to center with AZ and ALT. So it does make some sense for SGP to support polar alignment.
I am someone who has been dead in the water for some time on critical and core functionality for which I purchased SGP: plate solving and automatic focusing. I have never once been able even to attempt an automated imaging session because these two features have not been usable. Both issues were caused by hard-coded assumptions that were contrary to the way my system operates. Plate solving was somewhat usable, but problematic due to an assumption of JNow vs. J2000 equinox. That has been fixed, which is great. Automatic focusing remains unusable for me because the focus sequence can only go one way - and that is opposite the way my focuser backlash works. The options available for the focuser and SGP do not provide any way to make it work properly.
At this point I am mainly curious to see if and how the whole thing can work - so I am building a bracket to turn my robofocus motor upside down - effectively reversing its direction. I am at a temporary location so I needed to buy a drill to put this together. All because of a single binary setting inside the code that determines the direction of the autofocus sequence.
So when I see requests for bells and whistles - I hope people keep in mind that some of us are dead in the water on core functionality due to hard-coded assumptions that instead should offer options to fit a user’s setup.
I am puzzled that I seem to be the only one who happens to have a focuser that wants to go in increasing rather than decreasing numbers - but I suspect others do have this problem and don’t even know about it. They may have backlash set to 0 when it should be non-zero - or they may be unwinding backlash on every step without realizing it - which would be very bad.
This is exactly why we offer a 45 day trial. Software doesn’t always work for everyone. Unfortunately reversing the auto focus is not as easy a a binary switch…if it were we would have done that months ago. Same goes for the star detection with central obstructions.
If you’d like a refund on your purchase as you can’t use it just let us know. I can’t give you a timeline for addressing either of those two issues.
Thanks for the reply. I don’t mean to be critical - it’s just that I would like to be a strong promoter of this software and its capabilities - despite its low cost. The focuser issue is complicated because at first I was using a different focus driver - and it happened to go the right direction with SGP. But I had issues with it so I later switched to my old robofocus - and only then learned it wasn’t compatible with the sgp autofocus routine.
I can understand it would be problematic to make the change I requested - and it might introduce new bugs into setups that are currently working. But my main point is to keep in mind things that are hard-coded and perhaps hard to change - but critical for some users, vs. many nice features that are easy to add but somewhat extraneous and add to the overall complexity - and are possibly redundant with tools people already have.
My secondary point is that some users may be getting sub-optimal focus performance due to this issue - without knowing it. So - autofocus users should make sure they have backlash enabled if they need it - and they should make sure the natural focus direction (pushing against gravity) corresponds to decreasing numeric values of the focus position.
As it is I will take a mechanical approach to the focuser issue and see what I get.
I don’t understand. So many of us have it working, what is unique about your setup?
I have explained it in a separate feature request - but in simple terms - the autofocus routine insists on going from high focus numbers to low ones. If that is against the natural focus direction of the system, which is usually to push against gravity, it will not work well. If your system has a large amount of backlash, it will invoke backlash compensation on every single focus step while taking the curve. There are ways to change the direction of “in” and “out” - but the autofocus routine always goes from high numbers to low numbers, independent of those meanings.
I am a big proponent of using the built-in primary focusers on sct’s because in fact they work very well when used with automatic focus routines. But it is essential to take the focus curve in the “pushing” direction - and it is essential to include a large amount of backlash compensation. This backlash compensation does add time to the routine - but should only be invoked twice: Once when going to the start of the curve, and again after finding focus and then going back to focus.
Since I have a large amount of backlash compensation (on the order of a minute) I am very aware when it kicks in. For others who have only a small amount - it may be kicking in on every focus step through the curve - and they don’t know it. That would add time and reduce the accuracy of the routine.
It is well known that users like to have “in” and “out” defined properly for their systems - so both SGP and robofocus have settings that allow the right thing to happen for their systems. But “in” and “out” do not affect the behavior of the sgp autofocus routine - which always goes from high numbers to low numbers. And that will have only a 50% chance of being correct - if you cannot change the way the numbers map to the focus position.
If I am missing something and there is a workaround - that’s great but I have already been told there is no workaround. So I will try turning the motor upside down - just because I want to see plate solving and automatic focusing happen during an imaging session with SGP.
Can you reverse the direction in robofocus?
No - but I can reverse the meaning of “in” and “out” in robofocus - just like I can in sgp. So both the device and SGP are aware that users want “in” and “out” to behave in specific ways - but that can be done completely without reference to the numbering of the focus positions.
So it’s as if both sgp and robofocus know that “in” and “out” are important to distinguish. But when it comes to autofocus, where in and out are extremely important - sgp ignores their meanings and just says - “I’m going from big to small when I take the focus curve no matter what.”
My suggestion is that - if anything - sgp should always take the focus curve by moving “in” - and if users don’t like that direction, they can use the existing “reverse focus direction” button in SGP to make it do the right thing. But “in” may end up increasing or decreasing numbers. SGP shouldn’t care.
Why not use a external focuser like you would on a RC? Seems to be the tried and true method for it. I understand you want the focuser to work remotely… seems like you’d get a better product that way. The only limitation is cost.
I agree that having rock solid focusing/etc should be prioritized, but do think polar alignment would be a nice feature, perhaps even as an add on so those that see no benefit wouldn’t need concern themselves with it.
I currently use PHD2 drift align or just my RAPAS. But presumably, a polar align feature here would need to take images, plate solve, etc. I don’t think they are really separate activities when you consider the breadth of the product. It would certainly be easier to not jump into another program, connect everything, configure plate solving, etc.
Like I said, I wouldn’t prioritize it over the other items mentioned.
I have just finished my “motor inversion bracket” and it looks like everything should now work fine. Since this thread is about polar alignment but there are still questions about my “feature request” - I will respond in that original thread on focusing.