×

INDI Library v1.9.9 Released (30 Nov 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

Meridian flip interrupted on EQMOD mount - Alignment Module?

  • 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.
3 years 1 month 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 :-))
3 years 1 month ago #46602

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

  • Posts: 2831
  • Thank you received: 794
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
3 years 1 month ago #46603

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

  • Posts: 2831
  • Thank you received: 794

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
3 years 1 month ago #46604

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

  • Posts: 882
  • Thank you received: 87
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
kubuntu 22.04
700d, eq6, 120mm. Yes, the old one.
Last edit: 3 years 1 month ago by alacant.
3 years 1 month ago #46608
Attachments:

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

  • Posts: 1017
  • Thank you received: 303
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.
TSA-120 + FSQ-85 + ONTC 10"F4 Newton + epsilon-160 | Avalon Linear + M-zero | ASI 1600mm pro + 6200mm pro | KStars/INDI on Raspberry Pi 4/Intel NUC
3 years 1 month 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
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
3 years 1 month ago #46653

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

  • Posts: 85
  • Thank you received: 18
I started working through things last night but it clouded over while I was doing tests.

I can say definitively that it is NOT the Scheduler, at all. I can create a no-flip scenario without the Scheduler.
I can also say definitively that it is NOT the HA offset - I was able to get a no-flip with an HA > 0.2.

My tentative conclusion is that it is weird. Like very weird.

There does seem to be a relationship between using plate solving on the guider device and interrupted meridian flips. Ironically, the clouding over further pointed the way towards such a relationship, one that I suspected from the start (it's in the thread name, after all).

Before it clouded over, for all of my tests with a guide camera attached I was also doing plate solving with the guide camera and ending up with no-flips. But once it clouded over, I couldn't plate solve any more so I didn't (just pointed it at objects approaching the meridian and let it do its thing), and all tests after it clouded over came through with successful flips - which is consistent with my daytime dummy runs where I also never had a failed flip.

Tonight is looking promising for clear skies, and with the possible problems narrowed down I should be able to come up with a definitive scenario for these failures.

So I'm looking at the following setups in my INDI device profile for my equipment, an EQ6 mount and a ZWO ASI120MM camera:
Mount: EQMOD
CCD: None or Simulated or ZWO
Guider: None or Simulated or ZWO

The key pair of tests will be with the ZWO camera as guider and then (1) plate solving and (2) not plate solving prior to a meridian flip. I'm expecting to get no-flips following a plate solve with the guide camera, and flips without having plate solved with the guide camera. I'll also test plate solving with the ZWO as the CCD to see if the issue is generalized to the ZWO or limited to when set to the Guider device alone. Given I suspect a role for plate solving, I'll be including that in the logging.
3 years 1 month ago #46662

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

  • Posts: 554
  • Thank you received: 138
I've got a couple of ideas what could be happening. It needs verbose logging the mount driver to see exactly what commands are being sent to the mount and logging of the guider and align modules to see what they are getting up to.

If I'm right it's unlikely to happen with simulators because it needs real data. It also explains why tests when it's cloudy don't fail.
3 years 1 month ago #46665

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

  • Posts: 85
  • Thank you received: 18
Well the results are interesting and kind of discouraging.

The main takeaway is that plate solving even once impedes the ability to properly meridian flip, so it's not even target-dependent. So, for example, if the mount is aimed at M33, plate solved on that and then moved to M31 which is approaching the meridian without actually plate solving on M31, the meridian flip will still be interrupted, so it's not like a plate solve on M33 only impedes the subsequent flip while tracking M33. So long as I don't plate solve, it flips as many times as I have patience to line up flips for, but once plate solving is carried out once, meridian flips are interrupted and INDI has to be restarted to reenable them. Parking and unparking is not sufficient to eliminate the interruptions and neither is disconnecting and reconnecting Ekos.

It doesn't matter whether the ZWO is attached as a CCD or as a Guider in the profile - the controlling variable is plate solving. And with respect to plate solving, it matters not whether it's set to Sync or Slew to target after solving - the effect is the same.

When I tested the effect of guiding, it opened up a whole new can of worms. Naturally I had to test it without plate solving first. Guiding didn't seem to impede a meridian flip from proceeding, but the one that was initiated during autoguiding never actually "completed". It was perpetually "Running" even when it had actually finished. That didn't stop the mount from being able to be parked, where it still maintained a status of "Running".


I have logs for this and since I recorded times of meridian flip [non-]events I'll go through and pull out a few segments where they were invoked. "Verbose" is an understatement to these logs...
3 years 1 month ago #46674

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

Well folks, I tried again with having the guide simulator to do the solving and the flip happened... maybe something is off with using the real equipment. At any rate, I need to reproduce it exactly in order to figure out what's going on.

@Chris Please share any findings you have, I'd like to get this sorted out before KStars 3.3.9 is released.
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
3 years 1 month ago #46680

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

  • Posts: 554
  • Thank you received: 138
My theory is that a command is being sent to the mount which halts the slew. A log file showing the mount communication would show if this is happening.
The source of the command could be guiding or aligning. If the guiding module has not halted - or a guide function is still running when the flip starts - then the guide command could interfere with the slew that's in progress.
Similarly with alignment, there could be a sync command that is halting the slew.

@Aurneth suggests that a previous align at any time prevents the meridian flip. That's a puzzle but maybe it changes the mount state in some way. Again the mount log will show if the slew should do a meridian flip or not from the actual axis positions.

@Aurneth, log files compress very well, down to 5 to 10% of their original size.

Chris
3 years 1 month ago #46687

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

Time to create page: 0.679 seconds