×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Internal Guider Changes--please read if you use it

  • Posts: 19
  • Thank you received: 3
It is build 876 from 7sept  Kstars nightly build
Mount backlash is fairly tight, zero movement, with rowan kit too
2086 FL dirived from platesolve, so should be accurate
2 years 6 months ago #75323

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

  • Posts: 1208
  • Thank you received: 559
Pit,
Calibration never prints out the backlash, but it is measuring x,y points while it turns around DEC. One could see all those measurements in the log. What calculation exactly would you recommend? Do you need to turn DEC around many times?
Hy
2 years 6 months ago #75335

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

  • Posts: 1208
  • Thank you received: 559
My "binning change" went in on Sept 8, 10am California time, so Clive, you probably don't have that fix in your binary, but that fix wouldn't affect you unless you had calibrated with one binning, but were guiding with a different binning.
 
2 years 6 months ago #75339

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

  • Posts: 1009
  • Thank you received: 133
I was just thinking of the 'remove backlash' option, assuming that one does small moves until the guide star actually does move - then this duration/distance could be reported.  Not sure if some extra routines would be needed though - if one wants that, might be easier to use PHD2?

As for the guiding:  I just compiled the latest git (which seems to be identical to your guider-fix13).  I re-ran the guider calibration (equator near meridian), which gave me the (almost) exact same values I had before (angles within half a degree, speed 1.5ms/").  The attached image shows the EKOS tab.  Guiding as usual
I calibrated at binning 1x1, then for a test switched to 2x2.  No change in the arcsec display here, RMS around 0.25" , like with 1x1 binning.

Cheers,

  Pit
 
2 years 6 months ago #75345
Attachments:

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

  • Posts: 239
  • Thank you received: 38
Best place to do a calculation on DEC backlash is to do it during calibration when the DEC goes from DEC OUT to DEC IN. The difference between those two would give you the backlash value you would need to take it out, if your mount had that capability.
Last edit: 2 years 6 months ago by Sonny Cavazos.
2 years 6 months ago #75346

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

  • Posts: 985
  • Thank you received: 160
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: 2 years 6 months ago by Alfred.
2 years 6 months ago #75348

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

  • Posts: 1009
  • Thank you received: 133
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?
 
2 years 6 months ago #75349

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

  • Posts: 1208
  • Thank you received: 559
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
The following user(s) said Thank You: Peter Sütterlin
2 years 6 months ago #75350

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

  • Posts: 1208
  • Thank you received: 559
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).
2 years 6 months ago #75352

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

  • Posts: 985
  • Thank you received: 160
<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: 2 years 6 months ago by Alfred.
2 years 6 months ago #75354

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

  • Posts: 1009
  • Thank you received: 133
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
2 years 6 months ago #75382

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

  • Posts: 535
  • Thank you received: 109
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.
Last edit: 2 years 6 months ago by Jim.
2 years 6 months ago #75383

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

Time to create page: 4.433 seconds