×

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

Bi-monthly release with minor bug fixes and improvements

INDI doesn't recognize the new QHY Alccd 294 Mono Pro

  • Posts: 67
  • Thank you received: 17
Finally I can give the promised feedback:
qhy294pro is running with the new 3.5.0.
Made a fresh Astropi3 install on a RPI4 with 4Gig RAM. Now INDI controls the qhy294m and the qhy filterwheel.
Platesolves running with the new internal Stellarsolver very fast.
Thanks to Robert, Jasem, Hy and all the other people spending their knowledge and time to this project :)

Regards
Stefan
3 years 3 months ago #63629

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

  • Posts: 11
  • Thank you received: 0
Stefan,

Do you mind elaborating on what you did to get your QHY294M work with INDI nightlies installed via Astropi3 on your RPI4?

I have Astropi3 running on my RPI4 with INDI nightlies on UBUNTU-mate 20.04.1.

INDI doesn't recognize my camera. lusb lists it as a USB2.0 Hub:
esktop:~/Desktop$ sudo lsusb
...
Bus 001 Device 025: ID 1618:c296 USB2.0 Hub
...

5-qhyccd.rules does list this camera and the firmware image is located at:
~/Desktop$ ls /lib/firmware/qhy/QHY294PRO.img
/lib/firmware/qhy/QHY294PRO.img

thoughts on how to get this working?

Thanks!
3 years 3 months ago #64468

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

  • Posts: 85
  • Thank you received: 19
I have the QHY294C and it's not recognized by default either.

The developing consensus is that this is related to USB3.

The way I've dealt with it is to install the SDK from QHYCCD directly:

www.qhyccd.com/html/prepub/log_en.html#!log_en.md


Given what I learned in this thread on the 294C, it seems to be related to a helper program called fxload, which is now rather old. It turns out that the QHY SDK ships with an updated version of fxload, fx3load:

www.qhyccd.com/index.php?m=content&c=ind...how&catid=127&id=163


So perhaps the solution is for indi-qhy or libqhy to also install fx3load or have a dependency on it.
3 years 3 months ago #64469

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

  • Posts: 67
  • Thank you received: 17
Hi dtex,

my installation is on top of "Raspbian GNU/Linux 10 (buster)".
The qhy294m is connected to the first USB3 port of the rpi.


KStars states version 3.5.1 Beta.
The qhy sdk version is 20.11.26
Here are screenshots of the first two tabs of the INDI controlpanel for the cam:




Regards
Stefan
The following user(s) said Thank You: Jason
3 years 3 months ago #64476
Attachments:

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

  • Posts: 11
  • Thank you received: 0
What a great community.

After posting a question about a new camera, I get two helpful posts overnight on tips to fix the problem.

The QHY SDK solved the problem.

dmesg now shows
[  103.863057] usb 1-1.1: new high-speed USB device number 6 using xhci_hcd
[  103.963684] usb 1-1.1: New USB device found, idVendor=1618, idProduct=c296, bcdDevice= 1.00
[  103.963703] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  103.963716] usb 1-1.1: Product: WestBridge 
[  103.963727] usb 1-1.1: Manufacturer: Cypress
[  103.963738] usb 1-1.1: SerialNumber: 0000000004BE
[  104.149295] usb 1-1.1: USB disconnect, device number 6
[  104.295278] usb 2-1: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[  104.316193] usb 2-1: LPM exit latency is zeroed, disabling LPM.
[  104.317142] usb 2-1: New USB device found, idVendor=1618, idProduct=c297, bcdDevice= 0.00
[  104.317156] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  104.317168] usb 2-1: Product: QHY294SPV200917
[  104.317179] usb 2-1: Manufacturer: QHYCCD

and the camera is recognized in ekos.

So I used the astropi3 script on a arm64 distro and thought everything went fine. Turns out realvnc doesn't natively support arm64 without significant modifications... so I just installed tightvnc... but then i had to modify the vnc startup script to work properly... with flexibility comes challenges.

