1. 20 Jan, 2022 3 commits
  2. 19 Jan, 2022 1 commit
  3. 17 Jan, 2022 4 commits
  4. 16 Jan, 2022 2 commits
  5. 15 Jan, 2022 4 commits
  6. 13 Jan, 2022 4 commits
  7. 12 Jan, 2022 4 commits
    • Jasem Mutlaq's avatar
      Add support for flat darks. · d558c895
      Jasem Mutlaq authored
      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).
      d558c895
    • Jasem Mutlaq's avatar
      Update frame is always align +A · c16eb6f4
      Jasem Mutlaq authored
      c16eb6f4
    • Script Kiddy's avatar
      SVN_SILENT made messages (.desktop file) - always resolve ours · 1963a6ff
      Script Kiddy authored
      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"
      1963a6ff
    • Script Kiddy's avatar
      GIT_SILENT made messages (after extraction) · 668f8521
      Script Kiddy authored
      668f8521
  8. 11 Jan, 2022 3 commits
    • Jasem Mutlaq's avatar
      Wait until rotate state is OK before marking prepare as ready · 5ec6a801
      Jasem Mutlaq authored
      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.
      5ec6a801
    • Wolfgang Reissenberger's avatar
      Deactivating meridian flip while PAA is running · 7d63e044
      Wolfgang Reissenberger authored and Jasem Mutlaq's avatar Jasem Mutlaq committed
      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.
      7d63e044
    • Hy Murveit's avatar
      Don't allow guidestars to redo star correspondence if it isn't the first guide frame · 56ad052e
      Hy Murveit authored and Jasem Mutlaq's avatar Jasem Mutlaq committed
      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.
      56ad052e
  9. 10 Jan, 2022 1 commit
  10. 09 Jan, 2022 2 commits
  11. 08 Jan, 2022 2 commits
  12. 07 Jan, 2022 1 commit
  13. 06 Jan, 2022 4 commits
    • Hy Murveit's avatar
      change label for new dither control · 02ead1ff
      Hy Murveit authored
      02ead1ff
    • Jasem Mutlaq's avatar
      Extend properties that can be saved in a sequence file beyond just numbers.... · 267c5517
      Jasem Mutlaq authored
      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
      267c5517
    • Hy Murveit's avatar
      dither and calibration cleanup. · 31f0ef70
      Hy Murveit authored and Jasem Mutlaq's avatar Jasem Mutlaq committed
      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.
      31f0ef70
    • Script Kiddy's avatar
      SVN_SILENT made messages (.desktop file) - always resolve ours · 283b2b81
      Script Kiddy authored
      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"
      283b2b81
  14. 05 Jan, 2022 1 commit
  15. 04 Jan, 2022 4 commits