Domokos Molnar replied to the topic 'QHY 5-II camera in RPI4 setup' in the forum. 2 years ago

I can confirm. The executable is compiled against the so.20, while versions seem to be actual dates.

doma@astropi:~$ ldd /usr/bin/indi_qhy_ccd |grep qhy => /lib/aarch64-linux-gnu/ (0x0000ffffba0d2000)

A closer look reveals a work in progress, there is already a - broken - symlink for the oncoming so.21 series in the package:

doma@astropi:~$ ls -l /lib/aarch64-linux-gnu/libqhyccd*
lrwxrwxrwx 1 root root 15 Feb 16 03:12 /lib/aarch64-linux-gnu/ ->
lrwxrwxrwx 1 root root 20 Feb 16 03:12 /lib/aarch64-linux-gnu/ ->
-rw-r--r-- 1 root root 2939936 Feb 16 03:12 /lib/aarch64-linux-gnu/


Domokos Molnar replied to the topic 'QHY 5-II camera in RPI4 setup' in the forum. 2 years ago

I noticed that for 19.04 there is a build from 2020-02-24

This has SDK in it, which actually works and is more recent that the version 6 I used as per the previous thread, so I just put this lib there manually temporarily.

Still the question is on: where did you get a 21.1.19 from?


Domokos Molnar replied to the topic 'QHY 5-II camera in RPI4 setup' in the forum. 2 years ago

I actually seem to have the same problem in this topic:

The difference is that I'm on Ubuntu 20.04.

The latest packages are:

And they both contain the lib 20.12.23, which seem to be the problem.
I could get it working as described in the thread above.


I traced it down and found that the problem lies in /lib/aarch64-linux-gnu/

I managed to dig out an earlier version of this file from QHYCCD's website:

This one seems to be the latest one there for AARCH64:

I replaced the with in the package above, this solved the problem, my QHY5L-II is up and running but I wonder if there is a more recent working version for AARCH64?


It just popped up again. Yesterday I refreshed indi from a version from somewhere back in october 2020. And started to get this:

2021-02-16T06:28:24: [INFO] Device configuration applied.
2021-02-16T06:28:24: [INFO] USB Buffer updated to 512
2021-02-16T06:28:24: [INFO] USB Traffic updated to 10
2021-02-16T06:28:24: [INFO] Speed updated to 1 2021-02-16T06:30:07: [ERROR] GetQHYCCDSingleFrame error (-1)

2021-02-16T06:28:24: [INFO] Offset updated to 110
2021-02-16T06:28:24: [INFO] Gain updated to 10
2021-02-16T06:28:24: [INFO] Upload settings set to client only.
2021-02-16T06:28:24: [INFO] Loading device configuration...
2021-02-16T06:28:24: [INFO] USB Traffic Settings: Value: 30 Min: 0 Max: 255 Step 13
2021-02-16T06:28:24: [INFO] Offset Settings: Value: 180 Min: 1 Max: 512 Step 1
2021-02-16T06:28:24: [INFO] Gain Settings: Value: 1 Min: 1 Max: 29 Step 1
2021-02-16T06:28:24: [INFO] USB Speed Settings: Value: 0 Min: 0 Max: 2 Step 1
2021-02-16T06:28:24: [INFO] Camera exposure limits: Min: 0.000001s Max: 3600s Step 0s
2021-02-16T06:28:24: [INFO] Using QHY SDK version 20.12.23
2021-02-16T06:28:23: [INFO] Connected to QHY5LII-M-60b7db50f33c7356.

The camera works fine on windows with is driver downloaded from QHYCCD.

Same result on aarm64 and x86-64.

I also tried the nightly - same result.


It happened once again so I dag into it a bit more deeply. Indi actually works well, I could find no bugs but maybe others are interested so I share my findings and how I resolved the issues.

It is not specific to iOptron but it can affect anyone using a USB to serial device. It may also worth a FAQ item. I never saw this happening on Fedora22 but it happened on OpenSuse Tumbleweed.

The issue lies with ModemManager. Anyone not using a 3/4G connection on their Linux box controlling a telescope with Indi over USB-serial should disable/uninstall ModemManager. ModemManager is monitoring the hotplug of devices which can act as a 3G modem. These seem to include USB-serail devices. One can confirm this by running

sudo journalctl -f

and watching the output upon connecting the USB-serial converter. Normally ModemManager just fails on the device and it will become available for Indi but this does not always happen. What I found is that ModemManager sometimes misconfigures the serial port. It sets flags on it that will actually prevent serial port's normal use. I was unable to find out which flags ruin the port after spending 10+ minutes but one could try. Here's my working setup:

phd@mercury:~> stty -F /dev/ttyUSB0 -a
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho -extproc

Quite a few flags. If set wrong it is not a human task to find out what to change to get it working. I was in luck as I happened to have another USB-serial converter on an other machine from where I could copy the settings. stty has a flag to do it easily. This is:

phd@mercury:~> stty -F /dev/ttyUSB0 -g

and there is a way to restore it easily by issuing:
/usr/bin/stty -F /dev/ttyUSB0 0:0:8bd:0:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

So by now we just need a way to automate things. I made two things:
1. Tell ModemManager to ignore my USB-serial device
2. Set the serial port to the settings known to work upon plugin

I used udev to achieve this. First you need to find the vendor:device IDs of your device:

phd@mercury:~> lsusb
Bus 008 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

In my case it is the Profilic port with IDs 067b:2303. I created an udev rule file as follows:

