×

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

Bi-monthly release with minor bug fixes and improvements

Lost star when dithering causes capture module to hang

  • Posts: 421
  • Thank you received: 102
Even though you didn't respond to this post, I saw in Git you committed a change that addresses this. I pulled the latest and built it. Long story short, I had success. But not at first. :)

Setting the dithering to 10 pixels works fine the first time through, then the second time it starts dithering, then fails immediately saying it lost track of the guide star. Watching the window, I see the star didn't move hardly at all. Snooping though the code, I believe I ran up against this limit in the processGuiding() function:

// If within 90% of max pulse repeatedly, let's abort
if (out->pulse_length[GUIDE_RA] >= (0.95 * Options::rAMaximumPulse()) ||
out->pulse_length[GUIDE_DEC] >= (0.95 * Options::dECMaximumPulse()))
{
sendPulses = false;
m_highPulseCounter++;
}
else
m_highPulseCounter=0;

So that gave me the idea to adjust the maximum pulse to the maximum allowed by law, 9999. That, plus your fixes, seems to have done the trick. I'm writing this now while it is happily imaging and dithering.

Thanks!
-- Kevin
The following user(s) said Thank You: Alfred
5 years 9 months ago #26707

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

You've got the log for this? I can't imagine it needs 15 seconds of pulses to move 10 pixels (default max pulse being 5000ms)
5 years 9 months ago #26709

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

  • Posts: 421
  • Thank you received: 102
Sure do. But I suspect the counter wasn't getting set back to 0 after a successful dither, since the first one succeeded, then the second one immediately failed.

Attached is the log.
5 years 9 months ago #26710
Attachments:

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

