×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

(SOLVED)Meridian Flip fails with EQ6r-Pro and Kstars

  • Posts: 32
  • Thank you received: 7
Last night I set the HA>6 degree's, no luck. I'm confused why this used to work every night without fail. I've back rev'ed kstars to 3.5.0 beta which worked very well for me in the past thinking it was something in the final release of 3.5.0. I'm thinking its something in my config of kstars or indi. I think today I may just completely remove kstars on my pc and remove indi from the PI in the observatory and just start all over.
I haven't changed anything on the mount itself as far as firmware goes so it almost has to be a config issue that I'm missing.

This is last nights log:

"Meridian flip slew started..."
[2020-12-06T20:57:43.566 CST INFO ][ org.kde.kstars.ekos.guide] - "PHD2: Guiding Stopped."
[2020-12-06T20:57:43.569 CST INFO ][ org.kde.kstars.ekos.guide] - "Autoguiding aborted."
[2020-12-06T20:57:43.601 CST INFO ][ org.kde.kstars.indi] - EQMod Mount : "[INFO] Starting Goto RA=1.58406 DE=30.768 (current RA=3.82634 DE=26.71) "
[2020-12-06T20:57:43.607 CST INFO ][ org.kde.kstars.indi] - EQMod Mount : "[INFO] GOTO ALign Nearest: delta RA = 2.242304, delta DEC = -4.061214 "
[2020-12-06T20:57:43.608 CST INFO ][ org.kde.kstars.indi] - EQMod Mount : "[INFO] Aligned Eqmod Goto RA=3.82636 DE=26.7068 (target RA=1.58406 DE=30.768) "
[2020-12-06T20:57:43.609 CST INFO ][ org.kde.kstars.indi] - EQMod Mount : "[INFO] Setting Eqmod Goto RA=3.82636 DE=26.7068 (target RA=1.58406 DE=30.768) "
[2020-12-06T20:57:43.610 CST INFO ][ org.kde.kstars.indi] - EQMod Mount : "[INFO] Slewing mount: RA increment = 69, DE increment = -81 "
[2020-12-06T20:57:43.625 CST INFO ][ org.kde.kstars.indi] - EQMod Mount : "[INFO] Slewing to RA: 1:35:03 - DEC: 30:46:05 "
[2020-12-06T20:57:43.893 CST INFO ][ org.kde.kstars.indi] - EQMod Mount : "[INFO] Iterative Goto (1): RA diff = 0.42 arcsecs DE diff = 0.04 arcsecs "
[2020-12-06T20:57:43.900 CST INFO ][ org.kde.kstars.indi] - EQMod Mount : "[INFO] Telescope slew is complete. Tracking TRACK_SIDEREAL... "
[2020-12-06T20:57:44.315 CST WARN ][ org.kde.kstars.ekos.capture] - Skipping flat/dark cap since it is not connected.
[2020-12-06T20:57:44.540 CST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Tracking"
[2020-12-06T20:57:44.541 CST DEBG ][ org.kde.kstars.ekos.mount] - Slew finished, MFStatus "FLIP_RUNNING"
[2020-12-06T20:57:44.543 CST WARN ][ org.kde.kstars.ekos.mount] - Meridian flip failed, pier side not changed
[2020-12-06T20:57:44.544 CST INFO ][ org.kde.kstars.ekos.mount] - "meridian flip failed, retrying in 4 minutes"
[2020-12-06T20:57:44.545 CST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to "FLIP_COMPLETED"
[2020-12-06T20:57:44.545 CST DEBG ][ org.kde.kstars.ekos.mount] - meridianFlipStatusChanged "FLIP_COMPLETED"
[2020-12-06T20:57:44.546 CST INFO ][ org.kde.kstars.ekos.mount] - "Meridian flip completed."
[2020-12-06T20:57:44.549 CST INFO ][ org.kde.kstars.ekos.capture] - "Telescope completed the meridian flip."

This all happened within 1 second. There must be something in this log to point to the issue.
3 years 4 months ago #64049

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

  • Posts: 32
  • Thank you received: 7
UPDATE: I'm at a total loss here. I just finished some testing during daylight hours. With ONLY the scope (no phd2 running, no pics and no guiding) the flip works as it should. I then started the phd2 process, phd2 got a connection to the guild camera and mount (although no guiding) and the flip still works just fine. I have the HA set to .04 hours. 3 flips in a row without any issue.
3 years 4 months ago #64053

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

  • Posts: 527
  • Thank you received: 139
My mount is doing the same thing. And has for some time now. I thought it was just me. I'm seeing this issue on both the 10Micron and the Rainbow Astro RST-135. Flip says failed, and it repeatedly retries. Not sure what happened tonight, as I went outside and the mount was flipped (RST-135), but kept retrying to flip anyway. Even if I pointed to something way west, it still said retrying the flip in X minutes. I had to close down EKOS and restart to get it to clear. I'll post a log in the morning so we can see exactly what happened.
3 years 4 months ago #64196

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

Thank you all for the reports. I'm going to try this today in my observatory with EQ8 while running the scheduler to see if I can replicate this. I don't run PHD2, but I don't think I need to do that to replicate the issue?
3 years 4 months ago #64198

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

  • Posts: 1187
  • Thank you received: 370
Folks, just a hint for you, since I‘m not 100% sure whether all of you understand the mechanics behind a meridian flip (except for you, Jasem :-).

There is no magic dedicated command for mounts executing a meridian flip. On which pier side a scope is placed is decided within the firmware of each mount at that time when a slew to a certain point in the sky is triggered. The only chance for EKOS to control a meridian flip is a) remembering the last position that has been slewed to and b) checking, when this position crosses the meridian.

