×

INDI Library v1.9.2 Released (14 Sep 2021)

Bimonthly Stable INDI Library release introduces new drivers and fixes for existing ones.

Internal guider: do we have any control over DEC pulse aggression?

  • Posts: 750
  • Thank you received: 59
Hi everyone

In RA, I can adjust the pulse % and the amount of PE to correct but I can't find any control setting for DEC.
Is there any?

Cheers,
Steve
kubuntu 20.04
700d, eq6, t7m
Last edit: 9 months 2 weeks ago by alacant.
9 months 2 weeks ago #65630

Please Log in or Create an account to join the conversation.

  • Posts: 260
  • Thank you received: 46
I THINK we're intended to do this by adjusting the "Proportional Gain" number under the "Control Parameters" tab at lower right in the Ekos Guider panel. The left column here is (I think) supposed to be RA and the right column (I think) is supposed to be DEC. See screen cap below.

Not really sure but I believe "Proportional Gain" is somehow proportional to milliseconds of mount movement at guide rate per arc second of movement on the sky, with the default of 133 meaning half of sidereal.

You can also change "Integral Gain" which is some kind of scaling for correcting slowly-accumulating guiding errors in RA & DEC. Also worth experimenting with minimum and maximum pulse.

This is one of the most frustrating pieces of UI in the internal guider to me, because the numbers seem to be almost completely arbitrary and with four meaningless numbers to adjust in each of two unlabeled columns there are an infinite number of wrong combinations! Finding the correct (or even an acceptable) combination by random fiddling seems extremely unlikely!

We need better names for some of these parameters ("aggressiveness" comes to mind), and labels above the two columns.

[NOTE: 133.0 is NOT actually half the sidereal rate of change of position per unit time in milliseconds of motor movement per arcsecond on the sky.

0.5 * secPerSiderealDay * / arcSecPerSiderealDay * 1000 = 33.2 milliseconds of mount movement at half sidereal per arcSecond of sky
where secPerSiderealDay = 23 hours * 60 min/hour * 60 sec/min + 56 min * 60 sec/min
and arcSecPerSiderealDay = 360 degrees * 60 min/degree * 60 sec/min

]

Last edit: 9 months 2 weeks ago by Scott Denning.
9 months 2 weeks ago #65642
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 106
  • Thank you received: 4

+1
Powered by

GNU / Linux
Git
KDE neon
KStars | EKOS | INDI

and some cheap hardware
9 months 2 weeks ago #65645

Please Log in or Create an account to join the conversation.

  • Posts: 706
  • Thank you received: 322
For the record, I agree that the controls for the internal guider need to be improved, and it's on my todo list.

I often walk the line of, on one hand, not wanting to break things that are working for folks, and on the other hand, trying to make improvements. In this case, I hope to move the guider controls from that tab to the guider options menu, and yes rename them. If I get brave, I might even skip using that constant (133) and actually use the value measured in calibration for DEC.

That value is milliseconds of pulsing per arc-second of movement. That is, if the guider senses it wants to move the guide star over 1 arc-second in the DEC direction (which might be, say .8 pixels, or whatever it is on your setup) then it might add an extra 133 milliseconds of pulsing. If you look in the guider options menu, in the calibration section, you'll see the calibrated values for that. Here it is for my telescope:

You can see that my DEC actually typically needs 221ms of pulse to move an arcsecond. So, set at 133, it's under-pulsing. That's actually a good thing (in a reasonable control system, you don't want to try to fully correct the error, or you wind up with ringing). Of course, a better way to do it would be to use the real value, which the user doesn't control, and add in a "gain" parameter which is often set around 0.5.

I switched RA away from that 133 constant, for folks using the GPG guider (which I highly recommend you use) but I haven't made the change for DEC yet. You can see that RA control in the GPG section of the guider options (named control gain). Hopefully I'll implement that for DEC sometime soon ;)

Now, though, here's my request to (all of) you:

IMHO, you CAN contribute to KStars, in a big way, even if you can't code.
We really need someone (or several people) to take charge of improving the handbook, making it up-to-date, explaining all those parameters, etc etc etc.
You don't need to know everything, though it would be good if you're very comfortable with the system. You can interview different users and/or developers and build consensus.
You could also point out those places in the running system where names are bad, numbers are confusing, etc, and take charge of delegating the necessary improvements, if you can't do the coding yourself.

