Created a merge-request on invent.kde.org, this one is obsolete. Thanks for your support, @TallFurryMan !!

Many thanks for your explanation, Yuri. But if I get it right, this leads to a new clone of KStars. I just tried to import my GitHub project to Gitlab. This worked fine, but it has no linkage to its new upstream master on Gitlab. Is there a solution for this?

Great work Wolfgang, this indeed requires quite a bit of testing. Can you submit it directly to Gitlab? https://invent.kde.org/education/kstars

I need a little bit of support how to create a new merge request on gitlab. I've imported my kstars clone from Github, but it does not know its upstream repository.

Tests last night where positive, the meridian flip went flawless.

I did a first test with the simulator, everything seems to work smoothly.

OK, problem found. For small slews it might slip through the intervals where processNumber(...) is called. I think a shorter polling period will make this less likely to happen, but it won't heal it.

Very nice work, Hy, many thanks!!
I fully agree to that what Jasem and Robert have said.

Ah, sorry, you're right. Forget my comment please.

I tested this situation both with and without this diff. Without this diff, I could reproduce the problem that you described.

Yes, I agree. But this is just another sanity check. i.e. if the mount is slewing after settling time timeout, then something is very wrong and the state changes to ALIGN_SLEWING... after which is will actually end up calling settling again.

Sorry for being stubborn, but I don't see how this could happen. If the mount changes from tracking to slewing before we reach the end of the settling time, it should have been already detected by processNumber() or processSwitch().

It would not disturb, but it is partly redundant. The current change covers all, but vice versa if the settling time is too short, it will slip through. I only would avoid having both - with the perspective to future maintainability.

Good point, this would at least cover the cases where a new IPS_BUSY occurs during settling time. That would mean for users that see this happen they simply could increase the settling time.

5. After settle-ms is complete, it captures an image to solve. I propose that in step 5, we do another sanity check. We check if mount is _still_ tracking or not. If not, then we bail and wait until it stops. Does this sounds like a reasonable solution?

I would say that is already covered, since the align module receives all events regarding to the mount status and reacts immediately upon these events. The only thing that might happen is that it receives the update while it is already capturing.

Good point, so let's be careful with the core INDI driver. That's why I thought it would be safer making the align module more robust rather than tweaking the INDI driver, without knowing exactly the consequences...

@mutlaqja: I think the origin of the star trails is a behavior of many mounts that you fixed for iOptron. I observed a "hickup" in the logs of a 10micron mount, where EQUATORIAL_EOD_COORD shows the following status after a slew is issued:

• IS_BUSY
• IS_OK
• IS_BUSY
• IS_BUSY
• ...

My explanation is the following: when a slew command is issued, the immediate status response is IS_BUSY - so everything is fine at this stage. This is the standard behavior of inditelescope.cpp, which many mounts use as basis.

Handle mount motions during plate solving and abort when a mount motion is detected. As soon as the motion has finished, aligning continues.

You are right, the motion commands are not detected, since INDI handles them in a different way. If you issue a slew command in the mount box, it should work.

Works fine for me.

Well done!

Looks good! I suggested a minor change, but we can survive without.

It looks like this would give the user duplicate messages on success or failure of dithering.

That's not the case. I added a logging message to improve debugging, but it is not shown in the message frame of the INDI Client.

• Resume capture after dithering only if nothing else happened inbetween
• Dead code removed

When dithering is interrupted in the middle of a capture sequence, both the Capture module and the Schedule module restart capturing, which needs to be fixed.

Accepted.

Yepp, that's it. Well done, Robert!

At least for the internal guider, guideView->setTrackingBoxEnabled(false) is not sufficient. This method does not clear the guiding star position, the tracking box remains where it was.

Hm, unfortunately, the CCD simulator does not turn the frame upside down after a meridian flip. So after a flip, the stars are exactly the same, what makes it difficult to test. Any ideas?

We could just shut off / clear the tracking box position, so then it will be as if the tracking star had not been selected. I actually am thinking this makes more sense than turning on the autostar checkbox from a user's perspective because basically the old tracking star position is no longer valid so the box should just disappear.

Very good idea, far better than setting the checkbox!

I'm not sure if we should change the KStars/Ekos default for checking the autostar box. Currently the default is false, I just checked.

I would warmly recommend changing the default behaviour to auto-star.

I reported the issue to Rob. The issue comes up only if the "auto star" button is unchecked in the Guide tab. For me, 4 or 5 nights in a row last week I failed to guide after a meridian flip until I looked into the code and logs and discovered the root cause.

It would be great if you could share details, since I tried to reproduce the case without success. I had the "auto star" button unselected and checked it

1. with a scheduler running - no success (I think the scheduler sets the button automatically)
2. only with the Capture module running with pulse guiding - no success
3. same, but ST4 guiding - no success

So either there is a magic option in EKOS/PHD2 or a newer version of PHD2 that makes the difference.

@lancaster: I cannot reproduce the problem you described. With the latest KStars and latest PHD2, everything runs fine. After a meridian flip, in all cases I tried, PHD2 automatically selects a new star after the flip. Could you please give advise for a test case where PHD2 sticks to the old position?

Auto scale instead of show x axis reverses the logic

Maybe you mean "Auto Scale Y-axis or value-axis" ?

That sounds best. But in this case, the logic is vice versa. When then check box is selected, the value axis is scaled to [min, max], right?

I'm still not sure what "show x axis" means exactly.

