×

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
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: 984
  • 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.

  • Posts: 984
  • Thank you received: 160
This is from my most recent session. To me the dithering direction doesn't look random at all.
Last edit: 5 years 9 months ago by Alfred.
5 years 9 months ago #26775
Attachments:

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

  • Posts: 984
  • Thank you received: 160
Another picture (taken weeks ago) using 2,8 pixel dithering resulting in "noise rain" also shows dithering always goes in one direction.
Last edit: 5 years 9 months ago by Alfred.
5 years 9 months ago #26776
Attachments:

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

  • Posts: 984
  • Thank you received: 160
What strikes me is the factt that not only goes dithering in one and the same direction during a job. It appears to remain the same during the whole night.
Last edit: 5 years 9 months ago by Alfred.
5 years 9 months ago #26778

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

Thanks, I just pushed a fix for the not-so-random dither and used different algorithm and add a bounded area. Please try the nightly build or wait for next release.
The following user(s) said Thank You: nMAC, Alfred
5 years 9 months ago #26784

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

Time to create page: 0.287 seconds