×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Skywatcher CQ350 Pro and Ekos/Kstars

  • Posts: 4
  • Thank you received: 1
Anyone able to connect Ekos/Kstars with Skywatcher CQ 350 mount?

I have my old set up working with EQ6-R Pro connecting my Ubuntu Linux pc/USB port directly connected to the mount and using EQMOUNT indi driver.

When I try a similar setup with the CQ350 Pro mount, it doesn't work. I keep getting this error. There is no other serial device connected.
/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0 is already used by another driver or process.

Tried changing USB port to/dev/ttyUSB0, still the same error. (Baud rate is set to 115,200)

Tried connected to the serial port directly,
sudo screen /dev/ttyUSB0 115200
type :e1 gave me the output (=030925), so serial port seems to be responding.
1 year 3 weeks ago #91889

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

Edit your profile and toggle "Port Selector". Next time you start the profile, carefully select the serial port for each driver so they don't try to scan for available ports which may lead to this.
1 year 3 weeks ago #91897

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

  • Posts: 4
  • Thank you received: 1
I have tried several combinations. Selecting specific ports, changing port device path, Baud rates, Auto-Search enabled/disabled, Scan Ports etc. None of that worked. The computer (Ubuntu 22.04.02 LTS) has only mount (via USB) and ZWO Camera connected (minimum required for testing). This is a fairly newer mount from Skywatcher(announced in Dec 2022). I am wondering if the Indi driver needs some additional tweaking to make it work. Happy to help, if I can provide additional logging/debugging information.

(Another data point: Tried the same USB port with Synscan Pro software on Windows Computer, also using Prolific USB/Serial driver. It works with that.)
1 year 3 weeks ago #91901

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

The mount should be supported just fine. This an issue with the OS reporting the port is being used by another process.

Before running Ekos, run this:

fuser -k /dev/ttyUSB0

Do it report any processes using this port? After starting KStars and selecting 115200 baud rate, run this command again and if you get it's used by another process, then check the output again.
1 year 3 weeks ago #91941

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

  • Posts: 4
  • Thank you received: 1
Here are some of troubleshooting results. Computer is connected using USB port (computer) to USB/B type port on the mount
side.
----
fuser -k /dev/ttyUSB0. : Shows no output, before or after Ekos/Indi startup. (I would expect pid of some process, if busy using it, but nothing shows up)

lsof | grep -i usb0 : Shows no output, before or after Ekos/Indi startup. (I would expect process details, if using it)

I also captured the strace for the runnng indi_eqmod_telescope process and then hit connect several times. stace gave the following output.
$ sudo strace -fp 2686
strace: Process 2686 attached
pselect6(1, [0], NULL, NULL, NULL, NULL
 
) = 1 (in [0])
read(0, "<newSwitchVector device=\"EQMod M"..., 2048) = 127
openat(AT_FDCWD, "/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_CLOEXEC) = -1 EBUSY (Device or resource busy)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, NULL) = 0
openat(AT_FDCWD, "/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_CLOEXEC) = -1 EBUSY (Device or resource busy)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, NULL) = 0
openat(AT_FDCWD, "/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_CLOEXEC) = -1 EBUSY (Device or resource busy)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, NULL) = 0
sendmsg(1, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="<?xml version='1.0'?>\n<message\n "..., iov_len=176}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 176
sendmsg(1, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="<?xml version='1.0'?>\n<setSwitch"..., iov_len=278}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 278
pselect6(1, [0], NULL, NULL, NULL, NULL) = 1 (in [0])
read(0, "<newSwitchVector device=\"EQMod M"..., 2048) = 381
openat(AT_FDCWD, "/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_CLOEXEC) = -1 EBUSY (Device or resource busy)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, NULL) = 0
openat(AT_FDCWD, "/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_CLOEXEC) = -1 EBUSY (Device or resource busy)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, NULL) = 0
openat(AT_FDCWD, "/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_CLOEXEC) = -1 EBUSY (Device or resource busy)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, NULL) = 0
sendmsg(1, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="<?xml version='1.0'?>\n<message\n "..., iov_len=176}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 176
sendmsg(1, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="<?xml version='1.0'?>\n<setSwitch"..., iov_len=278}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 278
openat(AT_FDCWD, "/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_CLOEXEC) = -1 EBUSY (Device or resource busy)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, NULL) = 0
openat(AT_FDCWD, "/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_CLOEXEC) = -1 EBUSY (Device or resource busy)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, NULL) = 0
openat(AT_FDCWD, "/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_CLOEXEC) = -1 EBUSY (Device or resource busy)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, NULL) = 0

I have also updated the Mount firmware (latest at this time: 3.39.25). No change, same error. Not sure what else to try.


For now I am able to use the following two options. Reasonable options for me. Direct USB would still be good to have.

(Option-1) Connect computer USB cable via Synscan Hand-controller and use 'PC Direct Mode' on the hand-controller. Hand-controller is connected to the mount via RJ-45 port. On computer with Indi panel using EQMOD mount driver with Baud rate:9600. /dev/ttyUSB0 works fine in this case. "fuser -k /dev/ttyUSB0" command shows pid of the indi_eqmod_telescope process.

(Option-2) Using Synscan WiFI dongle and Indi connected via Dongle. Using 'Network IP address of the dongle" / Port : 11880/ UDP EQMOD mount driver, This works as well. Computer/Indi server then able to connect to the mount through wifi dongle.
1 year 2 weeks ago #91993

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

If you connect the USB cable to your PC, can you check the output for dmesg ? anything out of the ordinary there?
1 year 2 weeks ago #91999

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

  • Posts: 4
  • Thank you received: 1
@Jasem thanks for your help and patiently answering my questions. Finally solved the issue by disabling/removing virtualgps device (software) and after that it worked great. Now Indi panel can see CQ 350 mount with SkyWatcher -> EQMount driver. All good now!


--- Additional information, for those interested ---
In my troubleshooting attempts, nothing weird found in the dmesg. Although, there were logs in the syslog (/var/log/syslog) that indicated virtual gps daemon was trying to claim /dev/ttyUSB0 before EQMount driver
Apr 13 14:27:06 astro01 systemd[1]: Starting Manage ttyUSB0 for GPS daemon...
Apr 13 14:27:06 astro01 gpsdctl: gpsd_control(action=add, arg=/dev/ttyUSB0)
Apr 13 14:27:06 astro01 gpsdctl: reached a running gpsd
I also noticed 'fuser -k /dev/ttyUSB0' once showed the pid of gpsd process, but it killed the daemon after first attempt (OS issue), and after that it didn't show up the pid when running the 'fuser ..' command again. It was miss on my end earlier, as repeated attempts of fuser returned nothing. But it was definitely the other process trying to claim USB serial first, before EQMount daemon.

Removed the virtualgps/gpsd* software, rebooted and everything worked fine after that.
The following user(s) said Thank You: Jasem Mutlaq
1 year 2 weeks ago #92012

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

  • Posts: 239
  • Thank you received: 38
Yeah, looks like a case of the GPSD taking control of that USB.

This has happened to several USB controllers over the years.

Best to remove GPSD from the stack, because it will be hard to get the different distributions to remove that USB id.
1 year 2 weeks ago #92013

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

Time to create page: 0.468 seconds