My new QHY 5-III 200M received today works in SharpCap on Windows with the latest QHY beta driver (it's too new for the stable version).

It does not work in Ekos. Some dmesg lines:

[ 88.004084] usb 2-1: USB disconnect, device number 4
[ 88.088139] usb 1-1.1: USB disconnect, device number 8
[ 88.354541] usb 2-1: new SuperSpeed Gen 1 USB device number 5 using xhci_hcd
[ 88.385083] usb 2-1: LPM exit latency is zeroed, disabling LPM.
[ 88.386109] usb 2-1: New USB device found, idVendor=1618, idProduct=c193, bcdDevice= 0.00
[ 88.386129] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 88.386147] usb 2-1: Product: QHY5III200-20220421
[ 88.386164] usb 2-1: Manufacturer: QHYCCD

The device ID is apparently c193, and it shows up in lsusb (first line):

Bus 002 Device 004: ID 1618:c193
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

My rules.d file has this line for the QHY5II200:

ATTRS{idVendor}=="1618", ATTRS{idProduct}=="0200", RUN+="/sbin/fxload -t fx3 -I /lib/firmware/qhy/QHY5III200.img -D $env{DEVNAME}"

Clearly, it has the wrong device ID 0200 - should be c193. Some basic things work like the number of rows and columns, but not much more.
Any suggestions? Is there a missing driver that I can install?

Thanks in advance!

I may have to take back that device ID of c193. With a new QHYCCD installation lsusb now shows 0200 as it ought to be. The installation is from the QHYCCD pages, I took the 23.05.09 release. I doubt if I am doing it right because, from ldd, indi_qhy_ccd was linked to libqhyccd.so.22 that I don't have. Replacing it with the latest .so from aforementioned release is what I did, and of course that is totally improper. So in Ekos it crashes right away. In the worst case I will hghaev t learn how to build indi_qhy_ccd. I will keep trying.

Hi, I had a similar issue recently with a QHY-600 unttil I understood whats going on there.
When the camera appears the first time on the USB bus and while its not flashed with a firmware yet, it appears as a Cypress WestBridge with the Product ID that is used in the fxload rule.
After its flashed it needs to be powercyled and then appears with its real Product ID and Device Name on the USB bus and should be recognized by indi-drivers.
At the very beginning my fxload failed for some reason and I was totally desperating until i saw the reason in my system logs during startup.

Regarding the libqhy SDK I assume you are on a linux system. I can only recommend to build indilib and 3rd-party drivers completely from source.
Its pretty straightforward on a current linux distribution and the documention on github is excellent.
You just need to meet all requirements exactly and propably have to install a few other src-packages from github beforehand.
I am very happy that I have a extremely well reproducible environment now on my indiserver and don't have to rely on binary distos.

Best regards, Norman

Thanks Norman, I'm following the github instructions right now. I'm building on an Pi4b and there are some issues. It does not build indi_qhy_ccd for me, the main QHY driver component. The error log complains about pthread_join/detach/create symbols missing. With nm I checked that my pthread .so library has them so there is something wrong with the build commands.

There are some other minor problems too but those are easy to work around.

Hi Henk, when I look at my notes I didn't had this problem.
This is my system:

cat /sys/firmware/devicetree/base/model
Raspberry Pi 4 Model B Rev 1.51027

cat /proc/cpuinfo
Hardware : BCM2835
Revision : c03111
Serial : 100000001478c830
Model : Raspberry Pi 4 Model B Rev 1.1

lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye

ldd /usr/local/bin/indi_qhy_ccd | grep pthread
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007fbc82d000)

dpkg -S /lib/aarch64-linux-gnu/libpthread.so.0
libc6:arm64: /lib/aarch64-linux-gnu/libpthread.so.0

and I did the following to install it:

cd ~/src/build/
git clone github.com/lhondareyte/fxload
make install

git clone github.com/indilib/indi-3rdparty
mkdir -p ~/src/build/libqhy
cd ~/src/build/libqhy
cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_BUILD_TYPE=Debug ~/src/build/indi-3rdparty/libqhy
make -j4
make install

mkdir -p ~/src/build/indi-qhy
cd ~/src/build/indi-qhy
cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_BUILD_TYPE=Debug ~/src/build/indi-3rdparty/indi-qhy
make -j4
make install

