×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Solid Ekos/Indi version

  • Posts: 1119
  • Thank you received: 182
Hi Jasem and Eric,

As you know, I am using the scheduler extensively, it is what makes astrophotography feasible for me without compromising my job. In the past, I reported various issues that were then promptly fixed and that have tremendously improved the usability of Ekos. However, for some reason, these fixes are then often removed again during "upgrade" to the next version. For instance, in the last nightly build I used the scheduler no longer reassesses the object list and aborts after the first target although the next target still falls well within the altitude and time (ASAP) parameters. The only way around that was to manually delete the first target and then restart the scheduler. I have therefore reverted back to Ekos 2.9.8 (August 18-2018 build), which does not have this problem.

However, it has a different one which also had been fixed previously: Once the first target has fallen below the lower altitude limit and after switching to the second target, if that is still on the other side of the meridian the guide module fails to recalibrate or at a minimum swap the calibration data. As a result, all images show the stars jumping around wildly with multiple ghost images on each frame, basically trashing all frames until the meridian flip occurs, which then force recalibration.

Previously, Jasem had been able to fix this very quickly, by adding an additional button in the Scheduler tab in Ekos that allowed me to select an option instructing the guide module to force recalibration upon switching to another target. Recalibrating the guide module really does not take that long, less time than a trashed frame, or worse, many trashed frames. It would be great if that button could be added back again.

Finally, the only other remaining issue in 2.9.8 is that it fails to take flats. That also was fixed by Jasem within hours of me reporting it during the summer.

From my perspective, if only these two problems could be fixed in VERSION 2.9.8 and if you could then post a stable v2.9.8 that has ONLY THESE TWO flaws fixed, as far as I am concerned Ekos would be doing all that is required for my work flow.

Would that be possible?

Thanks for considering.

Jo

This what happens to the second target if it is still on the other side of the meridian
The following user(s) said Thank You: Alfred, Eric
Last edit: 5 years 3 months ago by Jose Corazon. Reason: Added image
5 years 3 months ago #32246
Attachments:

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

  • Posts: 535
  • Thank you received: 109

Replied by Jim on topic Solid Ekos/Indi version

Along those lines, has automated testing for features and fixes going forward been considered? If something was fixed and a test was created as part of the fix, then it should break the build if it is modified unknowingly or removed. The time it would not help are if a completely different version of the code tree is merged in that does not have the fix or the test.

I have experienced what the OP is talking about as well, so am trying to suggest ways to mitigate it and allow Jasem, Eric and our other devs with limited time to focus on forward-looking things instead of churning in fixes.

Jim
The following user(s) said Thank You: Alfred, Jose Corazon
5 years 3 months ago #32253

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

  • Posts: 985
  • Thank you received: 161

Replied by Alfred on topic Solid Ekos/Indi version

I second this request.

During recent months much work has been directed towards introducing new features and drivers. At the same time a few bugs creeped into other parts that did work OK in the past, impacting functionality. Some of these bugs have been left unaddressed. I'd favor an older, "hardened" version with a few "hand-picked" bugs removed over any new, feature-rich one.
The following user(s) said Thank You: Jose Corazon
5 years 3 months ago #32295

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

Ok, so this is NOT a scheduler issue. I worked on this today and made the Guide module aware of the pier side property IF supported by the mount. In cases where the pier side changes AND calibration was already done, it simply swaps the DEC switch and not recalibration is necessary. I will test this tonight as well to make sure it works as expected.
The following user(s) said Thank You: Eric, Jim, Jose Corazon
5 years 3 months ago #32311

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

  • Posts: 1029
  • Thank you received: 301

Replied by Eric on topic Re:Solid Ekos/Indi version

This has to be validated against PHD2 too. PHD2 has a setting to invert the DEC information from the mount depending on pier side. This setting has to be clarified if Ekos alters the mount configuration.

-Eric
The following user(s) said Thank You: Jose Corazon
5 years 3 months ago #32317

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

The change that I made (and forgot to push on my work PC) is only valid for internal guider.
The following user(s) said Thank You: Eric
5 years 3 months ago #32319

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

  • Posts: 1029
  • Thank you received: 301

Replied by Eric on topic Re:Solid Ekos/Indi version

I support the change. It is equivalent to the "reverse DEC after flip" in PHD2.

-Eric
5 years 3 months ago #32335

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

  • Posts: 1119
  • Thank you received: 182

Maybe I am interpreting this wrong, but that was not the problem I had. When imaging the same target, the guide module recalibrates reliably after the meridian flip.

The problem I encountered occurred when the scheduler was managing more than one target. After the first target slipped below altitude limits, the scheduler would then - correctly - switch to the next target in line. However, the guide module would not recalibrate. Which resulted in the ugly image I posted above: After switching to the second target on the other side of the meridian, the guide module would continue to use the previous calibration data from Target 1 now on Target 2. Which means that not only DEC is now reversed, but RA would also not be optimally calibrated.

It would be safer to just instruct the guide module to OPTIONALLY clear the data and recalibrate after EVERY meridian flip or else swap the DEC data, AND DEFINITELY recalibrate upon switching to a new target.
5 years 3 months ago #32347

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

If "Always Reset Guide Calibration" is check (by default it is), then it is reset after meridian flip. When switching to a different target like in your case, as soon as the pier side changes, the DEC is swapped so recalibration isn't necessary. At any rate, this is all theoretical I yet have to have a clear night to test it out.
The following user(s) said Thank You: Eric
5 years 3 months ago #32348

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

  • Posts: 1029
  • Thank you received: 301

Replied by Eric on topic Re:Solid Ekos/Indi version

For robustness when processing targets that are far away, I agree you should reset calibration for each. For close enough targets, such as mosaics, this should not be necessary (but see below). With DEC now swapped properly, calibration should survive the flip.
It must be noted that calibration results are different at zenith and at horizon, I certainly confirmed this with real-life tests. Damage due to a calibration done 4 hours before is clearly visible on my F=480mm.
So long-exposure targets, even close from each other like mosaics, should benefit from being divided to recalibrate in-between.
So there is room for improvement on when to reset calibration. We could consider using the same method as the refocus mechanism, but using HA/altitude-based angular distance instead of elapsed time.

-Eric
The following user(s) said Thank You: Jose Corazon
5 years 3 months ago #32350

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

  • Posts: 1119
  • Thank you received: 182
I agree, Eric, that was my assessment as well. It is not without cause that PhD2 asks for the Declination of the target prior to calibrating.
That's why I would prefer to rather calibrate one time too often than one time too few. Only after a meridian flip, while staying on the same target, i.e. when Declination does not change, should just swapping the DEC data be sufficient.
In all other cases, when DEC is changing, I would think only recalibrating can yield optimal results.
The following user(s) said Thank You: Eric
5 years 3 months ago #32351

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

  • Posts: 300
  • Thank you received: 57
Thankfully KStars internal guider calibrates very quickly, so it's not a big deal to repeat this procedure.

But a better approach is to use the declination and side-of-pier to calculate guiding adjustments, so that the calibration remains valid all over the sky. Just as with PHD, PHD2, TheSkyX, or MaxIM DL, it's unnecessary to calibrate for a specific target.

Rather, calibration provides the orientation of the guide camera and guider image pixel scale relative to the sky. The rest of the guide pulse calculation is precisely deterministic from the declination and pier side.

There's no reason to calibrate again unless you either (1) change out equipment -- mount, guide scope, camera; or (2) forget the declination and side-of-pier where calibration was performed. Unfortunately it appears that the KStars guider does the latter every time!
5 years 3 months ago #32382

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

Time to create page: 0.396 seconds