Meridian flip interrupted on EQMOD mount - Alignment Module?
universalmaster wrote: 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 )
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!
One thing that vaguely concerns me though is that Ekos' (or INDI's) idea of where the meridian is doesn't quite match up with the sky itself:
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.
700d, eq6, t7m
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:
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.
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.
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...
@Chris Please share any findings you have, I'd like to get this sorted out before KStars 3.3.9 is released.
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.
Here's a brief time line:
19:30 - System turned on, EQMOD Mount + ZWO Guider
19:31:42 - EQMOD instructed to goto M31 via R-click menu in KStars
19:31:43 - Mount slewing
19:32:28/9 - Mount tracking M31
19:32:30+ - Ekos instructed to plate solve, but doesn't show up in the log as far as I can tell
19:33:46 - Some plate solving results come through (n.b. the mount is consistently about 13° off in RA for the initial targeting of objects near the meridian coming out of parked position)
19:33:47 - Slewing after plate solving
19:34:03 - Tracking reengaged
19:34:21 - More plate solving results
19:34:22 - Slewing after plate solving
19:34:23 - Tracking reengaged - appears to be the final alignment correction yet I don't see any more plate solving results after this showing the mount to be satisfactorily aligned
19:41:16 - Meridian flip initiated
19:41:18/9 - Meridian flip "completed"
File Attachment:File Name: EQMODZWO-F...1207.txt
File Size:986 KB
Next I'll post from a successful flip.
19:43:04 - Ekos disconnection
19:43:05 - INDI disconnection
19:43:15 - INDI & Ekos restarted
19:43:44 - EQMOD instructed to goto star to the east of M31 via R-click in KStars
19:43:45 - Mount slewing
19:44:30 - Mount starts tracking
19:45:01 - Here I instruct Ekos to slew to another star closer to the meridian
19:45:02 - Mount slewing
19:45:10 - Mount starts tracking
19:45:46 - Here I instruct Ekos to slew to another star still closer to the meridian
19:45:47 - Mount slewing
19:45:49 - Mount starts tracking
19:47:40 - Meridian flip initiated
19:48:56/7 - Meridian flip completed
File Attachment:File Name: EQMODZWO-S...1207.txt
File Size:618 KB
I continued carrying out tests for another 90 minutes or so in which I was able to establish that plate solving impeded all subsequent meridian flips in that INDI session.
my theory is still that there is a mismatch in time or geo location between your mount and EKOS. EKOS itself has no influence upon the decision of the mount which pier side is chosen when slewing to a specific target. The assumption of EKOS is that the mount changes the pier side after the target has crossed the meridian when the same target is re-slewed to. That's the entire magic behind the EKOS meridian flip.
When we see that it takes only seconds to slew again to the same target, the mount simply has taken the decision to stay on the same pier side. This is something where EKOS has no influence, it's a decision of the mount firmware. The explanation is that at least for the geo location and time of the mount, this decision is correct - but it does not match with EKOS. So either EKOS has a different time or date set or the geo location do not match - or maybe both.
@Chris, Jasem: do I miss something here? I haven't seen anything unusual here besides the situation that the mount does not always change the pier side as expected. Everything else seems to run fine.