Hi all,

on my Raspberry 2 I've installed the INDI library and now I'd like to use both my QHY cameras, one for guiding (QHY5) and the other (QHY8L) for imaging.
I've noticed that when I use both cameras with the INDI driver, during the image download from the QHY8L the other QHY5 camera times out and the client (PHD2) puts it offline.
This doesn't happen if I use, for example, the QHY8L with the INDI driver and the QHY5 with PHD2 own driver.
Are there any known issues with using two cameras with the same driver?

Thank you.
Piero

Yes this was reported before. We can't do much you have to ask QHY for support.

Ok, I'll try.
So, even though the problem pops up only with the INDI driver you can exclude that it depends on it?

Thank you.
Piero

The problem is in the binary portion of the indi driver for the qhy. Not possible for us to fix it if it's in a binary blob that came from the vendor.

I have contemplated re-visiting the older qhy5 driver, and bring it back as a separate driver, that doesn't depend on the qhy binaries. At least then it would be possible to run two of them, as long as one is a qhy5.

Ok I see, now it's clear.
Having a separate qhy5 driver would be great, at least for me
Thanks a lot for the explanation.

I encountered the same problem using a QHY6 and a QHY5L II in a simultaneous setup. However I considered this to be an USB problem. At that time I was lucky to have access to a DMK21AF. that substituted the QHY6.
Now I want to return to the QHY6 for first tests in long focus (>3000mm) planetary nebula photography mainly for checking if this can be done at all with my equipment. The QHY5 will be used for guiding.
So, if there is some testing to be done I would like to join in.
CS
Michael

Our experience with the qhy5 is, it runs well, once it's set up properly. BUT, and this is a big BUT, it does NOT share well on the usb, and it requires FULL power from a usb port. If you plug it into a hub, and have something else in that same hub, it likely will cause problems unless you can confirm the hub delivers a full 500ma to each and every port (most dont). It also does NOT play well when other devices are using the bus. Our simple solution to that a few years ago, using a fully home grown custom software stack, ensure that we stop taking frames from the qhy5 during download of image from the main camera. That allowed us to use the camera plugged into a hub at the far end of a long active usb connection set. Without that work-around in software, it was pretty much a requirement to have the qhy5 in it's own usb port, on a completely separate usb run from other cameras. FYI, we went thru 5 different 7 port hubs till we found one that worked well with all the gear.

For the observatory build, I think I'm going to take a completely different strategy. Both telescopes will have a qhy5 mounted in a 9x50 to use as an electronic finder. I will probably mount a raspberry pi right on the telescope beside the finder, and plug the qhy5 into that. We will run an ethernet cable to the pi, and it'll have the facility to remotely power cycle that piece all on it's own. That ensures if we do run into issues during a run, it's possible to just power cycle the whole subsystem without actually walking out to the observatory, and do so without affecting the mount and other things running. if we use a couple of injector plugs at both ends of the ethernet run, it's possible to do the whole thing on a single cable, getting 100mbit ethernet and a couple amps of 5V on one cable for the pi. At that point, we just treat the pi+qhy5 combination as an ethernet attach camera.

I really like the large field we get using the qhy5 in a 9x50, but, I'm not fond of the finnicky nature of that camera and it's usb implementation. Having it isolated on it's own power and usb will guarantee it doesn't cause issues for the rest of the system.

Looks like we have made the same experience. I tried three different hubs, two of them separately powered, with no avail.
Aiming at a remote controlled observatory (actually my 3mx3,5m roll off roof hut is just 10 m from the door to the garden ) I some time ago acquired a used PC with an Intel i5 cpu and 8 USB ports and set it up next to the telescope plugging (almost) all devices directly into the PC USB ports. Monitor, keyboard and pointing device are connected via 5m cables. Keyboard and pointing device are plugged in an (powered) USB hub. There an USB stick could be added for a local download, but mainly the Ethernet connection is used as well as for remote control. I don't have any USB Problems any more.
.
From what I read in this forum in the meantime (about using a RasPi2 for control) I think this is an overkill.
Besides, and this occurred to me only after the purchase of the PC, the USB ports on the mainboard might principally have similar power problems if not properly designed. So mine might not necessarily be a reasonably solution for the USB problem.

PS: What focal length does Your 9x50 have?
I'm presently also working on an electronic finder, but intend to use an old 80mm Lumicon Super finder (f=~300mm). The FOV will be much smaller than with a visual finder, but I will rather use the finder (and astrometry) to initially sync the mount after leaving the parking position.

I have used the qhy5 in the 9x50 a lot. It's got 175mm focal length, gives us a field of 130x104 arcminutes, resolution 6.08 arcseconds per pixel. There are very few spots in the sky where that doesn't have enough stars clearly visible to do a very quick plate solution.

Having the pi separate for the qhy may be overkill to some extent, but, there are other reasons as well. I have another little gadget, 3 axis accelerometer, that will also be interfaced to the pi. The purpose of that one, is to give us a reading of mount direction that's totally independant of the mount motors. It will be used as a confirmation of park position, before roof is closed. So, in order for the roof to close, both the mount, and the accelerometers must agree, telescope is pointed at the horizon, and clear of the roof travel area. The pi was originally going to be just for the accelerometers, so that the confirm park data comes from a completely separate and independant source.

Some would say it's overkill, but, the first time things get confused, and we need a 'second opinion' of where the telescope is really pointed, it will pay for itself.

As to the usb hubs, here is what I figured out over time. We needed a 7 port hub, to many devices for a 4 port. Most of the powered 7 port hubs come with a 2 or 2.5 amp power supply, and they dont manage power intelligently, they just allocate 1/7 of the supply to each port, so, they cant actually power a device that needs the full 500ma that should be available at a usb port. I stumbled on one hub that came with a 3.5 amp supply, bought it, and voila, finally the camera ran ok, but we still had problems if the qhy5 was delivering data at the same time we were fetching data from another camera over that usb run. The solution was, only ever fetch data from one camera at a time. Once we got that figured out, it ran fine.

I've only recently got the astro gear out again, starting flesh out the systems for the observatory when it's built, which is planned for next spring. It will be remote, a little over 400 feet from the house, so, I want my systems reliable by the time we set them up out there.

Gentlemen, I would suggest you pause guiding during downloads. When downloading a large image file it chocks the overall bandwidth to the USB. Not just the powered hub, but what ever processor you are using. There are two hubs in every connection.... Bruce

In my case, as mentioned by knro and gerryr, it seems to be a QHY driver problem more than a USB bottleneck.
Apparently the QHY binary blob doesn't cope well with multiple simultaneous connections.
If I use two different drivers for the two cameras (all hardware remains the same), no hiccups occur and the guiding keeps running smoothly even during image downloads.
For now I'll stick with two different drivers.

Thank you.
Piero

How about port QHY5/QHY52 driver from Lin_guider for an indi qhy guiding driver and let the main camera still use QHY's official driver ?