×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

QHY5 not found by Ekos

  • Posts: 94
  • Thank you received: 8
Well for me, I am not using a clone, I'm using a real off-the-shelf QHY device I won in a raffle at NEAIC back in 2014 when their price was like $500 each.

Re: device IDs, I believe these are part of the hardware, because I get the same ID when I plug into the Raspberry Pi as when I plug into my desktop computer.

I'm in the process of taking a lot of calibration images, but my goal is to figure out what version of INDI caused this regression and use the last working build. I don't understand what hardware versions QHY has abandoned (or why they would do that either); from the conversation here, it sounds like my version is still supported. I'm really close to just pitching the thing into the river and buying some other brand.

Perhaps there's a way INDI can support both? Like have a "qhy-old" driver for the old devices and "qhy" for the newest SDK? It's tragic that this open source SW can't maintain support for older hardware - that was one of the original benefits of open source.

Charles
Ubuntu 18.04 and Raspbian Jessie; INDI 1.7.4
Mounts: CEM-60 chiefly; iEQ45
Cameras: Atik 383L+, QHY5-II-M
Focuser: Moonlite
4 years 9 months ago #40099

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

  • Posts: 61
  • Thank you received: 8

Replied by Odiug on topic QHY5 not found by Ekos

Charles, according to you signature, you have a QHY5-II-M. This one should still be supported by the QHYCCD library.

Yes, it is confusing. The original QHY5 (and SSAG) is a bit odd in various ways. The QHY5-II has the same CMOS sensor, but a different wiring and firmware. I guess M stands for mono. There are further cameras with names like: QHY-5P-II, QHY-5L-II...

When I investigated the linux driver and SDK, I found an older version. In this version it was seen that starting with the QHY5-II the USB commands used between camera and driver were unified across the various QHYCCD cameras. The original QHY5 uses a different command set.
That might also be the reason why it got finally abandoned.

I would be curious how the QHY5-II is different from the QHY5. If you have ever opened your camera, could you please make pictures of the PCB (both sides)?

CS
Guido
4 years 9 months ago #40116

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

  • Posts: 985
  • Thank you received: 161

Replied by Alfred on topic QHY5 not found by Ekos

I'm referring to a clone called "Q-Guide" that had been sold by "CCD Labs".

Back then there was a dedicated Indi-driver called "qhy-old" just for the QHY-5 that did work very well, even video did work reliably if memory serves. It was dropped years ago. I struggled with all sorts of problems ever since. So much so that at one point I decided to throw in the towel. I bought two ASI cams that work perfectly and without ANY issues from day one. I will stay away from QHY as far as I can.





4 years 9 months ago #40120
Attachments:

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

  • 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
4 years 9 months ago #40121

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

  • Posts: 61
  • Thank you received: 8

Replied by Odiug 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
4 years 9 months ago #40136

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

  • Posts: 985
  • Thank you received: 161

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: 4 years 9 months ago by Alfred.
4 years 9 months ago #40144

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

  • Posts: 61
  • Thank you received: 8

Replied by Odiug 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
4 years 9 months ago #40157

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

  • Posts: 61
  • Thank you received: 8

Replied by Odiug 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
4 years 9 months ago #40158

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

  • Posts: 102
  • Thank you received: 31
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.
4 years 9 months 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: 4 years 9 months ago by Charles Wright.
4 years 9 months ago #40165
Attachments:

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

  • Posts: 61
  • Thank you received: 8

Replied by Odiug 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
4 years 9 months 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
4 years 9 months ago #40183

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

Time to create page: 1.081 seconds