What is plotted is the difference between the measured position and the "lock position" or "target" or "guide star position", or whatever you want to call it. This difference tuple (also called "drift") is what's used when calculating the correction pulses to be sent to the RA and DEC motors--units are arc-seconds, and axes point in the RA and DEC directions (as determined by calibration).
This lock position is set at the start of guiding, and changes when dithering, or when the guiding restarts due to a slew, meridian-flip, or lost guide-star. So, the ideal value is 0,0 meaning, the measured position is exactly where we want it to be.
The same values are plotted on the "Drift Plot" and "Drift Graph" of the Guider tab, as well as the RA and DEC graphs in the Analyze tab.
BTW, calibration is something else--it does not determine the lock position. Often, though, the lock position is set right after calibration.
FWIW, here's my imaging session from tonight, so far, using GPG for the RA guiding.
You can see the Atlas Pro's periodic error pretty clearly at the start, but it seems to be reduced after about 21:05.
It's not an ideal night (you can see the SNR dip around 21:20).
Sorry, I haven't done any periodic error correction on my Orion Atlas Pro and am not really on top of that. Perhaps others can help out.
If you do correct your mount that way, which sounds like a good idea, then GPG's improvement will be less, of course,
though I don' t expect it to hurt to use both. Let me know if you do wind up doing that.
GPG should improve your PE for sure. It takes a few mount periods to reach its full potential (as it has to sample your periodic error before it can correct it).
More or less, all you need to do is check the box to turn it on (and it's probably best to also set the period--see below).
- In the guider tab, click Options in the lower right corner.
- Click on "GPG RA Guider" on the left to get to the GPG section
- Check the enable GPG checkbox.
The only control you should consider changing is to set "Major Period" with the period of your mount and, if you know that, disable the "estimate period" checkbox.
You would only do that if you knew your mount's period. Many are given on this PHD2 wiki page: github.com/OpenPHDGuiding/phd2/wiki/Mount-Worm-Period-Info
If you don't know it, you can let the GPG system estimate it, and then if you were happy with the guiding, e.g. after an hour, re-open that menu, look at the value it's estimated,
and freeze that value in there by unchecking estimate period. Of course, I suppose you could let it continue to always estimate, but it will get to its best sooner
if you give it the right period to start with.
Once it's setup, then you're good, and run guiding as you would.
The RA guiding is then controlled by this GPG algorithm.
Let me know if you have any further questions, and/or let us know how it goes.
OK, that is reasonable, but it is still possible to use the scheduler for on-demand right-now jobs.
It adds a little overhead, but not too much, and does make your imaging a little more resilient to
things like clouds passing by.
If you can, please try that. It might help diagnose the issue, and it might also be a work-around for
you until that gets fixed.
Not familiar with that code, but just to add my experience--I've done imaging with meridian flips the past two nights and had no issues. The align went to the proper spot.
I'm using the latest code, compiled on an RPi4 running Raspberry Pi OS.
I run with the scheduler--always--even if it's one capture sequence job. It seems to do a better job of error recovery, etc.
Are the folks who have been having issues running with the scheduler? If not, I suggest you try and see if that fixes things.
[Of course the underlying issue should be fixed as well.]
Also, @RDBeck, you should probably rename this thread as something like--Bug Report. Misalignment after Meridian Flip.
1) If you downloaded software and compiled, please let me know the last git commit so I can see what you're running. (I've really got to put some version ID in this).
2) Working great or not, I'd love a log from you, being in the southern hemisphere. Can you make sure that verbose logging is turned on to file for at least alignment, and then upload a log somewhere, e.g. google drive, that I could access?
Thanks so much for testing!
Can you please say when you downloaded your code, assuming you compiled from source, or when you got your nightly, if you're running ubuntu.
That sounds just like an issue I fixed a few days ago.
Below is a recent 'git log' on my pretty up-to-date system, and the commit marked
Date: Wed Jan 13 01:01:14 2021 -0800 PAA: sample from the center of the image. Update test. minor bugfix.
is the one that fixed the issue I have in mind.
Are you running with that commit?
commit b90f3ef33d11933fef3bd91b96f75da8b8edd868 (HEAD -> master, upstream/master, origin/master, origin/HEAD) Author: Jasem Mutlaq <email@example.com> Date: Wed Jan 13 20:58:04 2021 +0300 Set maximum temperature diff to 1 up from 0.1 as many cameras coolers are not usually accurate enough to 0.1. This would allow for first image to kick in a bit faster at least while the cooler stabilizes further commit 05510da0e0517c9979791cba1cf79b237dd5dbe6 Author: Hy Murveit <firstname.lastname@example.org> Date: Fri Jan 15 17:35:39 2021 +0000 PAA--cleanup test. Update user messaging. commit 53f886c33d992e5de0bfe7f03faa0a19e4c54d3d Author: Jasem Mutlaq <email@example.com> Date: Fri Jan 15 02:56:14 2021 +0300 Send ekoslive events even when not fully connected commit e15ef966fc27acad80f67a08fabf96ef84e79671 Author: Jasem Mutlaq <firstname.lastname@example.org> Date: Fri Jan 15 01:34:28 2021 +0300 Use KSNotification on device connection failure commit f87c3ba289a3b7c0f0b472877de01aff50726ef6 Author: Jasem Mutlaq <email@example.com> Date: Fri Jan 15 00:57:21 2021 +0300 Use KSNotification::event instead of direct KNotification commit 26c615d944dde77098bb89dcd50319004dbb1434 Author: Jasem Mutlaq <firstname.lastname@example.org> Date: Fri Jan 15 00:31:06 2021 +0300 Use more sane defaults for INDI message notification and starting step size for most focusers commit 29cda560e9ce7fe8f5cbd032220a885753a538c7 (paa-v2-fix2) Author: Jasem Mutlaq <email@example.com> Date: Wed Jan 13 20:38:21 2021 +0300 Use Blocking Queued Connection again since deadlock issue temporarily fixed on INDI side commit 0fa3935718e6d6330dbde253f110eeb6d0b538f5 Author: Hy Murveit <firstname.lastname@example.org> Date: Wed Jan 13 01:01:14 2021 -0800 PAA: sample from the center of the image. Update test. minor bugfix. commit b7ac3bd531a3d59ca36a882808ae342d05cd8199 (origin/paa-v2-fix1, paa-v2-fix1) Author: Hy Murveit <email@example.com> Date: Mon Jan 11 11:23:51 2021 -0800 Fix PAA type (purple -> green). commit cbe33115a418d64aa6f79186fb3096117552980e (origin/paa-v2, paa-v2) Author: Hy Murveit <firstname.lastname@example.org> Date: Sun Dec 20 22:00:15 2020 -0800 New polar-alignment scheme
I'm not on top of the nightly builds either, as I always compile from source.
Jasem's ubuntu builds are here:
The way the alignment works is that the system works out the altitude and azimuth angular offset of the mount's axis from the pole.
The UI then gives you a target position and asks you to adjust the "altitude knob" to correct the altitude offset,
then the "azimuth knob" to correct the azimuth offset.
As you point out, the mount may not be perfectly level, so this isn't entirely true. However, unless you're wildly out-of-level,
I think it would be reasonably effective anyway.
You can try it anytime you like--by using the nightlies. It's there.
Upon reflection, you are right that although it directs you to turn the elevation knob, if your mount is not level,
then that won't quite do the trick and you'd have to improvise.
Clearly best to level the mount as best as possible.
Still, if you iterate, you'd likely get close to a good alignment in any case.
I imagine you could get the result you desire with repeating scheduler jobs, as the next (identical) scheduler job could align at the start.
I've never tested this to make sure there are no gotcha's.