ZWO ASI290 lost connection

253 views
Skip to first unread message

menar...@gmail.com

unread,
Oct 10, 2021, 4:25:21 PM10/10/21
to Open PHD Guiding
I have been using a ZWO ASI290 attached to a Stellarvue SV90 for autoguiding. For the most part this combination has done well.

Lately I noticed that PHD2 reports 'lost connection' and then tries to re-stablish connection. This problem persisted. I tried to disconnect/reconnect the ASI290 but PHD2 continued to report 'lost connection'. The next day I tested the ASI290 and it seemed to work OK. I tried generating a Dark Library and I again got 'lost connection' once. I then just let it run without guiding for over an hour and did not get another 'lost connection' notification.

I am not sure if this is a hardware issue or a bus traffic issue. 

Ant thoughts or suggestions.

Roger

bw_msgboard

unread,
Oct 10, 2021, 5:05:26 PM10/10/21
to open-phd...@googlegroups.com
You should start by making sure you're running the 2.6.10dev2 version of PHD2 and the latest ZWO drivers for your camera.  ZWO keeps making changes in these areas and it's possible your drivers are out of synch with the ZWO library used in PHD2.  Then follow this guide from the trouble-shooting section of the manual:
 

3 - Camera Timeout and Download Problems

In some cases, you may experience problems where guider images are not downloaded or displayed. In extreme cases, this may even cause PHD2 or other camera-related applications to be non-responsive (i.e. to "hang"). This is almost always due to hardware, camera driver, or connectivity issues, with one of the most common culprits being a faulty USB cable or device. It is highly unlikely to be caused by an application like PHD2.

To help detect and work around these kinds of problems, PHD2 uses a camera timeout mechanism. This timeout value is set in the Disconnect nonresponsive camera after (seconds) parameter on the Camera tab of Advanced Settings, and has a default value of 15 seconds. This means that PHD2 will wait up to 15 seconds after the completion of the exposure to receive the image from the camera. This is a very generous amount of time and should work well for most cameras. However, some cameras are known to create problems by making large bandwidth or power demands on the USB subsystem. If you are getting timeouts of this sort and are convinced the camera is working properly, you can increase this timeout value.  Doing so leaves you vulnerable to apparent hangs in the user interface and erratic guiding behavior, but it is a choice you can make for yourself. A larger value for the timeout will not create extra delays during normal camera operations - once the image is downloaded from the camera, the timer is cancelled and guiding will proceed immediately.

If you get camera timeout problems the common sources of the problems are :

  • the USB subsystem on the host computer
  • incompatible USB-2 / USB-3 connections. There are often problems when a USB-2 camera is connected to a USB-3 port on your computer. Those things are supposed to be backward-compatible but that is only at the hardware level and some driver implementations can be adversely affected.
  • damaged or low-quality USB cables
  • flakey camera drivers

So try following this approach :

Start by confirming that the guide camera is basically working. Use a short, direct cable from the camera to the computer and take exposures with the native or test application that came with the camera.

If the camera is functional, you can start looking at the connection hardware - USB hubs and cables. Do not forget that we work in a hostile environment while doing our imaging, and many of the components we use are not designed for cold, outdoor conditions. Something that worked just last week or last month may no longer be reliable.

You will probably need to work through a number of scenarios to see what your problem is. Fortunately, this can usually be done in the daytime by putting the cameras in continuous-exposure mode and letting them run. Start by connecting only the imaging camera and the guiding camera on the USB subsystem as these will be the two heaviest users. There are two areas to look at, power delivery to the cameras and USB traffic and bandwidth :

Your main imaging camera probably has its own power supply but other devices like the guide camera may be powered via the USB cable. If so, you should consider using a powered USB hub to deliver power to the camera. It is also best to use high-quality USB cables with a 24AWG power conductor and eliminate long USB cable runs and USB extenders.  In recent years, poor-quality USB cables have proliferated including those that are shipped with many new guide cameras.

If your problem seems to be with USB traffic, there may be other things you can try :

    • Swap the USB cables, one at a time, to see if you can isolate the problem
    • Make sure your computer is running from AC power and that the OS cannot disable the USB ports for power conservation. In Windows, you can do this in the Device Manager by right clicking on any USB hub or controller, selecting Properties and then the Power Management tab, and unchecking the Allow the computer to turn off the device to save power parameter.  The default settings in current versions of Windows enable this type of power management.
    • Do not run other resource-intensive applications while trying to image
    • Bin the guide camera to reduce the size of the downloaded guider images
    • Adjust the USB usage limit of the camera if the camera driver supports that option
    • Use sub-frames
    • If you are running Windows, you can use a Microsoft tool, USBView, which shows how the various USB ports are tied to the USB controllers in the computer. Then you can try to isolate the two cameras on separate USB buses.
    • Try using a different camera driver (e.g. an ASCOM driver) if one is available

Since your camera may have worked with the native application or a video-streaming application like SharpCap, you may be inclined to think the problem is with PHD2.  That's a mistaken conclusion.  PHD2 uses the guide camera in a single exposure mode, so each exposure involves back-and-forth control traffic between PHD2 and the camera.  That is unlike a streaming application which basically just tells the camera to start streaming data, then tells it to stop sometime later.  The single-exposure mode uses different logic paths in the camera driver software and each control message is vulnerable to timing delays.



From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of menar...@gmail.com
Sent: Sunday, October 10, 2021 1:25 PM
To: Open PHD Guiding
Subject: [open-phd-guiding] ZWO ASI290 lost connection

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/b4fec2a9-2677-484c-8f3b-05ab2b7e0f9en%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages