×

INDI Library v1.9.0 Released (23 Apr 2021)

Major INDI Library release v1.9.0 bring significant internal changes championed by @pawel-soja to modernize core INDI Library drivers and clients. New drivers for DeepSkyDad Flat Panel & Pegasus devices plus further improvements to PCM8 drivers.

QHY5 not found by Ekos

  • Posts: 14
  • Thank you received: 4
I have a similar configuration but not identical. The checks should run fine on Raspbian.

My Configuration (remote server)
QHY5L-II-M
Raspberry Pi 3
Powered Hub
Ubuntu 18.04.2 LTS
indi-qhy/bionic 2.4~201906051400~ubuntu18.04.1 armhf [upgradable from: 2.4~201906030127~ubuntu18.04.1]
indi-qhy-dbg/bionic 2.4~201906051400~ubuntu18.04.1 armhf

On the desktop side, I am running
kstars-bleeding/xenial,now 6:3.2.3+201905220414~ubuntu16.04.1 amd64 [installed]

After camera is plugged in, verify that the LED in back of the camera is lite. If this fails to light, it indicates issues with the camera. Then in a terminal session, type the following command:
lsusb

You should see:
Bus 001 Device 007: ID 1618:0921

The ID is the important part. Now remove the the camera's usb connection and re-run the command "lsusb", the device should now be gone from the list of the devices. If the device fails to show up , verify the usb cabling.

If the device is present, you can dig a little further by using the command:
sudo lsusb -v | grep -A78 1618:0921

You should see the verbose output now. Here is what my output looks like for comparison:
sudo lsusb -v | grep -A78 1618:0921
Bus 001 Device 011: ID 1618:0921
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1618
idProduct 0x0921
bcdDevice 0.00
iManufacturer 1 QHY-CCD
iProduct 2 QHY5-II
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0002
(Bus Powered)
Remote Wakeup Enabled

Review the output from the following command:
dmesg

You should something like:
[ 2028.646670] usb 1-1.5.3: New USB device found, idVendor=1618, idProduct=0921
[ 2028.646682] usb 1-1.5.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2028.646692] usb 1-1.5.3: Product: QHY5-II
[ 2028.646702] usb 1-1.5.3: Manufacturer: QHY-CCD

If you get nothing, test with minimal USB cable length to the camera, replace the USB cable, and check the Pi's Power Supply. You should have at least a 2.5 amp good quality power supply. Also, if you are using a powered hub, I would test with a different power hub. You can test without a powered USB hub, but based on knowing the Raspberry Pi's, I would not recommend directly connecting to the Pi for normal use.

I hope this helps. As stated earlier in this thread, the older QHY5 camera have issues. And the above only pertains to QHY5L-II-M.

Cheers,

Chris
2 years 1 week ago #40121

Please Log in or Create an account to join the conversation.

  • Posts: 52
  • Thank you received: 7

Replied by Guido Muesch on topic QHY5 not found by Ekos

@herrhausen: Thanks for the pictures. Indeed exactly the same interior as the original QHY5. I guess the foam around the sensor is standard? I have seen it before in pictures. However the used QHY5 I bought at an astro fair was missing it.

If somebody has pictures of the interior (PCB) of a QHY5-II, I would be very grateful.
The QHY-5L-II has a different sensor chip (MT9M034), but they operate very similar. So pictures of that one or other variants of the QHY-5-II would be helpful as well.

CS
Guido
2 years 1 week ago #40136

Please Log in or Create an account to join the conversation.

  • Posts: 715
  • Thank you received: 114

Replied by Alfred on topic QHY5 not found by Ekos


I bought mine brand new and never modified it. So yes, the foam is standard at least with this CCD-Labs clone.

From today's perspective the sensor is too small and its noise characteristics are awful. One could add a TEC but then you'd have to add external power, too. It isn't worth it IMO.
Last edit: 2 years 1 week ago by Alfred.
2 years 1 week ago #40144

Please Log in or Create an account to join the conversation.

  • Posts: 52
  • Thank you received: 7

Replied by Guido Muesch on topic QHY5 not found by Ekos

Indeed. But even passive cooling helps a lot. I milled a piece of copper that fits exactly between sensor and the back of the housing. It improved the noise a lot. It is still not quite as good as my selfmade clone, which has seperate digital power supply for USB interface chip and image sensor IC and a better analog power supply. However, even mine still sucks and shows quite some line noise, which seems to be a known issue of the MT9M001 image sensor.