Hy
Orion Atlas Pro, William Optics ZS105, Moonlight V2 focuser, GSO RC10 w/RSF focuser
ZWO ASI1600, Astronomik Filters, ST80, QHY 5L-IIm guidecam.
KStars/Ekos/Indi on NUC10 & RPi4 w/SSD -- Ubuntu
Projects: Terrain, Polar Align, Analyze, Linear Focuser, SEP MultiStar & GPG Guide, FITS autostretch.
The following user(s) said Thank You: Alfred, Peter Sütterlin
9 months 2 weeks ago #65662
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 260
  • Thank you received: 46
Thank you Hy -- not just for your helpful response to this issue but for the actual functionality of the internal guider!

Regarding the specific numbers for Proportional Gain:

The user has no business entering the direct pulse-length-per-arcsec value at all! That number MUST MUST MUST be calculated by the calibration and not changed until we recalibrate.

Rather, we should have the option to enter a unitless scaling factor which defaults to leaving the calibration alone. Otherwise we've completely broken the declination calculation that allows calibration to be re-used for different objects at different declinations. If users make any change to the pulse-length-per-arcsec calibration, then the software must untick the "Save and reuse calibration" option in Settings, because the next slew will require a new calibration.

My mount has absolute encoders, so you've discouraged me from GPG guiding. I've noticed my setup produces about 1.5 x as much rms guiding error in DEC than it does in RA, so I'd like to tune the DEC aggressiveness. As it is I get rounder stars unguided for FL below about 1000 mm.

We really need a way to adjust the scaling of our corrections in both RA and DEC that doesn't break the calibration. Something like an "aggressiveness" number from 0% (no corrections) to 100% (full correction), for RA and for DEC that simply modifies the "real" pulse-length calculation that comes from calibration. It could be combined with the "Integral Gain" as you've described, but in my strong opinion it should not have physical units.

Thank you also for the reminder that this is a community project, and that all of us are needed to keep it moving. I am willing to help out with the guiding section of the hand book.

Scott
The following user(s) said Thank You: Hy Murveit
9 months 2 weeks ago #65664

Please Log in or Create an account to join the conversation.

  • Posts: 706
  • Thank you received: 322
Scott,

Thanks for offering to do the guiding section. I'll send notes on how in a bit.
I think what I'll do, hope you don't mind, is start a new thread on the topic, with instructions on how,
mentioning that you volunteered and looking for others. Please look for that thread in the next 24 hours.

I agree we should have a gain for the DEC, and that the DEC guiding should be using the calibrated values.
I've just been conservative in making changes, and this 133 stuff predates me. I'll try to get to that after my current project
(polar alignment, see invent.kde.org/education/kstars/-/merge_requests/165).

BTW, I was not saying "it could be combined with Integral Gain". I pretty much ignore the integral part of the control algorithm
(I did spend a week or two trying to see if that helped my guiding and couldn't get an improvement with it).
So, instead of a PID control, I really use P-control. No integral, no derivative, just proportional control.
And, yes I agree that the proportional control should use the calibrated values, along with a gain.
I want to caution you though, that, at least on mount (Orion Atlas Pro), which isn't as accurate as yours for sure,
the calibrated ms/arc-second value can be far from accurate for any given guider correction.
Backlash will rear its ugly head, especially for DEC, and you can pulse for most of a second without any movement.
Then the next time you pulse (in the same direction), you might get more movement than you expect from the calibration.
The calibration, after all, is an average of several movements (after backlash was mostly removed).
I guess that's one reason why we use control gains.

Also, I suppose, for your RA guiding, you might try the GPG guider with a low value for the predictive gain.
If you do try it, let us know how it works.

Hy
Orion Atlas Pro, William Optics ZS105, Moonlight V2 focuser, GSO RC10 w/RSF focuser
ZWO ASI1600, Astronomik Filters, ST80, QHY 5L-IIm guidecam.
KStars/Ekos/Indi on NUC10 & RPi4 w/SSD -- Ubuntu
Projects: Terrain, Polar Align, Analyze, Linear Focuser, SEP MultiStar & GPG Guide, FITS autostretch.
9 months 2 weeks ago #65665

Please Log in or Create an account to join the conversation.

Time to create page: 0.545 seconds