QHY5L-ii - "camera timeout during capture"

[alvaro cruz-cabrera]

Hello,

I just started getting "camera timeout during capture" with PHD 2.4, and PHD 2.5
It sometimes can happen in a couple of minutes, sometimes in an hour.
Last night I was using the latest PHD 2.4 and it was timing out.  Noticed that the new PHD 2.5 was available and downloaded that version and still got the same problem.
This morning I changed the drivers for the QHY5L-ii from the compatibility version to the performance version (after uninstalling the old one), and got the disconnected in 75 minutes.
, in this case I was not guiding for the lack of stars

This is my setup:
Using laptop Dell and connecting directly to the USB port.
Windows vista - my wife old computer.


These are some of the lines from the log - both logs are from PHD2.5:

 Last night trying to guide
==============================================================
03:08:13.406 06.122 4720 Alert: Camera timeout during capture
The camera has been disconnected. Please resolve the problem and re-connect the camera.
03:08:13.407 00.001 4436 Error thrown from worker_thread.cpp:152->Capture failed
03:08:13.407 00.000 4436 worker thread done servicing request
03:08:13.702 00.295 4720 Resizing image to 833,625
03:08:13.757 00.055 4720 Processing an image
03:08:13.757 00.000 4720 StopCapturing CaptureActive=1 continueCapturing=1 exposurePending=0
03:08:13.758 00.001 4720 Status Line 0: Waiting for devices...
03:08:13.759 00.001 4720 Changing from state 6 to 7
03:08:13.760 00.001 4720 Guider::SetState: clearing mount guide algorithm history
03:08:13.760 00.000 4720 UpdateImageDisplay: Size=(1280,960) min=53, max=121, FiltMin=57, FiltMax=117
03:08:14.058 00.298 4720 Resizing image to 833,625
03:08:14.112 00.054 4720 setting force full frames = true
03:08:14.112 00.000 4720 Status Line 0: Stopped.
03:08:14.114 00.002 4720 Changing from state 2 to 0
03:08:14.361 00.247 4720 Resizing image to 833,625
03:08:14.413 00.052 4720 Status Line 0: Stopped.
03:08:14.413 00.000 4720 OnExposeComplete(): Capture Error reported
03:08:14.413 00.000 4720 Status Line 2:
03:08:14.414 00.001 4720 Error thrown from myframe_events.cpp:378->Error reported capturing image



