×

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

Bi-monthly release with minor bug fixes and improvements

Meridian Flip - EKOS/Onstep Slews to last star

  • Posts: 33
  • Thank you received: 15
I think what's happening is that you're not setting the target in Ekos before you slew.  If all you do is right click the star before you lx200->goto , then  Ekos hasn't yet set the target.  Try doing "center and track" after selecting the star to ensure its set as the current target,  and then do the goto, and see if that works..
2 years 7 months ago #74791

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

  • Posts: 219
  • Thank you received: 41
But If I right click on a target on KStars, then select lx200 -> goto, and then perform a plate solve, it works flawlessly, so it seems to me that this is not the case, isn't it?
2 years 7 months ago #74794

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

  • Posts: 33
  • Thank you received: 15
Going to guess the alignment module has different approach.   Did you try setting a target first then doing the goto?
2 years 7 months ago #74824

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

  • Posts: 7
  • Thank you received: 1
I did try that but it still slewed to the last star I slewed to. I did see the target under Setup page in EKOS change to M3 when I completed the following: Clicked M3 -> Center, and Track then LX200 Onstep -> GoTo. But the meridian flip went to the last star I slew to..

I am gathering the logs requested by Wolfgang . Should have it uploaded later today.

Note that the only workaround I've found so far is to slew to my target of interest twice and when I do that, I do get meridian flip to happen correctly.
2 years 7 months ago #74826

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

  • Posts: 7
  • Thank you received: 1
Log files attached.
2 years 7 months ago #74827
Attachments:

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

  • Posts: 1185
  • Thank you received: 370
It seems like our mount reports the old position after the second slew:
[2021-08-23T19:09:29.160 PDT INFO ][           org.kde.kstars.indi] - LX200 OnStep :  "[INFO] Slewing to RA: 16:15:29 - DEC: 33:48:33 "
...
[2021-08-23T19:09:30.526 PDT DEBG ][     org.kde.kstars.ekos.mount] - Mount status changed from  "Slewing"  to  "Tracking"
...
[2021-08-23T19:09:30.681 PDT DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] CMD <:GR#> "
[2021-08-23T19:09:30.681 PDT DEBG ][           org.kde.kstars.indi] - LX200 OnStep : "[SCOPE] RES <18:33:39> "
You can see that OnStep reports 18:33:39 as current RA position and not 16:15:29, which is strange. Therefore it's not surprising that the mount uses 18:33:39 as current position for the meridian flip.

Conclusion: hm, either you are doing something unusual or this is simply a OnStep bug.
The following user(s) said Thank You: Jasem Mutlaq
2 years 7 months ago #74828

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

  • Posts: 7
  • Thank you received: 1
Thanks for checking it out. I might be doing something odd or did something odd at some poing. I am new to both Onstep and EKOS.

I'll reset the Onstep firmware and see if it resolves the issue.
2 years 7 months ago #74842

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

  • Posts: 322
  • Thank you received: 31
Hello all ...

This bug may be related to an issue that is inside Ekos (not INDI), that causes status changes to be immediate, and not reflect what is actually going on.

The above log seems to confirm that: it changed from slewing to tracking in merely one second.

This issue was discussed in this thread . I do not recall a definitive resolution yet.

One poster on the OnStep group identified where the issue is, but does not have a solution yet.
 
2 years 7 months ago #74848

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

  • Posts: 1185
  • Thank you received: 370
Could someone please check the status of the INDI property EQUATORIAL_EOD_COORD is always IPS_BUSY when the mount slews?

Here the explanation how Ekos recognizes the mount's tracking and slewing states:

There is one thread running that regularly reads the data of the INDI driver showing the current RA/DEC coordinates and its status. Simplified, IPS_IDLE --> mount is idle, IPS_OK --> tracking, IPS_BUSY --> slewing.

Now the question is how should we detect from EKOS that a slew is finished. Currently, we detect this that after a slew command, the mount shows the tracking state - and this is recognized by the thread above. When a slew is issued, Ekos sets the mount state to "slewing".

The problem occurs when the above mentioned thread reads the mount in parallel and obtains the tracking state BEFORE the INDI driver starts slewing. As a result, Ekos assumes that the slew has already finished while it hasn't even started.

But in this case, the time difference in the log is more than a second - that's why I think we do not have this problem here.

That's why I would like to check whether the OnStep INDI driver properly reports it's state
2 years 7 months ago #74854

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

  • Posts: 148
  • Thank you received: 19
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 years 7 months ago #74878

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

  • Posts: 1185
  • Thank you received: 370
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
The following user(s) said Thank You: JAMIE FLINN, Vrajesh
2 years 7 months ago #74881

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

  • Posts: 322
  • Thank you received: 31
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.
2 years 7 months ago #74884

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

Time to create page: 1.058 seconds