- User Since
- Jul 16 2018, 6:19 AM (83 w, 4 d)
Jan 13 2020
|before (vertically centered)||after (vertically aligned to top)|
Dec 28 2019
Dec 9 2019
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.
Dec 1 2019
Very nice work, Hy, many thanks!!
I fully agree to that what Jasem and Robert have said.
Nov 24 2019
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().
Nov 23 2019
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.
Nov 22 2019
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.
Nov 21 2019
Nov 20 2019
- 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:
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.
Nov 19 2019
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.
Nov 18 2019
Works fine for me.
Nov 4 2019
Looks good! I suggested a minor change, but we can survive without.
Nov 3 2019
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.
Nov 2 2019
- 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.
Nov 1 2019
Oct 31 2019
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!
Oct 30 2019
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
- with a scheduler running - no success (I think the scheduler sets the button automatically)
- only with the Capture module running with pulse guiding - no success
- 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?
Oct 28 2019
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.
Oct 19 2019
Oct 17 2019
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.
Oct 16 2019
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.
Oct 15 2019
- Add the option to clear the sensor data history
- Bug fixing of the display when no weather or no dome is present
Oct 12 2019
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.
Oct 11 2019
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
Oct 10 2019
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.
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.
Oct 9 2019
Here a screenshot of the new graphs:
Oct 3 2019
... 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.
Sep 30 2019
With "receive external guide frames" selected:
- pushing the "Capture" button in the Guide module creates an assertion failure in PHD2::captureSingleFrame().
- pushing the "Loop" button shows the warning "PHD2 Error: could not start looping", but PHD2 starts looping.
Sep 28 2019
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.
Sep 27 2019
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.
Sep 26 2019
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.
Sep 25 2019
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)
Sep 24 2019
i18n message arguments corrected
i18n message for observatory handling corrected
Sep 23 2019
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.
Sep 21 2019
[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:
Sep 20 2019
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.
Sep 19 2019
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.
Good idea, far better!
Sep 18 2019
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.
Sep 15 2019
Awesome job, Eric!
Sep 11 2019
Very nice idea, Eric - well done!
Sep 9 2019
Sep 5 2019
Aaaah, sorry, I misinterpreted one thing. You're absolutely right, 60sec for aligning makes sense, since it is more than one single astrometry run.
Good idea, Alex. And welcome to the Scheduler-Optimizing-Club :-)
Sep 3 2019
Thanks, understood. But where does the M102 entry for N5457 come from? In the OpenNGC catalog it's only mentioned in the comment. Same for N5866, by the way.
Sep 2 2019
@cdersch: when I understand OpenNGC right, then they do not contain any Messier names. Where do they come from?
Did Christian answer? I learned meanwhile that it is historically not clear, whether NGC5866 is really the M102 from Messier's catalog.