×

INDI Library v1.9.2 Released (14 Sep 2021)

Bimonthly Stable INDI Library release introduces new drivers and fixes for existing ones.

Meridian Flip - EKOS/Onstep Slews to last star

  • Posts: 140
  • Thank you received: 18
I have another message tread going that details exactly this - I have been hunting in code for who is setting that state and where and it eventually comes down to one block of code in mount.cpp and the check of m_status which is in a wrong state for sure. - I still cannot find it - have located the state changes to slewing but once that is set the other thread somewhere flips it back - I am tempted to throw a wait() into the block of code that sets the slewing state (it is right after the actual slew command) to give a second or 2 before setting slewing state in hopes it sticks - it is obvious that the driver is returning a steady stream of RA/DEC changes, so whatever is looking at that output should know but in the mount/driver there is a very small lag as the ramp up inthe physical mount starts slowly - I suspect THAT is what is giving thread #1 the chance to think the slew is done as the RA/DEC has not yet changed.....thinking of this perhaps the polling frequency could dropped via indi configuration forcing a slow down of the data stream - if BOTH threads have do wait perhaps the two will sync vesus the real state of RA/DEC and thus know a change has happed and set slewing!....hmmmmm...
The following user(s) said Thank You: Vrajesh
2 months 1 hour ago #74878

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

  • Posts: 858
  • Thank you received: 258
Its tricky :-) There is a thread running in Mount that calls updateTelescopeCoords() once a second. The place where Mount detects a mount status change slewing --> tracking (and subsequently sets the current position) is at mount.cpp::658 ff:
if (currentStatus == ISD::Telescope::MOUNT_TRACKING && m_Status == ISD::Telescope::MOUNT_SLEWING) ​​​
​​​{
    ...
    currentTargetPosition = new SkyPoint(telescopeCoord.ra(), telescopeCoord.dec());
    ...
}
A few lines above at line 652, the scope status is read from INDI scope client:
ISD::Telescope::Status currentStatus = currentTelescope->status();

The INDI scope client (inditelescope.cpp) determines the scope status by the status of the INDI property EQUATORIAL_EOD_COORD (see inditelescope.cpp::1286 ff).

This client listens to the connection to the INDI service for the scope. The INDI service informs its clients by pushing updates for INDI properties. In the case of a OnStep scope, this is lx200_OnStep.cpp from the libindi project. This happens through LX200_OnStep::ReadScopeStatus() (lx200_OnStep.cpp::1804 ff), which is regularly called through Telescope::TimerHit() (see indibase/inditelescope.cpp::1592 in the libindi project).

The frequency of TimerHit() is set through the polling period set for the INDI service.

HTH Wolfgang
TSA-120 + FSQ-85 + GSO 150/750 | Avalon Linear + M-zero | ASI 1600mm pro + 6200mm pro | KStars/INDI on Raspberry Pi 4/Intel NUC
The following user(s) said Thank You: JAMIE FLINN, Vrajesh
2 months 34 minutes ago #74881

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

  • Posts: 249
  • Thank you received: 22
It has to be a change in the past ~ several months, since it was working fine before.

For me, I use Jasem's PPAs for Ubuntu, and I noticed the 'immediate state transitions' issue only recently (past couple of months). Not sure how soon or how often changes in git make it to the PPAs though.

I tried to check the git log for kstars/ekos/mount, and I see two changes for meridian flips as follows. But checking the commits there is no smoking gun there.

commit e32f6399c20266c50e73280ddce1616428487fa2
Author: Wolfgang Reissenberger <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Tue May 4 13:26:15 2021 +0000

Bugfix meridian flip for lower culmination


commit 581c7ab7729be674eff87772e3c52f85f0317eea
Author: Wolfgang Reissenberger <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Wed Mar 10 15:38:41 2021 +0000

Meridian flip test case simulating current behavior

Currently, a guiding deviation while the mount is waiting for capture completed
leads to the result that after the meridian flip is completed, neither guiding
nor capturing is restarted.

This is not appropriate, since guiding deviations lead to restarting captures
and not to aborts. This should remain true if a meridian flip happens inbetween.
1 month 4 weeks ago #74884

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

  • Posts: 858
  • Thank you received: 258
I'm quite sure that the problem lies somewhere in the state update from the INDI service, that's why I asked for the checks about the status of EQUATORIAL_EOD_COORD. I could assist in an online session, but I need somebody with a OnStep mount and a debugging environment.
TSA-120 + FSQ-85 + GSO 150/750 | Avalon Linear + M-zero | ASI 1600mm pro + 6200mm pro | KStars/INDI on Raspberry Pi 4/Intel NUC
1 month 4 weeks ago #74885

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

  • Posts: 33
  • Thank you received: 15
