×

INDI Library v1.9.6 Released (21 May 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

Internal Guider Changes--please read if you use it

  • Posts: 805
  • Thank you received: 125
My proposal for doing DEC calibration:

1. Eliminate backlash (if there is any) before actual measurement: Do a step out. If movement is zero, do another step out. Continue until movement is detected. [In case there are steps with no movement, the user has chosen a too low "Pulse" value and the whole step happens "within backlash". Normally, the first step out should produce some movement. However we should ignore it as it could contain backlash.]
2. Start measuring "DEC out": Do X steps out, measure movement sum of steps out, then "DEC out" = "movement sum out"/X.
3. Eliminate backlash on the way in: Do a step in. Like in 1. repeat until there is movement detected. Remember a) "the number of "zero movement" steps and b) "the amount of movement with the last step" (the one that did cause movement).
4. Start measuring "DEC in": Do X steps in, measure movement sum of steps in, then "DEC in" = "movement sum in"/X. [Although in a perfect world the absolute values of "DEC out" and "DEC in" should be the same, in reality they are not. At least not in all cases. For instance the difference can stem from mechanical imperfections or bad balance.]
5. Now calculate DEC backlash: backlash = (a+1) * "DEC in" - b

The guider should make use of both values, "DEC out" and "DEC in", for their respective directions.


 
Last edit: 8 months 1 week ago by Alfred.
8 months 1 week ago #75348

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

  • Posts: 788
  • Thank you received: 101
Hah - only partially related maybe.  But in the context of the 2x2 binning test I was reminded that the dither radius is given in pixels, and as I had forgotten to switch back to 1x1 I was suddenly doing HUGE dithers.... :P

Would it make sense to specify the dither radius in arcsec, to make it independent of binning?
 
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
8 months 1 week ago #75349

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

  • Posts: 794
  • Thank you received: 372
Pit: I don't know if arc-seconds is any more intuitive than guide-camera pixels--one could argue that the right unit for dithering would be "imaging camera pixels" which would need to be calculated by converted from guide-camera pixels to arc-seconds, then to imaging-camera pixels by the imaging camera's parameters. That seems complex, though, and for the sake of not breaking things, I let inertia rule, and kept it what it was. I think that changing it, though, would likely inflict more pain than keeping it as is. Perhaps, the right thing to do would be add a new display to the right of the dither input which tells you how many imaging camera pixels result from the guide-camera pixels value you choose.

Even if I keep it in guide-camera pixels, one could argue that the dither input should be in units of 1x1 binning pixels, that is, changing your guide binning shouldn't change your dither amount--I think that is your main point. I could fix that too, but again, I'd wind up inflicting pain on people who happen to be dithering 2x2 (their dithers now would get halved), so I'm guessing less pain results if I just leave things as they are.

These are the issues with changing the meaning of parameters for software that has an established user base. 

Hy
AP1100 & Orion Atlas Pro, WO/ZS105 w/Moonlight V2 focus, GSO RC10 w/RSF focus
ZWO ASI1600, Astronomik Filters, ST80, QHY 5L-IIm.
KStars/Ekos/Indi on NUC10 & RPi4 w/SSD -- Ubuntu
Projects: Greedy Scheduler, Terrain, Polar Align, Analyze, Linear Focuser, SEP MultiStar & GPG Guide, FITS autostretch.
The following user(s) said Thank You: Peter Sütterlin
8 months 1 week ago #75350

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

  • Posts: 794
  • Thank you received: 372