phd@mercury:~> cat /etc/udev/rules.d/99-ttyUSB0.rules
ATTRS{idVendor}=="067b" ATTRS{idProduct}=="2303", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="067b" ATTRS{idProduct}=="2303", RUN+="/usr/local/bin/setttyUSB0"

The first rule tells ModemManager to ignore the device and the second one launches a script that set the required serial parameters.

phd@mercury:~> cat /usr/local/bin/setttyUSB0
/usr/bin/stty -F /dev/ttyUSB0 0:0:8bd:0:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

After setting these up, I never had the problem of connecting the mount from Indi. Hope that this helps others to resolve such issues.


Yes, with indi_ieq_telescope.


I uninstalled every indi related packages, manually wiped all indi directories, did a git pull, then checkout v1.4.1 and built from scratch.

Then I rebuilt phd2 from sources against it.

Now it works.

Thank you for your help.


doma@nappali:~> echo -ne ':V#' > /dev/ttyUSB0

gets me

doma@nappali:~> cat -v < /dev/ttyUSB0

But this does not seem relevant to me.

As said before I used a DSO to confirm that indi is doing nothing on the line. (DSO=Digital Storage Oscillloscope)
The scope captures the waveform on the physical RS232 line and decodes it to ASCII data for me.

When it was indi's turn to drive the serial line it did nothing. How can you debug that? How can one confirm that it actually tries to write to /dev/ttyUSB0? How can you explicitly tell it to use that block device?


I tried the following:

1. Running the Win7 machine with the ASCOM driver I hooked up the serial line to a DSO with RS232 decode turned on to see what they are doing. The iOptron ASCOM diver starts with an undocumented ":Deviceinfo*" command and then goes on.

2. I detached /dev/ttyUSB0 from the VM and on the Linux host I performed a quick session in two terminals in parallel (see attached screenshot). In one of them I ran these commands trying the command set:

doma@nappali:~> echo -ne ':Deviceinfo*' > /dev/ttyUSB0
doma@nappali:~> echo -ne ':GAS#' >/dev/ttyUSB0
doma@nappali:~> echo -ne ':GLT#' > /dev/ttyUSB0
doma@nappali:~> echo -ne ':Gt#' > /dev/ttyUSB0

In the other one I issued a cat and hit enter manually after each send to separate the replys
doma@nappali:~> cat -v < /dev/ttyUSB0

this verifies indeed that the USB connection is up and running fine from the Linux box. The error is indeed in indi somewhere. Maybe I misconfigured something.

3. I started an indiserver with
indiserver indi_ieq_telescope - (the same happens with the lx200_zeq driver)
and connected from a phd2. Selected the INDI mount, set the the port '/dev/ttyUSB0' and hit connect to mount. Nothing happened on the line, the DSO showed no activity. Indi is not trying to talk to the device through the USB device. Phd2 seems to simply timeout on the connect.

4. I installed the latest KStars/EKOS and tried it with its telescope wizard. Interestingly enough Ekos reposts a server crash and it does not work.

This all happened on an OpenSuse Leap 42.2 but I got the same results on an armv7 with OpenSuse Tumbleweed. indi 1.4.1 on both machines. A QHYIIL-5 camera works with indi just fine on both machines.


iOptron says on its home page ( ) that it uses this command set:

they also say that their ASCOM driver is compatible with
CEM60/CEM60-EC with latest firmware
iEQ30 Pro/iEQ45 Pro/iEQ45 Pro AZ with latest firmware
CEM25P/CEM25-EC/CEM25 with 8408 hand controller firmware 160523 and later
AZ Mount Pro with latest firmware
Cube-II/CubePro w/8408


I tried indi_ieq_telescope. It does not work either.


I have just received my shiny new CEM25p and wanted to connect to it via indi. I have been using indi for months to connect to my guide camera. It is indi v1.4.1 built from sources.

I connect an USB-rs232 converter to a laptop and connect it to the serial port of the mount. On the Linux machine I have a Win7 virtual machine, where - if the USB device is passed through - the mount works via ASCOM confirming that both the converter and the mount is OK.

I am trying to use the indi_lx200zeq25 driver - though tried other ones with no success. Both from phd2 and from "cartes de ciel" I can see the server offering the zeq25 but I cannot connect. With phd2 connection to the mount fails - probably timeout, in CDC just nothing happens. It seems to me that the driver is not communicating with the mount at all.

The port seems to be working and setup fine:
phd@mercury:~> stty -F /dev/ttyUSB0 -a
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^A; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O;
min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho -extproc

I switched on debug logging in the INDi control panel and this is what I can see in the debug log:
phd@mercury:~/.indi/logs/2017-06-21/indi_lx200zeq25> cat indi_lx200zeq25_09:17:46.log
INFO 35.123878 sec : Session log file /home/phd/.indi/logs/2017-06-21/indi_lx200zeq25/indi_lx200zeq25_09:17:46.log
INFO 109.535003 sec : Session log file /home/phd/.indi/logs/2017-06-21/indi_lx200zeq25/indi_lx200zeq25_09:17:46.log
INFO 111.081999 sec : Session log file /home/phd/.indi/logs/2017-06-21/indi_lx200zeq25/indi_lx200zeq25_09:17:46.log
INFO 121.965507 sec : Session log file /home/phd/.indi/logs/2017-06-21/indi_lx200zeq25/indi_lx200zeq25_09:17:46.log

I also tried to start the server with -vvv switch but there seems to be not much information regarding the communication between the mount and the driver. I'm attaching the log output.

Can someone please advise how to proceed?