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.
invent.kde.org/education/kstars/-/merge_requests/202

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.
Hy

Read More...

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.



Read More...

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.

Read More...

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.

Read More...

Pit,

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.

Hy

Read More...

Not familiar with that code, but a quick look shows that this is the method that compares things:
invent.kde.org/education/kstars/-/blob/m.../darklibrary.cpp#L58
and it looks like the two options referenced there are set in KStars -> Settings -> Configure KStars -> Ekos -> Dark Library

Read More...

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:

  • rotating East, starting by pointing near the northern pole,
  • rotating West, starting by pointing near the northern pole,
  • rotating East, starting East of the meridian at about DEC=60
  • rotating West, starting West of the meridian at about DEC=60
All my tests went well.

I have a couple things to mention, not directly related to my changes:
  • I once got a "Solver Failed" during PAA, and when that happens, the system doesn't gracefully retry. You need to stop the PAA process, and restart it. I'd like to correct that, but it may not be right away, as I want to make sure this system works, and this state machine can be tricky.
  • I noticed that my system started up with 8x mount speed. Perhaps that was due to some debugging I was doing previously, but if you notice the slew going very very slowly, check that menu item on the polar-alignment tab.
  • I removed the "flip the correction vector" option. I don't think it makes sense any longer, and would confuse the interface. If you feel you need to reverse the correction vector, please contact me and I will try and fix the underlying issue.
Please let me know if you see any further issues.

Read More...

Hy Murveit replied to the topic 'Drift Plot of Guide Module' in the forum. 3 days ago

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.

Read More...

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).



Read More...

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.

Read More...

Rene,

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.
Hy

Read More...