I would not recommend to buy a QHY5 or Starshoot Autoguider (SSAG) nowadays, especially not for use under Linux, because the firmware loaded by Linux has quite some issues. BTW, strangely, the Windows QHY5 driver loads a different firmware into the device.

And why the SSAG is still sold, especially for such a price, is a complete mystery to me.

I want to stress that in my rant I only refer to the original QHY5 and its clones (like SSAG), NOT the later models like QHY-5-II.

CS
Guido
2 years 1 week ago #40157

Please Log in or Create an account to join the conversation.

  • Posts: 52
  • Thank you received: 7

Replied by Guido Muesch on topic QHY5 not found by Ekos

But back to Charles... :-)

Have you tried your QHY-5L-II under Linux without INDI? e.g. use oaCapture (www.openastroproject.org/oacapture/). Same issue on RasPi and desktop?

Out of curiosity: Which other QHY device failed for you under Linux?

Slightly off topic: I am considering buying a ZWO ASI 294mc or a QHY-294c. The ZWO ASI seems to have some background artifact issues (maybe due to uneven cooling). The QHY cooling seems to be differently designed, however I read complaints about the QHY driver quality and I am not sure if the QHY-294c is even supported under INDI/Linux in the momemnt. I already have a ZWO ASI 224mc and this one works flawlessly so far under INDI/Linux.

CS
Guido
2 years 1 week ago #40158

Please Log in or Create an account to join the conversation.

  • Posts: 102
  • Thank you received: 30
FWIW: I am running the latest versions of INDI (Stellarmate OS), Kstars/Ekos and my QHY 5L-II-M is working perfectly with it - just had it running last weekend.
TPO 8" Ritchey-Chretien Astrograph
Moonlite CS focuser with Motor Drive
RoboFocus Auto Focuser
iOptron iEQ45 Pro Mount on Tripier
Stellarrmate OS RPi 4, 4GB
ZWO ASI533MC Pro Main Camera
Meoptex Off Axis Guider
Starlight Xpress Lodestar X2 Guide Camera
Polemaster Polar Alignment Camera
2 years 1 week ago #40161

Please Log in or Create an account to join the conversation.

  • Posts: 94
  • Thank you received: 8
Thanks everyone for the ideas and help. I've managed to get back to this and I believe the issue is something to do with the device id.

First, on my Intel-based PC (Linux Mint 19 based on Ubuntu bionic), lsusb says:
<code>Bus 001 Device 026: ID 1618:0921</code>
Also, I realized I could try the camera under Ekos on this machine, and, Ekos finds it and it works.

But on the Raspberry Pi (Raspbian, "stretch"), its:
<code>Bus 001 Device 005: ID 1618:0920</code>
<strong>0920!</strong> And this is when Ekos can't find the camera.

How does that happen? I thought the USB ID was in the hardware. Is this something to do with different firmware getting loaded on each platform? I built and installed INDI v1.7.8 on both platforms. I'm very confused.

Also, I realize I said earlier that the device IDs were the same on both computers, which I apologize for. Obviously I wasn't paying close enough attention.

RPi kernel info:
<code>
uname -s -o -m -v -r
Linux 4.19.42-v7+ #1219 SMP Tue May 14 21:20:58 BST 2019 armv7l GNU/Linux
</code>
FYI, photo of internals attached.
Ubuntu 18.04 and Raspbian Jessie; INDI 1.7.4
Mounts: CEM-60 chiefly; iEQ45
Cameras: Atik 383L+, QHY5-II-M
Focuser: Moonlite
Last edit: 2 years 1 week ago by Charles Wright.
2 years 1 week ago #40165
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 52
  • Thank you received: 7

Replied by Guido Muesch on topic QHY5 not found by Ekos

FX2 based hardware, like the QHY5 cameras, works like this: When an uninitialized device is connected to USB, the FX2 will read the VID:PID from an I2C EEPROM and use this for USB enumeration (initialization). The Linux udev subsystem will look up this VID:PID and execute the appropriate rules.
These rules can be found in /lib/udev/rules.d/ and in /etc/udev/rules.d/. You should find a file like 85-qhy.rules in one of those directories. In the files you can see which firmware is loaded for which VID:PID combination. After the firmware is loaded the device internally resets and another enumeration takes place with the final VID:PID. Now the USB device is ready to be used.