Around Noon after changing the drives
=====================================
12:05:08.961 00.001 4104 Alert: Camera timeout during capture
The camera has been disconnected. Please resolve the problem and re-connect the camera.
12:05:09.238 00.277 4104 Resizing image to 833,625
12:05:09.283 00.045 4104 Processing an image
12:05:09.283 00.000 4104 StopCapturing CaptureActive=1 continueCapturing=1 exposurePending=0
12:05:09.283 00.000 4104 Status Line 0: Waiting for devices...
12:05:09.284 00.001 4104 setting force full frames = true
12:05:09.284 00.000 4104 Status Line 0: Stopped.
12:05:09.284 00.000 4104 Changing from state 1 to 0
12:05:09.284 00.000 4104 Status Line 0: Stopped.
12:05:09.285 00.001 4104 OnExposeComplete(): Capture Error reported
12:05:09.285 00.000 4104 Status Line 2:
12:05:09.285 00.000 4104 Error thrown from myframe_events.cpp:378->Error reported capturing image
12:05:09.452 00.167 4104 Resizing image to 833,625
12:14:12.716 543.264 4104 Resizing image to 889,667
12:14:16.102 03.386 4104 Resizing image to 889,667
12:14:17.011 00.909 4104 Status Line 0: Connecting to Camera ...
12:14:17.806 00.795 4104 Connected Camera:QHY 5L-II Mono
12:14:17.807 00.001 4104 FullSize=(1280,960)
12:14:17.807 00.000 4104 HasGainControl=1
12:14:17.807 00.000 4104 GuideCameraGain=95
12:14:17.807 00.000 4104 HasShutter=0
12:14:17.808 00.001 4104 HasSubFrames=0
12:14:17.808 00.000 4104 ST4HasGuideOutput=1
12:14:17.808 00.000 4104 GetBoolean("/profile/2/camera/AutoLoadDefectMap", 1) returns 0
12:14:17.809 00.001 4104 GetBoolean("/profile/2/camera/AutoLoadDarks", 1) returns 1
12:14:17.809 00.000 4104 Auto-loading dark library
12:14:17.830 00.021 4104 loaded dark frame exposure = 8
12:14:17.846 00.016 4104 loaded dark frame exposure = 8
12:14:17.863 00.017 4104 loaded dark frame exposure = 9
12:14:17.879 00.016 4104 loaded dark frame exposure = 17
12:14:17.895 00.016 4104 loaded dark frame exposure = 17
12:14:17.912 00.017 4104 loaded dark frame exposure = 18
12:14:17.922 00.010 4104 loaded dark frame exposure = 19
12:14:17.929 00.007 4104 loaded dark frame exposure = 50
12:14:17.936 00.007 4104 loaded dark frame exposure = 100
12:14:17.944 00.008 4104 loaded dark frame exposure = 200
12:14:17.951 00.007 4104 loaded dark frame exposure = 500
12:14:17.959 00.008 4104 loaded dark frame exposure = 1000
12:14:17.965 00.006 4104 loaded dark frame exposure = 1500
12:14:17.972 00.007 4104 loaded dark frame exposure = 2000
12:14:17.979 00.007 4104 loaded dark frame exposure = 2500
12:14:17.986 00.007 4104 loaded dark frame exposure = 3000
12:14:17.993 00.007 4104 loaded dark frame exposure = 3500
12:14:18.000 00.007 4104 loaded dark frame exposure = 4000
12:14:18.001 00.001 4104 loaded dark library from C:\Users\Theresa Cruz\AppData\Local\phd2\darks_defects\PHD2_dark_lib_2.fit
12:14:18.001 00.000 4104 Status Line 0: Darks loaded
12:14:18.005 00.004 4104 Status Line 0: Camera Connected
12:14:18.005 00.000 4104 Status Line 2: Camera
12:14:18.145 00.140 4104 Resizing image to 889,667
12:14:18.769 00.624 4104 Resizing image to 889,667
12:14:24.298 05.529 4104 Resizing image to 889,667
12:14:28.563 04.265 4104 GetBoolean("/profile/2/target/refCircleEnabled", 0) returns 0
12:14:28.564 00.001 4104 GetDouble("/profile/2/target/refCircleRadius", 2.000000) returns 2.000000
12:14:28.807 00.243 4104 Resizing image to 889,667
12:16:18.021 109.214 4104 GetBoolean("/profile/2/target/refCircleEnabled", 0) returns 0
12:16:18.022 00.001 4104 GetDouble("/profile/2/target/refCircleRadius", 2.000000) returns 2.000000
12:16:21.292 03.270 4104 Resizing image to 889,667
12:16:21.773 00.481 4104 Resizing image to 889,667
12:16:21.948 00.175 4104 Resizing image to 889,667
12:16:23.980 02.032 4104 Throw from gear_dialog.cpp:1146->OnButtonDisconnectScope: called when not connected
12:16:23.981 00.001 4104 Error thrown from gear_dialog.cpp:1172->OnButtonDisconnectAuxScope called with m_pAuxScope == NULL
12:16:24.082 00.101 4104 Status Line 0: Camera Disconnected
12:16:24.082 00.000 4104 Status Line 2:
12:16:24.084 00.002 4104 Error thrown from gear_dialog.cpp:1298->OnButtonDisconnectStepGuider called with m_pStepGuider == NULL
12:16:24.085 00.001 4104 Error thrown from gear_dialog.cpp:1412->OnButtonDisconnectRotator called with m_pRotator == NULL
12:16:24.528 00.443 4104 Resizing image to 889,667
12:16:26.918 02.390 4104 Resizing image to 889,667
12:16:27.783 00.865 4104 Resizing image to 889,667
12:16:30.555 02.772 4104 GetInt("/wxLanguage", 0) returns 0
12:16:37.572 07.017 4104 User exited setup dialog with 'cancel'
12:16:38.980 01.408 4104 GetBoolean("/profile/2/target/refCircleEnabled", 0) returns 0
12:16:38.980 00.000 4104 GetDouble("/profile/2/target/refCircleRadius", 2.000000) returns 2.000000
12:16:39.211 00.231 4104 Resizing image to 889,667
12:16:40.931 01.720 4104 StopCapturing CaptureActive=0 continueCapturing=0 exposurePending=0
12:16:40.932 00.001 4104 StopWorkerThread(0x002C1270) begins
12:16:40.932 00.000 1920 Worker thread wakes up
12:16:40.932 00.000 1920 worker thread servicing REQUEST_TERMINATE
12:16:40.932 00.000 1920 worker thread done servicing request
12:16:40.933 00.001 1920 WorkerThread::Entry() ends
12:16:40.933 00.000 4104 StopWorkerThread() threadExitCode=0
12:16:40.934 00.001 4104 StopWorkerThread(0x002C1270) ends
12:16:40.934 00.000 4104 WorkerThread destructor called
12:16:40.934 00.000 4104 StopWorkerThread(0x002C2560) begins
12:16:40.935 00.001 5840 Worker thread wakes up
12:16:40.935 00.000 5840 worker thread servicing REQUEST_TERMINATE
12:16:40.935 00.000 5840 worker thread done servicing request
12:16:40.935 00.000 5840 WorkerThread::Entry() ends
12:16:40.936 00.001 4104 StopWorkerThread() threadExitCode=0
12:16:40.936 00.000 4104 StopWorkerThread(0x002C2560) ends
12:16:40.936 00.000 4104 WorkerThread destructor called
12:16:40.936 00.000 4104 Shutdown: forced=0
12:16:40.937 00.001 4104 Shutdown complete
12:16:40.937 00.000 4104 Server stopped
12:16:40.937 00.000 4104 event server stopped
12:16:40.938 00.001 4104 Status Line 0: Server stopped