Hope you get it running, good luck!
Norman

I am on Buster, which is 32-bit armv7l, running Raspbian GNU/Linux 10 while you are on Bullseye 64-bit aarch64, running Debian GNU/Linux 11.

I built all drivers at once so the error I displayed may just have been for the last one built. When following your directions, I got different errors than the one I listed. But first, comparing your system with mine,

---

cat /sys/firmware//devicetree/base/model
Raspberry Pi 4 Model B Rev 1.4

uname -a
Linux astroberry 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linux

cat /proc/cpuinfo
processor : 0 (and 1, 2, 3 ditto - not printed)
model name : ARMv7 Processor rev 3 (v7l)
BogoMIPS : 144.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3

Hardware : BCM2711
Revision : d03114
Serial : 10000000b38d238b
Model : Raspberry Pi 4 Model B Rev 1.4

lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster

dpkg -S /lib/arm-linux-gnueabihf/libpthread.so.0
libc6:armhf: /lib/arm-linux-gnueabihf/libpthread.so.0

---

The error I am getting now is about some C++ math symbols,

---

[100%] Linking CXX executable indi_qhy_ccd
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/8/../../../arm-linux-gnueabihf/libqhyccd.so: undefined reference to `exp@GLIBC_2.29'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/8/../../../arm-linux-gnueabihf/libqhyccd.so: undefined reference to `log@GLIBC_2.29'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/8/../../../arm-linux-gnueabihf/libqhyccd.so: undefined reference to `pow@GLIBC_2.29'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/8/../../../arm-linux-gnueabihf/libqhyccd.so: undefined reference to `std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >::basic_stringstream()@GLIBCXX_3.4.26'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/indi_qhy_ccd.dir/build.make:90: indi_qhy_ccd] Error 1
make[1]: *** [CMakeFiles/Makefile2:134: CMakeFiles/indi_qhy_ccd.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

---

I guess cmake could be made to work if I upgrade to the right toolchain. On the other hand, I just received a brand new Pi4b so I can simply flash that one to the same 64-bit OS that you use and avoid the hassle of figuring this out. But then I won't have the other goodies besides Ekos that come with astroberry that is still on a 32-bit release AFAICT. I don't use most of those goodies though. Mayb I should just bite that bullett.

I take that astroberry 32-bit comment back - I see there is a 64 bit Bullseye release!

Dang, so many things to learn, I take a wrong turn every time. Let me check that out.

Switching from 32-bit Buster to 64-bit Bullseye made all the difference. The library and drivers were all built successfully without errors AFAICT, following the github instructions. I started from a plain Raspbian Bullseye release. The desktop looks a bit emptier than Astroberry. It does not have a network configuration GUI but at least VNC works fine.

I tried using the astroberry instructions for 64 bit, but I could not figure out how to work around an invalid website certificate.

Next, on to the Kstars and Ekos GUIs. Only then will I know if my camera will work - I nearly forgot why I am doing this!

Happy it worked out now and grats for your build!

I don't use a GUI or Kstars on my PI at the telescope because I want all available processing power and network resources for handling the devices and downloads.
I use a dedicated Linux-VM on my Proxmox-Server to run Kstars, MountWizzard and other client-related stuff where I have plenty resources and diskspace.
But I guess its not a big problem to compile Kstars there.

For the network config I leave everything at default and let my DHCP-Server on the router handle it.

I'm pretty sure you won't regret the additional effort going this route

Norman

Building KStars via the github instructions did not work well. It needs apt-get-repository that I don't have and there are no instructions on how to get it. It also requires XISF that was optional so far, and StellarSolver. The prerequisites make it a bit overwhelming.

On the Losmandy Hackers IO board I received a very good tip though. Check out gitea.nouspiro.space/nou/astro-soft-build . It is a build-everything KStars/Ekos/indi/ind3rdparty script that performed flawlessly until my Pi crashed. I'm guessing it got overheated.

I'll restart the Pi and see how far it got then try to resume from there.

The build completed. I can now run KStars/Ekos. The aforementioned script is fantastic (thank you so much!)

I was still unable to use the camera. I realized that I had not run the fxload build/install that is part of the suite. Did that, and wow,

henk@raspberrypi:~ $ lsusb
Bus 002 Device 002: ID 1618:0201 QHYCCD QHY200U3G20-20230106
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Note that the PID is 0201, and not 0200 as rules.d says. I had noticed in Windows' device manager that the PID was 0201 on Windows as well. At least we are consistent now. Note also that the QHYCCD info shows up clearly. I suspect that ZWO changed the PID to 0201 because it upped the version explicitly in the product name "QHY 5-III 200M (Ver. 2)".

Next, running /usr/bin/qhy_video_test works, see the listing below. Basically, it works at a pretty good level!

It still does not work in Ekos though - because its rules.d wants a PID of 0200. I edited 85-qhyccd.rules and changed 0200 to 0201 but this did not work. It made lsusb show 0200 again, and the qhy tests failed. So I reverted back to 0200 and the qhy tests work again. I think I just need a new driver that works with PID 0201. At this point I may ask ZWO for help.

---

henk@raspberrypi:~ $ /usr/bin/qhy_video_test
|QHYCCD|qhyccd.cpp|EnableQHYCCDLogFile start
QHYCCD||EnableQHYCCDMessage| set gl_msgEnable from: 1 to: 0
QHY Video Test using VideoFrameMode, Version: 1.00
SDK resources initialized.
Number of QHYCCD cameras found: 1
Application connected to the following camera from the list: Index: 1, cameraID = QHY5III200M-6aa43543b04c23dba
Open QHYCCD success.
GetQHYCCDOverScanArea:
Overscan Area startX x startY : 0 x 0
Overscan Area sizeX x sizeY : 0 x 0
GetQHYCCDEffectiveArea:
Effective Area startX x startY: 0 x 0
Effective Area sizeX x sizeY : 0 x 0
GetQHYCCDChipInfo:
Effective Area startX x startY: 0 x 0
Chip size width x height : 7.680 x 4.320 [mm]
Pixel size width x height : 4.000 x 4.000 [um]
Image size width x height : 1920 x 1080
This is a mono camera.
SetQHYCCDParam CONTROL_EXPOSURE set to: 1 us, success.
InitQHYCCD success.
SetQHYCCDParam CONTROL_USBTRAFFIC set to: 20, success.
SetQHYCCDParam CONTROL_GAIN set to: 1, success
SetQHYCCDParam CONTROL_GAIN set to: 180, success.
SetQHYCCDResolution roiStartX x roiStartY: 0 x 0
SetQHYCCDResolution roiSizeX x roiSizeY : 1920 x 1080
SetQHYCCDBinMode set to: binX: 1, binY: 1, success.
Allocated memory for frame: 9534400 [uchar].
Press any key to exit...
Frames: 54 Duration: 3.029 seconds FPS: 17.829
Frames: 55 Duration: 3.018 seconds FPS: 18.224
Frames: 55 Duration: 3.014 seconds FPS: 18.245
Frames: 55 Duration: 3.016 seconds FPS: 18.233
Frames: 55 Duration: 3.016 seconds FPS: 18.235
Frames: 55 Duration: 3.016 seconds FPS: 18.234
Frames: 55 Duration: 3.017 seconds FPS: 18.233
Frames: 55 Duration: 3.016 seconds FPS: 18.235
Frames: 55 Duration: 3.018 seconds FPS: 18.222
Frames: 55 Duration: 3.014 seconds FPS: 18.247

Close QHYCCD success.
SDK resources released.

To close this thread, I was eventually able to run the camera. This happened after - at the request of QGYCCD's support - I installed their SDK so I was forced to rebuild from source code afterwards. I can't recall what I did differently, but after that it worked. One possibility is that my first source code build crashed one time and I had to restart it; it continued where it left off, maybe something broke there. It can also be a missed uninstall of the QHYCCD SDK - I can't remember.

I was told that the original PID in dmesg is 0200, afterwards it becomes 0201 (in lsusb for instance).

So, it's a bit of a mystery but it could well be my fault. Thanks for your support.

One very useful link that I found for rebuilding from source code is: gitea.nouspiro.space/nou/astro-soft-build . This builds Ekos and KStars, server and client, all in one go and works great.