jakubovic / open-phd-guiding

Automatically exported from code.google.com/p/open-phd-guiding
0 stars 0 forks source link

Fishcamp Starfish camera: User reports exposure delay #370

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The attached debug log shows a consistent ~ 670 ms delay for each exposure.

it is not clear what part of capture() is responsible for the delay. Is this 
issue specific to this one setup, or do all FC cameras have the issue?

this will require some investigation (perhaps some additional debug logging) to 
see if it is a camera issue or a phd2 issue.

Original issue reported on code.google.com by andy.gal...@gmail.com on 24 Nov 2014 at 7:48

Attachments:

GoogleCodeExporter commented 9 years ago
This issue is being closed based on the following test data.

Hi Wei-Hao.  I retrieved my Starfish camera from the observatory and just 
finished running some timing tests here at home on Windows 7.  Using PHD2, the 
timing sequence for a 500mS exposure looks like this:

18:31:27.113 00.000 11796 Handling exposure in thread

18:31:27.114 00.001 11796 img.Init call

18:31:27.115 00.001 11796 Set ROI call

18:31:27.164 00.049 11796 Set duration call

18:31:27.251 00.087 11796 Start exposure call

18:31:27.256 00.005 11796 Waiting until near-end

18:31:27.658 00.402 11796 Start polling for completion

18:31:28.089 00.431 11796 Fishcamp says it's done

18:31:28.272 00.183 11796 Fishcamp image downloaded

18:31:28.273 00.001 11796 Exposure complete

So the end-to-end time is about 1.16 seconds.  I then added diagnostic code in 
the test application that Fishcamp ships with the camera.  For the same 500mS 
exposure, their timings are:

20:08:53:101 Set ROI

20:08:53:152 Set duration

20:08:53:252 Start exposure

20:08:54:064 Done exposing

20:08:54:248 Download complete

Again, the end-to-end time is about the same.  Neither of these are using 
sub-frames, so the download time is worst-case.  But I don't see anything funny 
about the PHD2 behavior.  I think the delays are mostly due to the 
communication traffic and the polling behavior.  Changing any of this would 
require changes in the underlying Fishcamp Windows static library, which we 
don't have any control over.  For any sort of normal guiding exposures, I 
really don't see a problem here.  The actual shutter-open times on the camera 
look correct.

Original comment by bw_ms...@earthlink.net on 11 Dec 2014 at 5:00