The reason is that openweathermap has an update period of 60 secs. And other than the WeatherSimulator does not initially update the sensor values but waits for the update period until the values are read for the first time.

At least I didn‘t change anything there. It depends on the frequency how often the INDI driver updates its data.

I think one additional improvement for the future is to include the time in the tooltip as well instead of trying to gauge when exactly was this moment in time by looking at the horizontal axis.

I know, but I was not so sure if I get it right in one iteration with local time etc and all this stuff.

• Add the option to clear the sensor data history
• Bug fixing of the display when no weather or no dome is present

Great! now it works just fine. I think the only thing missing is a small clear button to reset all the data.

OK, update will come.

I also noticed another issue.. because there is warning, I see count-down.. however, there are no actions to take so why is there a count-down? it counts down to what?

That's not so easy to fix. Will be handled in a separate diff.

• Immediate replot sensor graph after rescaling axes
• Show graph value as tool tip, display optimization

also, I think instead of displaying the tooltip in the graph, it should be like the guide graph in the sense that it displays the reading value @ time. Then it's very useful to know the exact value at a particular time stamp.

Good point, I will do it.

In D24528#544530, @mutlaqja wrote:

It seems there is problem when switching between weather parameters, check video below.

Repainting the entire graph happens with a certain delay - I have to investigate this whether it is possible to accelerate it. And I think it makes sense having the 0-line always visible.

Here a screenshot of the new graphs:

... but it needs to rebased manually. @TallFurryMan: I slightly doubt that it is worth the effort...

Hm, indifferent. It does not seem like there is burning request for this feature. So never touch a running system?

Some code cleanup

Looks good, I update the commented parts and re-submit the diff.

With "receive external guide frames" selected:

1. pushing the "Capture" button in the Guide module creates an assertion failure in PHD2::captureSingleFrame().
2. pushing the "Loop" button shows the warning "PHD2 Error: could not start looping", but PHD2 starts looping.

We don't really want to be disabling cameras that are connected to Ekos unless they are actually being used in PHD2 as a guide camera I would think? The images are received and displayed in fits viewer because PHD2 hasn't said that that is the guide camera yet.

Personally, I do not like it when the FITS viewer pops up with the image from the guiding camera - no matter in what state Ekos and PHD2 are. I am not fully aware of all the consequences what happens if it is turned off.

Changing to contains method

Fine, that solved the problem. I am using the latest PHD2 version 2.6.6dev2. Maybe they changed something.

Fixing i18n

Great, thanks! But I now do not understand why this happens:
2019-09-28T01:24:39 PHD2's current camera: INDI Camera [Guide Simulator], is NOT connected to Ekos. It does not need to be connected, the PHD2 Guide Star Image should still be received.
This message always comes when I press "Connect" in the EKOS guiding module.

One behavior that seems to be new: if PHD2 is not connected to EKOS and PHD2 is looping, the images of the guiding camera are displayed in the FITS viewer. Is there a reason behind or is it simply a bug?

Looks good! There is one warning that seems to have a problem:
PHD2's current camera: Simulator(I18N_ARGUMENT_MISSING), is NOT connected to Ekos. It does not need to be connected, the PHD2 Guide Star Image should still be received.

I do not think it is super necessary. A user who is using KStars for astrophotography normally does not play around with the simulation clock. A message in the log should be a good compromise.

Please check D24232, this should hopefully fix the regressions we discussed here.

... hopefully the last i18n

... and now also in the dome model.

i18n arguments corrected (now hopefully complete)

i18n message arguments corrected

i18n message for observatory handling corrected

OK, I found the problem with hitting a constraint. In this case the Scheduler calls stop() which sets the job to ABORTED. That's explains the behaviour.

[2019-09-20T04:54:00.721 EEST INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'NGC1491' is now approaching astronomical twilight rise limit at pe syysk. 20 04:54:00 2019 (0 minutes safety margin), marking aborted."

Looks like at least the log warning is wrong. Assuming that @jpaana has the latest version, that's strange.

So we try to set jobs to COMPLETED based on frame count, we make sure we do not touch the frame count except when receiving a frame or recounting storage frames, and we do that state change when starting evaluation only? In other words, we never complete jobs during execution? The problem with states is that we must not jitter between values needlessly. Do you have a state diagram in head?

Let me give a try defining COMPLETED for a sequence job seq_j:

I agree. It is a regression from this diff, isn't it?

Well, some kind of. Before my diff, these where set to "aborted", which was also wrong from my perspective.

Hm, quite complicated. Has this ever worked? Nevertheless, I think when running multi-day-schedules, I would use "Remember job progress". In that case I think this situation would not happen.

Second regression observed minutes ago: when restarting after sleeping, all jobs are re-scheduled, even completed ones. I need to remove the jobs that were completed last night manually, or use Remember job progress.

Makes sense?

Good idea, far better!

OK, understood. But why did it happen that no frame has been captured? Was it due to the case that as soon as it would have been there turn to be started, they already hit their altitude or twilight limit, right?

When job #12 crossed the altitude restriction at 15° while focusing, it was incorrectly set to completed instead of aborted (KO).
When job #13 crossed the altitude restriction at 14.3° before starting, it was incorrectly set to completed instead of aborted (KO).

That's how it was intended from my side (see our discussion here).
I think I got your point now with the multi-day-schedules. As soon as a job is marked with JOB_COMPLETE, it will not be started the next night when the scheduler keeps running for more than one night.

Awesome job, Eric!

Very nice idea, Eric - well done!