×

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

Bi-monthly release with minor bug fixes and improvements

SNR Drops out periodically when guiding with internal guider

  • Posts: 152
  • Thank you received: 20
I have also seen that during that SNR drop to 0, also the green lines between stars disappeared for a while, until SNR returns to normal value. I am using multistar guiding.
BTW: The SNR has been calculated around 500, isn't that too much?
2 years 1 month ago #80577

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

  • Posts: 225
  • Thank you received: 16
Yep... all sounds like the same issue.

Is there someone with KStars/EKOS/StellarMate that can look into the issue?

Ron
2 years 1 month ago #80580

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

  • Posts: 1208
  • Thank you received: 559
Summary

Seeing the SNR occasionally drop to 0.0 by itself is not a major cause for concern--it is a user-interface issue, but by itself not a problem <strong>as long as your guiding continues to be good</strong>. 

Dropouts in the SNR is an indication that the star detection is having some issues detecting the guide star.  As long as the SNR is high a good percentage of the time, things are probably OK. 

Details

Here's more background than you probably want to hear ;)

1. When it starts up, SEP MultiStar selects a guide star, and also selects several "reference stars", which are just other reasonable level stars in the image. (The guide star is in the square in the displayed guide image, and lines are drawn to the circled reference stars.)  The geometrical relationships between all those stars are stored.  In later guider iterations, when computing the drift, SEP MultiStar uses the median drift of all the stars (guide star and reference) as the overall drift to be used by the guider's control algorithm.

2. The SNR plotted is computed as the ratio of the sum of the levels in the guide star's pixels to the "background pixel level" for a comparable number of pixels. The star sizes and positions are all "as computed by the SEP star extraction library". Thus, for a given image, if the algorithm happened to pick a brighter guide star, the SNR reported would be higher than if it chose a less bright guide star. You should not look at SNR as an absolute level, but rather relative to times during the night when the same guide star was being used. <strong>The SNR on its own isn't important to guiding</strong>. It isn't used in the guide drift calculations or in the guide control algorithm. <strong>It just gives you a rough idea of the calculated sky conditions.</strong>  You can see www1.phys.vt.edu/~jhs/phys3154/snr20040108.pdf for details on the SNR calculation.

