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

I spent a frustrating morning playing with my rig in three different setups.
1. No Dongle
2. Dongle connected after Pi booted
3. Dongle connected before Pi boot (the situation last night).
In no case could I reproduce the problem I saw last night. I made the mount go to various objects which were all invisible (due to my doing this in daylight hours) but in all cases the scope was pointed in the right general direction according to the map in KStars. If the problem had recurred, i would have seen error messages like these I saw last night

<code>[2024-04-17T20:32:32.364 MST DEBG ][ org.kde.kstars.indi] - Celestron Advanced VX HC : "[DEBUG] CMD <e> "
[2024-04-17T20:32:32.364 MST INFO ][ org.kde.kstars.indi] - Celestron Advanced VX HC : "[ERROR] Serial write error: Write Error: Input/output error "
[2024-04-17T20:32:32.365 MST INFO ][ org.kde.kstars.indi] - Celestron Advanced VX HC : "[ERROR] Failed to read RA/DEC</code>

Failed to read RA/DEC is a sign that communication with the mount is lost.

So I'm going to try your suggestions.

I looked at the /lib/udev/rules.d/25-gpsd-usb.rules file and it seems to include my gps device:

So that doesn't appear to be the problem.

But the USB/RJ cable appears to be more interesting.


Why would my USB/RJ cable be found under GPS devices?? Note that the cable does NOT appear in lib/udev/rules.d/69-libftdi.rules. Could that be the source of the confusion?

After mulling my last post over, several questions come to mind. I am referring to this:



1. Why does this vendor ID occur in two different rules files (99-indi_auxiliary.rules and 25-gspd-usb.rules)?
2. What is the significance of the numbering inherent in the rules file names? Do lower numbers get processed first or last?
3. When a matching device is found in different rules files, which rule is followed? Is the first matched rule followed or the last?
4. What is the significance of MODE="0666"? Why is this entry much shorter than the others in 25-gspd-usb-rules?
5. Should this particular item (the USB-RJ cable) be in 25-gspd-usb.rules at all?
6. Should an entry for it be created in 69-libftdi.rules?

If you were unable to reproduce the problem, it is probably because the configuration files are correct. Tried changing your gpsd file with the previous values, and you should end up with the mount problem again.

IdVendor is the name of the company that produces several products (idProduct). The products are found in different rule files with the (unique) company id in front.
Look at these links to better understand the rules files:

devicehunt.com/view/type/usb/vendor/067B/device/2303

unix.stackexchange.com/questions/44308/u...ermissions-in-libusb

forums.opensuse.org/t/udev-rules-priorit...with-operator/100210

Your cable contains a PL2303 chip and not FTDI. So nothing to change in 69-libftdi.rules and you must leave it in 25-gspd-usb.rules because the PL2303 chip is used in some GPS

1. Any software author can make rules for their requirements. So you end up with multiple applications/drivers trying to claim the same device.
2. The rules are processed in numeric order.
3. Higher numbers "win" by overwriting matching rules in lower numbers. There's also priority from where the rules are stored. See www.freedesktop.org/software/systemd/man/latest/udev.html
4. Mode=0666 is setting permissions. 6 means r/w, there are three of them for owner, group & all users. Ignore the leading 0 for most purposes.
5. Don't know
6. Don't know

>> If you were unable to reproduce the problem, it is probably because the configuration files are correct. Tried changing your gpsd file with the previous values, and you should end up with the mount problem again.

I don't think that's right. I experienced failure after changing the gspd file and rebooting. See this post and this post .

Thanks for the explanations of how this all works but I'm still not seeing anything that would explain the intermittent failure. It would be nice to create a rule that would get the dongle onto a completely different /dev entry.

hey Steve, when something like what you see happens it likely means the device gets disconnected (reasons here can be vary, but most often than not is about voltage drop)

May I suggest to open a terminal and run sudo dmesg -w

It will tail all kernel logs and you will see any action taken against your devices. That should help at least identifying the root cause