Polar alignment capability based on SharpCap

New feature request: add a polar alignment capability along the lines of that in SharpCap, i.e.

  • From home position, take and platesolve image
  • Rotate scope in RA through 90 degrees
  • Take and platesolve image
  • Deduce centre of rotation and notify user of error in az and alt
  • (optional) Based on above, identify star onscreen and where to move it to while shooting new images continuously to give realtime update on user adjustments of alt/az knobs

Apart from the last optional step, all the functionality is already there. Just needs a simple bit of code to identify the coordinates of the centre of the rotation and the distance of that from the pole.

Would be especially useful for those of us in the southern hemisphere.

Restriction of SharpCap is that
(a) it requires a particular sized field of view to plate solve and so need to use a separate finder guider + camera combo piggybacked on the main scope (whereas SGP could do it with the main scope as its plate solve works fine as is), and
(b) SharpCap can only solve within about 5 degrees of the pole. SGP has no such constraints.

In addition, with the mount control, SGP could do the 90 degree rotation automatically - that is currently a manual step with SharpCap.


Would be a nice feature for SGP

Agree it would be great if Polar Alignment could be done in SGPro to avoid switching between software packages.

1 Like

Agree… :blush:

Why? What’s the reason for not wanting to switch packages?

Its not only for “not wanting to switch packages, after all we do that right now & already and that is why we want it changed” it is a matter of a intergated solution for polar alignment capability in SGP:. You buy one SGP package and have an all in solution within SGP " including polar alignment capability" …

Plus you wouldn’t be limited by the constraints of Sharpcap e.g. within 5 degrees of the pole and only a certain range of sizes of fields of view supported.

I understand that what’s in SharpCap may not be what you want but why in SGP specifically? Polar alignment has nothing to do with what SGP does.

I guess because
(a) the functionality is basically already there so it’s easy to add, and
(b) I’m not too sure that it doesn’t fit in with SGPs philosophy i.e. with what SGP does. After all, it has a focus capability for the scope. Why not an equivalent tool to “focus” the mount?

You mean the ability to acquire and plate solve images I suppose. That’s a small part of what’s required.
The application must be able to move the mount about the mount primary (hour angle) axis without moving it about the secondary (declination) axis. There is no functionality available to SGP that will do that reliably.
The core of a polar align routine is the 3D geometry that determines where the mount primary axis is pointing, determines the polar align error and works out where the mount must be pointed so that adjusting another set of axes, the mount azimuth and altitude axes, to centre a star will polar align the mount. SGP has nothing like this, not even close. It’s not at all trivial to work out the coordinate transforms required and easy to get something that seems OK but isn’t. A support nightmare. I’ve tried it.

t doesn’t really fit into SGP. SGP’s core functionality is to automate the collection of images. Focus is a property of the image so it’s reasonable that SGP does it. Polar alignment is a property of the mount and it doesn’t change. It’s part of the mount setup and should be done before SGP is started.

1 Like

No, it doesn’t need to do all that. All it does is move the RA axis by (about) 90 degrees. If it’s not aligned, when it plate solves the second time and works out the centre of rotation, that’ll show it’s not aligned.
[The way SharpCap’s routine work is it simply solves two images separated by a 90 degree or thereabouts - doesn’t have to be precise - rotation about the mount’s RA axis. It doesn’t need to model the sky. It then from the two plates can work out the true RA/dec coordinates of the centre of rotation - simple bit of geometry - and tells the user how much they’re out by from the true pole.]

I’m quite happy even to move the RA axis by hand as I do with SharpCap i.e. undo the clutch, move it 90 degrees, and redo the clutch. All that’s then needed is two plate solves and the simple bit of code to work out the centre of rotation between the two.

I’m merely suggesting taking advantage of SGPs superior plate solving and not having to set up a second camera to do it (given the field of view constraints of SharpCap I need to use a finder guider mounted on the scope just for this - I use an OAG for guiding normally).

I agree with you Paul. SGP already seems to have all the pieces including the ability to take an image, plate solve and move the mount in RA. I’ve done some google searches and found the calculations and reproduced these in Excel. They don’t seem that complex to me however I’ve only looked at one case (Southern hemisphere and looking East) so there would be a bit more effort to make it completely generic. The Sharpcap routine is very good so it is obviously within the realms of possibility however the limited image scale/fov in Sharpcap is a shame. I’m surprised there is so much negativity to including this in SGP. I suspect most SGP users have a portable setup rather than an observatory so it would probably get a lot more use than some of the very specific features that are being included.

