Image download time

I thought I had this fixed but that is not the case. At this point I think I might just try another laptop. I just timed a download and from the time SGP displayed “Downloading” until a dither was performed was 1min 48sec. It only seems to happen during actual imaging.

There are reasons other than readout speed that can adversely affect your perceived download time (for instance, image history). If you want to post logs, we can try to give you a more granular view of events between integration completion and dither.

Thanks Ken. Attached is the log file. I did have Image History on and tried disabling it tonight. The first image downloaded and the dither was executed very quickly. The next image, still with image history disabled, is the one that I timed. Here is a log snip:

[6/3/2015 11:04:08 PM] [DEBUG] [Sequence Thread] Entering super dangerous loop to await image completion…
[6/3/2015 11:05:48 PM] [DEBUG] [Camera Thread] SGM_CAMERA_CAPTURE complete…

The previous exposure was much quicker I am not sure if this is related but it seems to be:

[6/3/2015 10:44:15 PM] [DEBUG] [Sequence Thread] Entering super dangerous loop to await image completion…
[6/3/2015 10:44:15 PM] [DEBUG] [Camera Thread] SGM_CAMERA_CAPTURE complete…

sg_logfile_20150603213138.txt (275.2 KB)

That download link appears to have been massacred somehow, can you post it again?

Should be fixed now sorry.

I can look at this a bit more later… here is the first thing that strikes me as odd. When SGPro goes into “integration wait” mode, it uses a high precision timer to “wait” so that it does not tax the camera with silly queries about image status when we know it shouldn’t rightly be done yet. As you can see, we start the timer at 23:06:51. This means that the “wait” timer should report that it is done exactly 1200 seconds later at 23:26:51… BUT your machine reports this timer is complete at 23:25:20 (about a full 90 seconds early), THEN the camera reports it is actually done (properly) at about the time we expect for a 1200 sec exposure. The only thing I can think of immediately is that your CPU clock speed is off (has the laptop been behaving strangely with any other applications?). Precision timers should not behave this way. Your downloads do not appear to actually be taking forever… they just make it seem that way because SGPro says “downloading” a full 90 sec before the camera is really done.

[6/3/2015 11:06:51 PM] [DEBUG] [Sequence Thread] Finished sending frame capture.  Entering wait mode...
[6/3/2015 11:06:51 PM] [DEBUG] [Camera Thread] SGM_CAMERA_CAPTURE message received...
[6/3/2015 11:25:20 PM] [DEBUG] [Sequence Thread] Waking from exposure time sleep period...
[6/3/2015 11:25:20 PM] [DEBUG] [Sequence Thread] Entering super dangerous loop to await image completion...
[6/3/2015 11:26:58 PM] [DEBUG] [Camera Thread] SGM_CAMERA_CAPTURE complete...

The frame before this “seemed” normal because the timer failed in the opposite way. It completed later than the expected 1200 second wait and the camera reported it was done immediately (because it was). The “wait” timer should have expired at 22:43:44, but instead expires at 22:44:15 (about 30 seconds late).

[6/3/2015 10:23:44 PM] [DEBUG] [Sequence Thread] Finished sending frame capture.  Entering wait mode...
[6/3/2015 10:23:44 PM] [DEBUG] [Camera Thread] SGM_CAMERA_CAPTURE message received...
[6/3/2015 10:44:15 PM] [DEBUG] [Sequence Thread] Waking from exposure time sleep period...

At this point, using another laptop would go a long way in ruling out some odd behavior at the hardware level.

Thanks for taking a look Ken. I haven’t noticed any other strange behavior like this. I have had some connectivity issues and instances where during PHD’s calibration the star does not move at all. I have also had instances where during SGP’s centering routine if there are a lot of Sync points in EQMOD in the same area I am trying to center it gets confused and the RA/DEC error doesn’t change. If I clear the sync data in EQMOD it then centers fine.

Attaching the full log file from my session last night if it helps.

sg_logfile_20150603213138.txt (706.3 KB)

I also have a Trius SX694 and I’ve noticed some intermittent image download time issues over the last few beta builds. What typically happens is that I connect all my equipment and then take a test frame and focus image, 4x4 bin and 1sec, sometimes this test image takes over a minute to show up while SGP reports downloading. Other times, I start looping frame and focus exposures but the first one exibits the same behavior. If I’m patient enough and let the first image take 90sec to show up, the other frame and focus images download in the normal 4sec. I do not remember this behavior in earlier SGP builds.

Here’s a log file that shows some suspect reporting (not that I know what to look for): Dropbox - Error

@karambit27 I don’t see anything new in the full logs.

@joelshort Not a lot in those logs, only one plate solve frame and it took 4 seconds to download and 1 second to save to disk… seems pretty normal

OK, next time it happens I’ll be sure to identify the log. It’s strange, I’m not making this up but when I look back at some of the recent logs I can’t see anything in them that would point to a long download time like I’m seeing standing in front of the computer.

@joelshort Please keep in mind you may also somehow be experiencing the “illusion” of long download times if your wait timer is also expiring early. SGPro will just throw up the “downloading” message despite the fact that it is really waiting on your camera to finish integration.

I can’t seem to reproduce the issue inside tonight. I’ve done a bunch of long exposures and every one from the time the capture message is received until SGP wakes from the sleep period is exactly the amount of time it should be and then the image downloads in 7secs which is normal. I don’t mind it waking early but the waking after the camera completes the exposure worries me as that is wasted imaging time.

Despite the fact that this logic has existed in its current form for years, I think we might change it to do something like leave the camera alone for 75% or 80% (something) of the exposure time and then start asking it if it’s done. It shouldn’t hurt anything so long as we are not obnoxious about the frequency at which we poll the camera for done.

In the case that the high precision timer we were using is somehow affected by external influences (it seems it is sometimes), we have moved to a timer system. This will be out for testing with the first 2.4.2 beta.

I have the QSI683 which is almost as slow. I was writing to an external USB2 memory stick, which I found added some considerable time to the overall inter-exposure time, more than it should. I switched back to the SSD harddrive and it was noticeably quicker.

One other thing occurs. SGP focusing has some difficulty with a globular cluster - it is not nebulosity but I think the close-proximity stars confuse the HFD calculation. Is there a way to do AF with a defined sub-frame, which misses the core of the cluster? That would also speed up the download too if one could just do focusing on a dozen good stars. If you think so too - should I make it a stand-alone request for a feature add?

1 Like

I used to have this problem and I thought they’d fixed it.

I think you can use the nebulosity slide to eliminate the core too.

Ken - just a thought, the QSI has a bi-colored LED on the back that confirms its status. I can check this against the SGP status bar and see if, on a long exposure, it is out of sync.

Thanks @buzz it might be helpful, but it seems to be computer dependent and have way less to do with the camera. It may tell you if your machines does this… a stopwatch could too. Either way, if you come across any data that supports this theory, please let us know.

Folks, some very interesting results:
QSI 683, High Quality 1x1 Binning mode. Connected via StarTech Ind. Hub to Intel Core I5 NUC (1.9GHz) via one of its 4 USB3 ports.
I created a simple sequence to download flats - no dither, no scope, guider or focuser. I compared the download times and noted the time when the QSI indicator indicated idle with three different types of storage: USB storage was formatted as FAT32 and plugged into the NUC’s USB 3 ports

USB2 Sandisk Cruzer 64GB (new) - 44-47 seconds between end of exposure and start of next, green light came on (download complete) after about 15 seconds.

USB3 Sandisk Extreme 32GB (new) -21 seconds between end and start of next exposure, green light came on (download complete) after 15 seconds

Internal NUC SSD - 18 seconds, download complete after 15 seconds.

I started using an external USB stick when I used the NUC and was operating with Microsoft Remote Desktop. I attributed the slow response to MRD. The above tests were with the NUC connected to keyboard, monitor and mouse directly, so MRD is in the clear - it is the pesky USB ports playing up with USB3 vs. USB2. I checked my USB2 stick on my Mac. It records at 8Mbytes/s, so it is not the memory stick per se. Unfortunately my USB3 memory stick has a known issue and the NUC refuses to stay powered down if it is left inserted after an eject. Looks like I will store to the SSD and move the files at the end of a session. I have just bought a USB3 caddy for a spare SSD and will try that too. [update] - that works fine, recording a 16MB file in an instant - especially if you turn on the cache.

Interesting huh?

Oh - Ken - I was doing 5 minute and 1 minute exposures - no indication that I could see to suggest there was a timer issue. The blinky orange / green LED was synchronised to the SGP status bar, during download and exposure.