Therefore I assume that the VID:PID for an unitialized QHY5-II is 1618:0920 and for an initialized device (firmware loaded): 1618:0921.
So that means that something is wrong with the udev mechanism on your Pi. Either the rule is missing or some permission is wrong.

CS
Guido
The following user(s) said Thank You: Charles Wright, Alfred
2 years 1 week ago #40180

Please Log in or Create an account to join the conversation.

  • Posts: 94
  • Thank you received: 8
Thanks Guido, this is very helpful and educational! Will give this a try over the weekend.

Charles
Ubuntu 18.04 and Raspbian Jessie; INDI 1.7.4
Mounts: CEM-60 chiefly; iEQ45
Cameras: Atik 383L+, QHY5-II-M
Focuser: Moonlite
2 years 1 week ago #40183

Please Log in or Create an account to join the conversation.

  • Posts: 52
  • Thank you received: 7

Replied by Guido Muesch on topic QHY5 not found by Ekos

Good Luck Charles!

Run "journalctl -f" in seperate terminal when you plug in/out your QHY-5-II. Probably you can see an error message then. (If Raspbian is not using journalctl, then "tail -f /var/log/messages" or "syslog")

If the same rule file is found in /etc/udev/rules.d and /lib/udev/rules.d then the one in /etc is taken. Packages usually install their rules in /lib/udev/rules.d, which gives the administrator (you) the possibility to overwrite rules in /etc or even disabling them by creating a symlink to /dev/null with the same name in /etc/udev/rules.d

And if everything fails, I would recommend Astroberry, a Linux distribution for the Raspberry 3, based on Ubuntu Mate. That's the nice thing about the Pi: quickly test another OS by just swapping the SD-card.

CS
Guido
The following user(s) said Thank You: Charles Wright
2 years 1 week ago #40187

Please Log in or Create an account to join the conversation.

  • Posts: 385
  • Thank you received: 13

Replied by John Robison on topic QHY5 not found by Ekos

Hello,

I have a QHY-5LII-C. This was working fine. An update to Astroberry and 18.04 occured. Now, I have been chasing my tail thinking BAD USB hubs or worse a dead camera.

QHY-CCD does not see the camera. LSUSB -V enumerate the camera just fine. I have the PoleMaster and that was working fine until the updates. I found that key files specific to the QHYCCD RPI install were overwritten. The PoleMaster PI version now works.

The QHY-CCD QHY5L-II-C does not . EKOS says no cameras found. This thread has identified the source. No chance of EKOS having this back from the looks of this thread. What a waste.

I never did see a completed thread on how to integrate PoleMaster into EKOS. The claim is there. But EKOS is not listing it as an option and QHY for PI is not itegrating the QHY driver into EKOS. Hmm.... To me, EKOS has illiminated the QHY5L-II-C and not by choice. This suggests the QHY5L-II-C dead product line and not RPI friendly. Not even Windows 10 ASCOM likes the product. Oh well.
Last edit: 2 years 1 week ago by John Robison.
2 years 1 week ago #40192

Please Log in or Create an account to join the conversation.

  • Posts: 52
  • Thank you received: 7

Replied by Guido Muesch on topic QHY5 not found by Ekos

I do not think that EKOS is eliminating devices. There is an indi_qhy_ccd driver, which will rely on the QHYCCD proprietary library for communicating to an initialized QHYCCD USB camera.

Multiple things could have gone wrong:
* The device did not get properly initialized. Maybe it was not recognized, or udev failed to load the appropriate firmware.
* The QHYCCD library cannot communicate with the device anymore, because it was obsoleted (might have happened to the original QHY5).
* Something changed in the QHYCCD library and indi-qhy-ccd cannot handle it.

As you are running Astroberry, try oaCapture (without starting INDI at all) and see if it recognizes your QHY-5L-II. I assume it also uses the QHYCCD library, but maybe it uses a different version. At least we would know if the issue is in INDI or already in initializing the device.

CS
Guido
2 years 1 week ago #40211

Please Log in or Create an account to join the conversation.

Time to create page: 1.041 seconds