It would be more useful if the functionality of SharpCap / PoleMaster could be put into a smartphone via WiFi. You need a visual reference while altering the Alt/Az and I don’t want to balance my laptop while fiddling with the bolts in the dark. As it is now, I run the Polemaster software but use a small iPad in remote desktop mode, so that I get immediate feedback on my alignment. It is better if this is done with a continual feed, as PM does.
This doesn’t fit with what SGP is designed to do. Fully integrated applications are not a panacea. For instance SGP uses other applications for guiding and platesolving and I have not noticed any opposition for that ongoing delegation.

You can do that now. Install teamviewer on your phone ;). SGP has the ability to give constant updates in frame and focus. How is this different to what polemaster does?

Just because something could be made to work is not a reason to make it so. SAK



I understand the points re the ethos of SGP and how this might not fit into it (and I think the same argument could be levelled at Sharpcap as the tool feels slightly incongruous within that program). My point was mainly that Sharpcap’s routine is good. SGP could do it even better (fewer constraints) and much of the core functionality is already there so it’d be easy(ish) to add.

Whether it could be integrated into the main program or spun off as a separate utility might be a discussion worth having.

Just an aside re Polemaster, as was raised above: the algorithm is essentially the same. The main difference as I understand it (never used Polemaster) is that it doesn’t plate solve but relies on the user to identify the appropriate asterism - easy for those in the northern hemisphere, but a bit more painful for us down south! :slightly_frowning_face:

Buzz, I can understand why it is not of interest to you since you have already purchased polemaster however your decision to do that demonstrates you understand the importance of good and rapid polar alignment for successful astrophotography.

There are aspects of SGP that I don’t need however I don’t argue against them as they are of interest to others. There are users who don’t have polemaster and would benefit from a polar alignment option that takes advantage of the main ota focal length. I don’t believe this compromises any other sgp functionality so I remain surprised that there is such strong negativity to something that would benefit many users.

We started developing a Polar Alignment Wizard a few years back and decided to drop it as we decided other features were more important (Framing and Mosaic Wizard). It may be something we decide to revisit later but there are a handful of great tools out there for it already so I’m not sure if we need to reinvent the wheel there (PHD2, PoleMaster, etc)

The still remaining shell of the Polar Alignment Wizard:


Peter, it is a question of priorities, not negativity. There are still plenty of things to do within the current scope, reminding ourselves of the finite resources that two guys can bring to bear when they program in their spare time.
I have a pier mounted Paramount MX. It has TSX, which aims to be fully integrated. It has an accurate polar alignment routine and acquisition capability. I do not use TSX as a capture program since it requires add-on applications to reach the automation possibilities of SGP. That has been the case for many years, so it suggests SB have decided not to go into automation themselves. Likewise both TSX and Maxim DL almost advertised the use of FocusMax, when it was a freebie. If these applications work together in harmony, there is little advantage to integrating it into your application, with all the necessary incremental labor of ongoing maintenance and support.

I’d like to add my experience to the discussion. I use Macs as far as I can and I had great expectations from KStar/Ekos, which uses INDI (a very attractive alternative to ASCOM), is multi-platform and implements all it’s needed to do astrophotography, from planetarium to auto-focus, from sequencing to polar alignment. But as it tries to be everything to everyone, reliability is hardly its best feature. While I appreciate the effort of development community, it seems they are much more interested in adding new features than fixing bugs. As an itinerant astrophotographer, I can’t stand to live in a perennial beta testing status. I demand reliability when I’m out imaging, so I went off the wagon.

I really hate to boot my MacBook with Windows, yet I went for SGP and I don’t regret it at all. It does what it is supposed to do with 100% reliability. Period. I do polar alignment with a PoleMaster before launching SGP, but it could be PHD2 or SharpCap or whatever. I don’t really care it’s two different processes. Give me a real screwdriver and scissor, not a flimsy Swiss-Army knife!

That’s why I agree with @Jared, @buzz and @Chris: it’s a matter of priority, reliability and support. To me, the game of adding a feature that’s well implemented elsewhere, at the risk of weaken reliability/support, isn’t worth the candle.

This concept is so important to me that I moved in the reverse path, from a do-it-all application like Kstars/Ekos to a do-just-one-thing-but-do-it-well application like SGP.