Jasem and Chris,

Thank you both for analyzing the problem on which my original posting was based, i.e. the conflicting parking and meridian flip processes at the end of the nights observation.

I may be wrong here, but the way I understand this is that that problem is different from the failure of the properly scheduled (and executed) meridian flip to complete during the middle of an observation run for which I also showed excerpts of the log files 4 posts above.

In that case. the flip visually completed normally, the mount ended up in the correct position, but it never quite reached a stable endpoint, oscillating between two very close positions in DEC. My interpretation of that is that the mount was wobbling ever so slightly, which caused the internal encoder to randomly read one of two neighboring positions. Therefore, if the requirement for completion of the meridian flip by the mount is that all movements in DEC must have ceased for an x amount of time, the mount may never "conclude" that the flip is completed and Ekos can never proceed if it is only waiting for the completion signal from the mount.

My question now is, is this something that can be overridden in Ekos, say that if the difference of the movement in DEC is smaller than 1 arcmin or so over an x amount of time (i.e. 25 polling periods, that seems to be the time the mount is waiting until defining the flip as complete), then Ekos independently concludes that the flip is completed, sets the appropriate flag and then continues.
That small oscillation in DEC would then naturally fix itself during the subsequent realignment process.

It is possible that Max, who also had a recent flip failure with similar symptoms had the same problem, as likely do others who have posted on flip failures now and then. This may be due to mechanical shortcomings of the various mounts, but if it were possible to introduce a safeguard in Ekos that can overcome this problem, that would be awesome.

Again, I may not understand this problem correctly, but wanted to run what I perceive as a possible solution by you nonetheless.

Thanks, Jo

As I see it items 2 and 3, and maybe 4 are errors, none of which are actually fixed. They may be hidden by doing a retry but the underlying error generating code remains in place and some apparently minor change could trigger this problem again.

So my suggestion that the MF check should also check the 'parking' state is insufficient, there are many other possible states. And who knows how many other possible things that might affect this. I certainly don't.

Jasem,

I really don't think that the meridian flip enhancements are ready for production code. There are too many unresolved issues in the mount control system that are not understood to take the risk of moving this beyond beta. This code survived a review by far more expert people than me and passed only for several issue to emerge when users tried it.

There also seem to be more issues with drivers than I anticipated,

I don't think it should be inflicted on people who reasonably expect things to work.

I'm sorry to raise people's hopes but I couldn't have known before it was released as beta. The whole complexity of the Ekos system is far greater than I had imagined. I think quality is more important than features.

I've had a bit more of a look at this and part of the problem is that the mount reports the pier side incorrectly when the declination is close to 90 degrees.

The reason is that that declination repored by the GEC commad and the declination axis position reported by the GEA command do not match. What I'm seeing is that at a declination of 90 deg the declination axis moved about 1.5 degrees past the meridian. This changed the pier side but not the hour angle. From what EKOS was seeing the mount appeared to be parked with the counterweight shaft pointed up instead of down. The difference in position could have been because of a sync.

There may be a solution to this in a closer examination of the axis positions, for example when the declination is close to 90 use the hour angle to determine the pier side. The snag is that for hour angles close to 0 or 12h this will be inaccurate because the mount may have tracked past the meridian. Some one observing Polaris track through the meridian could be out of luck.
I may be able to reduce this area of uncertainity by comparing the dec and declination axis positions but I don't have one of these mounts so need log data from someone who does.

I have a series of experiments that i need doing, yes, this is Science! It doesn't need any imaging or guiding and can be done in daylight.

This is what I need:

• You must be running the ieqpro driver.
• I need full data from the driver but nothing from anything else. If running from EKOS the mount ekos logging should have debug on but nothing else. The mount logging must be on and set in the driver to debug or verbose if you have it.
• I'm looking for a log that contains full data from the driver but nothing from any other device. A little from the EKOS Mount module might help.

Then:

• Get the mount aligned, a quick align, starting at the park position should be OK.
• Slew away from the pole.
• Sync the mount about a degree different in declination from the reported position. This is to give us a small difference to cope with.
• Make sure Meridian flip is off, we don't want unexpected flip attempts.

