×

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

Bi-monthly release with minor bug fixes and improvements

Meridian flip interrupted on EQMOD mount - Alignment Module?

  • Posts: 85
  • Thank you received: 19
I've read through the Synscan manual - the only reference to meridian flipping is with respect to whether it's auto or, for the next goto movement only, forced or disabled. As far as I'm aware, the EQ6 doesn't have mount limits at all. Left to its own, it will eventually strike the tripod through normal tracking.


At any rate, none of this particularly explains the behaviour that far more concerns me, the interruption of a just-started meridian flip when there's a guide camera attached. Is it perhaps because I'm using the guide camera for both alignment and guiding, so when the guiding gets turned off by the meridian flip it's available to take an image for alignment? I would guess that under most use cases one would preferentially use the main imaging camera for alignment?

I still have to investigate Tim's suggestion of increasing the meridian offset but even if does that does seem like a workaround given that it *does* work with a minimal offset when there is no guide camera attached.
4 years 3 months ago #46578

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

  • Posts: 2876
  • Thank you received: 809
So I think you are misunderstanding something about the meridian flip. Mounts generally do not really have concept of a meridian flip, and they will not do it automatically, nor can they be told to do one using a simple command. Software like Ekos can use the mount's features to effectively perform a meridian flip, but you need to know how it works to use it effectively.

