Had a surprise last night:
I was running on two different objects, first a short one, later a longer one. I usually have 'refocus every X' active, with something like 80 minutes. The first run was only a bit longer than that, so I had deactivated the box after I had done the AF run.
After the first sequence had finished, the next target was only 15 minutes before meridian. So I ran an autofocus during that time on a close-by area that was already on the flipped side and waited for the target to cross meridian.
That was going to be a sequence for the rest of the night, so I reactivated the check box. But I did this after I had run the AF. This seems to not set the mark that an AF had been run. Because, when I started the sequence, I got the message
[2020-08-12T01:04:08.620 WEST INFO ][ org.kde.kstars.ekos.capture] - "Ekos will refocus as soon as possible, last procedure was 9,724 seconds ago."
Those 9,724 seconds referred to an AF run I had done in the very beginning of the night, before I had deactivated the timer based refocus. Both the AF run before the short sequence and the one a few minutes before were ignored
I think the timer reference should be set to zero after any AF run, not only if the timer box is checked
Read More...
Last night my observations had stopped after the meridian flip (yes I know, I should run via scheduler...)
I had a look at the logs, to figure out what happened. I was running a sequence of 200 120s Hα exposures, directly from the Capture tab, with guiding via PHD2.
I used settings 'refocus every 64min' and 'refocus if ΔT>1°'.
At 02:12 a timer-based refocus occurred. Guiding is suspended during AF, as I use an OAG and sometimes the image moves a bit when changing focus direction.
All went fine, including the 20s settle after AF (as the guide star sometimes drifts away from focuser movement)
Right after that, at 02:21, it was time for a meridian flip that started one minute later.
After slewing to the other side, alignment was started. This unfortunately switched my filter from Hα to Red (*)
Alignment went fine without issues, autoguiding was restarted (02:23:57) and the next exposure initiated (02:24:10)
This switched back to Hα, which in turn again triggered an autofocus run (I have set AF on filter change)
Also this AF run finished successfully. But when settling after re-enabling the guiding, already after 4 seconds it reported a failed settling, and aborted the sequence.
PHD2 itself needed some 20s to catch the star back and after that continued to guide for the rest of the night....
So I somehow suspect the problem was starting the guiding but immediately pausing it again, leaving it with a large error (some 7 pixels)
I had checked the PHD2 log, and indeed it had reported a settle failure right after the first exposure
Here's the part from the PHD2 log file:
INFO: SETTLING STATE CHANGE, Settling started
1,4.041,"Mount",-5.575,4.081,-5.095,5.074,-2.802,4.059,260,E,315,S,,,989036,489.46,0
2,8.046,"Mount",-3.526,1.777,-3.310,2.420,-1.820,1.936,169,E,150,S,,,1012387,457.94,0
3,12.113,"Mount",-2.078,0.182,-2.045,0.577,-1.125,0.462,105,E,36,S,,,1005718,446.58,0
INFO: Server received PAUSE
INFO: Server received RESUME
INFO: SETTLING STATE CHANGE, Settling failed
4,200.581,"Mount",-6.844,-1.689,-6.988,-0.346,-3.844,0.000,357,E,0,,,,1012080,406.98,0Not sure who's to blame there - should PHD2 reset the settling state when it gets paused, or shouldn't EKOS send a pause while PHD2 is still settling?
In doubt I attach the logs (kstars and PHD2)
(*) I always disable the filter selector in Alignment and Focus tabs, as I want it to always use the current filter. Unfortunately it is not possible to save this setting, after each restart it is active again. And if I forget to disable that - see above
Read More...
Thanks for the explanation! Indeed sounds like a horribly complex thing...
Ah, I'll give it a try then.sterne-jaeger wrote:
In case that this happens, the currently running capture is aborted and restarted. This is a very neat feature for example in windy nights.And checking that box would abort the sequence in case of hitting the limit, no?
I mostly run only the capture part, doing the initial setup manually, and go to bed once things run fine. Clouds are usually not an issue here at 2400m.Even better is it if you use the scheduler. In case that guiding aborts, the scheduler restarts the capture sequence (as long as it is configured to restart). If the scheduler is not used, aborted guiding leads to aborting the capture sequence, so a single cloud and the session aborts.
But last night it would have been helpful, as guiding aborted after the MF. Still have to find out what happened, as PHD2 was happily guiding, but EKOS had it showing idle mode, I needed to manually "start" guiding again... It's the first time I saw it, so it might have to do with the way I started things (I had killed kstars, which left INDI on the remote compute running without disconnecting, so that when restarting kstars and ekos it would have all devices connected and running. Likely PHD2 didn't like that.... But that's in doubt another thread; sort-of hijacking this one once is enough
Thanks again!
Read More...
Hm, why would that explain it? And why has it changed? I have never used the deviation limit, and have not seen overwritten frames until recently, and now it's always doing this.
And checking that box would abort the sequence in case of hitting the limit, no?
Read More...
No, the box is not checked. Only focus, via Temperature and a timer. Should I do a run with some limit in place? Would be tomorrow though, as I've now started regular observations (with timestamps enabled ;^>)
Read More...
So, here's one with full debug enabled. Guiding is extremely verbose though...
Also, it didn't do an alignment this time after the flip - likely because I didn't align before? Is that intended behavior?
Read More...
So it's linked to guiding somehow. I just ran two MFs. First one guided (PHD2) inclusive dithering. It overwrote one file again. Second one was done without guiding/dithering (and also had no target name defined). This time, frame number was advanced, no overwrite occured.
The log is attached, with verbose dbg. However, there's not really much more info in it seems. Have I enabled the wrong debug? I did 'capture', 'guide' and 'fits'.
Do you need other modules?
Read More...
Hmm, yes indeed there's other files, for each FITS there's a .wcs file, from my Live Stacking. But IIRC for the first case reported in the other thread I didn't have that running, then it would have been only the files of the running sequence.
The other difference between the two cases reported here was that the second one had no target name, i.e., only "Light_<number>.fits".
I'll try to get a verbose log tonight and figure out which of those conditions causes the problem....
Read More...
That was a test run, without guiding (which is why I replied here). That was indeed successful.
But there's a second MF around 01:20/01:22. That is 'real' observations, with guiding (PHD2).
There it saves file Light_073.fits before the flip, and (again) Light_073.fits after the flip as "Received image 74 out of 200."
The Ha directory contains 199 files (not 200), and the time stamps show the 01:22 file is missing, and has been overwritten by the 01:25 one:
woodstock:Ha% l Light_07[234].fits
-rw-r--r-- 1 pit users 32785920 Aug 8 01:19 Light_072.fits
-rw-r--r-- 1 pit users 32785920 Aug 8 01:25 Light_073.fits
-rw-r--r-- 1 pit users 32785920 Aug 8 01:27 Light_074.fitsRead More...
I had some attached to the linked post in the other thread.sterne-jaeger wrote: Log files?
Here's the full log from yesterday, with both flips. No debug settings though
After the first one worked I had assumed it had been fixed....Read More...
I noticed EKOS now spits out two error lines every second if guiding via PHD2 is configured but PHD2 is not (yet) running. And I found no way to stop this other than starting up PHD2. It also seems to be set to auto-connect on startup. I have disabled that for INDI, but there's no equivalent option for PHD2 (?)
Any chance of muting this a bit? I have one logfile that consisted to 60% (or 10000 lines!) of this messages.
Read More...