When I change to that same issue in Ekos (can't find ttymount, searching then finding the only plugged-in serial port ttyUSB0) but also, in a terminal window if I do a ls /dev there is no ttymount listed (where previously it was listed but in a different colour).

Ian

At least on the RPI4 running Ubuntu 20 (64-bit) it is working. What OS are you running. (different flavours, different issues)
My mistake: it should be SUBSYSTEM not SUBSYSTEMS in that case.

My system
The udev rules:
ubuntu@indi:/lib/udev/rules.d$ more 99-serial.rules
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", ATTRS{serial}=="UPB2409XH9", SYMLINK+="UPB2"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", ATTRS{serial}=="PA3FGRBA", SYMLINK+="FOCUSCUBE"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="AM00GZ1Z", SYMLINK+="iOptron"

Before connecting the iOptron
ubuntu@indi:/lib/udev/rules.d$ ls /dev/iO*
ls: cannot access '/dev/iO*': No such file or directory
after connecting the iOptron
ubuntu@indi:/lib/udev/rules.d$ ls /dev/iO*
/dev/iOptron


P.

I'm using RPi3 running Raspbian (latest version, recent update)

Tried changing MODE= to be 0777 (in case execute made any difference) - no change

Tried changing SYSTEMS to SYSTEM and error reported was
Interestingly a search looking for hints on rules.d under Debian results seem to use SUBSYSTEM (rather than SUBSYSTEMS). Soome to only create the device under /dev with the plural form.
Using as per original udev rules line, then doing udevadm info -n -a /dev/ttymount the initial output isFull output in attached file (in case something further down is relevant), But (recognising bt beginner experience with Linux) that suggests the ttymount does link to the physical device (the FDTI USB serial adapter).

(thanks for your ongoing help)

Ian

Think I had the same error when running on raspbian but can't remember the exact details.
I would expext a link created like this:

lrwxrwxrwx 1 root root 7 Sep 30 17:19 /dev/iOptron -> ttyUSB0 (or whatever ttydevice the ioptron is mounted to)

if you issue a dmesg command just after plugging in the mount what do you get?

when I do that I get
[ 5456.846844] usb 1-1.2: new full-speed USB device number 4 using xhci_hcd
[ 5456.962972] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[ 5456.962988] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5456.962999] usb 1-1.2: Product: FT232R USB UART
[ 5456.963010] usb 1-1.2: Manufacturer: FTDI
[ 5456.963020] usb 1-1.2: SerialNumber: AM00GZ1Z
[ 5456.969766] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[ 5456.969934] usb 1-1.2: Detected FT232RL
[ 5456.973876] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0

and then udev links (symbolic link) to /dev/iOptron

It's strange on your machine it point to a gpio (which I thought is the gpio pins on the raspberry, but I might be wrong here)

P.

......

It's strange on your machine it point to a gpio (which I thought is the gpio pins on the raspberry, but I might be wrong here)

P.[/quote]
I agree. Although further down the "parent chain" it seemed to get to an FTDI device the start to gpio looked very wrong.

Do a bit more searching and I found a site suggestingand it was the KERNEL bit (rather than SUBSYSTEMS) that interested me so I triedI don't understand this stuff so I'm just repeating bits of what others are suggesting and it looks like that seems to work - starting Ekos (with ttymount set as the serial port) seeks to not report issues and I can drive the mount (N/S/E/W - issues with everything "below the horizon" at the moment but GPS can't work indoors and still investigating cause ... but that's another issue).

If you/anybody thinks this wrong and wants me to try anything else I'm very happy to experiment further. I am getting a large number of timeout errors (but I think I got those on ttyUSB0 - but that's think so more playing around and experimenting and a separate issue).
On the assumption this is "the answer", is this thread enough to pass the info to others or does the tutorial need updating.

Thanks
Ian

You can confirm it works when defining it manually.

sudo unlink /dev/ttymount
sudo ln -s /dev/ttyUSB0 /dev/ttymount
ls -l /dev/ttymount should show /dev/ttyUSB0

Then in the connection tab use /dev/ttymount (include /dev and no hyphen in tty-mount)

Ok, I did a few tests.
Connecting the FTDI also creates a /dev/gpiochip device. I don't have to much knowledge on that, but I think that is a device file talking directly on USB level, nott via the usb-serial convertor which create a /dev/ttyUSB type device.
So your udev seems to link to the wrong one (which makes the ioctl go wrong, because it's not serial protocol)

I would try the SUBSYSTEM=="tty" or SUBSYSTEMS=='usb-serial' in the rules fike.

Don't forget to restart udev after every change: udevadm control --reload-rules && udevadm trigger

Paul

I'd previously tried both of those (got the usb-serial from a bit of search engine use) - but in both cases the symbolic persistent name was not created. Unfortunately my limited Linux knowledge is such that I don't know how to get any error logs.

Ian

Running out of ideas now.
Tested a few things:

with SUBSYSTEMS="usb" links to wrong file (the usb bus number)
only combination that works on my machine is SUBSYSTEM=="tty"
- udev is very stricht on naming so a small typo and it does not work
- naming of the rule file? Should end with .rules or it failed on my machine

....


It might behave different on raspbian, but I have no raspbinan SD anymore ....



Paul

Yes, that is also what I'm using since years to have persistent names for my USB-to-Serial devices:I have three of those lines, to discriminate eqmod, synscan and a Pegasus DMFC.
If you can connect, but get spurious errors now and then, that is for sure not related to the above symlink setup, I'm definitely sure you'd also get them using the native ttyUSBX name. So rather look for connection or baud rate issues, or other hardware stuff...

......
Yes, that is also what I'm using since years to have persistent names for my USB-to-Serial devices:
<code>
SUBSYSTEM=="tty", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", KERNEL=="ttyUSB*", SYMLINK="eqmod"
</code>
I have three of those lines, to discriminate eqmod, synscan and a Pegasus DMFC.
If you can connect, but get spurious errors now and then, that is for sure not related to the above symlink setup, I'm definitely sure you'd also get them using the native ttyUSBX name. So rather look for connection or baud rate issues, or other hardware stuff...[/quote]
Re: .rules file. Mine seems work fine (a few hrs playing around, few reboots all indoors) without the SUBSYSTEM== but with the KERNEL==

But yours "makes more sense" (to me - whilst I don't understand much Linux/udev, specifying the SUBSYSTEM as a tty seems a "safer bet"). So I experiemented and changed mine to(hope above is correct, I had to retype as my VNC client does not seem to cut/paste nicely)
and that seems to work well - so I'll stick with yours as it specifies more info.

Re: Timeout Errors: It does not make much sense but playing around this morning (now using KStars in a Virtual Machine but RPi running remote IndiServer) and the timeout errors have disappeared. Previously loads of re-boots, etc. so only change is extended power off period - which makes no sense but it's working so all I can do is keep an eye on it.

Thanks to all for your help.
Ian

Just a wild guess: Is this a Pi 4? Could it be temperature problems?