a few steps closer to getting this all to work again...
3 years 3 months ago #64489

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

  • Posts: 11
  • Thank you received: 0
So I see on the QHY tab on the INDI control panel there is a "Read Mode" row and you can set it to either read mode 0 or 1.

Does switching between read mode 0 and read mode 1 work, or is there additional configurations needed? I'm waiting for the weather to clear up before I can experiment on my own ;)

In the control panel, the size of the pixels doesn't seem to change like I would expect it to on the "Image info" tab like I would expect it to when changing to read mode 1. It stays at 4.63 um, which is the correct size for read mode 0...

Thanks!
3 years 3 months ago #64491

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

  • Posts: 85
  • Thank you received: 19

Out of curiosity, does fx3load exist on your system?

The SDK installs it to /usr/local/fx3load but fxload is at /sbin/fxload so it might be in /sbin/ as well.
3 years 3 months ago #64492

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

  • Posts: 67
  • Thank you received: 17
There is no fx3load on my system, just /sbin/fxload.
Installation is Rasbian Buster with Astropi3 scripts. The qhy-sdk 20.11.26 has been installed automatically with INDI.
Regards
Stefan
3 years 3 months ago #64496

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

  • Posts: 207
  • Thank you received: 14
Hi. For info. Similar issue but solved it.
Just installed a new indi server using latest ubuntu 20.04-2 server on pi4.
Ran command from 85-qhyrules by hand and got this:
root@rigel:/home/nick# /sbin/fxload -t fx3 -I /lib/firmware/qhy/QHY294PRO.img -D /dev/QHY294M
illegal microcontroller type: fx3

fxload seems to be out of date - even through applied all updates.
This means 85-qhyrules fails.
Copied version of fxload from existing ubuntu 18 server and now all works. Presumably fxload from latest QHY sdk should be ok as well.
Might help someone with same issue.
3 years 2 weeks ago #68614

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

  • Posts: 207
  • Thank you received: 14
Another issue I had with GHY294M was with USB. The QHY camera seems to need more power via USB3 than the equivalent ZWO, so when I simply swapped my ASI294MC pro for QHY294M it didn't work at all, so I am now running all my USB stuff through a good (12V,3A powered) USB hub (Anker 10 Port 60W Data Hub with 7 USB 3.0 Ports and 3 PowerIQ). Cheap hubs "powered" by usb power may not work. This arrangement works 100%. Hope that helps.
2 years 11 months ago #70086

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

  • Posts: 6
  • Thank you received: 0
hey mate.
i just got a new qhy294m-pro cam. im running ekos on astroberry on a rpi4.
You mention you needed a powered usb3 hub to get the qhy cam to work properly. My qhy indi driver always crashes when plugging the camera directly into a usb3 port on my rpi4. it crashes less when plugged into a usb2 slot instead. is this something you found too? Can you use your qhy cam in a usb3 slot on the rpi via the powered hub without crashes?

cheers
2 years 6 months ago #75727

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

  • Posts: 207
  • Thank you received: 14
Hi Martin. I have have no problems with the QHY294M as long as I use a good quality powered USB3 hub - I use the Anker 12V powered hub (see my earlier post). Also make sure you are using an adequate power supply for the PI. A PI4 needs a minimum of 3A@ 5.1V when attaching power hungry USB kit.
The only issue I had originally was that the fxload program in the package I installed was out of date and did not support the camera.
I updated it from the QHY SDK (32bit arm for Astroberry). To check fxload use fxload -V:

[EKOS]$ fxload -V
Jul 16 2021 (development)

This is a recent one. If it is years out of date then update it.

QHY cameras all seem to require more power via usb than ZWO equivalent ones.

Cheers,
Nick
The following user(s) said Thank You: Martin Ams
2 years 6 months ago #75738

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

Time to create page: 1.332 seconds