I decided to make a new thread about this, but the issue appears in at least two other earlier threads:

indilib.org/forum/ccds-dslrs/6594-qhy294...3-4-0-and-3-4-1.html
indilib.org/forum/ccds-dslrs/8161-indi-d...cd-294-mono-pro.html

I have determined why installing the QHYCCD SDK enables my 294C to be detected and why the INDI packages do not. For reference, I'm using Kubuntu, variously 20.04 or 20.10, depending on the machine, but the same issues appear when using indilib packages only, namely:

• lsusb does not properly identify the camera (it often shows up as 'Cypress WestBridge')
• INDI fails to detect the camera at all

The package libqhy places a dependency on fxload, but the version available in Ubuntu and most other distributions is now a dozen years old. The SDK however has a much more recent fxload, which is included in its own folder named 'fx3load'. The SDK install script actually takes the rather forceful step of replacing the system fxload with its own fxload, while its uninstall script simply deletes it without reinstating the original (!).

What I did today was to uninstall the SDK, reinstall the indilib qhy packages and then manually copy across the SDK fxload to replace the system fxload... and it worked.

Until the various Linux distributions update their included versions of fxload that support the '-fx3' flag, realistically KStars/INDI is going to have to provide the functional binary.

That could be done by:

• replacing fxload
• putting it somewhere else and changing 85-qhyccd.rules to point to it
• giving it another name and changing 85-qhyccd.rules to point to it

This last seems to be the approach taken by the Open Astro Project over at GitHub, where they use the name qhyfxload. He discusses it on the QHYCCD Forum:
www.qhyccd.com/bbs/index.php?topic=7459.0

And you can find the repository at GitHub:
github.com/openastroproject/libqhyccd-pkg

Note that the Open Astro Project is another voluntary project; this is not an official QHY creation and it seems that his hope of some of his changes making their way back to the SDK are likely in vain.

Sadly, I haven't been able to use his scripts to create the tar file needed to create the .deb packages as the script hangs on a version name of a library.


At the user level, as a temporary workaround to get your QHYCCD USB3 camera working, you'll need to do what I did:

1. Download the SDK - probably Linux_64 for most users - from the QHYCCD website here: www.qhyccd.com/html/prepub/log_en.html
2. Extract the contents of the archive
3. From a console, change to the top level directory of the extracted archive:

   $ cd /path_to/sdk_linux64_<version>

4. Backup your original fxload:

   $ sudo cp /sbin/fxload fxload.orig

5. Copy the new fxload across:

   $ sudo cp -a sbin/fxload /sbin/fxload

6. Now plug in your camera to a USB3 port and see if it's identified properly:

   $ lsusb

If it is, and barring any other problems, you should now have access to your QHYCCD USB3 camera in Ekos.

Thank you. I confirm that this fix is still needed and still works with:
- Kubuntu 22.04
- KStars 3.6.7
- Indi 2.0.4
- QHY SDK version sdk_linux64_23.10.11
- QHY 163M and 163C connected with USB 3.0

Hi,
is anybody getting higher download rates than 400Mb/s (mega bit per second) with a QHY533/268/600 USB3 connected camera?
I do not get below 2.5 seconds for a download of a 120MB image from a QHY600. (120MB/2.5s = 48MB/s = 384Mb/s)
I'm using Raspberry Pi 4B and 5 with INDI, both are showing same rates regardless if connecting to USB2 or USB3.
With a USB Stick connected to USB3 I can reach much higher rates, so USB3 at the Raspberries is generelly working.
QHY SDK version sdk_linux64_23.10.11 installed.

Thanks and Regards,
Detlef