Then the tests:

• Slew to a position where the mount is looking more or less East, I'm looking for an hour angle of -6h, declination 30 to 60 degrees.
• Wait a few seconds then slew to declinations of +80 deg, +89 deg and 90 degrees. Each time wait for the slew to stop and allow a few seconds for the log to record the position. You should see the pier side be reported as West (looking East) but it might change close to or at the pole.
• Repeat this with the mount starting looking West, at an hour angle of about 6h and again at declinations of 80, 89 and 90 degrees. The pier side should be reported as East (looking West) but again it might change close to or at the pole.
• Repeat this for positions looking South, both before and after the meridian by a small amount.
• And if you aren't too bored do the same thing looking North, as if you are tracking an object passing close to but under the pole.

If you think this is tedious think of the hours I will have to spend deciphering this.

Now if you can, set your mount with a southern latitude, make sure it is sucessfully operating in the southern hemisphere and repeat this, except that the declinations are negative.

Or if you are fortunate enough to be based in the Southern hemisphere just do the test I described above for the North but for negative declinations.

Post the logs to me, with a commentary describing anything you see. The full log should give me a lot of the detail.

Please try not to be too creative about this and try to remove all extraneous data. I need telescope driver and mount module data that just covers this. Somethng like a half hour, not 25 mbytes of data covering an entire night.

Hi Chris,

The problem goes beyond the flip loop when the mount is parked. That could be specific to the iOptron mount, I don't know, but would be happy to test. However, I reproduced the meridian flip issue when using the scheduler on a completely different system, using my EQMOD mount. I posted the results earlier ( indilib.org/forum/ekos/7087-ongoing-prob...dian-flip.html#55004 ) and Jasem made some changes, but it did not fix the problem.
Please have a look at the log there, that may be informative also for what you are looking at now. Just search the text file for 'meridian flip' that will take you right to the problem.
And that is happening while imaging M51, which is far away from the pole.

Thanks for all your efforts!

Jo

Just to chime in: I had issues with INDI nightly and parking with my SkyWatcher EQ6-R mount connected with EQMod as well. I have been using this mount for nearly two years and never had issues with it. Unfortunately I didn't collect any logs and of course now the weather has turned to probably the worst I have seen since I moved to Chile 5 months ago. I'll keep this topic in mind though and will report back as soon as the weather allows me to. Or possibly set it all up inside and try to reproduce this without any real stars visible if that's good enough as well.


Wouter

Any problems with the meridian flip, Wouter? It is possible that that only manifests with the scheduler, if the object is already close to the meridian. I did not test it on other objects further away from the meridian. It did not manifest when I did not use the scheduler, but I would need to test that more thoroughly.
Anyway, the problem is not there in the stable release from April 25, so whatever changes were made between that and the last nightlies must be the likely culprit, I would think.
Jo

Yes an indoors test is exactly what I want, especially as you are in the Southern Hemisphere. If you can do a Southern test and Jose a Northern one there's a chance that I can get the pointing state more accurate close to the pole.

OK I'll try to get the logs for you as soon as possible, Chris. I may not be able to do it before the weekend but I'll try.

Jo, I haven't used the scheduler for a while now. The meridian flip in general goes well, I suppose because I always clear the mount model when doing a flip. I noticed that the mount one time would park to the correct position but never enter the Parked state and one time that the park data seemed to be WAY off because the telescope parked in a very different position than it should. I restarted the mount, KStars and Ekos and wrote new park data. Then it parked fine apart from the state not being set correctly. When I then again restarted the mount, KStars and Ekos, it would park in a very wrong position again.

Too bad I don't have the logs for this. Let's see if I can reproduce this.


Wouter

Chris, it looks like my issues with this don't show up anymore. Whether this is due to the fact that I am not using my self-compiled INDI drivers anymore or that some code change in KStars nightly has solved this or both, I don't know. Would you still like me to perform the test that you described? Remember, I am using the EQMod driver and not the ieqpro driver.


Wouter

No, not with the EqMod driver. This is for the ieqpro driver.

Jo provided me with some log data and I'm trying to decipher it.