sterne-jaeger wrote:Sorry, I have to admit that I ended up with option <strong>3</strong>, 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?
Hi Wolgang, everyone
Does this affect those of us who guide only with PHD2 in any way?
Here's hoping negative!
Cheers and clear skies to all.
The intent is that this only comes into play when the box "Always reset guide calibration" is selected. There were cases where this did not happen, although the box was ticked and that would result in the following exposure sequence showing star trails.
So as long as you do not tick that box, nothing should change for you. If you tick the box, recalibration would occur every time the mount slews.
I also need to come back to Wouter's point, though: Would dithering trigger recalibration then, i.e. is dithering handled by the mount the same way slewing is? Intuitively I would say not, because dithering only involves guide pulses, which happen all the time during guiding anyway, so of that were to trigger recalibration, it would effectively start an endless loop. But I want to make sure that this does not become an unintended consequence.
Thanks so much, Wolfgang, for restoring this option.
Herrhausen wrote: Point taken, Jo! It was just a negligible comment from some guy who does neither use the scheduler nor re-calibrate at all, thus doesn't have a clue!
Out of curiosity... if you scheduled a movement in declination once the meridian has been crossed, let's say by pointing the scope to a nearby star and immediately returning to the object, wouldn't that achieve the same?
Ahhh..., Alfred, thanks for bringing that up!
That is precisely the difference of imaging from the middle of Frankfurt and the middle of Dallas....
...well, not really...
But in good old American, I would say 'that's a klutz!'
Which loosely translated into German means something like '' ' ne Kruecke hoch 3".
Here at Indi, we strive for PERFECTION!
Nothing less will do.
That's why nitpickers like me are tolerated here.
I wonder for how much longer...
Anyway, it really will help a lot if you are using the scheduler to fully automate your imaging sessions. That is my main objective here.
Herzliche Grueese und nimm's mir nicht uebel,
Herrhausen wrote: You're right, back to the task at hand. My thoughts:
1) "What is expected"? Well, "always" is pretty clear. The normal expectation would be 3.
2) Would that be reasonable and helpful though? No. I agree with Wouter and Jo, 1+2 would be the proper solution. And "always" should be changed to something that doesn't raise wrong expectations. But then,
3) since I would never use this option, don't pay much attention to my opinion.
P.S.: "2 only" is good enough! IMO it doesn't make sense to put that much effort into implementing something that I deem a negligible detail.
With all due respect, it is not a negligible detail if your imaging is dependent upon the scheduler. I agree, if you sit next to your scope, or rather are awake to control the flip and can manually erase the calibration and restart it if necessary, then this becomes a negligible detail. But for those of us who are putting the scope out in the backyard and letting it acquire images fully automatically, it really is an essential feature.
Thanks Wolfgang for putting it the effort! Will test as soon as there is a clear night again.
etamburini wrote: Goodmorning everyone!
I would like to know if the nikon d3400 works with ekos and, if it works, what does it need?
I have the Nikon D3300 and that works just fine with Ekos. You just need the USB cable to connect it and you should be good to go.
I agree, in theory. However, in practice guiding often breaks down after switching to another target. Recalibrating in that case restores it.
I also don't know how difficult your solution would be to implement given the current code. Wolfgang would be able to weigh in on that.
In the end I don't care one way or the other, as long as guiding works reliably and there is a way to fix it, short of rebooting everything, if it goes awry.
It doesn't really take that long to calibrate. Less than 1 min. I set the number of steps to 3 and I usually expose in 1 s intervals. If you iterate 5 steps and expose for 5s intervals, then, yes, that would indeed take a lot longer.
I prefer the internal guider. Usually, that works like a charm for me, and is far less complicated than patching in PhD2. The less can go wrong when running a multi-target schedule unattended through the night, the better.
That did the trick.
Only change for RPi4 users is that the directory is aarch64-linux-gnu and not x86_64-linux-gnu.
So RPi4 users (using Ubuntu MATE) need to change the first line of your terminal commands to
The rest is the same.
I agree with Wouter.
The combination of 1 and 2 would take care of all variables that could affect optimal guiding.
Better to calibrate one time too many than one time too few.
My PoleMaster is recognized now, but my ZWO cameras are not and Indi crashes.
2019-11-21T04:33:13: startup: /usr/bin/indiserver -v -p 7625 -r 0 -f /tmp/indififo967579a5
2019-11-21T04:33:13: listening to port 7625 on fd 3
FIFO: start indi_asi_ccd
FIFO: Starting driver indi_asi_ccd
2019-11-21T04:33:13: Driver indi_asi_ccd: pid=1896 rfd=4 wfd=7 efd=8
2019-11-21T04:33:13: Driver indi_asi_ccd: indi_asi_ccd: error while loading shared libraries: libASICamera2.so: cannot open shared object file: No such file or directory
2019-11-21T04:33:13: Client 5: new arrival from 127.0.0.1:59474 - welcome!
2019-11-21T04:33:13: Driver indi_asi_ccd: stderr EOF
Child process 1896 died
2019-11-21T04:33:13: Driver indi_asi_ccd: Terminated after #0 restarts.
Here the logs:
File Attachment:File Name: log_22-32-18.txt
File Size: 271 KB
I don't know whether you tested two sequential targets in the simulator. Sequence for target 1 was processed fine, no star trails after the meridian flip. So sequence 1 completed flawlessly. Whether recalibration occurred or whether calibration swap was activated, I don't know. Swap in that case would not have produced the problem.
The problem came with sequence 2, which was started 5 min AFTER sequence 1 was terminated as scheduled in the timer (as per your earlier suggestion). When sequence 2 was activated, the mount moved BACK across the meridian (moving from the west to the east side of pier) to start imaging target 2. THAT was when I saw swap enabled and all images had star trails. In other words, moving BACK across the meridian apparently did not trigger recalibration, moving FORWARD across the meridian very well might have.
If you can simulate that sequence of events in the simulator, you may be able to find the problem.
This is a real life practical issue for the scheduler, since most of the time one wants to use that to image 2 targets in one night, with the second target coming up in the East as the first target is setting in the West. So recalibrating when the mount swings back across the meridian becomes paramount (pun fully intended).
sterne-jaeger wrote: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.
Thanks for the suggestions!
The Always Reset Guide Calibration Option is set, I can guarantee that, since I watch that like a hawk every time I start a sequence for that precise reason. Nonetheless, when the second sequence was exposing, the Swap box was ticked in the Guide module, so it seems to me that Ekos ignored the Reset command. That has only occurred again recently.
It would be great if there were an option in Ekos where one can activate calibration swap, if someone absolutely feels like they want to save 60 s of recalibration. I always prefer to recalibrate, though, just makes guiding much more stable. Sometimes a mount is not perfectly balanced (especially with the iOptron Smart EQ Pro+ that is almost impossible to achieve, too much friction in the mount), so after a flip recalibrating helps even out these imbalances, I think.
As for the guiding limit: Restarting capturing was not the problem, in fact, all the frames were captured, they all just looked like the one I posted. If I set the guiding limit, then there will be fewer frames I have to visually sort out later, true, but in this case, I would have missed the fact that guiding was consistently using the wrong calibration data for all frames that were exposed. Looking at the individual frames I could see that with one glance, and without the need to study reams of log files.
Unfortunately, it is cloudy now for a few days, so it will take some time until I can reproduce the problem, this time with the logs turned on.
I second all of that, Thomas!
As for speaking into the forest: I know what you mean. I always feel guilty when I find a bug in Indi or Ekos and report it here. Sounds so much like nagging, but really only is conscientious testing and ultimately helps to improve the program (I hope).
Birthdate01. 01. 1960
About meStarted astrophotography with the eclipse last year. I never knew what was possible these days. Now I'm hooked.
Unfortunately, I am living in a white zone, so the only solution to getting acceptable pictures is to collect as much light as possible above the background. That's where the Ekos scheduler can become a life-saver!
Great job, team!