So the problem is that in the 2nd dither and for some reason, it is not waiting enough time before it requests the capture. This is the first dither:
[2018-06-22T00:13:47.199 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Dithering process started.. Reticle Target Pos X  55.9713  Y  59.3415
[2018-06-22T00:13:47.199 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Tracking Square  QRect(48,48 32x32)
[2018-06-22T00:13:47.199 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - ################## BEGIN PROCESSING ##################
[2018-06-22T00:13:47.199 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Star    X :  64.4963  Y  :  64.6565
[2018-06-22T00:13:47.199 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Reticle X :  55.9713  Y  : 59.3415
[2018-06-22T00:13:47.199 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Star    RA:  178.169  DEC:  178.612
[2018-06-22T00:13:47.199 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Reticle RA:  154.619  DEC:  163.929
[2018-06-22T00:13:47.199 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - -------> BEFORE ROTATION Diff RA:  23.5501  DEC:  -14.6826
[2018-06-22T00:13:47.199 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - -------> AFTER ROTATION  Diff RA:  -15.676  DEC:  -22.9009
[2018-06-22T00:13:47.199 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - RA channel ticks:  27  DEC channel ticks:  27
[2018-06-22T00:13:47.199 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Processing Axes
[2018-06-22T00:13:47.199 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - At # 27 drift[ 0 ][ 27 ] =  -15.676  , t_delta:  -15.676
[2018-06-22T00:13:47.199 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - delta         [ 0 ]=  -15.676
[2018-06-22T00:13:47.200 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - drift_integral[ 0 ]=  -0.305027
[2018-06-22T00:13:47.200 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - pulse_length  [ 0 ]=  3949
[2018-06-22T00:13:47.200 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Direction     :  Increase RA
[2018-06-22T00:13:47.200 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - At # 27 drift[ 1 ][ 27 ] =  -22.9009  , t_delta:  -22.9009
[2018-06-22T00:13:47.200 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - delta         [ 1 ]=  -22.9009
[2018-06-22T00:13:47.200 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - drift_integral[ 1 ]=  -0.482537
[2018-06-22T00:13:47.200 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - pulse_length  [ 1 ]=  4628
[2018-06-22T00:13:47.200 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Direction     :  Decrease DEC
[2018-06-22T00:13:47.200 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - ################## FINISH PROCESSING ##################
[2018-06-22T00:13:47.201 Eastern Daylight Time WARN ][        org.kde.knotifications] - Audio notification requested, but sound file from notifyrc file was not found, aborting audio notification
[2018-06-22T00:13:51.767 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Capturing frame...

Here you see it waited ~4 seconds before it started capturing the next frame. However, then the next dither was started, this happened:
[2018-06-22T00:18:33.789 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Dithering process started.. Reticle Target Pos X  52.9669  Y  50.2402
[2018-06-22T00:18:33.789 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Tracking Square  QRect(40,43 32x32)
[2018-06-22T00:18:33.789 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - ################## BEGIN PROCESSING ##################
[2018-06-22T00:18:33.789 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Star    X :  56.6057  Y  :  59.2494
[2018-06-22T00:18:33.789 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Reticle X :  52.9669  Y  : 50.2402
[2018-06-22T00:18:33.789 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Star    RA:  156.372  DEC:  163.675
[2018-06-22T00:18:33.789 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Reticle RA:  146.32  DEC:  138.787
[2018-06-22T00:18:33.789 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - -------> BEFORE ROTATION Diff RA:  10.052  DEC:  -24.8877
[2018-06-22T00:18:33.789 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - -------> AFTER ROTATION  Diff RA:  -25.2947  DEC:  -8.97887
[2018-06-22T00:18:33.789 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - RA channel ticks:  16  DEC channel ticks:  16
[2018-06-22T00:18:33.789 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Processing Axes
[2018-06-22T00:18:33.789 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - At # 16 drift[ 0 ][ 16 ] =  -25.2947  , t_delta:  -25.2947
[2018-06-22T00:18:33.790 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - delta         [ 0 ]=  -25.2947
[2018-06-22T00:18:33.790 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - drift_integral[ 0 ]=  -0.630896
[2018-06-22T00:18:33.790 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - pulse_length  [ 0 ]=  5000
[2018-06-22T00:18:33.790 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Direction     :  Increase RA
[2018-06-22T00:18:33.790 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - At # 16 drift[ 1 ][ 16 ] =  -8.97887  , t_delta:  -8.97887
[2018-06-22T00:18:33.790 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - delta         [ 1 ]=  -8.97887
[2018-06-22T00:18:33.790 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - drift_integral[ 1 ]=  -0.153814
[2018-06-22T00:18:33.790 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - pulse_length  [ 1 ]=  1811
[2018-06-22T00:18:33.790 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Direction     :  Decrease DEC
[2018-06-22T00:18:33.790 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - ################## FINISH PROCESSING ##################
[2018-06-22T00:18:33.790 Eastern Daylight Time DEBG ][     org.kde.kstars.ekos.guide] - Capturing frame...

So the next frame was captured immediately, even though it was supposed to wait for 5000ms. I'm dumbfounded because both in simulations and when I tested a few days ago in my observatory, 10 pixel dithering went without a hitch for 20 consecutive runs. Let me see if using KStars on Windows has something to do with this... or you can debug the code and try to find out why this fails. It's at line #888 in internalguider.cpp
5 years 9 months ago #26711

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

  • Posts: 421
  • Thank you received: 102
So reading the code a little more carefully...
    bool sendPulses = true;
 
    // If within 90% of max pulse repeatedly, let's abort
    if (out->pulse_length[GUIDE_RA] >= (0.95 * Options::rAMaximumPulse()) ||
        out->pulse_length[GUIDE_DEC] >= (0.95 * Options::dECMaximumPulse()))
    {
        sendPulses = false;
        m_highPulseCounter++;
    }
    else
        m_highPulseCounter=0;
 
    if (m_starLostCounter+m_highPulseCounter > 3)
    {
        qCDebug(KSTARS_EKOS_GUIDE) << "m_starLostCounter" << m_starLostCounter
                                   << "m_highPulseCounter" << m_highPulseCounter;
        emit newLog(i18n("Lost track of the guide star. Searching for guide stars..."));
 
        reacquireTimer.start();
        rememberState = state;
        state = GUIDE_REACQUIRE;
        emit newStatus(state);
        return true;
    }
 
    if (sendPulses)
    {
        emit newPulse(out->pulse_dir[GUIDE_RA] , out->pulse_length[GUIDE_RA],
                      out->pulse_dir[GUIDE_DEC], out->pulse_length[GUIDE_DEC]);
 
        // Wait until pulse is over before capturing an image
        const int waitMS = qMax(out->pulse_length[GUIDE_RA], out->pulse_length[GUIDE_DEC]);
        // If less than 250ms, then capture immediately
        if (waitMS > 250)
            // Issue frame requests 50ms before timeout to account for
            // propogation delays
            QTimer::singleShot(waitMS - 50, [&]() {emit frameCaptureRequested();});
        else
            emit frameCaptureRequested();
    }
    else
        emit frameCaptureRequested();

It looks to me that the very first time it tries to move more than the max pulse limit, it sets sendPulses = false. Later down, if sendPulses is false, it will request a frame immediately, without sending a guide pulse. Then the next time it comes through here, it will do the same, try to move 5000ms, hit that limit, sendPulses=false again, immediately request a new frame, etc. Until the m_highPulse counter hits its limit, and it finally aborts. Looks like the reason it worked the first time is because it only tried to move 4628ms out of 5000, so it didn't hit that limit.

So it looks like the error is the sendPulses boolean itself. Looks like it isn't needed at all. Just increment the counter. Then in the next if statement, when it checks the counter, if it's over, then try to reacquire. Otherwise, fall through and send the guide pulse. Get rid if the if(sendPulses) check altogether.

But this is just a laypersons view, of course. I'm not intimately familiar with this like you are. :)
The following user(s) said Thank You: Jasem Mutlaq, Alfred
5 years 9 months ago #26712

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

You're absolutely right, that's the reason it failed. I think the original reason was to reject any pulses at near maximum, since it is most likely that something is very wrong at this point. However, this is not the case with dithering, and not just any dithering, but a whopping 10 pixel dither which puts it to the limit.

Another reason for this "kill-switch" here is that you probably do not want to stray off your target while you're guiding, so it protects against wild swings that might ruin your session. So I think I'll limit the sendPulses = false to regular guiding and not while dithering.
The following user(s) said Thank You: Alfred, Kevin Ross
5 years 9 months ago #26715

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

  • Posts: 421
  • Thank you received: 102
Sounds like a plan! :)
5 years 9 months ago #26724

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

Changes already committed yesterday.
5 years 9 months ago #26731

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

  • Posts: 486
  • Thank you received: 87
I tested the last build tonight with 10 pixel dithering and it went very well. I acquired 18x600s and it lost the star only 2 times.
The star was lost when it was very close to the frame limit but even after failure the guiding continued and did not interrupt the sequence.
Sometimes the movements are always in the same direction and with a big pixel movement (10 pixels) it gets very close to the frame limit.
When it changes direction it goes fine again.
The following user(s) said Thank You: Alfred
Last edit: 5 years 9 months ago by nMAC.
5 years 9 months ago #26750

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

  • Posts: 985
  • Thank you received: 160
In fact, at least in my case (using Losmandy G-11), dithering ALWAYS moves in the same direction. You can easily check this by blinking the light frames that have been taking during a session. Usually I do use 10 pixel dithering and it doesn't take too many frames for the guide star to run into the subframe border. I could resort to using full frame guiding but that limits the frame rate quite a bit.

Would it be possible to "dither" (move) the subframe in lockstep with the guide star in order to have the guide star stay in the middle of the subframe?
Last edit: 5 years 8 months ago by Alfred.
5 years 9 months ago #26762

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

  • Posts: 2876
  • Thank you received: 809
I have a better question. How can a random dither always move in the same direction? That sounds like a bug to me. . .
5 years 9 months ago #26767

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

Well, randomness is not truely random in computers, but still it would be odd to _always_ move in the same direction. I guess an invisible protection zone can be arbitrarily defined to bound the star to it to ensure it doesn't stray too far off.
5 years 9 months ago #26772

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

Time to create page: 0.315 seconds