As soon as this happens (plus a configured delay plus waiting for a capture to complete), EKOS issues a slew command to the last position hoping for the mount to flip. But it remains the decision of the mount firmware, whether this is done or not. In several logs posted here you can see that the firmware decided against a flip - the log reports that the pier side did not change. In this case, there is a hardcoded delay of 4 minutes where EKOS will make a new attempt.

For all of you experiencing this problem: you can simulate the flip in a dry run during daytime: position the mount close but east of the meridian and wait, until it crosses it. Then simply send a manual slew to the exact same position and see what happens. This way you can find out what delay is appropriate for your mount and all other parameters of your mount influencing the flipping behaviour. And don‘t to forget turning off the MF feature of EKOS to avoid intervening. And don‘t forget to turn it on afterwards again!

HTH
Wolfgang
The following user(s) said Thank You: Jasem Mutlaq
3 years 4 months ago #64202

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

Wolfgang, I fully agree. However, just for the sake of completeness, I'll try later tonight to schedule Ekos to image a target near the meridian just to see if there is perhaps a regression elsewhere that is affecting this.
3 years 4 months ago #64203

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

  • Posts: 1187
  • Thank you received: 370
Sure, totally makes sense!
Especially the last thing that Andrew reportedshould be investigated.

Let's see what the logs say...
3 years 4 months ago #64204

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

  • Posts: 1029
  • Thank you received: 301
I think you are probably hitting the same issue that made be completely disconnect phd2 from the mount driver. I write this from memory, because I could never really pinpoint what happened, and I had other issues with kstars crashing preventing tracking from being stopped by the watchdog, because of phd2 being still connected.

Check the geographical location when phd2 connects first after indiserver is up.

Check the geographical location when Ekos connects first after indiserver is up.

In my situation, I had the geographical location stored in the INDI configuration. For whatever reason, the geographical location is not set when phd2 connects first. Then when Ekos connects, the driver configuration is not loaded because there is already a client, but is actually saved. This erases the information, and the LST computation is broken from then on, as well as flipping.

Have a look to see if my analysis is grounded please.

-Eric
3 years 4 months ago #64216

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

  • Posts: 527
  • Thank you received: 139

This happens with the internal guider as well.
3 years 4 months ago #64224

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

  • Posts: 527
  • Thank you received: 139
I'm attaching my log here. I may have a few issues going on here described below. It's the full log from the whole night. The meridian flip starts around 22:50 or so. The object passes the meridian at 22:52-22:53. I had the mount set to allow the flip at 0 degrees past the meridian. The reason for this is the Rainbow mount stops tracking at 0 by default. Issuing a goto command anytime after 0 should cause it to flip. You can see it start the flip at this time. It tries again several times saying flip failed, pier side not changed. I didn't set the flip after 0 because I didn't want guiding to lose the guide star and position because the mount would stop tracking at 0. All that said though, I did on the pervious night set it to flip at 5 minutes past 0, and I ran into all the same problems that happened tonight.

At some point prior to the flip the guide star keeps getting lost, some how tracking rate changed from sidereal to "guiding" which looks like a custom rate and the guiding system can't get a lock on a guide star because it's moving faster than sidereal. I've seen this before a bunch, and this must be a bug or issue with the Rainbow driver.

At some point after a bunch of failures and guiding issues due to the tracking rate change I think I correct the tracking rate by setting it back to sidereal in the Indi control panel. I issued a few manual goto's and kept getting the flip failed message on the mount tab. I walked outside, and saw the telescope on the east side of the pier pointing west of the meridian. So, the mount at some point did flip despite the messages saying it didn't. I don't know if it was my manual goto that got it to flip or not. So I went back inside to issue a goto command to go to NAVI which was very west of the meridian at the time. The flip message was still there saying flip failed, retrying in x minutes. After this, I stop the scheduler, and quit EKOS. Restart it, and reconnect all devices, and we're back to normal again.

I'm not super good at deciphering the log, so I included the full log so you can see any settings or things that might be contributing to these problems.

log_18-15-23.txt.zip
Last edit: 3 years 4 months ago by Andrew Burwell.
3 years 4 months ago #64229

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

  • Posts: 32
  • Thank you received: 7
I fixed it!!!!! I'm going to try to explain what my issue was and hope I don't sound like an idiot in the process AND hopefully help someone else.

After much testing here was my problem. My mount (Eq6r-pro) for whatever reason was reporting to ekos the wrong position. Here's how I discovered it. I noticed the mount was reporting an odd position when the mount was clearly pointing somewhere else. When I first launched Ekos, instead of kstars showing the mount was pointing to the north star (as that's my parking spot for the mount), the reticle on the kstars was showing the scope to be pointing way off, I mean WAY off. Even when I synced the mount to the north star and thought the problem was fixed, when I quit kstars and re-lauched kstars, the reticle was WAY off again, but always showing in the same position. I don't know much about mounts, I'm aware they have encoders, but this kind of implies the encoders have a start point and that start point somehow got messed up. Out of pure frustration, I rummaged thru a box of telescope stuff, found the hand controller to the mount, plugged it in, did a factory reset. PROBLEM SOLVED! The meridian flip worked as planed last night. I'm guessing the flip wasn't working simply due to the fact the mount was giving ekos a wrong position.

As far as plate solving not working, this was fixed when I changed ownership of the index files to myself, instead of root. Now the new solver in kstars works VERY fast.

I thank all of you for your help on this matter.
The following user(s) said Thank You: Eric, Michael
Last edit: 3 years 4 months ago by mikeE.
3 years 4 months ago #64234

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

  • Posts: 1029
  • Thank you received: 301
It's great you could solve this (don't forget to update the title of the thread). Things are easier when the mount doesn't remember stuff from one session to the other! Especially when the drift stretches over several months.

-Eric
3 years 4 months ago #64269

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

Time to create page: 0.694 seconds