3. Sometimes the guide star isn't detected by SEP.  It used to be (pre MultiStar) that this would cause a guider iteration to fail, and enough consecutive guide iteration failures will cause the guider to reset. However, because MultiStar has reference stars, if SEP has detected enough of them, SEP MultiStar can recover from a missing guide star. In fact, since it knows the geometrical relationship between the guide star and the reference stars, it will "invent" a guide star location where the missing guide star likely should have been detected, given the locations of the detected reference stars. However, as the code currently stands, the SNR is not invented when the guide star isn't detected, but rather just reported as 0. [To eliminate confusion, I plan to change this and estimate an SNR estimate based on the reference stars' SNRs.]. In Ron Clanton's log, each of the 28 times the SNR=0, the guide star was invented.

Bottom line, in Ron's log, in about half of the 28 guider iterations where the guide star was invented and the SNR was reported as 0, it looks like the system was able to recover from the missing guide star and continue guiding well. However, in the other half, though guiding continued, there were large (> 2 a-s) drifts reported. 

So, why was the guide star not detected?  I cannot answer that. It could be bad sky conditions, e.g. a cloud passing by.  It could be a poor choice of guide star by the algorithm. I would need the guide images to find out. It wouldn't be surprising if the heuristic that chooses guide stars could be improved. My approach recently, though, has been to be less dependent on detecting the guide star.

FYI here's an edited portion of Ron's log taken from  2022-02-10T20:28:23.099 EST.
The guide star target was 245.8,321.8 (see the 2nd line after "BEGIN PROCESSING")
but no such star is in the table below that. You can see in the line just before BEGIN PROCESSING
that it "invented" the guide star at 245.437,321.784 but gave it SNR 0.

"Multistar: findTopStars returning: 100 stars, 0.54s"
StarCorrespondence found guideStar (invented) at  245.437 321.784 found/not 8 1
StarCorrespondence invented at 245.437 321.784 SNR 0
################## BEGIN PROCESSING ##################
Star    X: 245.437 Y: 321.784 arcsecs:  1812.5 2376.31
Reticle X: 245.819 Y: 321.866 arcsecs:  1815.32 2376.92
> AFTER ROTATION  Diff RA:  0.718711  DEC:  2.79517
Multistar getDrift, reticle: 245.819 321.866 guidestar 244.899 320.553 so offsets: 0.9207 1.31302
"            #   x      y      flux    HFR  SNR      Ref:    #   x      y      flux    HFR  SNR   dRA   dDEC"
"MultiStar   1  347.6   45.8 232601   1.61 341.0     Ref:    1  347.4   45.9 218345   1.63 330.4  0.56 -1.25"
"MultiStar   2  339.4  349.1 149869   1.58 273.7     Ref:    2  339.2  349.2 150459   1.55 274.3  0.63 -1.43"
"MultiStar   3  378.5   77.8 149777   1.50 273.7     Ref:    3  378.2   77.9 150313   1.50 274.1  1.09 -1.65"
"MultiStar   4  730.2  427.9 127234   1.53 252.2     Ref:    4  730.0  427.9 130649   1.56 255.6  0.61 -1.25"
"MultiStar   5  425.4  193.9 126121   1.55 251.1     Ref:    5  425.3  194.0 127434   1.58 252.4  0.73 -1.18"
"MultiStar   6  667.1  118.0 110642   1.47 235.2     Ref:    6  666.8  118.1 111520   1.46 236.1  1.03 -1.81"
"MultiStar   7  246.7  165.4 110570   1.46 235.1     Ref:    8  246.5  165.5 104301   1.47 228.4  0.93 -1.67"
"MultiStar   8   36.7  205.8 105495   1.66 229.7     Ref:    7   36.5  205.9 104664   1.74 228.8  0.52 -1.16"
"MultiStar  11  208.4  266.1  74292   1.80 192.7     Ref:    9  208.2  266.2  75047   1.53 193.7  0.49 -1.35"
MultiStar: Drift median  0.626249 -1.34745 9  of  100 #guide 10
> MultiStar:      Diff RA:  0.626249  DEC:  -1.34745
Processing Axes
drift[ "RA" ] =  0.626249  integral[ "RA" ] =  0.522664
"GPG::result(in=  0.63,snr=  0.0,ts=  3.00,ppt= -1.0)"
"PPEC rslt: input =  0.63, final =  0.18, react =  0.31, pred = -0.13, hyst =  0.25, hyst_pct =  0.00, period_length = 598.00"
pulse_length  [RA] = 19 Direction     : Decrease
"GPG: elapsed 0.005s. RA in 0.626249, result: 0.179773 * 108.842 --> 19.5668 : len 19 dir 2"
pulse_length[ "RA" ] =  19 ms, Direction =  "Decrease RA"
drift[ "DEC" ] =  -1.34745  integral[ "DEC" ] =  -1.1877
pulse_length[ "DEC" ] =  124 ms, Direction =  "Decrease DEC"
################## FINISH PROCESSING ##################


This line is taken from the table in the previous iteration

"MultiStar   0  245.7  322.0 333011   2.12 408.1     Ref:    0  245.8  321.9 330430   2.12 406.5 -0.72  0.71"

It clearly is the detection of the guide star that's missing from the above table.
 
The following user(s) said Thank You: Chris Kuethe
Last edit: 2 years 1 month ago by Hy Murveit.
2 years 1 month ago #80596

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

  • Posts: 225
  • Thank you received: 16
Hy,

Thanks for the great write-up! Your explanation matches what I'm experiencing.

I guess the remaining mystery is why is it losing the guide star? I'm watching the guiding subs while it's doing all of this and I can't visual see any difference in the subs when it fails to find the guide star. I had pretty good seeing on this night. Plus, on the occasions (virtually every session) when I have this issue, I switch to PHD2 and have not had this problem.... ever.

The other issue is the "drift". When it has this problem, I'm pretty sure that it is sending guiding pulses to the mount. I see the streaks in my images (both guiding and subs) when this occurs. My PA is pretty good on this concrete pier mount and even without guiding I don't get that kind of drift on three minute exposures. I certainly would see anything that drastic on a three second guiding sub.

I'm really wondering if there is something unique regarding the EQ6-R Pro that is occurring? Some kind of stray pulse? Does the log indicate any pulses sent when the SNR=0?

Thanks again for all your help!

Ron
2 years 1 month ago #80600

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

  • Posts: 1208
  • Thank you received: 559
Ron,

If you look in your log, search for "snr=. 0.0" and you can find those sections. You can see it in the log snippet I included previously. You can look in the few lines below it and see the pulses sent. If you look in that log, there were 28 times it happened, and in about half it found pretty big deviations and thus sent pretty big pulses. In the snippet I included, you can see: "Diff RA:  0.626249  DEC:  -1.34745" which means it decided there was an error of .6 arcseconds in RA and 1.3 arcseconds in DEC, and you can see "pulse_length  [RA] = 19 ms" and "pulse_length[ "DEC" ] =  124 ms". So, not really big pulses there because the error wasn't really big.

If the sky was really good, and there were no clouds at those times, then perhaps your stellarsolver profile you're using in guiding isn't good for your guide camera/scope. Don't know. It's often hard to get at, but if you really wanted to, you could run the latest beta software, go to kstars settings, to the developer settings, and enable saving guide images--don't forget to turn this off when you're done ;) Then, you could run for an evening and have collected all the guider fits files, and if you sent me your log and the appropriate fits files around the time of the issues, I could look at them.

