As for the other question about ports and port scanning, as I recall Jasem wrote that code a few years ago when we were working on getting a bunch of drivers to be easier to use so that it would find and list all the available ports and make them clickable buttons or drop down boxes, rather than the user having to type in the port’s path directly which was hard for most users. I do not remember though exactly where that code was
Product ID: 0xfbb2
Vendor ID: 0x04d8 (Microchip Technology Inc.)
Serial Number: 00000000P3
Speed: Up to 12 Mb/sec
Location ID: 0x14100000 / 31
Current Available (mA): 500
Current Required (mA): 240
Extra Operating Current (mA): 0
However, EKOS shows a failed to connect message.
2021-10-30T18:59:09: [ERROR] Failed to connect to port (/dev/cu.usbserial). Error: Port failure Error: No such file or directory. Check if device is connected to this port.
See the message "Could not connect to /dev/cu.usbserial"
In the INDI control panel for the nStep you need to select the correct port or force set it
In a terminal window, do a
ls -ltr /dev/*usb*
You shoudl see something like
See the image of my control panel above, notice the row with the Ports on it
Copy the text of the file name (e.g. /dev/cu.usbmodem621) shown for the cu device and open your control panel, paste the device name into the right field of the Ports and do a 'Set'
Then on the Option tab of the control panel, do a Save
Then try your connect.
This, to me, is just INDI configuration and not nStep related.
I assume all devices use the underlying INDI port/device selector when dealing with 'serial' interfaces.
I have the same issue on a PI for the Celestron Nexstar device selection.. If I have the Celestron connected at power on or not previously connected after power on I see a
If I unplug/replug the Celestron I then see it enumerate on /dev/usbmodem1 (a different /dev entry)
Yes, you are correct that this issue could affect users of multiple drivers, but if both of you were confused as to which ports to connect to for the devices tty vs cu, you can be sure others might be as well. So perhaps a paragraph can be written for all drivers that might have this port issue and maybe copy it to all the driver explanation pages? or maybe make one page with the information for all of those drivers explaining it?
I had to dust off my MAC, last time used was year+ ago and never for INDI.
I had been involved with Craig S back in the PHD0 MAC days with the nStep, but that was back in 2012 or so when I did MAC work for the nStep.
It was two choices to try, cu or tty and a web search cleared up MAC use of each.
Got it connected! Its not quite the steps in your post, as it gave me a yellow 'light' and then no connection. I tried scan ports and I think that did it but when fiddling with the settings I'm not exactly sure. Attached is a screen-shot of the settings and messages when it worked. thanks for your work. HTH some others per your discussions with Rob. Clear skies, and maybe a big aurora tonite! -although I have lots of clouds.
/Users/ursamajor_1/Desktop/Screen Shot 2021-10-30 at 9.21.46 PM.png
To be honest, nothing seems to be broken or need extra explanation beyond INDI port scan and choosing the correct port (/dev/cu.DEVICE) the device (for any driver that is a usb serial CDC type device) has enumerated on.
I can not explain what issues I had when I first DL'ed Kstars for MAC
I tried recreating them by moving Kstars.app to trash then deleting all vestiges I could find of preferences
/Users/USERNAME/Library/Application support/ anything with kstars
Then re-install Kstars
All looked clean, no vestiges of previous profiles and wizard was first thing offered
Chose CCD Sim and rigel nStep
The port was filled in correctly (i had only one type of USB CDC device attached) as expected and the 'Connect' just worked.
Now what I do see is if the device is entered manually (and wrong) and a 'Connect' is hit, I had reported seeing a 'Yellow' on the Connect.
Each and every time this happens seems to leave a hung process for the indi driver, e.g. I have all these hung processes (e.g. entering /dev/tty.DEVICE)