Ken (@kengs): The issue where PAA asks you to rotate your mount some crazy number of degrees was my fault.
I hadn't tested manual rotation well. Sorry about that.
(BTW, it shouldn't have affected your results, just a bad message).
I sent Jasem a fix for his review just now.
Also, the issue with a big number in the Err field during PAA was fixed a week or so ago.
That text box should not be filled at all in PAA.
If you go to the GPG Options page (described above) and enter the mount period in "Major Period", and click apply, then KStars should remember it.
If "Estimate Period" is not checked, then the period should not be updated by GPG.
As I said, either look up the period if it's on the PHD2 Wiki page above, or keep a good estimate from a successful KStars GPG session that lasted
a long time, e.g. over an hour since the last slew or other GPG reset.
Unfortunately it doesn't store that information, and needs to start from scratch each time. That's why I recommend at least saving the mount period.
When I introduced this to KStars, I asked GPG's developer, Edgar Klenske, who's developed this as part of his PhD, the same question. He said that was possible but never done, and not a trivial task.
I think this is unlikely to happen in the near term.
The way I see the code, those parameters are not stored in the FITS header. They are store in a side database.
See saveDarkFile: invent.kde.org/education/kstars/-/blob/m...darklibrary.cpp#L139
So, I think, the system has a record in its permanent storage of the CCD, binning, temperature, duration, filename.
When it wants a dark, it looks through all of the possibilities in this storage for a match. If it finds one, it tries to load the fits file from the filename.
If that fails, it destroys the record. If that succeeds, it uses the file it loaded.
To hack around the lack of a good dark-frame estimate, I think you'd
- capture a single dark frame with KStars using existing code with the right name, binning, temperature and duration.
- capture other files somehow, outside the KStars dark-frame framework.
- generate your averaged (or median'd) dark frame outside the KStars framework.
- replace the KStars file with your new file.
- adjust those options related to temperature range and longevity.
- give it a try!
For sure, this is a hack, and the right thing to do is implement an improved dark-frame scheme. [Also, I can't be sure I'm right
about the above procedure, as I just looked at this quickly.]
The better solution may happen at some point. One of the developers (or you if you can) could implement things could pick up this project.
However, doing this hack and demonstrating improved performance with a good dark estimate would be valuable in motivating
someone to do the work.
Thanks for the challenging test!
Re the lines not matching the star movement, my guess is this: You have a huge error, 17 degrees. I implemented drawing a straight line in image space (2D projection of the actual 3D curve) between the start point and the solution point. This projection is likely fine for most use cases, but when your error is that large, the projection probably doesn't match the geodesic as well as you'd like. You're the expert in this kind of math, so let me know if you disagree.
I'd expect that this isn't a problem as (a) it led to the solution iteratively anyway, and (b) with a compass and an astro setup, most folks should start much closer to the solution, even with that poor a view of the night sky.
If there was good reason, I could switch from a single projected line, to a series of line segments that better match the geodesic, but I think that would be overkill for almost all use cases. Again, let me know what you think.
Not familiar with that code, but a quick look shows that this is the method that compares things:
and it looks like the two options referenced there are set in KStars -> Settings -> Configure KStars -> Ekos -> Dark Library
FYI, I submitted a fix to the Polar Alignment Assistant (PAA) for an issue related to the rendering of the correction triangle. This fix is detailed in https://invent.kde.org/education/kstars/-/merge_requests/198 and has already been merged into the KStars source code, though as I write this is not yet in any nightlies. This will likely fix the triangle-rendering issue reported by @rbarberac and also by Jasem. I'm hoping my fix from last week solved the east/west issue reported by @rugbyrene (and seconded by Jasem). Assuming these are indeed fixed, I'm not aware of other issues with the new PAA code (Jasem is looking at the "manual issue" brought up by @kengs).
While I was testing that fix, I ran polar alignment using my telescope 18 times over the course of an hour in several different ways:
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.