×

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

Bi-monthly release with minor bug fixes and improvements

Meridian Flip does not complete on iOptron Mount

  • Posts: 1119
  • Thank you received: 182
I am having this consistent problem with the Meridian Flip being initiated, but not completed, on my iOptron SmartEQPro+ mount using Kstars 3.3.6 (latest stable version).
The same problem does not occur with the same Kstars version on my Orion Atlas (EQMOD) mount, so I think this may be an isolated driver issue.

What happens is that the Meridian Flip is being initiated, but not completed. As a result, the telescope ends up pointing somewhere far from its target in the sky and the Align Module then fails to solve, because it is looking in the wrong place (i.e. the telescope is nowhere where it should be).

Here a copy of the relevant log part (I think):

[2019-10-31T19:53:12.700 CDT DEBG ][ org.kde.kstars.ekos.guide] - Capturing frame...
[2019-10-31T19:53:13.282 CDT DEBG ][ org.kde.kstars.fits] - FITHistogram: JMIndex 0
[2019-10-31T19:53:13.329 CDT INFO ][ org.kde.kstars.fits] - Loading FITS file "/tmp/kstars/NGC7000_Light_30_secs_2019-10-31T19-53-11_032.nef.yV6267.fits"
[2019-10-31T19:53:13.330 CDT INFO ][ org.kde.kstars.ekos.capture] - "Received image 29 out of 300."
[2019-10-31T19:53:13.334 CDT DEBG ][ org.kde.kstars.ekos.capture] - Focus elapsed time (secs): 1297 . Requested Interval (secs): 3600
[2019-10-31T19:53:13.334 CDT DEBG ][ org.kde.kstars.ekos.focus] - Frame is reset. X: 0 Y: 0 W: 6016 H: 4016 binX: 1 binY: 1
[2019-10-31T19:53:13.340 CDT INFO ][ org.kde.kstars.ekos.mount] - Meridian flip: slewing to RA= "21h 01m 20s" DEC= " 44° 40' 12\""
[2019-10-31T19:53:13.340 CDT DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 4
[2019-10-31T19:53:13.342 CDT INFO ][ org.kde.kstars.ekos.guide] - "Autoguiding aborted."
[2019-10-31T19:53:13.346 CDT DEBG ][ org.kde.kstars.ekos.guide] - Aborting "Guiding"
[2019-10-31T19:53:13.348 CDT DEBG ][ org.kde.kstars.ekos.mount] - Slewing to RA= "21h 01m 20s" DEC= " 44° 40' 12\""
[2019-10-31T19:53:13.358 CDT DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "21h 01m 20s" ( 21.0224 ) DE: " 44° 40' 12\"" ( 44.6701 )
[2019-10-31T19:53:13.359 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] CMD <:Me00200d#> "
[2019-10-31T19:53:13.439 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] CMD <:Sr75680640#> "
[2019-10-31T19:53:13.514 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] RES <31> "
[2019-10-31T19:53:13.514 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] CMD <:Sd+16081235#> "
[2019-10-31T19:53:13.514 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] RES <31> "
[2019-10-31T19:53:13.516 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] CMD <:MS#> "
[2019-10-31T19:53:14.242 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] RES <31> "
[2019-10-31T19:53:14.249 CDT INFO ][ org.kde.kstars.indi] - iOptron CEM60 : "[INFO] Slewing to RA: 21:01:21 - DEC: 44:40:12 "
[2019-10-31T19:53:14.252 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] CMD <:GLS#> "
[2019-10-31T19:53:14.253 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] RES <-348454442028010801#> "
[2019-10-31T19:53:14.253 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] CMD <:GEC#> "
[2019-10-31T19:53:14.253 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] RES <+1596285975595060#> "
[2019-10-31T19:53:14.261 CDT DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 5
[2019-10-31T19:53:14.263 CDT INFO ][ org.kde.kstars.ekos.capture] - "Telescope completed the meridian flip."
[2019-10-31T19:53:14.266 CDT INFO ][ org.kde.kstars.ekos.capture] - "Performing post flip re-alignment..."
[2019-10-31T19:53:14.873 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] CMD <:GLS#> "
[2019-10-31T19:53:14.917 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] RES <-348454442028020801#> "
[2019-10-31T19:53:14.917 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] CMD <:GEC#> "
[2019-10-31T19:53:14.945 CDT DEBG ][ org.kde.kstars.indi] - iOptron CEM60 : "[DEBUG] RES <+1596274475595210#> "
[2019-10-31T19:53:14.979 CDT DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from 3 to 2


Note that at

[2019-10-31T19:53:13.340 CDT INFO ][ org.kde.kstars.ekos.mount] - Meridian flip: slewing to RA= "21h 01m 20s" DEC= " 44° 40' 12\""

the mount starts slewing to initiate the flip, but at

[2019-10-31T19:53:14.263 CDT INFO ][ org.kde.kstars.ekos.capture] - "Telescope completed the meridian flip."
[2019-10-31T19:53:14.266 CDT INFO ][ org.kde.kstars.ekos.capture] - "Performing post flip re-alignment..."

i.e. less than a second later the mount "thinks" the flip is completed and post flip realignment is started.

That matches what I am seeing happening at the mount. It starts to move, then a second later it stops and from there on it remains stuck. I need to manually stop the scheduler, park the mount and then reinitiate the schedule.

I have put the logs from two nights in here, just in case there is more info you need to see.

www.dropbox.com/sh/87xa1k8mt6d0e3a/AACzg...t0APgn_QOv3HMha?dl=0

Is this an iOptron specific driver problem?

It seems to be relatively recent. I recall that I did not have this problem when I last used that mount about a month (?) ago. At that time, the flip worked fine and I had also used 3.3.6.

Thanks for looking into this,

Jo
4 years 4 months ago #45297

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

  • Posts: 1009
  • Thank you received: 133
Hmm, following the reply to the :GEC# command, the mount points to 20h 59m 55s, 44⁰ 20' 27". So reasonably close.
What was the hour angle when you tried the flip? Looks like the mount thought it is still on the correct side. You should initiate flip with enough offset ( a few degrees past meridian), and set the mount itself (via HC) to react even later.
The following user(s) said Thank You: Jose Corazon
4 years 4 months ago #45301

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

  • Posts: 1119
  • Thank you received: 182
I initiate the flip 0.1 h after passing the meridian. The mount is set to autoflip at 3 degrees past the meridian.
I have used these settings ever since starting with Ekos almost 2 years ago and it never was a problem until about 4 weeks ago. And only with the iOptron Mount, not with my Orion Atlas.
As the log shows, the flip is INITIATED, but then aborted less than a second later. That never happened before.
But I can easily test your hypothesis. I'll set it to flip 0.2 h past the meridian tonight and advance the autoflip to 5 degrees.
The reason I had the limits set more tightly is that my camera hits the mount if I wait too long. That creates a whole other problem.
4 years 4 months ago #45303

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

  • Posts: 1185
  • Thank you received: 370
There are several reasons why this could happen:
  • Time / location of KStars and mount do not match.
  • Meridian flip is disabled for the mount
4 years 4 months ago #45314

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

  • Posts: 1119
  • Thank you received: 182

Except, as I wrote, it worked for almost 2 years, same location, no change made to the mount settings.

I'll adjust the parameters and will try again tonight.

Thanks ALL,

Jo
4 years 4 months ago #45315

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

  • Posts: 1119
  • Thank you received: 182
OK, I stood next to the mount tonight during a meridian flip. It is still not working. The problem is as follows:
I set the mount to flip at 3 degrees past the meridian (in EKOS, the mount itself was set to flip at 5 degrees past the meridian, so it was EKOS, NOT the mount that initiated the flip).

That flip was executed perfectly on time and worked fine. The mount moved and settled at the approximately correct new post-flip position. Therefore, the mount is receiving the Flip signal from Ekos and it executes it correctly.

HOWEVER, as the mount was moving, EKOS reported that the Flip had been completed and then the camera immediately took an exposure. Despite the star trails, that position was solved. As expected, that was close to the previous position of the mount (pre-flip). As a result, the mount left again the almost correct position it had settled in to move to the position indicated by the solution of the image taken during the movement of the mount.

The result was a beautiful image of the wall of my garage....

This must have something to do with the drivers. Ekos thinks the mount has finished the flip, although that is still ongoing. It starts the first realignment image prematurely while the mount is still moving.

Anyone else having noticed this with an iOptron mount (CEM60 driver, which is supposed to also drive the SmartEQ Pro+)?
Last edit: 4 years 4 months ago by Jose Corazon.
4 years 4 months ago #45331

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

  • Posts: 1185
  • Thank you received: 370
Hi Jo,
I think I found the explanation. It seems like the iOptron driver has a delay of 300-400ms until it reports the slewing state. Unfortunately, the mount checks the state too fast, i.e. reads a tracking state and thinks that the flip has been completed. But it is exactly the opposite, it hasn't started slewing yet (or at least it did not report it yet).

Could you please check the polling period for the iOptron mount driver? Maybe it helps when you set it to a lower value.

- Wolfgang
4 years 4 months ago #45355

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

  • Posts: 1119
  • Thank you received: 182
Hmmm....

Polling rate was 1000 ms.

I am a bit confused, though. What do you mean with 'lower value'?

Set it to 100 ms and thus increase the polling rate, or set it to 2000 ms and decrease the polling rate.

I.e. should I set it to a shorter polling interval and thus higher polling rate, or should I set it to a longer polling interval and thus lower polling rate?

I set it to 100 ms When I watched the mount yesterday, it was clearly moving when EKOS reported that the flip had been completed.
4 years 4 months ago #45360

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

  • Posts: 1185
  • Thank you received: 370
Ah, sorry, I meant to a smaller value like 100ms or 200ms. I know this is only a workaround, but maybe it helps.
4 years 4 months ago #45366

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

  • Posts: 1009
  • Thank you received: 133
I wonder whether this might be related with some issues Andrew (OzAndrew from Down Under) is seeing in CN discussions. He also says sometimes the status reports of the mount (specially CEM60 in that case) is wrong, with those values coming from the mount, not the driver.
As for faster polling, not sure if that's a good idea (serial only runs at 9600 baud), and will really help. If the mount reports the state (change) too late, asking for it even earlier won't help, would it? I'd rather delay the status request in case of meridian flip, assuming even the fastest mounts will take >10s to do a flip....
The following user(s) said Thank You: Jose Corazon
4 years 4 months ago #45373

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

  • Posts: 1119
  • Thank you received: 182
Yes, I intuitively also thought I need to increase the polling period, not decrease it.
Wolfgang, can you explain why going shorter would solve the problem?

I am still puzzled by what has changed. I did not do a firmware update on the handset, so it must be something in the driver or a change in Ekos that is causing this. As I wrote, it worked in the past, but since I did not use this mount much during summer, I don’t know when the change happened.
4 years 4 months ago #45376

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

  • Posts: 1009
  • Thank you received: 133
The handset should not be included there, the driver is/should be communicating with the main board directly to request the status. Did you do an update of the mount firmware? Which version are you running?
4 years 4 months ago #45377

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

Time to create page: 0.718 seconds