Hy
 
2 years 1 month ago #80601

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

  • Posts: 225
  • Thank you received: 16
Hy,

Okay...

The movement on the OTA looked much larger than the small pulses in the log. Just seems like there is something else going on here... it's like when the star is lost, the mount sometimes has a spasm. lol

I'll give some thought to getting the guide images. Not sure I have that much storage on my device. It may just be easier for me to continue using PHD2... it's just that you are building some cool features in the internal guiding (like one pulse) that I would like to use.

Thanks again for looking into this!

Ron
2 years 1 month ago #80602

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

  • Posts: 1208
  • Thank you received: 559
Ron,

Re the spasms:  Sorry, I forgot to mention, you are right about that. I fixed a bug a week or so ago (invent.kde.org/education/kstars/-/merge_requests/525) where the guider could lurch when it was restarting guiding. See for instance this thread indilib.org/forum/ekos/11029-internal-gu...tart-with-cloud.html and my response indilib.org/forum/ekos/11029-internal-gu....html?start=12#80292

Re PHD2: of course, that is a very good guider.

Hy
2 years 1 month ago #80603

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

  • Posts: 225
  • Thank you received: 16
Okay... When this fix hits the next stable release, I can go back to the internal guider.

Thanks,

Ron
2 years 1 month ago #80604

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

  • Posts: 1208
  • Thank you received: 559
Ron,

FYI I was looking at an imaging run tonight, and saw a lot of those SNR dropouts you were talking about. FWIW, I traced it down to having a StellarSolver profile for guiding with MinSize set to 1.5. I guess my guide star must have been near an HFR of 1.5. I moved Min Size much lower to 1.05 and my dropouts went away.

Yes, way too many parameters in these things.
Hy
The following user(s) said Thank You: Alfred
2 years 2 weeks ago #81240

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

  • Posts: 225
  • Thank you received: 16
Hy,

Interesting... where do I find this parameter?

Thanks,

Ron
2 years 2 weeks ago #81248

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

  • Posts: 1208
  • Thank you received: 559
Ron, 

This is part of the StellarSolver configuration. There's configuration like this in several place, Focus, Guide, Align--whereever star detection is run. For guiding, you look in the Guide Options menu, the Guide tab, and you'll see a "SEP Profile" line as the 2nd line in "Other Settings".

 

Rob has provided several choices for starting. There is "1- Guide Default", "2- AllStars", "3-SmallSizedStars", "3-MidSizedStars", "3-BigSizedStars", 
You can choose one of them. Then, given your choice, you can further edit these starting points by clicking on the pencil to the right of the chosen profile.
That brings up a menu where you can modify all the parameters (shown below)

 

You can see MinSize is the 2nd row from the bottom on the left side. There are mouse-over help messages and some links on that menu.

Hy

 
The following user(s) said Thank You: Ron Clanton
2 years 2 weeks ago #81267
Attachments:

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

  • Posts: 225
  • Thank you received: 16
Hy,

Thanks for this! Will try when I get another clear night.

One thought... whenever you change the minimum, isn't there a possibility of EKOS selecting a star that is near the new minimum and the problem recurring? So, things might be good for this session... but the next night the star select is closer to the new minimum and the problem is repeated?

Also, what is the disadvantage of setting the minimum to zero?

Thanks,

Ron
2 years 2 weeks ago #81269

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

Time to create page: 0.513 seconds