Welcome, Guest
Username: Password: Remember me
14 Nov 2018
Glad to announce of release of INDI Library v1.7.5 on 2018-11-14. A few drivers were added in this release as we continue to improve & stabilize existing drivers.
Read More...

TOPIC: Lost star when dithering causes capture module to hang

Lost star when dithering causes capture module to hang 4 months 3 weeks ago #26707

  • kross
  • kross's Avatar Topic Author
  • Offline
  • Senior Boarder
  • Senior Boarder
  • Posts: 54
  • Thank you received: 24
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: Herrhausen

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

Lost star when dithering causes capture module to hang 4 months 3 weeks ago #26709

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)

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

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info

Lost star when dithering causes capture module to hang 4 months 3 weeks ago #26710

  • kross
  • kross's Avatar Topic Author
  • Offline
  • Senior Boarder
  • Senior Boarder
  • Posts: 54
  • Thank you received: 24
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.
Attachments:

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

Lost star when dithering causes capture module to hang 4 months 3 weeks ago #26711

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

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

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info

Lost star when dithering causes capture module to hang 4 months 3 weeks ago #26712

  • kross
  • kross's Avatar Topic Author
  • Offline
  • Senior Boarder
  • Senior Boarder
  • Posts: 54
  • Thank you received: 24
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: knro, Herrhausen

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

Lost star when dithering causes capture module to hang 4 months 3 weeks ago #26715

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: Herrhausen, kross

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

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info

Lost star when dithering causes capture module to hang 4 months 3 weeks ago #26724

  • kross
  • kross's Avatar Topic Author
  • Offline
  • Senior Boarder
  • Senior Boarder
  • Posts: 54
  • Thank you received: 24
Sounds like a plan! :)

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

Lost star when dithering causes capture module to hang 4 months 3 weeks ago #26731

Changes already committed yesterday.

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

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info

Lost star when dithering causes capture module to hang 4 months 3 weeks ago #26750

  • nmac
  • nmac's Avatar
  • Offline
  • Platinum Boarder
  • Platinum Boarder
  • Posts: 329
  • Karma: 2
  • Thank you received: 64
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: Herrhausen

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

(PT) SC@ROS Observatory
x86_64 Atom PC / TS 6" F4 Newtonian / Canon 550D / GPU CC / Datyson T7M / Arduino Moonlite DC Clone- HEQ5 Pro
x86_64 MacMini / Explore Scientific ES80480 / G2-8300FW5 / ES FF 2" / ASI120MM - Arduino Moonlite DC Clone - Vixen GPD2
www.flickr.com/photos/139335144@N03/ ...
Last Edit: by nmac.

Lost star when dithering causes capture module to hang 4 months 3 weeks ago #26762

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?

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

Last Edit: by Herrhausen.

Lost star when dithering causes capture module to hang 4 months 3 weeks ago #26767

I have a better question. How can a random dither always move in the same direction? That sounds like a bug to me. . .

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

Lost star when dithering causes capture module to hang 4 months 3 weeks ago #26772

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.

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

Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
Time to create page: 0.119 seconds

Login



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!


Gallery

Replica

Why INDI

Replica