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

Read More...

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

Read More...

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.

Read More...

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

Read More...

Ekos mounts the /dev/ttyUSB0 point for the dongle as can be seen in your image for the mount settings. And it will try to send on it the commands which will fail. The mount will be mounted on /dev/ttyUSB1 since the first port is used, but cannot be used by Ekos.

You must then remove the dongle and the USB cable from the mount to dismantle the dev points.

Systemd looks at the gspd file and first mounts the dongle with USBAUTO. With the value false, we prevent this. And START_DAEMON allows you to launch the gpsd service only on request, for example with Ekos.

Read More...

Hi Steve,

We can all change with system settings, including time zone userbase.kde.org/System_Settings

The name of the browser tab refers to the name of the VM used and not the user session. In this case the noVMC VM launched by root under AstroArch. This was requested by system administrators in 2014 to differentiate all VMs by tab names.

Good day.

Stéphane

Read More...

Hello Steve,

I see you are using a u-blox gps dongle. The usb port confilt is between the mount and the dongle.

If your GPSD service is started, you must modify the /etc/default/gpsd file so that the GPS launches after the mount and on another port.

The file should look like this

START_DAEMON="false"
GPSD_OPTIONS="-n"
DEVICES="/dev/gps0"
USBAUTO="false"

Or

DEVICES="/dev/ttyACM0"

The mount takes the port /dev//tyyUSB0 and the GPS /dev/gps0 or /dev/ttyACM0

A very good day

Stéphane

Read More...

Hello Steve,

If you are using version 1.8, may I suggest that you connect your pi with a hdmi cable to your monitor or TV?

This would allow you to see if the pi boots correctly. And use a USB keyboard/mouse to run a few commands in a console to find a solution to your problem.

Read More...