Sorry, I have to admit that I ended up with option 3, i.e. each slew clears the calibration. This is more or less one line of code.
I implemented option 2 - which was quite easy. You can test it here .
Implementing 1 and 2 turned out to be more complicated, since there are several ways in KStars to slew to a new target and not all are handled the same way.
But during my tests it seems that option 3 isn't that bad, since in a typical workflow slew --> align --> guide it does not matter whether you clear only once or additionally during alignment, since no new calibration has taken place.
OK for you or are there situations where this could be disturbing?
Just a small clarification: my question was, what is expected if the option was selected and not whether this behaviour should be mandatory.
I personally have very good experience in the combination of EKOS and PHD2 and never had problems with calibrations once calculated. I even re-use calibrations over several nights as long as I am sure that I did not rotate the camera and changed the scope.
But there are several out there that need such re-calibrations. And for those, I would like to set the option such that it makes most sense for them.
When analyzing a
recently reported problem with guiding
it seems to me that the expectations what should happen when the option “Always reset guiding calibration” and the current implementation diverge.
Currently “always” means after a meridian flip. I’m quite sure that this is wrong, but does it mean
- each time the pier side changes
- each time when a new target is addressed
- each slew of the mount, even during alignment
I personally would prefer option 1 - which is the most complicated to implement. What are your thoughts?
If the option was set, the meridian flip would have triggered a re-calibration. I just tested it with simulators and PHD2 and everything went as expected. After the completion of the meridian flip, PHD2 re-calibrated.
The option "Always Reset Guide Calibration" is still present under the Scheduler options. Maybe you haven't set the option.
The reason most likely is that during the execution of sequence 1 a meridian flip occurred and the guide calibration was merely swapped instead of "recalibration forced upon pier side change". That swapped guide calibration was not reversed when sequence 2 started and the mount switched back to the other side of the meridian.
So, it looks to me that during one of the last updates the previously mandatory guiding recalibration upon pier side change was dropped. It would be great to have that option back in in the scheduler tab in Ekos.
In addition, I would recommend setting a guiding limit in the Capture module so that at least capturing restarts when guiding fails.
Hm, this behaviour is independent of the option you select for aborted jobs, since a job is set to IDLE when it hits a constraint and is not aborted. But when this happens, it will be re-evaluated again and sent to sleep until the constraint is met again. As a result, it covers all other entries below - which I guess is not the intention here.
For me the question is, whether scheduling works right when sorting by altitude is selected (which I never use). Should the scheduler jump to the first job in the list that meets its constraints or should it postpone all until the first in the row that is not complete meets its constraints (as it currently does)?
For such situations, I use a fixed order and set termination times. Interestingly, in such cases the scheduler behaves different. If the termination time of the first job has passed, the job is set to IDLE and the next in the row is scheduled.
Let's call it a bug... Yes, another strike of our spaghetti code monster (aka scheduler.cpp)
I am using an Arduino Metro Mini, which works fine under Linux. What do you use as housing for the electronics?
Still under investigation, since it is not that easy to reproduce with Simulators. Meanwhile the best explanation I see is, that this is a concurrency issue where a slew command overtakes a sync command. It looks like a sync happens while the mount already has started to slew.
You could reproduce a similar situation using the model builder of the align module:
- Create a set of alignment points with the mount model tool
- Start the mount model routine and let the first position being resolved.
- Wait until the mount slews to the second position.
- While slewing, use the INDI dialog and sync the mount to the first position.
- Observe, that capturing immediately starts although the mount is still slewing
What I could not explain right now is, why the sync command is overtaken by a slew.
Great work, Gilles, many thanks, having the tsl2591 as light sensor brings much value!
Since I am building my own small weather station I am very interested what type of enclosure you are using. Especially for the light sensor, is it possible to shield it from the weather without disturbing it?