Yes for chrony add these 2 lines.

nano /etc/chrony.conf

refclock SHM 0 offset 0.5 delay 0.2 refid NMEA
drift file /var/lib/chrony/drift

For START_DAEMON, I actually changed it to false to be sure to eliminate all conflicts. But if it works well with true then you might as well leave it like that

Actually START_DAEMON must be set false from my experiments.

With that, and the chrony stuff, it's all good now.

Nope. I spoke too soon. Somehow, in spite of all the changes, /dev/ttyUSB0 still goes away (only /dev/ttyUSB1 remains). Enough. Not going to fight this tonight. Willing to try anything else you might want to recommend another night.

Hi Steve,

What we are missing to determine the problem are the logs and screenshots, as in your first message.

The ideal would be to first test the mount alone to determine if Ekos likes it and to use it for a few minutes. In the mount connection settings, you should see the name of your mount's driver above the "Port" line instead of the GPS name (like in your image in the first post).

Then, if it works correctly, connect the GPS and observe what is happening in the logs and settings panel.

And finally, if everything goes well so far, restart everything in order to determine which processes are blocking the dev points with the logs, screenshots, versions of Kstars and Indi and copy of your gpsd configuration file.

After sleeping on the matter, I decided to say, to hell with the GPS. Since I have to enter the time and location every time I start the mount, I could just go with that, and use the "Mount updates KStars" for time and date setting. That would cover most of it. The only thing missing would be updating the system clock. I could live with that.

In any case that would fulfill your first test item. I will send you logs and screenshots. Then I would go back to trying the GPS, both after startup and before, and send those logs and screenshots and the other information you request.

But I am still wondering, what is going on on the system level here? Why doies tthe system decide that /dev/ttyUSB0 is no good, and set up /dev/ttyUSB1 instead? KStars and INDI logs provide no information on that, even at the most verbose level. Something is causing that to happen and I wonder if system logs would record some useful information about this.

The problem comes from udev and its way of mounting dev points.
It is possible to create rules to obtain a static point according to the manufacturer's name
wiki.archlinux.org/title/Udev#Setting_static_device_names

A tutorial made by Indi to create the rules file
www.indilib.org/support/tutorials/157-pe...al-port-mapping.html

It would be interesting to know the identifier of your GPS and the USB/RJ cable of your mount. And check if they are in the rules /lib/udev/rules.d/25-gpsd-usb.rules and /lib/udev/rules.d/69-libftdi.rules
To find them, use the following command as noted in the tutorial

"To find out the serial ID, run the following command against the device node. For example, the find the serial id of the device connected to /dev/ttyUSB0:"

udevadm info -a -n /dev/ttyUSB0 | grep '{serial}' | head -n1