Alfred post=71515 userid=2597
A few other quirks that I spotted during testing:
1. I started with SEP-multistar. After clicking "Guide" to start calibration, an error message "failed to select an auto star" appeared (as just one bright enough star was in the field of view) even though "Autostar" was not ticked. I find this confusing. In case SEP-multistar always selects the guide star on its own (I'm not sure), the "Auto Star" box should be ticked and greyed out automatically once SEP-multistar is chosen.
You are right: Mode 'SEPMultistar' always uses 'Autostar'. I was able to write a small patch that corrects the display of the 'Autostar' checkbox. It is now checked and greyed out if the guider is in 'SEPMultistar' mode. I hope it will be merged in KStars-3.5.5.
AOK Skywalker DDM
Celestron Edge HD 14"
Starlight Trius SX35
Starlight Lodestar X2
Starlight SX Maxi Filterwheel
Focus Boss II Focuser
KStars Ubuntu 20.04 LTS on NUC
I really like the internal guider, especially the MultiStar guiding. However, I have had mixed experiences with the guiding quality. It works, but I cannot really control the guiding quality, because there are a lot of unknown variables:
- the guiding pulse duration
- the proportional gain
Both are very technical aspects of the guiding mechanics behind the scene. I cannot really describe the problem with all this - it just feels less natural from the thinking I'm doing. On the other hand it seems that my NEQ6 introduces some problems, at least with pulse guiding. Until now, I'm back to PHD2 using an ST4 cable. Not because the internal guider is not good enough, but I'm still new to KStars/Ekos and the best results I got with the ST4 cable and PHD2 - here I get a nearly flat graph, if I have a good polar alignment and the seeing conditions are not so bad. And I have some easy to understandable controls to control aggressiveness and hysteresis for both axes. These are things I just can bring into relation to what I want, the hysteresis for overcompensations and the aggressiveness for reactiveness. Thinking in pulse duration (when I not even know how long the pulse should go) and a proportion factor is much harder to express how I want to control the curve, it's a less mathematical and more technical perspective of nearly the same thing. What I'm missing from PHD2 guiding with Ekos is the visible feedback from the camera, it is really soothing to see the stars matched inside their boxes - so if I would be able to have better control over the internal guider I really would prefer using it (needless to say: not having the control over it is just a user feeling ).
I would really appreciate if we could see some improvements in the UI and perhaps the logic of the internal guider in KStars 3.6 or so - understanding that it is not as easy as it might seem, but good things might take a while.
Yes, a revamp of the guider UI has been on my plate for quite a while. Hopefully it will get done in the next few months. Until that happens, though, let me try to describe what is going on.
Guiding can be split into (a) estimating the current error--how far and which direction the scope has moved from its target position in the sky, and (b) generating and producing a correction pulse.
SEP MultiStar is used for "a". I believe you are more concerned with "b", which is described below.
We send correction pulses to RA and DEC motors, so the scheme needs to understand what those motors do. Calibration is the process that measures, for each motor, how far "the target moves" when that motor is pulsed for N milliseconds, and in which direction it moves. This is complicated by backlash, but let's ignore that for now, and also assume calibration is "good enough".
So, given we have estimates for the RA and DEC directions in image space, and for RA and DEC's "arc-seconds of movement per millisecond of pulse" we can apply a control algorithm to correct the guiding error.
[Please forgive me if I'm over-explaining something you already know below, just wanted to be as clear as possible.]
Say we measured 2 arc-seconds error West in the RA direction, and 100ms pulses --> 1 arc-second of movement. A full RA correction pulse might be 200 ms East. Of course, it's not a good idea to full correct the pulse, so there's a gain associate with that, and if the gain is 0.6, then the correction pulse would be 0.6*200=120ms. That's a basic proportional control. That's what's going on with DEC and RA guiding (when not using GPG), with the exception that instead of entering 0.6 or whatever, you control the proportional gain by changing the values of the "Proportional Gain" row in the table on the "Control" sub-tab on the lower right of the Guider tab, where the RA and DEC values default to 133. Increasing the value (above 133) increases the proportional gain.
Why 133 you ask? Not sure, this pre-dates my involvement in the project, but I believe that 133 means "provide 133ms of pulse for a 1 arc-second error". That is, it is NOT using any calibrated measure of your mount. So, if your mount required 266ms/arc-second, then the effective proportional gain is 0.5. There is also a min-pulse field (e.g. don't send any pulses lower than, e.g. 30ms) which implements a type of hysteresis, and a max-pulse field which is a type of protecting for things going out-of-whack on a bad measurement. [BTW, there is also an Integrated gain implemented (defaulting to 0)--I haven't been able to improve my guiding performance when using it.]. That's it (if you're not using GPG). Thus, this guiding scheme does NOT use the calibrated "arc-seconds of movement per millisecond of pulse" values, but rather relies on the user to enter the appropriate numbers. It does use the calibrated directions for RA and DEC, of course.
If you are have enabled GPG guiding (which only applies to RA), then the situation is a bit better. The calibration measurements are used, and the gains are input in a traditional 0.0 -> 1.0 way. Ignore the "Proportional Gain" and "Minimum Pulse" fields in the RA column of the "control sub-tab", and instead use the settings in the Guider tab's Options --> GPG RA Guider menu. There you will find a traditional control gain (which does use the calibrated movement value) and minimum move value (now in arc-seconds). You also get a prediction gain, as the GPG scheme is predicting what the next error value will be and preemptively correcting for it. It's basically that, but slightly more complicated, see the code in: invent.kde.org/education/kstars/-/blob/m...cess_guider.cpp#L341 and invent.kde.org/education/kstars/-/blob/m...alguide/gpg.cpp#L221
BTW, I'm happy to take concrete suggestions for improvements and, even better, work with you and provide you with custom versions of Ekos you could evaluate and provide feedback for. However, this latter interaction would require that you compile Kstars from source (cloning and git pulling from a forked repo of mine).
many thanks for taking the time to explain the details of Ekos' guiding. I use the guider for years and never got my head around why I would have to type in a value for proportional gain when the guider does its own calibration and should know these values very well.
In my maybe naive thinking calibration measures how the mount moves when a certain pulse duration to the N,E,S or W is applied. Once the "learning" has been accomplished, the software knows the pulse lengths that have to be sent to the mount to counter a measured error.
Reality, according to your explanation, is much different though. The first thing that strikes me is the fact that calibration does not measure backlash. IMO calibration should do this for both axis and subsequent guiding should compensate for it.
The second thing I am scratching my head about is this: Although calibration measures movement per ms pulse duration for all four directions, it never uses all of them. It rather (at best) uses two, one for RA and one for DE (i.e. the two proportional gain values). Mounts are not perfect and as it is the case with my G-11, a 100ms pulse to the W will move the mount almost twice as much as a 100ms pulse to the E. I know that should not happen and maybe something is wrong with my gear or motor. But Ekos, despite measuring these differences, ignores them. It sends the same RA pulses to the E and the W which leads to over-correction in one direction or under-corretion in the other. Guiding should make optimum use of all the information that has been gathered during calibration.
In my opinion guiding is right at the heart of any astronomical imaging software as it (besides factors like seeing that are out of our control) decides the quality of our raw images. I'd be more than happy to help improve this most critical aspect of the software.
- Calibration currently measures the movement-per-millisecond-pulse in RA and DEC. Though, admittedly it moves in both directions for each motor, it currently only calculates the "out" direction (whatever direction results from positive pulses). I suppose that an imbalance in the efficiency of the pulses could be due to scope balance, and could change depending on where in the sky one was pointed, and calibration is intended to work across large parts of the sky? Because of that, I'm not sure that it makes sense to distinguish the directions. Of course, if it made sense, it could be modified to measure the average of the in & out directions for RA (and 2 for DEC), or perhaps all 4 as you say, but right now it's just measuring "out".
-Feel free to research and propose a backlash scheme--in enough detail to be implemented
I'd be haappy to hear your ideas
<em>Calibration currently measures the movement-per-millisecond-pulse in RA and DEC. Though, admittedly it moves in both directions for each motor, it currently only calculates the "out" direction (whatever direction results from positive pulses). </em>
I propose we measure 6 values: RA in, RA out, DE in, DE out, RA backlash, DE backlash. I have an idea how we could measure all these values in one go. Ekos guiding should then compensate for backlash and in addition provide distinct pulse durations for all four directions thus compensate for mechanical imperfections of any mount (or even scope imbalance). These 6 values can be measured and can be applied during guiding. It would further improve the quality of guiding so why should we not use them? I'll write to you in more detail about it after the weekend.
<em>I suppose that an imbalance in the efficiency of the pulses could be due to scope balance, and could change depending on where in the sky one was pointed, and calibration is intended to work across large parts of the sky?</em>
That was my first suspicion, too. More often than not, balance IS the cause of the problem. Since I am well aware of my mount's problem, I pay utmost attention to scope balance. So far, all my testing has lead me to believe that balance is not the root cause of the problem. I took everything apart and found that in some (that's what makes it extra tricky) cases my RA transmission gearing moves easier in one direction than the other. I suspect the motor is not strong enough to completely overcome the extra resistance. I'll switch (RA<->DE) motors first and gears later and see what happens.
I'm looking forward to discussing the details with you.
sorry to get involved but I wanted to understand things a bit better.
For how I know guiding, backlash in RA is meaningless as you never reverse. Or you shouldn't. RA is always moving, so the motor is always working against a weigh. Now, the guiding pulses should always be accelerating or slowing the motor, but never running in the opposite direction, as is the case with DEC. So that's why you shouldn't bother with backlash in RA.
Now, even in DEC, you shouldn't either. DEC errors account for polar alignment inaccuracies. In a perfect world, a perfectly aligned mount would leave the DEC motor off for the entire session. Of course this being impossible to achieve, the next best thing should be figure out where the DEC drift is heading (N or S) and correct only in the opposite direction, disabling the unwanted direction. The DEC should only have a drift, hence why you need to correct in one direction only.
Please verify what I'm saying is right, I always like to learn
Also, question to Alfred: are you positive the same amount of pulse moves your mount differently in RA+ and RA-? If so, please check that your mount have maybe a different guiding speed per direction? It sounds strange but you never know.
Thank you for your explanations. I'm happy to hear there are some further improvements planned and I will be happy to assist you. I think the most important problem with the UI is simply the fact that all supported guiders have slightly different logic and behavior and this results in many different settings which can be found at different places in the UI. I did not try GPG Guiding yet, my polar alignment seems to be very good in DEC now but there are still smaller corrections in DEC. But I will give this a trial some day just to get some experience with it.
Another idea: Can we "detect" guiding issues like bad polar alignment, large backlash and badly balanced mounts? I think, with multistar guiding we could perhaps derive something like an upper estimated limit for the seeing. Not sure, if we could see from the required corrections and the mount behavior on correction pulses if polar alignment is not good enough or if the balance is an issue. However, if we could give some feedback to the user about estimated seeing conditions, mount balancing or polar misalignment - this would really be helpful - I guess a larger backlash could be detectable. It could be that we can not always derive the exact issue, but even if the user gets the hint "polar alignment or mount balance should be improved" this could be a valuable information, especially for those who need to polar align each night. We don't need really exact values here, just to check if things are above a threshold corresponding to the sensor pixel size for the used focal length. I did not see this in comparable software, however multistar guiding is something new and this could be the key to reduce seeing effects when estimating the other things.
you're right, there shouldn't exist backlash in RA provided guiding rate is <=1x siderial. I don't know whether there is a case where guiding rate is >1. Frankly, we don't even have to know it. If there is no backlash, our procedure won't detect any and guiding wont try to compensate for it. Same goes for DE backlash. The procedure will detect what's there. If there is no backlash or backlash in one direction only, the procedure will detect it and guiding will act accordingly.
Fabio Papa wrote: "Also, question to Alfred: are you positive the same amount of pulse moves your mount differently in RA+ and RA-? If so, please check that your mount have maybe a different guiding speed per direction? It sounds strange but you never know. "
Yes, Fabio, I am. This
is a photograph of a star trail that I generated sending 5 guiding pulses (of the same duration) to the mount in each direction (while tracking). As you can see, movement in DE+ and DE- is the same but movement in RA+ and RA- differs very much. The G-11 provides several guiding rates (0.2, 0.5 and 0.eight). They are all the same for RA+ and RA- (at least as far as I know).
Your image is really puzzling. You cannot have backlash in RA.. Are you 100% positive you're actually pulsing the right axes? Ie, when pushing RA+ the actual DEC motor is absolutely silent? Because looking at that image, it would be perfectly normal if the labels were reversed.
Yes, I am sure. I did use the Indi "Guider Conrol" TAB,
entered the pulse duration for NORTH, did press SET 5x and then did the same for WEST, SOUTH and EAST. As I said, my transmission gear sometimes is "stiffer" in one direction than the other. I have no idea why that is or even how this is possible. I'll have to do a couple more tests to find out what's going on.