David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 6 days ago

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.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 6 days ago

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.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 6 days ago

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.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 6 days ago

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.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 6 days ago

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-SuccessfulFlip-20191207.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.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 6 days ago

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-FailedFlip-M31-20191207.txt
File Size: 986 KB



Next I'll post from a successful flip.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 6 days ago

Well the results are interesting and kind of discouraging.

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

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 7 days ago

I started working through things last night but it clouded over while I was doing tests.

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:
Mount: EQMOD
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.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 1 week ago

Here again is what is - and is not - happening with emphasis on the differences between two scenarios where flips do and do not occur. It's all been nicely colour-coded to aid in following along. You can pretend I'm a dimwitted idiot who shouldn't be anywhere near an equatorial mount at all if it makes you feel better about being dismissive, but that still doesn't change what the logs say.


Scenario 1:
Live EQMOD mount, simulated camera, no guide camera real or simulated. Accordingly, in the Schedule tab, the 'Align' and 'Guide' boxes are UNCHECKED. Meridian flip set to >0.05h

When I set up a schedule that involves a meridian flip with this scenario and run it, the mount successfully carries out a meridian flip, as expected.

So, under this circumstance, I am able to get the mount to flip.

Fwiw, these dummy runs were carried out during the day, but I see no reason it wouldn't work under clear night skies either. I could test that out too on the next clear night.

Scenario 2:
Live EQMOD mount, simulated camera, live ZWO ASI guide camera on a real guidescope. So, in the Schedule tab, the 'Align' and 'Guide' boxes are now CHECKED. Meridian flip is set to >0.05h

As there is no live camera, alignment is being carried out by the guide camera on the guidescope. This run is also being carried out under clear night skies, so Ekos goes through an alignment routine after the mount has been aimed at the target.

When I set up a schedule that involves a meridian flip with this scenario and run it at night under clear skies, here's what happens:
-the mount is moved to the target, with the mount head on the west side
-once on target Ekos goes through an alignment routine to centre the target
-once the alignment routine is satisfied that the target is centred, a guide calibration is initiated
-once the guide calibration is successful, the guiding begins
-once guiding begins, the capture sequences are initiated
-at this point, on the Mount tab, I can see a count down to the meridian flip
-once the meridian flip countdown gets to 0, it goes into a waiting stage while the current capture finishes
-once the current capture finishes, a meridian flip *IS INITIATED*
-but almost instantly the meridian flip is INTERRUPTED or stopped
-Ekos then proceeds to carry out an alignment using and recentres back on the target
-on the Mount tab the meridian flip status is now Inactive


So just so we're clear, with a live mount and a live guide camera on the guidescope and the guide camera serving as the alignment device, with 'Align' and 'Guide' checked in the Schedule tab, under clear night skies, a meridian flip is initiated and then almost instantly stopped. That's in contrast to when it did fully carry out a flip when there was no guide camera set in the profile and the 'Align' and 'Guide' steps were unchecked in the Schedule tab.

And you can see for yourself in the logs I've attached. In my first post, i.e. 'Scenario 2':