Alfred: As I've mentioned offline, I could give you a private version to compile and experiment with--not convinced yet, though, of its general use.
In my experience, RA guiding is more problematic than DEC guiding (and backlash shouldn't play a major role in RA guiding).
Is your experience different?

Re your DEC backlash equation: once you compute the backlash, what would you do with that number? Just warn the user?
Also, I believe, based on looking at my own calibrations, that stiction is also a significant factor in DEC motion during calibration, at least for me.
I rarely see nice even motion in my calibration even after backlash is eliminated, and there does seem to be a pattern to it
(e.g. the lack of even motion might be attributed to seeing effects, but it does seem more deterministic than that).
AP1100 & Orion Atlas Pro, WO/ZS105 w/Moonlight V2 focus, GSO RC10 w/RSF focus
ZWO ASI1600, Astronomik Filters, ST80, QHY 5L-IIm.
KStars/Ekos/Indi on NUC10 & RPi4 w/SSD -- Ubuntu
Projects: Greedy Scheduler, Terrain, Polar Align, Analyze, Linear Focuser, SEP MultiStar & GPG Guide, FITS autostretch.
8 months 1 week ago #75352

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

  • Posts: 805
  • Thank you received: 125
<em>In my experience, RA guiding is more problematic than DEC guiding (and backlash shouldn't play a major role in RA guiding). Is your experience different?</em>

Not at all, I fully agree with you!

<em>Re your DEC backlash equation: once you compute the backlash, what would you do with that number? Just warn the user?</em>

I would allow the user to select a percentage of the DEC backlash which the guider would add to its guiding pulses once a change in DEC direction occurs.

<em>Also, I believe, based on looking at my own calibrations, that stiction is also a significant factor in DEC motion during calibration, at least for me.</em>

Again I fully agree. Stiction can be different for "DEC in" and "DEC out" movement and the guider could compensate for it by using two DEC values instead of one (same in RA). IMO seeing does play a role but the effect could be minimized by selecting high enough values for "pulse" and "iterations". The higher these values the lesser seeing's distortion of calibration results.
Last edit: 8 months 1 week ago by Alfred.
8 months 1 week ago #75354

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

  • Posts: 788
  • Thank you received: 101
Thanks for your detailed analysis Hy!
I agree, changing it might cause even more head-scratching than in it's curent state (and lots of threads, e.g., on CN, confirm that...). Even more as the quasi-standard PHD2 uses guider pixels, too.

But the idea that additional info box doing the conversion for you I really like. :D
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
8 months 1 week ago #75382

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

  • Posts: 515
  • Thank you received: 103
Isn't the calculation more involved than a percentage of backlash to apply? For example, if I am not guiding, my mount will be tight against the worm gear on one side with just tracking. The worm is already engaged at one side of the backlash. If the guide pulse is additive in the direction of the tracking, you would want to add in all the backlash to the pulse. If the pulse is slowing tracking, it is already against the engaged worm gear and you would want to apply no backlash adjustment, just the straight up calculated pulse.
12" pier with HDX110 using EQMod
ASI 1600 mono/color mains with ASI290MM in off-axis
ASI filter wheel
Moonlite focusers for the sharpening
AT115EDT w/.8x for the light
Fedora Linux, 100% INDI
Last edit: 8 months 1 week ago by Jim.
8 months 1 week ago #75383

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

  • Posts: 805
  • Thank you received: 125
My proposal was purely related to DEC backlash. In RA there should not be any backlash provided the mount is tracking and the guiding rate is <= 1x siderial.
Last edit: 8 months 1 week ago by Alfred.
8 months 1 week ago #75384

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

  • Posts: 515
  • Thank you received: 103
Under normal guiding circumstances, DEC doesn't move, but we can pulse it to account for cyclic error, or missing polar alignment. When it is pulsed, it is tight against one side of the worm gear or the other, and the motor is stopped again, correct?

The next adjustment would use the full backlash, or no backlash, depending on the direction of the previous adjustment. If the direction is the same as previous, the worm is tight and no backlash should be added to the pulse. If the direction is opposite the last pulse, the full backlash comes into play and should be added before the mount would move the scope. I don't understand why a percentage would be used here. I would rather that the variability is accounted for in the pulse width, and not the backlash, where we already have some ability to set things like aggressiveness. The backlash is fairly fixed for a session I would think. The caveat being a meridian flip where the first pulse might be way off. It could be off by as much as 2x the backlash, but after the first correction, the full or nothing works again.
12" pier with HDX110 using EQMod
ASI 1600 mono/color mains with ASI290MM in off-axis
ASI filter wheel
Moonlite focusers for the sharpening
AT115EDT w/.8x for the light
Fedora Linux, 100% INDI
8 months 1 week ago #75386

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

  • Posts: 788
  • Thank you received: 101
Hy,

another issue that maybe you can comment on:

Two nights ago, when I had tested the new version, I had put my guide camera in 2x2 bin mode and forgot to set it back.  During that session, I had some really weird (and bad) guiding errors.  Guiding would be great, until suddenly it would start to oscillate:
 
Those excursions came back several times (roughly half an hour spaced), so I assumed there might be something with the belt of the RA axis.
It went away after the meridian flip.
Last night, I got a similar behavior right from the start.  What I had noticed was that the jump/error was about 3 arc sec, which is the (binned) pixel size of the guide cam, and RA and DEC were basically in anti-phase... that really looked artificial to me.
I switched back to 1x1 binning, and the problem was gone.
Now I wonder if anything in the code could trigger such an error, or if maybe the binning algorithm is unstable somehow. Or do you have other ideas?
This is an ASI1600MM.  I use multistar SEP/guide profile and GPG.

  Pit

Edit:  The example shown started the oscillation after a dither.  But there's other instances where it started during normal guide operation.
The main log file doesn't show any messages (but logging was 'normal')
openSUSE Tumbleweed KStars git INDI git
GPDX+EQMOD, CEM60EC, ASI2600/1600/290mini+EFW+EAF
Last edit: 8 months 1 week ago by Peter Sütterlin.
8 months 1 week ago #75415
Attachments:

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

  • Posts: 316
  • Thank you received: 78
There is one "comical" thing I noticed. The "target" drift plot and the drift graph are inverted with respect to RA. That is, if one of those says the latest RA drift is 1 arc-second West, the other will show -1 arc-seconds (or 1 arc-second East). The guiding itself works fine, this is a display issue, not a guiding issue. I would fix it, but I don't actually know which one is right. I suppose I could trace through the code and see which makes more sense, but if you know for sure, please let me know.

I did a little testing. I started guiding, but disabled the guide pulses, so that I could just graph the tracking error.

I went to the INDI control panel, and sent a 500 ms North pulse for Dec. The guide plot, and the bullseye target both moved to the North. I ussed 500 ms South pulses, and the target moved to the south.

I then sent a 500 ms West pulse. The bullseye target moved to the West, but the graph moved to the East. I sent a 500 ms East pulse, and the bullseye target moved to the East, but the graph moved to the West.

So I think the bullseye target is correct, and the graph is wrong.

Hope this helps!

-- Kevin
The following user(s) said Thank You: Alfred
8 months 1 week ago #75447

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

  • Posts: 91
  • Thank you received: 18
Kevin Ross post=75204 userid=4509
Overall I am very pleased with these changes, this seems to be a move in the right direction. However, I have encountered a few issues, none of which are show-stoppers, just minor annoyances.</em></em>
  • <em><em>I usually bin 2x2. With the latest version, if I select 2x2, then go to a different tab, then back to the guide tab, it reverts back to 1x1. In the INDI control panel, the camera is still set to 2x2, so it doesn't actually change the setting, just the display of it in the guiding tab.
Kevin Ross post=75214 userid=4509
2) I tried to set binning to 2x2 and then switch to another tab, and then switch back to the guide tab. When I did that, I saw no issue--if I set it to 2x2 in guide, then moved e.g. to the capture tab, then moved back to the guide tab, it still displayed 2x2. What exactly do you do to expose the issue? Can you re-create it with the simulator and describe specifically what you did? Are you setting binning before you start guiding, or during guiding when you see the issue?
Jasem says he made a fix for this, I'm building KStars now and will test it out later.



 Sorry folks, I was away for two weeks and couldn't reach the forum meanwhile.
I wrote the little patch to save the binning value for guiding.
The idea was to handle the "guider binning"  independently from the "indi control panel" parameters! This way - I thought - it is possible to use the camera either directly as an imaging camera with the "native" binning (set in "indi control panel") or as the "guiding" camera with the binning settings in "ekos guider tab". There is one restriction however: In case of the presence of a "guider head" in the "indi control panel" the binning settings are overwritten with the value of this tab. This is in accordance with the already existing programming logic.
So what happened to Kevin is exactly that: Because the "simulator camera" has a "guider head" the value of the binning set in there overwrote the binning in the ""ekos guider tab". Of course the flaw of the patch was, that it didn't reset the value to the guider head value immediately. In addition there wasn't (and still isn't!) any information given to the user about this "guider head" feature.
IMHO the question is now the following: Should the feature of a "guider head" be preserved or should it be abandoned?
I'm looking forward to get some feedback.
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
Last edit: 8 months 1 week ago by Toni Schriber.
8 months 1 week ago #75466

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

Time to create page: 0.708 seconds