What kind of debugging environment?  
1 month 4 weeks ago #74886

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

  • Posts: 858
  • Thank you received: 258
Linux + QT Creator
TSA-120 + FSQ-85 + GSO 150/750 | Avalon Linear + M-zero | ASI 1600mm pro + 6200mm pro | KStars/INDI on Raspberry Pi 4/Intel NUC
1 month 4 weeks ago #74887

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

  • Posts: 140
  • Thank you received: 18
I have now been testing changes in polling time with no effect so far but I can reproduce this consistently - I am on my 3rd attempt now and will post logs when it is done - from what is can see, the polling changes simple move along the time between MF slewing started and flip completed - this behavior does actually stop the full slew - the mount stops and resumes tracking at some half baked position after about 2 seconds (with the added wind-down of the slew to tracking - so perhaps 6 seconds of motion)
1 month 4 weeks ago #74888

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

  • Posts: 249
  • Thank you received: 22
Jamie,

An simpler and easier test scenario may be enabling the notification for end of slew (a popup will show). Then when you start a slew, the popup will show instantly saying the the slew is done, whereas in reality, the slew has just begun and has not reached the destination coordinates yet.
1 month 4 weeks ago #74889

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

  • Posts: 140
  • Thank you received: 18
FYI latest test - increased the polling to 2000 ms and I get exactly the same MF_complete 1 second after slewing started BUT the mount was able to physically do the full flip whihc was NOT the case with 500, 1000, 1500. So regardless of polling the actor that is resetting m_state to tracking is not being impacted by polling. I need to find out where that tracking is being pulled from - will be checking the new logs - I am suspecting teh state is coming form a default or local variable that is just sitting at tracking - there is a LOT of cross-variable checking going on here
1 month 4 weeks ago #74890

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

  • Posts: 140
  • Thank you received: 18
Think I found something - the main windows status shows slewing-> the mount control utility shows tracking...this tell me there ARE to status variables being looked at and teh CORRECT one is whatever is use in the main window!!!! - it is reflecting state correctly - I think I can hunt this down knowing this - back trace the variables used by the gui
1 month 4 weeks ago #74891

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

  • Posts: 249
  • Thank you received: 22
Jamie,

Here is a guess ..

I tested with my OnStep Python API, and the mount was showing correct behaviour
Note state changed from SLW to TRK.

The code I use is the result of :GU#, which is in 's' below:
    if 'n' in s and 'N' in s:
      self.is_slewing = False
      self.is_tracking = False
 
    if not 'n' in s and not 'N' in s:
      self.is_slewing = True
      self.is_tracking = False
 
    if not 'n' in s and 'N' in s:
      self.is_slewing = False
      self.is_tracking = True

Whereas, when I check indi/drivers/telescope/lx200_OnStep.cpp (from github.com/indilib/indi.git).

There is the following:
bool LX200_OnStep::ReadScopeStatus()
        getCommandString(PortFD, OSStat, ":GU#"); // :GU# returns a string containg controller status
        if (strcmp(OSStat, OldOSStat) != 0) //if status changed
        {   
            // ============= Telescope Status
            strcpy(OldOSStat, OSStat);
 
            IUSaveText(&OnstepStat[0], OSStat);
            if (strstr(OSStat, "n") && strstr(OSStat, "N"))
            {   
                IUSaveText(&OnstepStat[1], "Idle");
                TrackState = SCOPE_IDLE;
            }
            if (strstr(OSStat, "n") && !strstr(OSStat, "N"))
            {   
                IUSaveText(&OnstepStat[1], "Slewing");
                TrackState = SCOPE_SLEWING;
            }
            if (strstr(OSStat, "N") && !strstr(OSStat, "n"))
            {   
                IUSaveText(&OnstepStat[1], "Tracking");
                TrackState = SCOPE_TRACKING;
            }

Looks like that is wrong. For slewing it should be:
            if (!strstr(OSStat, "n") && !strstr(OSStat, "N"))
Last edit: 1 month 4 weeks ago by Khalid.
1 month 4 weeks ago #74892

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

  • Posts: 140
  • Thank you received: 18
scrap that last note - it is not repeatable - I still see on all slews a flip from slew to tracking - no flip is required to do this (easier to test) - I know now it is NOT related to Meridian Flip

HOWEVER - slewing status IS consistent when PARKING! so the mechanism used in that code is GOOD, the rest has an issue - I think this is a eureka moment - now to find the diff between normal slew and a slew to park
Last edit: 1 month 4 weeks ago by JAMIE FLINN.
1 month 4 weeks ago #74893

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

Time to create page: 0.915 seconds