GitLab

Update sequence prefix for ADU-calculated flat frames since full prefix can change due to dynamic exposure calculated in the process

Set Focus module to the filter of the first light job in the sequence so that it is focused for that particular filter when the capture sequence begins

Use KSNotification when rejection motions outside of enabled mount limits. When limits are disabled and user issues GOTO below horizon, issue a timed warning and remember user choice. Fixes #149

In Edit job mode, set default button to validate job. On exit edit mode, reset default button to preview. Fixes #152

Hy Murveit authored Jan 13, 2022 and Jasem Mutlaq committed Jan 13, 2022

The test to (optionally) not start a capture is the guide deviation is greater than a certain amount was broken for a while. It never triggered. This MR fixes that. 

The issue was that the test, internal to sequenceJob/sequenceJobState, checks to see if guiding is active before applying the test. However, when capture sees guider change state to active (in Capture::setGuideStatus) it cannot change the guide state internal to the sequence job, because currentJob is still a nullptr, not yet set to the current job. This change fixes that by always setting the sequenceJob's guide state before emiting prepareCapture().

Add support to dark flats. Steps:

1. Add flats
2. When done, click on "Generate Flat Darks"
3. Dark flat frames are generated and appended.
4. Start sequence. 

Dark flat frames would be captured for the same duration of the flat frames. The only limitation to this method is that it need to be performed in the same session. i.e. you cannot take some flats, restart Ekos, and then continue since we can no longer know the duration that was calculated for the flat frames. While it is possible to open the FITS files and inspect them, this is very complicated now and perhaps a better solution for such case is available in the future (maybe a file to track the flat frame exposures).

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Rotator position angle was set as ready as soon as it is within the mechanical threshold, but we didn't check if it fully stopped. Now, we check to make sure it stopped before marking the action as ready.

Wolfgang Reissenberger authored Jan 11, 2022 and Jasem Mutlaq committed Jan 11, 2022

Running a polar alignment close to the meridian might lead to the situation that the scope crosses the meridian. In this case, the meridian flip feature of `Mount` will be deactivated so that the polar alignment is not disturbed.

As soon as the polar alignment is finished, the meridian flip feature is activated again.

Hy Murveit authored Jan 11, 2022 and Jasem Mutlaq committed Jan 11, 2022

This is an attempt to fix the bug described in 
https://indilib.org/forum/ekos/11029-internal-guider-shift-when-loosing-guide-start-with-cloud.html?start=12

What I think is happening is that GuideStars::findGuideStar() was allowed to re-define the guide star if there were no multi-star StarCorrespondence setup, because of in the logic where the scheduler was restarting the guider, selectGuideStar() was not being called. This normally works OK. However, in poor skies it, if not enough stars detected (there needs to be a minimum of 5) then starCorrespondence is not established, and the selectGuideStar can find a new/different guide star. Even this would be OK if the guider realized that this was a new guide star, but it doesn't know that and tries to move the two stars to the same image position.

The solution here is to not allow findGuideStar to redefine the guide star unless it's the first guider iteration (InternalGuider::m_isFirstFrame is true).

A possible weakness is that if the guider is started in poor skies MultiStar won't be used, but then if the skies clear up and MultiStar is now possible, it would not switch over to MultiStar. I suppose something like that could be engineered.

**Why Draft**

This is marked as Draft as there has been minimal testing, just quick simulator--I have not been able to test on a telescope. Am creating the MR in hopes of getting other to test until my skies clear up.

Robert Lancaster authored Jan 10, 2022 and Jasem Mutlaq committed Jan 10, 2022

Making the data directory install first on Macs so that it gets copied by craft to install directories properly

In case we have pending in-sequence tasks, we need to suspend fast exposure to tend to these tasks and only enable fast exposures afterwards

Hy Murveit authored Jan 08, 2022 and Jasem Mutlaq committed Jan 08, 2022

Cleanup of the previous dither MR.
- disable the max-iterations dither option when one-pulse is selected, as it doesn't apply
- disable some PHD2-only controls when PHD2 is not being used.
- change the label on those PHD2-only controls to indicate PHD2
- For one-pulse dithering, include the miss in the dither in the accumulation of dither random walk.

Make video streaming window appear on top since if a user activates live feed then it is more important than other windows on the desktop

Extend properties that can be saved in a sequence file beyond just numbers. Now switches and texts can also be saved in the sequence file

Hy Murveit authored Jan 06, 2022 and Jasem Mutlaq committed Jan 06, 2022

The dithering process calculates a random offset in pixels and moves that amount using the same mechanism as guide corrections. Since this is a random movement, exactly meeting the random dither amount isn't critical, and takes time and can potentially stall the system. Therefore, this MR removes the guide/dither iterations that check if the mount is pointing very closely to the desired dither location. It simply calculates the pulses it expects to need to move the mount the desired random amount and issues those pulses without checking that the movement was done. It records the observed position, of course, as the target guide position. This is enabled with a new checkbox option in the guider/dither options menu, but I'm tempted to remove the checkbox from this MR and just make the behavior the default. 

Another change is that previously, if one of the guide axes or directions were disabled, the dithering would not pulse in that direction (which can cause a nasty dithering issue currently, see https://indilib.org/forum/ekos/11008-dither-failure-while-guiding-is-good.html#78956
This MR changes it so that both RA and DEC are always dithered, even if an axis is disabled.
We could instead make this an option, or even add separate enable/disable-axis buttons for dithering. That can be up for discussion.

Finally, when testing the new dithering behavior using the simulator, I found that the dithering movements made weren't as close to the desired random dither as I'd expected. I traced this to the fact that the simulator has non-square guider-camera pixels. There was a TODO in the calibration code to improve matters with non-square pixels, and it was not difficult to implement, so I corrected this as well. Now the new dithering with the simulator operates well, as I expected.


- I have tested this with the simulator, but not with my telescopes (due to weather). I can/will test in a few weeks, or feel free to test yourself and let me know how it goes.

- Please feed back whether you're comfortable that always dithering in both axes is OK, even with the axis disabled for guiding. Alternatively whether I should add enable/disable axis checkboxes to the guider/dither options menu.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Wolfgang Reissenberger authored Jan 04, 2022 and Jasem Mutlaq committed Jan 04, 2022

Although filter change is not part of capture preparation, signaling
a filter change is essential for meridian flips at the end of a sequence.
If this is not signaled, guiding is not restarted.