[2019-12-02T21:19:22.226 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 4
[2019-12-02T21:19:22.232 EST DEBG ][ org.kde.kstars.ekos.mount] - Slewing to RA= "01h 58m 47s" DEC= " 37° 55' 49\""
[2019-12-02T21:19:22.316 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Aborted"
[2019-12-02T21:19:22.316 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Meridian Flip"
[2019-12-02T21:19:22.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:22.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:22.830 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Slewing"
[2019-12-02T21:19:22.840 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[...]
[2019-12-02T21:19:25.877 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Tracking"
[2019-12-02T21:19:25.879 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 5
[2019-12-02T21:19:25.923 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 3

That's 3 seconds.

Now take a look at the log from my second post, where it does carry out the flip fully, i.e. 'Scenario 1':

[2019-12-03T11:51:13.896 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 4
[2019-12-03T11:51:13.898 EST DEBG ][ org.kde.kstars.ekos.mount] - Slewing to RA= "16h 33m 37s" DEC= "-13° 05' 36\""
[2019-12-03T11:51:13.907 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:13.909 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:51:13.985 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Meridian Flip"
[2019-12-03T11:51:14.828 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Slewing"
[2019-12-03T11:51:14.840 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:14.843 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:51:14.862 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[...]
[2019-12-03T11:52:38.828 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Tracking"
[2019-12-03T11:52:38.829 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 5

That's a minute and twenty four seconds (1:24), i.e. the time it took for the mount to flip.


So, quite frankly, whether or not I understand how a meridian flip is supposed to work is a moot point given that under both scenarios the flip is initiated. It's just that it will complete the flip under a limited scenario but won't under a slightly more involved scenario with more equipment attached. For some reason, the meridian flip is initiated but it is stopped in the scenario where the guide camera is attached and operating. It's repeatable - I've run both scenarios thrice and get the same results each time, so it's not a one-off fluke.

I'll run them again with logging of the INDI messages as well to see if that turns up any more useful information.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 1 week ago

I've read through the Synscan manual - the only reference to meridian flipping is with respect to whether it's auto or, for the next goto movement only, forced or disabled. As far as I'm aware, the EQ6 doesn't have mount limits at all. Left to its own, it will eventually strike the tripod through normal tracking.


At any rate, none of this particularly explains the behaviour that far more concerns me, the interruption of a just-started meridian flip when there's a guide camera attached. Is it perhaps because I'm using the guide camera for both alignment and guiding, so when the guiding gets turned off by the meridian flip it's available to take an image for alignment? I would guess that under most use cases one would preferentially use the main imaging camera for alignment?

I still have to investigate Tim's suggestion of increasing the meridian offset but even if does that does seem like a workaround given that it *does* work with a minimal offset when there is no guide camera attached.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 1 week ago

Sorry, which behaviour are you referring to?

The one I described in my last post of the mount head slewing to the west side for a just-west-of-meridian object?

Or the behaviour I described in my initial post whereby a dummy run successfully meridian flips but a night time run with a guide camera in the mix gets interrupted seconds after the flip starts?

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 1 week ago

Thanks Tim, I'll give that a try.

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: it's quite evident that the mount itself has passed the meridian some time before the software thinks it has. Time and again I can tell KStars to go to an object that is just west of the meridian only for the mount to slew to it with the head still on the west side, including occasions in which it has slewed from an object even further west when the head was on the east side. So given this behaviour, plus the 0.2h trigger point past the meridian plus the delay to complete a capture, I'm concerned it could get kind of hairy for high elevation targets.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 2 weeks ago

Today I recreated a dummy run without the Alignment and Guide Steps checked. Here's an abbreviated log of what happened:

[2019-12-03T11:50:26.827 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:50:26.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:50:27.827 EST DEBG ][ org.kde.kstars.ekos.mount] - Meridian flip planned with LST= "16h 36m 39s" scope RA= "16h 33m 38s" and meridian diff= 0.05
[2019-12-03T11:50:27.827 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 1
[2019-12-03T11:50:27.833 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:50:27.835 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...

[...]

[2019-12-03T11:51:12.831 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:12.833 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:51:13.599 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Image Received"
[2019-12-03T11:51:13.600 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "Searching in path '/home/astroberry/netdrive/photos/Capture/M107/Light', files 'MeridianTest_Light*' for prefix 'MeridianTest_Light'..."
[2019-12-03T11:51:13.688 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_001'"
[2019-12-03T11:51:13.689 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_002'"
[2019-12-03T11:51:13.689 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_003'"
[2019-12-03T11:51:13.689 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Frame map summary:
[2019-12-03T11:51:13.689 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "/home/astroberry/netdrive/photos/Capture/M107/Light/MeridianTest_Light" : 3
[2019-12-03T11:51:13.896 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 4
[2019-12-03T11:51:13.898 EST DEBG ][ org.kde.kstars.ekos.mount] - Slewing to RA= "16h 33m 37s" DEC= "-13° 05' 36\""
[2019-12-03T11:51:13.907 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:13.909 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:51:13.985 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Meridian Flip"
[2019-12-03T11:51:14.828 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Slewing"
[2019-12-03T11:51:14.840 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:14.843 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:51:14.862 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[2019-12-03T11:51:15.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:15.830 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...

So here it has started the meridian flip.
[...]
And a little over a minute later it completes the flip:

[2019-12-03T11:52:37.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:52:37.830 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:52:38.828 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Tracking"
[2019-12-03T11:52:38.829 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 5
[2019-12-03T11:52:38.833 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:52:38.836 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:52:38.853 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 3
[2019-12-03T11:52:38.854 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Idle"

So this is interesting, and I don't know if this happened or not on my previous dummy run, but it attempts to align when the Align step isn't actually checked:

[2019-12-03T11:52:38.854 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Aligning"
[2019-12-03T11:52:39.827 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 0
[2019-12-03T11:52:39.827 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:52:39.829 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:52:40.349 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "In Progress"
[2019-12-03T11:52:40.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:52:40.832 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:52:41.672 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "In Progress"
[2019-12-03T11:52:41.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:52:41.838 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...

[...]
Naturally it fails:

[2019-12-03T11:53:04.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:04.830 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:04.976 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "Failed"
[2019-12-03T11:53:04.976 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Aligning"
[2019-12-03T11:53:05.827 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:05.836 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:06.469 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "In Progress"
[2019-12-03T11:53:06.827 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:06.830 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:07.744 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "In Progress"
[2019-12-03T11:53:07.829 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:07.832 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:08.829 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:08.831 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:09.829 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:09.831 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:10.830 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:10.843 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:11.830 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:11.832 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:12.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:12.830 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:13.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:53:13.831 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:53:14.790 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "Aborted"

And I finally aborted it.

Read More...

David James created a new topic ' Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 2 weeks ago

The other day I set up a test of the meridian flipping on my EQ6 by setting up a quasi-dummy profile consisting of the following:

-EQMOD
-CCD Simulator

With that up and running, I set up a dummy exposure sequence of an object very close to the meridian - just a whole slew of 90s exposures. The Scheduler only has 'Track' selected in the Steps. So off it went taking dummy 90s exposures and once the >0.05h threshold was exceeded, the mount proceeded to flip after the completion of the dummy exposure it was on. So all is good and expected.

With some clear skies, I now made a real profile with the following:

-EQMOD
-CCD Simulator (I have an unsupported X-T1, so this is my workaround to be able to use scheduling - I just create a number of very long dummy exposures)
-ASI CCD (for an ASI120MM)

As I have a guidescope and guidecamera attached, the 'Align' and 'Guide' Steps are now also selected in the Scheduler.

But this time what happens is that the meridian flip is initiated and almost instantly halted. From the message window, I can tell that the Guider was halted when the flip was initiated. But something seems to have set off the Alignment module as it takes an image, determines the object isn't too far away and proceeds to recentre it before the meridian flip has actually taken place. On the Mount module, the Meridian Flip status changes to Inactive. Ekos restarts the Guider with a new calibration, then resumes taking exposures. All the while, the mount and camera continues to head for the tripod legs.

It first happened with M31, then I tried it with M33 with the same result. So I started a log with Scheduler, Alignment and Mount checked and tried again with NGC 752.

This is with KStars Build 2019-11-20T07:25:31Z running on an Astroberry server:

[2019-12-02T21:19:21.696 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Image Received"
[2019-12-02T21:19:21.697 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "Searching in path '/home/astroberry/netdrive/photos/Capture/NGC752/Light', files 'MeridianTest_Light*' for prefix 'MeridianTest_Light'..."
[2019-12-02T21:19:21.797 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_001'"
[2019-12-02T21:19:21.797 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_002'"
[2019-12-02T21:19:21.798 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_003'"
[2019-12-02T21:19:21.798 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_004'"
[2019-12-02T21:19:21.798 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_005'"
[2019-12-02T21:19:21.799 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_006'"
[2019-12-02T21:19:21.799 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_007'"
[2019-12-02T21:19:21.799 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_008'"
[2019-12-02T21:19:21.799 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_009'"
[2019-12-02T21:19:21.799 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "> Found 'MeridianTest_Light_010'"
[2019-12-02T21:19:21.799 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Frame map summary:
[2019-12-02T21:19:21.800 EST DEBG ][ org.kde.kstars.ekos.scheduler] - "/home/astroberry/netdrive/photos/Capture/NGC752/Light/MeridianTest_Light" : 10
[2019-12-02T21:19:22.211 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:22.216 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:22.226 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 4
[2019-12-02T21:19:22.232 EST DEBG ][ org.kde.kstars.ekos.mount] - Slewing to RA= "01h 58m 47s" DEC= " 37° 55' 49\""
[2019-12-02T21:19:22.316 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Aborted"
[2019-12-02T21:19:22.316 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Meridian Flip"
[2019-12-02T21:19:22.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:22.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:22.830 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Slewing"
[2019-12-02T21:19:22.840 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[2019-12-02T21:19:23.853 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:23.856 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:24.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:24.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:25.837 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:25.843 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:25.877 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Tracking"
[2019-12-02T21:19:25.879 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 5
[2019-12-02T21:19:25.923 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 3
[2019-12-02T21:19:25.924 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Idle"
[2019-12-02T21:19:25.924 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Aligning"
[2019-12-02T21:19:26.825 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:26.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:26.829 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 0
[2019-12-02T21:19:27.439 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "In Progress"
[2019-12-02T21:19:27.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:27.829 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:29.146 EST DEBG ][ default] - WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
[2019-12-02T21:19:29.146 EST DEBG ][ default] - WARNING: Phonon::createPath: Cannot connect Phonon::MediaObject ( no objectName ) to Phonon::AudioOutput ( no objectName ).
[2019-12-02T21:19:29.146 EST DEBG ][ default] - WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
[2019-12-02T21:19:29.146 EST DEBG ][ default] - WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
[2019-12-02T21:19:29.225 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:29.231 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:29.248 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "In Progress"
[2019-12-02T21:19:29.827 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:29.829 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:30.830 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:30.833 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:31.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:31.829 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:32.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:32.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:33.831 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:33.833 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:34.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:34.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:35.899 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:35.902 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:36.829 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:36.832 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:37.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:37.829 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:38.848 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:38.851 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:39.844 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:39.849 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:40.922 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:40.927 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:40.929 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Slewing"
[2019-12-02T21:19:40.939 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "Syncing"
[2019-12-02T21:19:41.022 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[2019-12-02T21:19:41.124 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "Slewing"
[2019-12-02T21:19:41.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:41.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:42.072 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "In Progress"
[2019-12-02T21:19:42.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:42.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:42.830 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Tracking"
[2019-12-02T21:19:42.831 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 3
[2019-12-02T21:19:43.579 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "In Progress"
[2019-12-02T21:19:43.825 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:43.827 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:44.825 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:44.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:45.272 EST DEBG ][ default] - WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
[2019-12-02T21:19:45.272 EST DEBG ][ default] - WARNING: Phonon::createPath: Cannot connect Phonon::MediaObject ( no objectName ) to Phonon::AudioOutput ( no objectName ).
[2019-12-02T21:19:45.272 EST DEBG ][ default] - WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
[2019-12-02T21:19:45.272 EST DEBG ][ default] - WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
[2019-12-02T21:19:45.294 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "In Progress"
[2019-12-02T21:19:45.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:45.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:46.825 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:46.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:47.833 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:47.835 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:48.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:48.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:49.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:49.829 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:50.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:50.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:52.006 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:52.016 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:52.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:52.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:53.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:53.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:54.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:54.829 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:55.862 EST DEBG ][ default] - WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
[2019-12-02T21:19:55.862 EST DEBG ][ default] - WARNING: Phonon::createPath: Cannot connect Phonon::MediaObject ( no objectName ) to Phonon::AudioOutput ( no objectName ).
[2019-12-02T21:19:55.862 EST DEBG ][ default] - WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
[2019-12-02T21:19:55.863 EST DEBG ][ default] - WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded
[2019-12-02T21:19:55.893 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:55.897 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:55.911 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Align State "Complete"
[2019-12-02T21:19:55.911 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Calibrating"


I don't have a log of the successful dummy run from the other day, but I can recreate it.

Read More...

David James replied to the topic 'Issue with exposure length using Fuji XT2' in the forum. 3 months ago

I have a Fujifilm X-T1 and it is absolutely unusable with Ekos, or any other Linux app, for that matter. INDI simply fails to connect to it properly. Using the tether function in Darktable I can preview and take 1 - and only 1 - photo before it bails and disconnects. I then have to unplug the camera, turn it off, then plug it back in and power it back on. Using Entangle, it crashes after every photo.

Are you able to successfully take photos using the program Entangle or with the tethering function in Darktable? Because if you can't, the problem is with gphoto2 support for Fujifilm cameras (having done some reading into the subject, there appears to be some non-standard stuff in how Fujifilm cameras communicate).

Read More...