Setting up AstroPi3 and using the serial port mapper, not working. Using my limited Linux skills and 4 hours of searching this forum (Docs) it would seem that multiple usb devices need to be persistently mapped.
Tried now all day and eventually find both USB devises (EQDir and Gstar GPS) report the same serial. The mapping script works for each individually but both rules files are the same except for the names.
Yes, Rob, that does seem to be the outcome of using the script on AstroPi3. I tried to attach the two resulting rules files but this form doesn't see them as txt files???? so I have copied the contents below.
I just did a google search and found that in these cases, some people write the UDEV rule such that it uses the port that you plug the device into to determine its identity. If you did that of course then it would really matter which port you plug each device into, but at least this way they would get a unique identification
Rob, I've been doing the same and it would appear that using the same Hub, which I want to do for these devices and have them attached to the Pi on the tripod, then one USB cable to a Hub on the scope. This gives me the least number of 'moving' cables.
So, if I always plug the devices in the same USB port on the Pi can I assume they will always be /ttyUSB0 and /tty/USB1, and then do I use the serial script or not and remove the udev.rules files for these devices. Sorry my Linux system skills are blunt.
So the reason we use these UDEV rules is because the first device to connect gets called usb0 and the next will be usb1. The reason that this is a problem is because if both are already connected when you turn on your system you don’t know which one will get which name or if you plug them in in the wrong order the names could get switched. So just always plugging them into specific USB ports is not enough
I think you can also make a UDEV rule that uses the port you plug it into to define the name of the device just like my script does for the product, vendor, and serial ids. I haven’t tried this before of course since I just found out about it today when I googled your issue.
Thanks Rob but I am at a dead end here. Everything I read about Indi makes it a solution for remote astronomy, but this issue does not seem to have a solution. If I watch the Stellarmate tutorials all refer to an INDI Web Manager that resolves this issue, but the 'standard Indi Web Manager', although reporting that its Stellarmate in the title bar does not have this option. I appreciate that Stellarmate is a product that can be purchased, but if it is using only standard 'opensource' Indi code, why the cost?
I was going to purchase the Stellarmate OS as a download but I fail to see what I get, other than a modified Web Manager, and my experience to date has not supported paying for a product that I cannot get to work in a stable manner. it's like having a car that you need to pump up the tyres before you can set off.
I do believe this issue has a solution, it is to create a udev rule that uses the port to determine the name. My script does not do that because I didn't think that we would have a device that had all of those things be the same, but I could modify it to include that option as a last resort.
I do not know if the Stellarmate web manager would solve this problem, you would have to ask Jasem about that. But certainly if his code encounters the same issue that mine did with your problem, he could modify it to have a similar solution to what I mention above.
The idea of Stellarmate is that it is a completely set up and configured system to help people who are less familiar with Linux, raspberry pis, or do not like to tinker as much. Jasem also provides lots of support if you run into issues like the one you mention here.
Yes, stellarmate does use mostly the same open source code from INDI and KStars. Jasem, myself, and a number of other folks have invested countless hours in developing free and open source software for astrophotography. Purchasing the product will support him in continuing this development and you could consider it a donation to his countless efforts to help us all. But since it is free and open source, you don't have to buy it. But the alternative is that you have to be willing to tinker and work at it until you can get it all working. Purchasing stellarmate would result in less frustration I think.
I have researched more and this issue is widespread, and each seems to get specific solutions so I have re-grouped and looked at this issue from a different angle.
There are several EQDir adapter solutions and not all use a prolific chip, which is at the root of this issue. I am very tempted to invest in a new EQDir with the better, and identifiable, FDTI chipset. I have not seen any posts about this adapter type, but as it is broadly USB-RS232 it should perform with Indi in exactly the same way. The costs are worth it if it eliminates this constant 'tinkering' during each setup, and the loss of Dark Sky's while doing so.
I will post results if this sorts the problem. Comments or views on this very welcome.
I confirm the single serial number used for multiple products is often a consequence of cheap hardware cloning. FTDI chips suffer from this parallel market. You can probably fix this by simply choosing a different brand for the second adapter.
HEQ5-Pro - Atik 314E - Orion ED80T - DMK21 on Orion 50mm
DIY 3D-printed Moonlite and FWheel RGB/LPR
KStars and indiserver on two Atom 1.6GHz 1GB RAM Linux, VPN remote access