Two key points:
1. Most telescope mounts will go to an object and then when you tell them to track the object, they keep tracking and tracking and tracking until either the telescope limit is reached or it hits the tripod legs.
2. Most telescope mounts, when told to go to an object will make the telescope orient itself in on whichever side of the pier makes the most sense (Note: the most sense in the mount's mind, not always in your mind). You cannot tell most mounts which side of the pier to orient themselves on.

So to make pier flips happen, typically what will happen is the software will wait till an object crosses the meridian (or goes an angular distance past the meridian that you decide), and then it will issue a goto command to the object (even though it is already pointing at that object). If the mount thinks that it would make more sense to go to the object on the other side of the pier since it is past the meridian (which is what you are hoping), then the meridian flip will happen when the goto command is issued. If the object is really close to the line though, the mount may not actually do the meridian flip, because it decided the scope was able to point at this object on its current side of the pier.

Now there could still be a bug, since I think there are some people currently working on the code for alignment, guiding, and meridian flips. But from your discussion I don't think you understood how it was supposed to work.

Hopefully this helps,

Thanks,

Rob
4 years 3 months ago #46579

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

  • Posts: 85
  • Thank you received: 19
Here again is what is - and is not - happening with emphasis on the differences between two scenarios where flips do and do not occur. It's all been nicely colour-coded to aid in following along. You can pretend I'm a dimwitted idiot who shouldn't be anywhere near an equatorial mount at all if it makes you feel better about being dismissive, but that still doesn't change what the logs say.


Scenario 1:
Live EQMOD mount, simulated camera, no guide camera real or simulated. Accordingly, in the Schedule tab, the 'Align' and 'Guide' boxes are UNCHECKED. Meridian flip set to >0.05h

When I set up a schedule that involves a meridian flip with this scenario and run it, the mount successfully carries out a meridian flip, as expected.

So, under this circumstance, I am able to get the mount to flip.

Fwiw, these dummy runs were carried out during the day, but I see no reason it wouldn't work under clear night skies either. I could test that out too on the next clear night.

Scenario 2:
Live EQMOD mount, simulated camera, live ZWO ASI guide camera on a real guidescope. So, in the Schedule tab, the 'Align' and 'Guide' boxes are now CHECKED. Meridian flip is set to >0.05h

As there is no live camera, alignment is being carried out by the guide camera on the guidescope. This run is also being carried out under clear night skies, so Ekos goes through an alignment routine after the mount has been aimed at the target.

When I set up a schedule that involves a meridian flip with this scenario and run it at night under clear skies, here's what happens:
-the mount is moved to the target, with the mount head on the west side
-once on target Ekos goes through an alignment routine to centre the target
-once the alignment routine is satisfied that the target is centred, a guide calibration is initiated
-once the guide calibration is successful, the guiding begins
-once guiding begins, the capture sequences are initiated
-at this point, on the Mount tab, I can see a count down to the meridian flip
-once the meridian flip countdown gets to 0, it goes into a waiting stage while the current capture finishes
-once the current capture finishes, a meridian flip *IS INITIATED*
-but almost instantly the meridian flip is INTERRUPTED or stopped
-Ekos then proceeds to carry out an alignment using and recentres back on the target
-on the Mount tab the meridian flip status is now Inactive


So just so we're clear, with a live mount and a live guide camera on the guidescope and the guide camera serving as the alignment device, with 'Align' and 'Guide' checked in the Schedule tab, under clear night skies, a meridian flip is initiated and then almost instantly stopped. That's in contrast to when it did fully carry out a flip when there was no guide camera set in the profile and the 'Align' and 'Guide' steps were unchecked in the Schedule tab.

And you can see for yourself in the logs I've attached. In my first post, i.e. 'Scenario 2':

[2019-12-02T21:19:22.226 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 4
[2019-12-02T21:19:22.232 EST DEBG ][ org.kde.kstars.ekos.mount] - Slewing to RA= "01h 58m 47s" DEC= " 37° 55' 49\""
[2019-12-02T21:19:22.316 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Aborted"
[2019-12-02T21:19:22.316 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Meridian Flip"
[2019-12-02T21:19:22.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:22.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:22.830 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Slewing"
[2019-12-02T21:19:22.840 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[...]
[2019-12-02T21:19:25.877 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Tracking"
[2019-12-02T21:19:25.879 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 5
[2019-12-02T21:19:25.923 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 3

That's 3 seconds.

Now take a look at the log from my second post, where it does carry out the flip fully, i.e. 'Scenario 1':

[2019-12-03T11:51:13.896 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 4
[2019-12-03T11:51:13.898 EST DEBG ][ org.kde.kstars.ekos.mount] - Slewing to RA= "16h 33m 37s" DEC= "-13° 05' 36\""
[2019-12-03T11:51:13.907 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:13.909 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:51:13.985 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Meridian Flip"
[2019-12-03T11:51:14.828 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Slewing"
[2019-12-03T11:51:14.840 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:14.843 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:51:14.862 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[...]
[2019-12-03T11:52:38.828 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Tracking"
[2019-12-03T11:52:38.829 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 5

That's a minute and twenty four seconds (1:24), i.e. the time it took for the mount to flip.


So, quite frankly, whether or not I understand how a meridian flip is supposed to work is a moot point given that under both scenarios the flip is initiated. It's just that it will complete the flip under a limited scenario but won't under a slightly more involved scenario with more equipment attached. For some reason, the meridian flip is initiated but it is stopped in the scenario where the guide camera is attached and operating. It's repeatable - I've run both scenarios thrice and get the same results each time, so it's not a one-off fluke.

I'll run them again with logging of the INDI messages as well to see if that turns up any more useful information.
4 years 3 months ago #46587

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

  • Posts: 1208
  • Thank you received: 559
Here's how I would interpret your log:

In the case where the meridian flip failed (ie took only 3 seconds),
when EKOS determined it was time for a meridian flip, it sent a slew command to the mount.
It was "hoping" the mount would switch to the other side of the pier (which normally takes a minute and a half) but the mount decided to
stay on the same side of the pier and only took a few seconds to finish its slew to a very nearby coordinate. That is, I believe it was probably
not interrupted, but rather it probably just finished quickly. Once the slew was complete the normal post-meridian-flip-slew alignment process started up.

To try and fix your situation, I'd try setting the meridian flip threshold to >0.1hour or maybe even a little more and seeing if you have more luck
(assuming that would be safe--e.g. the camera/telescope would not hit tripod, and so on). Going that much further past the meridian might
cause it to go to the other side of the pier.

If that doesn't work, or perhaps even before trying that, another, less likely possibility, is that your mount somehow has the wrong time, or geographic
coordinates, etc so that it doesn't have the same meridian in mind as your software. You can test that by commanding it to point to some star e.g. 15 degrees
east of the meridian, and another one 15 degrees west of the meridian and making sure picks the appropriate (different) side of the pier for both stars.
Make sure you have your finger near the stop-the-slew button just in case it really is off.

I've had (and solved) both of the above issues in the past 6 months! Moving to .1h definitely improved my meridian flips.

Hy

PS Please be civil, I'm certain Rob was genuinely trying to help you and not being dismissive.
4 years 3 months ago #46588

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

  • Posts: 1208
  • Thank you received: 559
BTW, I checked, and I'm actually using "Flip if HA > 0.2h" for my Orion Atlas Pro mount.
Again, make sure your OTA/Camera can safely go this far past the meridian without hitting anything.
4 years 3 months ago #46589

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

  • Posts: 554
  • Thank you received: 138
It looks as if we've got all out of those logs that we can. As you say, in your Scenario 2 the meridian flip slew takes 3 seconds which is far too short. Either the slew is being commanded before the meridian has been reached from the mount's POV or something has stopped the slew.

Finding out what is going on from the mount side is vital so enabling the INDI logging should help. Set all the options, select log to file and look in ~/.indi/logs. The driver log will show something useful. Maybe something is stopping the slew early.

The ASCOM specifiction has to work round the same issues and in addition to the SideOfPier property has a DestinationSideOfPier(rightAscension, declination) method which reports the pier side that the mount will be on if a slew to the destination coordinates is started. This would give the client a chance to decide what is likely to work. When a plip is required the client checks the DestinationSideOfPier and only starts the meridian flip process when it is different to the current pier side.

With a mount that reports pier side, which eqmod does, Ekos should be able to check, see that the pier side is still West, and leave the pier side required flag set so it tries again after another acquire.
4 years 3 months ago #46593

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

  • Posts: 278
  • Thank you received: 17
I have a stupid question to understand this, sorry to butt in.... When you say 'the mount' issue the actual flipping etc., do you then mean the eqmod indi driver or the actual mount/electronics in the eq6 mount?

(The synscan controller is not usually used with eqmod, so I thought the remaining electronics where just dumb motor controllers without knowledge of the sky, but it would be great to know for sure where to look for mistakes like this :-))
4 years 3 months ago #46602

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

  • Posts: 2876
  • Thank you received: 809
Aurneth,

Please understand that I was not trying to be dismissive in any way of your issue, and I apologize if you think that I was. Yes in fact there might be a bug, as I indicated in my post. I know there were some folks working on some things that were happening during a meridian flip. I think what they were investigating was related to guiding in particular, but it could be related. I did in fact see that you mentioned it started to do the meridian flip and then got interrupted by something. That is not good and that does lead me to think there might be a bug as you indicated.

I wasn't trying to dismiss this with my post, but because of the way the software has to do meridian flips, as I explained in my other post, it is possible that the mount was properly told to go to the object, but maybe it was just a little too close to the meridian, so the mount finally decided it didn't need to switch sides to go to that object. I have a mount that often when told to go to an object that is a short distance away from its current position, or even at the same position, it will slew past the target, and then come back to it. I was thinking that my mount might look like it is doing exactly what you were describing when told to go to an object.

I was just thinking, as I believe some other posters had mentioned, that maybe increasing the hour angle a little might help. This had already been mentioned to you as a possible solution, and from the discussion that was going back and forth I got the impression that there was some misunderstanding about why increasing the hour angle might help solve the problem. I am not guaranteeing that it will solve the problem and as I said there could still be another bug that caused the interruption. But there is a pretty good reason that it might help with your issue and I was just attempting to explain why that is. I meant no offense, I was just trying to relay some information because I know a lot about how the software works because I volunteer my free time to help work on it when I can.

Thanks,

Rob
4 years 3 months ago #46603

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

  • Posts: 2876
  • Thank you received: 809

Yes EQMod is a special case because the "brains" are in the EQMod driver instead of in the mount itself like in my Gemini mount. So you are quite correct in that presumption. But from Ekos's point of view it is still talking to the mount driver, and telling it to go to the object. The difference in how that command is handled would be at the driver level instead of in Ekos. Ekos wouldn't really know that the driver is handling the computations instead of the mount. That was not a stupid question at all.

Hopefully that helps!
The following user(s) said Thank You: S
4 years 3 months ago #46604

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

  • Posts: 969
  • Thank you received: 94
Hi
    1. Make sure you have at least one accurate plate solve before the meridian
    2. Don't forget to check 'Reset mount model after meridian flip'.
    3. Set flip meridian + a few minutes.

    HTH
Last edit: 4 years 3 months ago by alacant.
4 years 3 months ago #46608
Attachments:

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

  • Posts: 1185
  • Thank you received: 370
Did you check whether geo location, date and time are matching between EKOS and your mount? It might simply be the case that your mount has a setup where the meridian crossing is later for your mount than for EKOS.
4 years 3 months ago #46636

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

I tested today in my observatory without alignment/focus/guide checked and it worked as expected. I set the HA > 0.2
4 years 3 months ago #46653

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

Time to create page: 0.714 seconds