Hello!
I was wondering if this was a problem that only I was having, a bug, or a normal feature.
You can see from the log, that the images are saved to file ~3 sec after the expected exposure completion time. This is in line with the predicted download time of the camera. However, after the image is saved, there is a fairly long dead time of ~6 sec, where nothing seems to happen.
I am using SGP mostly to do photometry, and this dead time is actually quite important to me.
Does anybody have any insight into what is happening in these 6 seconds, and how to reduce this dead time? Image history is already disabled.
Also, according to the logs, it looks like SGP is attempting to settle the autoguider, even though I have this option disabled. Is this just a small bug in the logs, or is the āsettleā checkbox not working?
As a side note: at the end of the log file, it can be seen that there is a 4 sec delay between the calibration frames. This is caused by an explicit delay between frames specified in the sequence (so no problem there). If I donāt use this delay, there is no dead time between saving an image and starting the next one. So, the delay observed only occurs on light frames, not on calibration frames, leading me to believe it is caused by some sort of operation on the image that Iām not thinking ofā¦
On my laptop it take SGP over twice as long to download and save a file as Maxim DL and even longer compared to Sharpcap using the ASCOM camera driver.
On my i7-4790 desktop these delays disappear - making me fear that for most people with fast computers they donāt see this problem. I hope it will be addressed as many of us use slower machines to save power when in the field.
Thatās very interesting to hear, thank you! Do you have a problem only with the time of download and save, or do you also have a delay between save and start of next image?
Hmm my problem appears to be the time from the end of the download to the time the save to disk is completed. I have a log file on my thread. Something fishy goes on it seems as I said before other software on the same computer/OS are significantly faster.
For me this is an issue when I am shooting lots of 15-30s exposures with my low read noise camera - instead of the dead time between frames being 1-2s it is 6s+ with SGP which completely wastes a significant portion of the night.
If you can attach a log file (not the notification module output), we can take a look. Without a log I would venture to guess that it might be due to image analysis (this is CPU dependent).
If you are having image analysis problems on you have a couple options. We do not intend on changing the code in place right now as it is as optimized as we can get it (and still properly detect stars structures when they present as donuts). You can:
Turn image history off. This effectively disables the per-image analysis.
In the options dialog, use the āfastā method for find stars.
Having a quick look it seems like it has something to do with Phd guiding? The following repeats few time after image download:
[06/26/17 23:04:52.043][DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Post-Wait: Paused
[06/26/17 23:04:53.044][DEBUG] [Sequence Thread] Checking PHD2 stateā¦
[06/26/17 23:04:53.044][DEBUG] [Sequence Thread] PHD2 GetPhdStatus - Pre-Wait : Guiding
[06/26/17 23:04:53.044][DEBUG] [Sequence Thread] Sending to PHD2:
{āmethodā: āget_app_stateā, āidā: 1001}
I am not 100% sure of what is happening here. The settings you are using are atypical and, because of this, it may not be the most well tested path. While it is functioning properly, SGPro seems to be engaged in some redundant checking before proceeding. Because I am not able to reproduce this issue (even with your sequence), I have instrumented the code to help shed light on where this extra wait comes from. It will be available in 2.6.0.25.
Thank you very much for this! I realised Iām doing something a bit atypical, but itās nice to see how flexible the software is. Thanks for all your work
In the meantime, Iāll try to see if, by leaving the guiding on during image download, the problem disappears.
Should I repost the logs after version 2.6.0.25 is out?
Just to follow up a bit on this. I disabled āPause autoguider between framesā. The resulting log is here:
This is much better now, and the 6 sec delay after the image is saved is gone. The total dead time between the start of two consecutive exposures is now only ~4 sec instead of ~10 sec, most of which seems to be due to the ASCOM driver.
There is still about 0.5-0.7 sec which is lost while trying to settle the autoguider (even though I do not have that option checked!).
So I suppose I have a partial fix to my original problem (disable the āpause autoguider between framesā option).
