×

INDI Library v1.9.3 Released (11 Nov 2021)

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

Internal Guider Changes--please read if you use it

  • Posts: 778
  • 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
2 months 2 weeks ago #75382

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

  • Posts: 509
  • Thank you received: 102
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: 2 months 2 weeks ago by Jim.
2 months 2 weeks ago #75383

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

  • Posts: 780
  • Thank you received: 122
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: 2 months 2 weeks ago by Alfred.
2 months 2 weeks ago #75384

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

  • Posts: 509
  • Thank you received: 102
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
2 months 2 weeks ago #75386

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

  • Posts: 778
  • 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: 2 months 2 weeks ago by Peter Sütterlin.
2 months 2 weeks ago #75415
Attachments:

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

  • Posts: 303
  • Thank you received: 76
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
2 months 2 weeks ago #75447

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

  • Posts: 85
  • Thank you received: 15
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: 2 months 2 weeks ago by Toni Schriber.
2 months 2 weeks ago #75466

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

  • Posts: 149
  • Thank you received: 25
Hi Kevin,
I was wondering how to visualise and record a PEC file on a Mac and your screenshot gave me the answer :
1/ in the EKOS guide panel, "guide" with the RA + DEC directions unchecked
2/ in the INDI Control Panel / Scope / Motion Control / Record
Thanks
2 months 1 week ago #75671

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

  • Posts: 303
  • Thank you received: 76
I don't think that will work, because it isn't sending any guide pulses to the mount to record. Unless I'm misunderstanding.

What I think will work is to use GPG guiding for several worm cycles. That should be enough for it to characterize the PE of your mount. Then in the settings, change the guide aggressiveness to 0. Change the GPG control gain to 1. I think that will disable guide output for errors, but will continue to output what it learned via GPG. Then record the PEC in the mount. I don't know for sure if that will work or not, just a thought.

-- Kevin
2 months 1 week ago #75683

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

  • Posts: 72
  • Thank you received: 4
I don’t know if it is related to new guider but I am seeing occasional exposure timeouts on my guide camera (ZWO ASI290mm mini).  This freezes the whole process for a minute or so.  I have not previously seen this.  Running kstars/ekos 3.5.5 on Ubuntu 20.04.  The exposure timeout correlated with dark subtraction ceasing to work properly.  It was working fine, camera timed out, after camera and guiding returned the dark subtraction was resulting in loss of stars and I had to disable it.  It’s unfortunate as dark subtraction improved guiding to 0.65 arc second rms from 0.85, at least hat was the effect tonight.

When the camera isn’t frozen the new internal guider is working fine for me including gpg, dithering, and multi-star.
Borg 107FL, Astro-Tech AT130EDT; Rainbow Astro RST-135 SkyShed Pier; QHY600PH Chroma LRGBHa; QHY5-III-462C; IR Guiding WO Uniguide 50 & ASI290mm mini; ASUS PN51 ubuntu, kstars/ekos, & firecapture; Pegasus PPBA; Stellarvue Optimus + WO Redcat, Skyguider Pro RT90C, rPi4/stellarmate
Last edit: 2 months 6 days ago by Thomas Mason.
2 months 6 days ago #75731

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

  • Posts: 723
  • Thank you received: 332
Thanks for the report Thomas.
Could you please do me a favor and re-post as a new thread, with the topic something like "Dark Subtraction seems to freeze guiding" and a log?
My changes should not have affected the dark processing pipeline, of course anything is possible, but I think it would be best looked into from the dark-subtraction point-of-view.
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.
2 months 6 days ago #75732

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

  • Posts: 780
  • Thank you received: 122
Hy and Thomas,

I believe the timeout problem is unrelated to dark subtraction as I also experience these timeouts although I never use dark subtraction. I reported the problem here indilib.org/forum/ekos/10329-sequence-qu...t-of-step.html#75373
The following user(s) said Thank You: maxthebuilder
2 months 6 days ago #75739

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

Time to create page: 0.589 seconds