×
INDI Library v1.8.6 Released (21 Aug 2020)

August 2020 release of INDI Library v1.8.6 introduces new drivers while providing fixes and improvements to existing devices and core framework.

Meridian flip interrupted on EQMOD mount - Alignment Module?

9 months 1 week ago
Aurneth
Senior Boarder
Senior Boarder
Posts: 64
More
Topic Author
Meridian flip interrupted on EQMOD mount - Alignment Module? #46689
So I've excised the entire log from starting up to failed flip, which is just under 12 minutes. By luck M31 was approaching the meridian so I plate-solved on it and let it go. I've cut nothing from the log for this period.

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.
Attachments:

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

9 months 1 week ago
Aurneth
Senior Boarder
Senior Boarder
Posts: 64
More
Topic Author
Meridian flip interrupted on EQMOD mount - Alignment Module? #46692
Following the above, I parked the mount then disconnected Ekos and stopped INDI before restarting it all again.

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.
Attachments:

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

9 months 1 week ago
sterne-jaeger
Platinum Boarder
Platinum Boarder
Posts: 640
Karma: 6
More
Meridian flip interrupted on EQMOD mount - Alignment Module? #46693
Hi Aurneth,
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.

- Wolfgang

TSA-120 + FSQ-85 + GSO 150/750 | Avalon Linear + M-zero | Moravian G2-8300 + ASI 1600mm pro | KStars/INDI on Raspberry Pi 4 with Raspbian 10

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

9 months 1 week ago 9 months 1 week ago by alacant.
alacant
Platinum Boarder
Platinum Boarder
Posts: 645
Karma: 1
More
Meridian flip interrupted on EQMOD mount - Alignment Module? #46694
Hi everyone
JTOL...

The eqmod side if pier was fixed here and has worked perfectly ever since:
github.com/indilib/indi/pull/658

Eqmod users are fortunate in that we have accurate side of pier reporting.

@OP. Is there any way you could get a physical imaging camera to test this with align and eqmod? A DSLR with a lens would be fine.
Is your computer set to receive Internet date and time?
Cheers and HTH
Steve

ubuntu 18.04
700d, eq6, t7m

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

9 months 1 week ago
ChrisRowland
Platinum Boarder
Platinum Boarder
Posts: 534
Karma: 9
More
Meridian flip interrupted on EQMOD mount - Alignment Module? #46696
You are right Wolfgang, the meridian flip slew move does not involve a meridian flip. It's possible that the flip has already happened, or that a guide command has blocked it.