Thanks.

Alvaro

[bw_msgboard]

Hi Alvaro.  I think you already know what’s going on – the camera is not downloading an image in the expected time.  You can change the timeout interval on the ‘Camera’ tab of the advanced settings dialog.  The default setting is 5 seconds.  That means PHD2 starts the exposure, waits for the exposure time you have specified, and then waits for up to another 5 seconds to get the image.  You can try increasing this number to see if it helps.  Normally, this problem is caused by a problem in the USB subsystem - often a USB cable - or sometimes a problem in the camera itself.  The only reason we have the timeout logic is to alert you of a problem with the camera – in the past, this would have resulted in a “hang” of the application.

 

Good luck.

Bruce

 

---

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[alvaro cruz-cabrera]

Bruce,


As we speak, I just increased the timeout time to 65 seconds (don't ask me why :-) ) but it is hanging at about 75 minutes.  I'll keep you posted of what happens later.

Alvaro

[alvaro cruz-cabrera]

Bruce,

I just realized a question, which I think I know the answer.  Does PHD2 uses the camera driver already installed in the computer, or does install its own camera driver?


Thanks

[bw_msgboard]

It’s a mixed bag and depends on how the vendor has implemented the driver.  Some of them are redistributed with the PHD2 release and will reside in the same directory as phd2.exe.  But this isn’t true in a variety of cases, for example when the camera uses an ASCOM or video-standard interface or when the vendor has some other mechanism for the system to locate its driver.  And that assumes you’re running Windows, I have no idea what happens on the Mac or Unix platforms.  That said, I haven’t done a camera driver interface in PHD2, so Andy or someone else will have to correct me if I’m wrong…

 

---

--

[bw_msgboard]

I have seen some discussion on other forums indicating the QHY5 family of cameras can be very consumptive of USB resources, especially at high frame rates.  If your failures are so intermittent, perhaps they’re caused by contention with another device on the USB subsystem.  Just a thought…

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of alvaro cruz-cabrera
Sent: Sunday, April 19, 2015 3:34 PM
To: open-phd...@googlegroups.com
Subject: Re: QHY5L-ii - "camera timeout during capture"

 

Bruce,

--

[Rob Cormack]

I have to agree with and support what Bruce stated. Its not a PHD problem and its not uncommon with the QHY guide cameras. For some reason the exposures take longer than requested and sometimes do not terminate. The problem appears to be related to the camera cable not being plugged  firmly into both the usb port and camera. Try  re plugging the cable or use another usb port.. I have the PHD2 source and put some timing stats in the PHD2 code for my QHY5L-II.  The round trip time to get an image for a 1 second exposure is typically 1.28 seconds but I have seen this blow out to 3 or 4 seconds for no apparent reason. 

                 Rob 

  

[bw_msgboard]

Wow, this is good information for us to have.  We’re usually flying blind with these sorts of problems because we typically don’t have the camera in question.  Thanks a lot for the post.

 

Bruce

 

 

---

From: Rob Cormack [mailto:kar...@bigpond.com]
Sent: Monday, April 20, 2015 2:12 AM
To: open-phd...@googlegroups.com
Cc: aacc...@gmail.com; bw_m...@earthlink.net
Subject: Re: QHY5L-ii - "camera timeout during capture"

 

 

I have to agree with and support what Bruce stated. Its not a PHD problem and its not uncommon with the QHY guide cameras. For some reason the exposures take longer than requested and sometimes do not terminate. The problem appears to be related to the camera cable not being plugged  firmly into both the usb port and camera. Try  re plugging the cable or use another usb port.. I have the PHD2 source and put some timing stats in the PHD2 code for my QHY5L-II.  The round trip time to get an image for a 1 second exposure is typically 1.28 seconds but I have seen this blow out to 3 or 4 seconds for no apparent reason. 

 

                 Rob 

 

  

[alvaro cruz-cabrera]

Ok, I have several data points:

1- I did try the changing the cable and the port, but I got the same result.
2- From other sources I had found out that the QHY5L-II software is a bit finicky about the USB power setting  ( http://www.cloudynights.com/topic/488345-qhy5lii-stop-working-due-to-usb-suspend/ )
This is a tricky thing because it depends on the computer brand, type and OS - in my case is VISTA and a Dell).  The point here is that it seems that if you have a laptop; The USB ports will have a power policy related to the use of batteries.  This should not affect you    in most cases is you are plug.  In my case my power cord has been bugging and it is not charging the battery.  It does not let the battery discharge, but it sets a new power management on the laptop, and from reading the exchange in the link, it makes me think that this is my problem.  It seems that the drivers for the QHY5L-II are not up to snuff for this kind of applications.


Any way, I am trying another power source that does not allow the battery only policy and see if the camera dies on me.

Alvaro

[alvaro cruz-cabrera]

Hello, and continuing with this problem fix:

I started noticing that my guiding was failing (maybe it has been failing for while and I had not notice it).  The cause: the guiding camera (QHY5L-II) disconnects from PHD2.   After switching around: ports, USB cables, drivers and PHD versions.

I found out that if:

-I connect my ASI120 MC to PHD2 in that laptop, there is no disconnect.  But the ASI is a bit heavy and cumbersome for my setup to work.

-I connect the QHY5L-II to my desktop (which is a behemont), and it seems to work ok.

Important note my AP computer is an at least 7 year old DELL Studio, with windows vista 32 bits, 4GB of memory, and 320 Gb of hard drive, CPU Core 2 Duo. 4 USB ports

My thinking seems to point out that there is not a good reaction between PHD2, QHY5L, laptop (USB power settings are optimized for laptop no matter how you tweak them), and windows Vista.

So, I found that I can get a Dell Inspiron $200, brand new Celeron Dual Core, 4GB Ram, 500GB Hard Drive, and at least 6 USB ports (2 of them I think are USB3). WIndows 8.1.

It would be a desktop (so I have to move two more pieces: a Screen which is slightly bigger and a keyboard), that will not have the USB policies of a laptop, windows 8.1 (better USB management).  All the USB ports can be oriented in the same direction, and I could Isolate the QHY5L-II to the USB3 ports.  And, I have to move the setup to my backyard, so it is not that bad.

The other option, is to get a better guding camera (lodestar $500,  lodestar X2 $600, SBIG $500) and consider the QHY5L as a loss for guiding, so it is about $300 (QHY)+$500(New Camera) = $800

With the new computer the total cost is: $300(QHY)+$200(New Computer)= $500.

Is there another option?  BTW: I am using an OAG for guiding, so the camera should be sensitive, that is why I went for the QHY.

Thanks

Alvaro

[aaron craig]

Alvaro, I had the same problem with 2.4x and 2.5 and my qhy5l-ii m.

My solution has been to revert back to 2.3x. This problem only came about with 2.4.

[bw_msgboard]

I'm sorry, but I think this is bad advice. The camera/USB behavior is the
underlying issue here, not the software. The only thing that changed in
PHD2 was the timeout mechanism, which we have already discussed. You can
set the timeout value as high as you want in PHD2 and thus achieve the same
behavior you would see in the earlier releases.

Bruce

-----Original Message-----
From: open-phd...@googlegroups.com
[mailto:open-phd...@googlegroups.com] On Behalf Of aaron craig
Sent: Thursday, April 23, 2015 7:17 AM
To: open-phd...@googlegroups.com
Subject: Re: QHY5L-ii - "camera timeout during capture"

[aaron craig]

In theory this is how it may work, but in practice setting the time out value higher (I had mine at 30) had no effect on the camera timing out.

Yet in 2.3 with global default values from install I guide all night with out any problem.

I think there is some underlying incompatibility with 2.4+ and qhy5l-ii drivers. As stated before this wasn't a problem with 2.3 and I know other users of the qhy5l-ii are in the same boat as I because the downgrade to 2.3 and guiding reliably is far greater than any new implementations in 2.4+ and having to babysit PhD.

An additional note: I also run an asi120mm and have zero problems which used the same sensor/hardware as Qhy5l-ii. However its puck shape discludes it from being used with my OAG.

[Andy Galasso]

Aaron,

The more likely explanation is that sometimes your camera stalls for more than 30 seconds just as Alvaro's does.  2.3 does not detect these stalls, but 2.4+ does.  If it were me I would want to know about the stalls, but if you prefer to overlook them you can set the timeout to a very high value, like 99999 seconds.

We don't need to speculate; we can look at your 2.3 debug log to see if the stalls are present.

Andy

[aaron craig]

I will post my 2.3 log when I get home.

[alvaro cruz-cabrera]

Well.  I have tried some things, and this is what I found:

• It works with my desktop which runs win 7
• I went looking for extra copies of the QHY drivers in my laptop, and only managed to find the one I had intended (the high performance) and the planetary application.  I got rid of both of them and try the camera without the computer recognizing it.  I installed the compatibility driver and I am testing as we speak.
• I do have to say that the camera will be stable for a couple of hour with it being the only one connecting to all the USB hubs, and it disconnect in couple of hours, and will disconnect  in 8 minutes when imaging.  As a reference the ASI120MC did not disconnect  from the laptop, and the QHY did not disconnect from the desktop.  In other words in my setup QHY5L will disconnect even if it is by itself
• Some people suggested getting a powered USB hub, in this case I wonder if this is related to the power in any of the two hubs of the computer (see previous bullet), but if it is a communications issue, I am not sure a hub will help.

 

That leaves me:

-Operating system (Vista, we all suspect it).

-Hardware (computer is 8 years old), and being an 8 year old laptop at the same time.

-Combination of the two

 So how easy is to get Windows 7 installed on that computer?  or just look for new computer hardware?

 

Alvaro

[aaron craig]

Debug log from 2.3.1o attached

[aaron craig]

And the associated guide log

I run a Win 8.1 64bit laptop purchased in Nov. 2013

[Andy Galasso]

Thanks Aaron.  There is no sign of any camera hang at all in that debug log. The 1.5s exposures always completed in 1.7s or less.

FWIW I did go back and look at all the the code changes in PHD2 for the QHY 5L-II camera between 2.3.1 and 2.5.0 and confirmed that the only difference is that the newer code checks for the timeout condition while waiting for the image to complete. Both versions check for image completion every 100ms; the old version keeps checking forever; the new code stop and aborts if the timeout is reached. No other differences.

Andy

[aaron craig]

Here are three sets of logs from 2.5.0 pre release. One with a 5 sec timeout and the other with a 30 sec timeout and the other as my first attempt with 2.5

[Andy Galasso]

Thanks, Aaron.  I see timeouts in two of those three logs (the two from 3/31, but not the one from 3/30). Are we confident that when you ran those attempts back on 3/31 everything was exactly the same conditions as on 3/30 and 4/19 when you did not see the timeouts?  Shane has pointed out that the timeouts can be sensitive to seemingly inconsequential things like which port the camera is plugged in to and what other USB traffic is present.

We have been hearing of the QHY5LII lockups since before the v2.4.0 timeout change was made. I first heard of the problem last October from Shane at the SWAP conference. In fact, the reason we added the timeout detection in 2.4.0 was to prevent phd2 from hanging indefinitely when cameras are hung.

If we are going to pursue the idea of a difference between 2.3.x and 2.5.0 then we need to do some carefully controlled experiments.  For example, to start: leave the camera running looping exposures with v2.5.0 with the timeout limit set to 99999; loop for, say, 30 minutes. Then, switch to 2.3.x and loop for another 30 minutes at the same exposure duration. Then we can compare the 2 debug logs and see if the camera responded differently. I'm not yet convinced this is a productive effort. But if you want to run more experiments I don't mind helping look at the debug logs.

Andy

[aaron craig]

Will do and get back to you on.

--
You received this message because you are subscribed to a topic in the Google Groups "Open PHD Guiding" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/open-phd-guiding/9m1Xo6UMhkI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to open-phd-guidi...@googlegroups.com.

[aaron craig]

As for the conditions the 4 logs were produced with, exact same. 95% confidence. Can you tell if I was using the st-4 port? I think I had stopped using it by then.

Qhy5l-ii using its gray stock USB cable plugged into the same (marked) port of a powered USB 3.0 hub which then goes in to the same USB 3.0 port in my laptop (I use the same ports to avoid Windows switching around the com ports numbers for my serial port adapters).

After timing out multiple times I tried plugging it straight into the laptop but still had time outs.

Tonight I will set up some controlled conditions indoor with looping mode ( plugged straight into laptop, plugged into hub, etc.) to see if I can reproduce the time outs.

I wonder if th

[aaron craig]

I wonder if the problem doesn't lay within the timeout detection. Is there a way to remove that piece of code for qhy5l-ii cameras to test it with?

[Andy Galasso]

setting the timeout to a very high number like 99999 effectively removes it.

[aaron craig]

Andy,

Last night I started testing. This may take a while as there are many variables to account for. The control (as done last night) is as such:

Hardware:
QHY5L-II-M
Generic (NON-QHY) 6ft USB 2.0 A to B Cable
Lenovo G500 Windows 8.1 64bit Laptop (i3-3120M 2.5 GHz, 8 GB ram)

Direct connection to Laptop via USB 3.0 port

Software:
Windows 8.1 64bit
QHY Driver ver14-12-12 (QHY Ascom v11 is present but not used)
Fresh install of PhD 2.5.0 (Camera Disconnect @ 5 Seconds / Camera Gain @ 95)
Celestron NexRemote PC software control v1.7.22 (Virtual Com Port Com1) - aligned (actual mount not connected)

I looped exposures for frame and focus for an hour straight. No timeouts. I was able to cause a timeout prior when messing around with the Mount PC software and PhD mount connection.

This may be something that requires actual mount interaction.

The second, third and fourth tests will introduce a new constants with each.
Second test will replace the generic usb cable with the one supplied by QHY.
Third test will introduce a 4 port USB 3.0 hub (unpowered) connected to the PC with a 3ft USB 3.0 cable and another 6ft USB 3.0 Male to Female extension.
Fourth test will power the hub.

If no timeouts occur by looping. The next test will be to reproduce tests 1-4 while guiding the mount, which adds two new constants guide star being selected/tracked and communication with the mount. Hopefully, there will be no timeouts to report.

[Colm Brazel]

Hi,

I've just been troubleshooting similar problem with PHD2.5 dropping and losing its connection to my Orion G3 monochrome camera.

Reading through above I've good and bad news. Good news is problem is fixed by me changing the timeout camera disconnect non responsive setting to 9999 suggested by Andy above.

I did try raising default 5 value initially to 8+ and even higher that allowed low number exposures to be taken but even then there were further problems eg trying to disconnect camera got message, 'waiting for devices'

No time to experiment around different exposure times to analyse results.

However, I can confirm setting to 9999 has fixed my camera and it now disconnects immediately I need it too.

So, I would suggest users just set default to 9999 and be done with it.

PHD2.5 might consider suggesting users set default to 9999 as well until connection problems such as the above can be solved some other way.

Cheers,

Colm

[Andy Galasso]

On Thu, Aug 20, 2015 at 12:12 PM, Colm Brazel <colmb...@gmail.com> wrote:

I would suggest users just set default to 9999 and be done with it.

Colm,

I'm glad that increasing the timeout worked for you but I would not necessarily agree with the blanket recommendation to increase the timeout to a large value like 9999.

The timeout value is how long PHD2 will wait after an exposure is expected to complete.  If PHD2 starts a 2 second exposure and the timeout is 5 seconds, then phd2 times-out after 7 seconds. Most guide cameras finish their exposure within a fraction of a second of the requested duration, so a failure to complete the exposure after an additional 5 seconds is a pretty good indication that something is wrong.

If your camera is not completing a 2 second exposure in 10 seconds or longer, (2 sec + 8 sec timeout) then this is probably going to affect your guiding.   Chances are your mount's PE varies considerably over 10 seconds or more and failing to send guide corrections (because the camera is not giving us frames) will show up as star elongation in RA in your image subs.

If your photos are unaffected, then increasing the timeout is a perfectly valid solution.  In other cases, you may be better off finding the root cause of the timeouts.

Andy