Has there been any more thought given to adding a polar alignment module? Seems like once you have plate solving it wouldn’t be too difficult to add that capability. I know there were some views in the past that it wasn’t the highest priority however many of the issues that were being prioritised at the time seem now to be resolved. Something that doesn’t rely on a view of the celestial pole would be very useful for those who have obstructed horizons. I think Astrotortilla does this but I’m yet to try it.
There are some mixed results about astrometry.net pa routine. I was doing some tests this past night with pempro and phd2. While altitude error was within 2 arcmins, azimuth was out of a degree or more. While pempro routine gave me an accurancy of 1 arcmin, long term drifting on phd2 gave back less than 0.5. Astrometry was out on heaven…
I don’t think that a software like sgp should focus on a feature that should belong to mount-programmers, rather i’d prefer to see the option ‘center here’ place the star on dead-center (and that was the nudge panel for)
I think you are right, polar alignment is a mount function. Determining the correct adjustment is complex and requires more information than is available from a single plate solved image.
I think it’s better to use one of the specialist applications to do a polar alignment - there are numerous ways to achieve this - then use SGP for what it can do well - acquiring high quality imaging data.
You could say the same about other modules like environment data or modules that are applicable to a small subset of users like focus lock. Polar alignment is critical to getting good astro photography results. There are many users who don’t have permanent setups and there are also many that don’t have a view of the pole from their home due to trees and other buildings. Many of the third party applications like Sharpcap and Polemaster rely on a view of the pole. Drift aligning works in the case where you can’t see the pole but can be time consuming.
SGP already has the platesolving capability and can slew the mount. It doesn’t seem too difficult to slew to near the horizon, take an image, plate solve. Repeat this for four locations between the horizon and the meridian and the drift rate and hence altitude and azimuth errors should be able to be determined form the change in Dec position for a given move in RA.
All that’s needed then is an overlay that shows you how much to move a star while the camera is looping.
Because this is a one time activity at the start of the session it shouldn’t introduce any overhead in the way the program runs during imaging.
What’s not to like?
That is not accurate, that is the problem. i attempted to use both astrometry.net and pempro, both results were tested by phd2, and guess what? pempro was way, way more accurate.
As long as you code a drifting assistant, you almost do a standalone guiding software. i am not a programmer, but i guess it is a loooot of work.
Perhaps it was just the way you were using the tools? Hard to say without any data. I also suspect PHD2 drift align and Pempro are doing the same maths so I can’t imagine why Pempro would give a different result.
I’ve built the calcs in a spreadsheet today. Took a few hours to programme for southern hemisphere pointing east (which is what I do). I imagine someone more proficient than me would knock it over pretty quickly.
in the end, what it matters is how phd2 follow the path. That is the most common used software. Whatever we use, we do it to improve our phd2 guiding, so if itsays “no good”, i tracks no good…
What the astrometry.net presumes,is that there are no flextures, aberrations, seeing conditions and more. Due my experience, that tool is a starting point, not a refined system. i would love to have a demo of tpoint and see how the two differs.
i always look up to the sky x, but still i decided not to purchase it, maybe one day…
Astrometry.net knows nothing about polar alignment. All it does is take an image of the sky and determine the position of that image in the sky. No assumptions can get from this to a mount polar alignment error.
TPoint is different, it takes a series of positions on the sky and the corresponding mount axis positions and uses this data to determine a number of mount properties, including the polar alignment error. There’s an article on the web that describes this, search for “Patrick Wallace TPoint”.
Even then there are more coordinate transforms to convert these to the mount adjuster coordinates system and to convert to the change in position of a reference star.
I’ve spent some time with this, first helping to debug the original ASPA system, later writing a polar alignment helper for when StarSense could determine the polar alignment error but not apply the right star correction.
It’s all stuff that is part of the mount set up process that you do before starting SGP. It can’t be automated because you need to be at the mount to be able to adjust the mount’s polar alignment.
Hi Chris.
I think this is worth a try based on my experience with Sharpcap at a site where the SCP was visible. Polar alignment was achieved in minutes and checking this with PHD2 showed a very good result. The problem for me is the SCP is not visible at my home location due to trees. From what I’ve read, it should be possible to calculate the errors quite accurately using plate solving at a series of locations between the horizon an the meridian around DEC=0 with the mount only moving in RA. It seems like the calculation of alignment error is quite straight forward based on an article by Hook from 1989.
The difficult part seems to be the star offset calculation to provide some feedback of how far to move the alt and az knobs. This is complicated because you need to convert from RA/DEC to Alt/Az and back again.
I think I’ve got the calcs working in a spreadsheet so plan to give it a try using SGP/EQMOD to do the slews, image capture, plate solving and star centering and the spreadsheet to calculate the coordinates to move to.
Peter
No this is wrong. The definition of Right Ascension (or Hour Angle) is a movement about the pole. If the mount moves in Ra only then the declination does not change and the polar align error will appear to be zero.
The mount must only move about it’s misaligned hour angle axis. Then three positions can be used to determine the position of the pole in the misaligned axis coordinate system. Once you have this you can do as you suggest and point at a star that, when centred by using the mount polar alignment adjusters, will polar align the mount.
It is important to differentiate between the Ra (or Hour Angle) and the axis positions because this is what is being compensated for. Using Ra as an analogue for the axis position will generate all manner of confusion where people have aligned mounts.
From what you are saying you seem to be most of the way there, why not put it all together? Doing a few slews, collecting images and plate solving them is all achievable. I know because I’ve done it. You already have the code to determine the polar align error and understand the coordinate transforms that are required.
Why not put it all together and publish it?
I don’t think this should go into SGP for the reasons I’ve outlined but that doesn’t mean I think that something like this is not needed. I certainly understand the need for a polar alignment method that doesn’t need sight of the pole because that’s my situation.
Hi,
did someone of you give ‘Polar Drift Alignment’ (by Ken Self) a try?
It is implemented in the development snapshot builds of PHD2 since v2.6.4dev5 (30th november 2017). The current dev is v2.6.4dev6 (19th december 2017).
Announcement:
https://groups.google.com/forum/?fromgroups=#!topic/open-phd-guiding/_n9BMLa4PFI
Bernd
i agree with chris.
Setting up a polar alignment routine is not an easy task when North or south pole is not visible. i will take a look to last phd2 build, but doing the task with polaris is easy, specially at north emisphere. I tried several softwares, i found damn easy pempro without polaris, sharpcap with.
However, right now many of us (me too) are confusing Sgp being from “automated astrophotography suite” into “one for all suite”.
i’d love to have a better manual control of the mount. have a a diagram that shows where the scope is pointing, maybe setting sky limits (don’t go here becouse there is the wall of my house), have the possibility to point manually from the quick panels (move 1 arcsec north, move 2 arcmin est… things like that). but truth is…
…that are not necessary into an automation tool. The diagram would be damn useful to understand if something went wrong on mount control (a reverse settings, example), specially when you’re far from your scope
I’m not sure this feature belongs in an automated acquisition package. In the days when I was setting up my rig each night, I was able to do polar alignment just the one time and then be able to reproduce it each night. I was within 1 arcmin. I did this by locking one of the azimuth bolts with a nut and not adjusting the tripod legs between sessions. The tripod feet were spiked and I had them located in cap-head bolts set into (in my case) metal rods driven into the lawn. From time to time I confirmed it by other means but it was always good.
Chris, I don’t really follow what you are getting at here. When I drift align for Altitude adjustment I center a star near the horizon, the mount tracks in RA for 10-15 minutes and I look for a drift of the star north or south (ie in DEC). The DEC of the star is actually constant and the apparent movement of the star north or south is caused by the mount not tracking along a line of constant DEC due to an error in the adjustment of the Altitude.
What I’m proposing is effectively the same except use plate solving to find the coordinates of the center of the image (rather than center a star) and move the mount in the RA axis (say 15-30 minutes of arc) only at a rate higher than siderial then take a second image an plate solve again. Plate solving enables this because I don’t need to track a star to get an accurate measurement of the center of the image in each case so the amount of RA movement and the amount of DEC drift can be determined. Compare the difference in DEC divided by the difference in RA which is equal to the rate of drift. This is effectively what PHD2 and Pempro are reporting except they do a linear interpolation of a series of points where the Y axis is DEC and the X axis is time which is proportional to how far the mount has tracked at siderial speed in RA.
In your comments you refer to the definition of Right Ascension (or Hour Angle) in the first paragraph and then you go on to make a distinction in the third paragraph. Can you explain what you mean by “using Ra as an analogue for the axis position” and why this will generate all manner of confusion?
In relation to you comment about putting it all together, I spent months trying to learn Spanish a couple of years ago ahead of a trip to South America. In the end I could order a glass of non sparkling water or two beers and say hello. Learning to write code is a trick this old dog is unlikely to perfect. There are already people in this community that possess this skill and would do a much better job than me. The trick is to get them to see the potential of someone’s new idea.
Luckily Jared and Ken have been good at doing this and SGP has improved a lot in a very short period of time thanks to them listening to the community of users that come up with ideas. In return the users beta test, provide feedback and tell all their friends how good the product is. I think it is a very clever business model where you tap into free innovation though a forum like this.
I was thinking about the comments about polar alignment not being core to image acquisition. I think it would be an interesting exercise to look a the pool of SGP users. What proportion of them have observatories vs mobile setups (I would bet the majority maybe 70% are mobile) and what proportion can view the pole from their most common imaging location (I bet that’s their home and maybe 50% can’t see the pole due to houses or trees). I bet 100% of them are taking images and 100% of those that are serious about taking decent images understands good polar alignment is a pre-requisite.
There are many good tools for polar alignment where you can see the pole but drift alignment is the only current tool I’m aware of when you can’t. I’m not in sales or marketing but I bet people who are would say offering your customers something they want is one of the keys to success.
Cheers,
Peter
Thanks for the suggestion Bernd. I am well familiar with the tools Ken has added to PHD2. Both of them require a view of the pole. The third option in PHD2 for polar alignment is drift alignment which is what I use.
Hi Peter,
I must admit that I didn’t install one of PHD2’s devs and have no experience with Ken’s tools. Obviously I misinterpreted the function of his drift alignment tool, I’m sorry.
Bernd
No problem. Thanks for trying to help.
Hi Peter,
I’ve investigated using delta declination from plate-solved coordinates, but the accuracy was not very good compared to electronic drift alignment. Plate-solved coordinates are usually only accurate to within a few arc-seconds while drift alignment can be about 10x as accurate.
That said, I think that using the delta declination via plate-solved coordinates should usually be good enough for rough alignment.
BTW, what PEMPro’s electronic drift alignment does differently than PHD2’s is that PEMPro approximates and subtracts refraction from the drift. I believe that this produces a slightly more accurate result.
-Ray Gralak
(Disclaimer: I am the author of PEMPro)
Hi Ray - Bill McLaughlin here (my OES avatar and username can be confusing).
I have always used PEMPro for polar alignment and like it. OTOH I abandoned MaxIm for SGP a few years ago
so am wondering what the status of version V3 is? As I recall it will support SGP for camera control, correct?
So what’s somewhat funny is that we actually started on this about 2-3 years ago but ended up abandoning it. I’m sure you can find remnants of the discussion of this throughout the forum and potentially on the (now non-existant) Yahoo Group. Some remnants still exist in the SGP code base but are not visible to users:
The idea was to slew an “un-modelled” mount only using the RA axis or to have the user slew only with the RA Axis. From there we could model different points and figure out how to adjust the mount with some on image hints.
We ended up dropping it as PHD2 came out with drift alignment and QHY has the PoleMaster which uses the same general idea. Also PemPro has had drift alignment for a long while as well. Also, I’m not that great at the level of math required to make those calculations, so it was very slow going and required outside testing which slows things down considerably 
Thanks,
Jared