The initial position is set here:
[2019-12-07T19:31:42.381 EST DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "00h 43m 49s" ( 0.730369 ) DE: " 41° 22' 45\"" ( 41.3794 )
The mount calculates the slew delta and sends commands:
[2019-12-07T19:31:42.484 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] SlewTo() : deltaRA = 2537643 deltaDE = -1218500 "
[2019-12-07T19:31:42.485 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] SetMotion() : Axis = 1 -- dir=forward mode=goto speedmode=highspeed "
...
[2019-12-07T19:31:42.572 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] SetMotion() : Axis = 2 -- dir=backward mode=goto speedmode=highspeed "
This is a fairly large slew and so the motors are commanded to run at high speed.
The slew is completed with a low speed run:
[2019-12-07T19:32:26.249 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] IsRARunning() = false "
[2019-12-07T19:32:26.250 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] CheckMotorStatus() : Axis = 2 "
[2019-12-07T19:32:26.250 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] IsDERunning() = false "
[2019-12-07T19:32:26.259 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] SlewTo() : deltaRA = 4588 deltaDE = 0 "
[2019-12-07T19:32:26.259 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] SetMotion() : Axis = 1 -- dir=forward mode=goto speedmode=lowspeed "
And tracking is started:
[2019-12-07T19:32:28.445 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] IsRARunning() = false "
[2019-12-07T19:32:28.445 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] CheckMotorStatus() : Axis = 2 "
[2019-12-07T19:32:28.445 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] IsDERunning() = false "
[2019-12-07T19:32:28.451 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] ResetMotions() "
[2019-12-07T19:32:28.451 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] CheckMotorStatus() : Axis = 1 "
[2019-12-07T19:32:28.452 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":G110\", 6 bytes written "
[2019-12-07T19:32:28.452 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=\", 2 bytes read "
[2019-12-07T19:32:28.452 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] CheckMotorStatus() : Axis = 2 "
[2019-12-07T19:32:28.452 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":G211\", 6 bytes written "
[2019-12-07T19:32:28.452 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=\", 2 bytes read "
[2019-12-07T19:32:28.453 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] StartRATracking() : trackspeed = 15.0411 arcsecs/s, computed rate = 1 "
Then there's a sync:
[2019-12-07T19:33:46.563 EST DEBG ][ org.kde.kstars.indi] - ISD:Telescope: Syncing...
[2019-12-07T19:33:46.571 EST DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "23h 51m 07s" ( 23.8521 ) DE: " 41° 22' 05\"" ( 41.3681 )
[2019-12-07T19:33:46.816 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":j1\", 4 bytes written "
[2019-12-07T19:33:46.816 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=A8C4A1\", 8 bytes read "
[2019-12-07T19:33:46.817 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] GetRAEncoder() = 10601640 "
[2019-12-07T19:33:46.817 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":j2\", 4 bytes written "
[2019-12-07T19:33:46.817 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=BCD38F\", 8 bytes read "
[2019-12-07T19:33:46.833 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[ALIGNMENT] New sync point Date 2458825.523439 RA 23.852100 DEC 41.368100 TDV(x 0.750013 y 0.022445 z 0.661042) "
...
[2019-12-07T19:33:46.846 EST DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "00h 43m 51s" ( 0.731074 ) DE: " 41° 22' 45\"" ( 41.3794 )
And a slew, high speed in RA
[2019-12-07T19:33:46.959 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] SlewTo() : deltaRA = -330415 deltaDE = 283 "
[2019-12-07T19:33:46.959 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] SetMotion() : Axis = 1 -- dir=backward mode=goto speedmode=highspeed "
Then a slow slew:
[2019-12-07T19:33:57.678 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] IsRARunning() = false "
[2019-12-07T19:33:57.679 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] CheckMotorStatus() : Axis = 2 "
[2019-12-07T19:33:57.679 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] IsDERunning() = false "
[2019-12-07T19:33:57.689 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] SlewTo() : deltaRA = 1046 deltaDE = 0 "
[2019-12-07T19:33:57.689 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] SetMotion() : Axis = 1 -- dir=forward mode=goto speedmode=lowspeed "

There are a series of slow slews through small amounts that I guess are guiding.

Now the meridian flip 'slew'.
[2019-12-07T19:41:16.084 EST DEBG ][ org.kde.kstars.ekos.mount] - Meridian flip planned with LST= "00h 44m 31s" scope RA= "00h 43m 54s" and meridian diff= 0.01
[2019-12-07T19:41:16.084 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 1
[2019-12-07T19:41:16.701 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] Compute local time: lst=0.74219640 ( 0:44:31.91) - julian date=2458825.52864834 "
[2019-12-07T19:41:16.701 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":j1\", 4 bytes written "
[2019-12-07T19:41:16.713 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=F46F9D\", 8 bytes read "
[2019-12-07T19:41:16.714 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] GetRAEncoder() = 10317812 "
[2019-12-07T19:41:16.714 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":j2\", 4 bytes written "
[2019-12-07T19:41:16.728 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=51D98F\", 8 bytes read "
[2019-12-07T19:41:16.728 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] Current encoders RA=10317812 DE=9427281 "
[2019-12-07T19:41:16.729 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":f1\", 4 bytes written "
[2019-12-07T19:41:16.754 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=111\", 5 bytes read "
[2019-12-07T19:41:16.754 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":f2\", 4 bytes written "
[2019-12-07T19:41:16.754 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=101\", 5 bytes read "
[2019-12-07T19:41:17.084 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 4
[2019-12-07T19:41:17.084 EST DEBG ][ org.kde.kstars.ekos.mount] - Slewing to RA= "00h 43m 52s" DEC= " 41° 22' 45\""
[2019-12-07T19:41:17.094 EST DEBG ][ org.kde.kstars.indi] - ISD:Telescope sending coords RA: "00h 43m 52s" ( 0.731238 ) DE: " 41° 22' 45\"" ( 41.3794 )
[2019-12-07T19:41:17.179 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] StopRA() : calling RA StopWaitMotor "
[2019-12-07T19:41:17.179 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":f1\", 4 bytes written "
[2019-12-07T19:41:17.186 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=111\", 5 bytes read "
[2019-12-07T19:41:17.186 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] StopWaitMotor() : Axis = 1 "
[2019-12-07T19:41:17.186 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":K1\", 4 bytes written "
[2019-12-07T19:41:17.187 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=\", 2 bytes read "
[2019-12-07T19:41:17.187 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":f1\", 4 bytes written "
[2019-12-07T19:41:17.187 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=101\", 5 bytes read "
[2019-12-07T19:41:17.187 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] StopDE() : calling DE StopWaitMotor "
[2019-12-07T19:41:17.187 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":f2\", 4 bytes written "
[2019-12-07T19:41:17.187 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=101\", 5 bytes read "
[2019-12-07T19:41:17.188 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] StopWaitMotor() : Axis = 2 "
[2019-12-07T19:41:17.188 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":K2\", 4 bytes written "
[2019-12-07T19:41:17.200 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=\", 2 bytes read "
[2019-12-07T19:41:17.200 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: \":f2\", 4 bytes written "
[2019-12-07T19:41:17.202 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: \"=101\", 5 bytes read "
[2019-12-07T19:41:17.211 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] SlewTo() : deltaRA = 274 deltaDE = 0 "
[2019-12-07T19:41:17.212 EST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[MOUNT] SetMotion() : Axis = 1 -- dir=forward mode=goto speedmode=lowspeed "

The movement is very small and is low speed only, a little later tracking is started.
And after that the log stops.

One possibility is that the meridian slew has already happened. The slew at 19:31:42 is a long one in both Ra and Dec.
As for the pier side, I woud expect that there would be more in the log about it there is very litte data other than raw data.

If someone who is more familiar with this driver might be able to get more out of the logs, in particular converting the raw axis positions to hour angle and declination to see if the flip is still needed.

Chris

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

9 months 1 week ago
Aurneth
Senior Boarder
Senior Boarder
Posts: 64
More
Topic Author
Meridian flip interrupted on EQMOD mount - Alignment Module? #46697
Hi Wolfgang,

Well I'm open to the possibility of some sort of time/geo-based cause as the initial slews to targets well removed from the parking position are off by about 13° W in RA (typically ~47000" is reported in the plate solver). I don't really have a satisfactory idea of why this is. You can see it in the log I posted on slewing to M31 at 19:33:46 where the plate solving reports a location of 23h 51m 07s rather than the 00h 43m 49s of M31's actual position. Would clearing the mount model help?

That said, the times reported in the log upon system initialization are correct, so KStars and Ekos are at least using the correct times. If there were a mismatch with the mount, how would I determine it and how would I correct it?

With respect to location, I've set up KStars with the city of Ottawa, Canada as its location using its default coordinates in the KStars setup wizard. From my phone, it tells me I'm about 6' west and 1' south of those coordinates. Now if I understand the implications of that correctly, with no other data available, the mount would tend to aim slightly west of the true location of an object and thus it would tend to flip slightly *earlier* in time than it would were the precise coordinates known. So how would updating that with information from a plate solve affect it? I've already determined that an HA>0.2h has the same results, and that's more than the time difference introduced by my physical offset from the default Ottawa coordinates.

Given this ~13° initial targetting discrepancy, and given than I've tended to aim for objects fairly close to the meridian to plate solve (it's sort of a site constraint), I suppose there is a possibilty that there is an erroneous determination post-plate solving that the mount has already been flipped, even though Ekos reports a countdown to a pending flip? I guess I could try to initially solve on objects well east of the meridian to remove any possibility of uncertainty as to what side of the pier the mount is on.

But that would have to wait for another clear night, not until Thursday.

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

9 months 1 week ago
Aurneth
Senior Boarder
Senior Boarder
Posts: 64
More
Topic Author
Meridian flip interrupted on EQMOD mount - Alignment Module? #46698

ChrisRowland wrote: You are right Wolfgang, the meridian flip slew move does not involve a meridian flip. It's possible that the flip has already happened, or that a guide command has blocked it.


Hi Chris,

There was no active guiding taking place during either of the posted logs. The ZWO was attached as a guide camera and used only for plate solving in the events of the first log.

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

9 months 1 week ago
Aurneth
Senior Boarder
Senior Boarder
Posts: 64
More
Topic Author
Meridian flip interrupted on EQMOD mount - Alignment Module? #46701

alacant wrote: Hi everyone
JTOL...

The eqmod side if pier was fixed here and has worked perfectly ever since:
github.com/indilib/indi/pull/658

Eqmod users are fortunate in that we have accurate side of pier reporting.

@OP. Is there any way you could get a physical imaging camera to test this with align and eqmod? A DSLR with a lens would be fine.
Is your computer set to receive Internet date and time?
Cheers and HTH
Steve


By physical imaging camera do you mean other than the ZWO ASI120MM I have attached? My imaging camera is a Fujifilm X-T1 which isn't functionally supported by gphoto and it crashes out whenever I've tried to tether it with INDI. In my tests, I did attach the ZWO as both Guider and CCD (separately, with INDI restarts) with no change in results.

The computer is a Raspberry Pi 3B+ running Astroberry. After a few minutes on wifi it gets the correct internet time so I tend to turn it on and let it sit there for a few minutes to allow it time to grab the correct time before connecting to it. The KStars version is 3.3.8, running directly on the Astroberry.

Now I could test this from a KStars installation running on another computer with the Astroberry limited to running INDI.

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

9 months 1 week ago
sterne-jaeger
Platinum Boarder
Platinum Boarder
Posts: 640
Karma: 6
More
Meridian flip interrupted on EQMOD mount - Alignment Module? #46703
Let' try to narrow it down step by step.

That said, the times reported in the log upon system initialization are correct, so KStars and Ekos are at least using the correct times. If there were a mismatch with the mount, how would I determine it and how would I correct it?

OK, so the time of KStars is correct. When you take your hand controller, what does the mount say? If you take a look a the INDI EQMod tab, do the time, date and location values match with KStars?

With respect to location, I've set up KStars with the city of Ottawa, Canada as its location using its default coordinates in the KStars setup wizard. From my phone, it tells me I'm about 6' west and 1' south of those coordinates. Now if I understand the implications of that correctly, with no other data available, the mount would tend to aim slightly west of the true location of an object and thus it would tend to flip slightly *earlier* in time than it would were the precise coordinates known.

It's not optimal, but you are right, that should not be a significant problem. By the way, you could add your own location with precise GPS coordinates.

So how would updating that with information from a plate solve affect it? I've already determined that an HA>0.2h has the same results, and that's more than the time difference introduced by my physical offset from the default Ottawa coordinates.

Plate solving has no effect upon this, it only helps to position the scope in the right direction.

Given this ~13° initial targetting discrepancy, and given than I've tended to aim for objects fairly close to the meridian to plate solve (it's sort of a site constraint), I suppose there is a possibility that there is an erroneous determination post-plate solving that the mount has already been flipped, even though Ekos reports a countdown to a pending flip?

Sure, either the the mount was already on the eastern side of the pier before crossing the meridian or - vice versa - remained on the western side when the meridian flip function initiated a re-slew to the current target.

I guess I could try to initially solve on objects well east of the meridian to remove any possibility of uncertainty as to what side of the pier the mount is on.

Don't think that this helps. More alignment points improve the model but it does not have an influence which pier side the mount selects. This is only dependent on date, time, location and target position.

But that would have to wait for another clear night, not until Thursday.

You do not need plate solving for testing it, it is sufficient if you have your mount running.

As a next step it would be interesting on which pier side the mount is when a meridian flip fails (or finishes within seconds).

- Wolfgang

TSA-120 + FSQ-85 + GSO 150/750 | Avalon Linear + M-zero | Moravian G2-8300 + ASI 1600mm pro | KStars/INDI on Raspberry Pi 4 with Raspbian 10

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

9 months 1 week ago
alacant
Platinum Boarder
Platinum Boarder
Posts: 645
Karma: 1
More
Meridian flip interrupted on EQMOD mount - Alignment Module? #46704
IIRC, the OP's home position has an error of 13°, so I think a plate solve anywhere east of the meridian will cancel this error. eqmod will then know exactly where the meridian is located.

I think another thing to try would be to set the mount's home position using a rough polar alignment followed by a bubble level to set the RA and DEC axes, locking the setting circles accordingly.

Make sure the mount model is cleared before each test.
HTH.

ubuntu 18.04
700d, eq6, t7m

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

9 months 1 week ago
Aurneth
Senior Boarder
Senior Boarder
Posts: 64
More
Topic Author
Meridian flip interrupted on EQMOD mount - Alignment Module? #46705

sterne-jaeger wrote: Let' try to narrow it down step by step.

That said, the times reported in the log upon system initialization are correct, so KStars and Ekos are at least using the correct times. If there were a mismatch with the mount, how would I determine it and how would I correct it?

OK, so the time of KStars is correct. When you take your hand controller, what does the mount say? If you take a look a the INDI EQMod tab, do the time, date and location values match with KStars?


I'm using a direct connection cable from the Astroberry to the mount, so the hand controller is not attached. The EQ6 never held the time anyway; it always had to be reentered on the Synscan controller or taken from GPS. I do have a Skywatcher GPS dongle which gave accurate time info until about April this year when its up-to-1024-week offset means of counting dates ran out.

On the Site Management subtab of the EQMod tab, the UTC time was loaded with the correct time. I do note that it doesn't increment the time, unlike the Julian and Sidereal fields.

Given this ~13° initial targetting discrepancy, and given than I've tended to aim for objects fairly close to the meridian to plate solve (it's sort of a site constraint), I suppose there is a possibility that there is an erroneous determination post-plate solving that the mount has already been flipped, even though Ekos reports a countdown to a pending flip?

Sure, either the the mount was already on the eastern side of the pier before crossing the meridian or - vice versa - remained on the western side when the meridian flip function initiated a re-slew to the current target.


Physically, the mount has always been on the west side of the pier before carrying out meridian flip test runs.

I guess I could try to initially solve on objects well east of the meridian to remove any possibility of uncertainty as to what side of the pier the mount is on.

Don't think that this helps. More alignment points improve the model but it does not have an influence which pier side the mount selects. This is only dependent on date, time, location and target position.

But I'm trying to consider factors that might have an effect on creating flip failures.

But that would have to wait for another clear night, not until Thursday.

You do not need plate solving for testing it, it is sufficient if you have your mount running.


But it's only when there's a plate solve in the mix that I'm having problems with meridian flips. No plate solving and all works fine. So there's something about plate solving or having plate solved that is creating conditions for failed meridian flips.

As a next step it would be interesting on which pier side the mount is when a meridian flip fails (or finishes within seconds).


It's always on the west side.

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

6 months 3 weeks ago
Aurneth
Senior Boarder
Senior Boarder
Posts: 64
More
Topic Author
Meridian flip interrupted on EQMOD mount - Alignment Module? #50012
So after spending some months (or rather a few nights here and there during the past few months) shooting targets in Orion, which is along the celestial equator and thus not a critical area of the sky for meridian flipping, I've returned to investigating this issue further.

In the meantime, I've acquired a QHY294C, so I can now do alignments with the main imaging camera rather than using the guide camera for that purpose.

And here is what I have found, though this is tentative as I haven't gone through an exhaustive series of tests, either.

If I use the 294C for alignment, meridian flips do seem to be carried out. I haven't tried this in an imaging sequence or with the scheduler, however, just pointing the mount and aligning with the camera.

However, when I used the ASI120MM as before for alignment, the abortive flipping issue returned.

When I aligned again with the 120MM and then followed it up with an alignment with 294C, the flip was carried out.

So my tentative conclusion is that plate solving with the ZWO ASI120MM creates the conditions for an abortive flip, but this can be superseded or cancelled by aligning with the QHY294C.

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

Time to create page: 0.306 seconds