×

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

Bi-monthly release with minor bug fixes and improvements

EKOS internal guiding - elapsed time between acquisition and pulse command

  • Posts: 137
  • Thank you received: 97
 

File Attachment:

File Name: guide_log-...9-49.txt
File Size:141 KB
Hi,

yesterday while guiding with the internal guider, I started to notice a weird guiding, after inspecting the logs, it seems there are big gaps between acquisition of the guiding frame and sending back the pulse command, I was using a 2s exposure and as you see from logs, elapsed time for the procedure is between 3 and 5s.

I am not sure this is my issue, but is it normal that it takes for me 1-3s to check the drift and send back the command to the mount?
Last edit: 2 years 4 months ago by Mattia. Reason: Added logs
2 years 4 months ago #77333
Attachments:

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

  • Posts: 1208
  • Thank you received: 559
It shouldn't take that long. What it does depends on the guide algorithm you're using, but, for example, SEP MultiStar calls SEP to find all the stars. This could take a second with a large main image, but for a typically small guide-camera image, it should be pretty quick. You didn't attach the log, but is that for an isolated guide iteration (where for some random reason the RPi could be busy with something else) or does this happen every time?
2 years 4 months ago #77338

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

  • Posts: 421
  • Thank you received: 102
I also get the same results. If I bin my guide camera 1x1 (ASI290mm mini) it usually takes a few seconds after receiving the image and issuing the guide pulse and taking the next image. Binning 2x2 does speed things up, but still takes at least a second.

I do find this to be a bit weird, since on the autofocus tab, with full field enabled, it takes a couple seconds to find all the stars when binning 1x1 on my ASI1600mm Pro. If I bin 2x2 or especially 4x4, it's extremely fast. So I would expect the guiding tab to find the stars pretty fast, since it is lower resolution than my imaging camera.
2 years 4 months ago #77347

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

  • Posts: 1208
  • Thank you received: 559
OK, I stand corrected. The star detection + a little processing time is printing in the debug logs, on this line (for SEP MultiStar)
    [2021-09-17T21:08:13.845 PDT DEBG ][     org.kde.kstars.ekos.guide] - "Multistar: findTopStars returning: 42 stars, 0.88s"
I plotted a histogram of those times, when running on my RPi4 (8Gb with SSD) and my QHY 5L-II M guidecam (bin 1x1)
using SEP MultiStar and got this:
 

FWIW, with the same guidecam and guider settings, but with my NUC, I see this order of magnitude speedup:
 
The following user(s) said Thank You: Jasem Mutlaq, Alfred, Jim
2 years 4 months ago #77351
Attachments:

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

  • Posts: 137
  • Thank you received: 97
that is impressive, thaknks for checking that out. I am gathering more data at the moment from my colleagues, different kstars version/raspberry versions and will report back soon maybe plotting more data.

In the meanwhile, what would be the suggested right thing to do for those who owns only a raspberry? using a single star SEP? PHD2?
2 years 4 months ago #77380

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

  • Posts: 1208
  • Thank you received: 559
IMHO the right thing to do is to continue to use SEP MultiStar. It’s not obvious to me that that lag is causing problems. I’ve run on a RPi for several years, and on a RPi4 with SEP MultiStar since it’s come out until just recently (and continue to do so with a second scope).

If you wanted to speed things up, you could bin 2x2.

Note that you said you were getting 1 to 3 seconds post receipt of the guide image. I’m not seeing anything like 3s, but I do see ~1s delays.
2 years 4 months ago #77386

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

Time to create page: 0.424 seconds