Thanks Mattia.
> had a look at the logs, they look mostly normal to me, and if the ttyUSB1 stays that way I wouldn't bother too much,
Gotta disagree there. It’s a BIG problem.TtyUSB1 is NOT available before starting EKos and only comes into view after this error in the log AND TTYUSB0 disappears So I would have to change the configuration when this happens, every time. And even then, I have no guarantees it won’t switch back. Gotta find a solution to this.
>> do you have a so called eqmod cable? it seems pl2303 may look like one and the eqmod chip may cause problems on Linux (I recomment in fact using normal USB cables).
Gee, I don’t know! I simply bought a USB-RJ cable and went with it. I could look for a different cable and would welcome recommendation on where to buy one.
I will also try the config change you recommend.
But did you check the link to the other post I provided? This one details mysterious failures on the focuser and camera soon after a successful connection. Would this change affect these devices?
I am increasinlglv convinced that these problems are all related. I sent that post to the Ekos forum because it happened shortly before the one with USB ones. My leading suspect is the Pi5, as these problems did not appear with the 4 I used to use.
Read More...
Thanks, Mattia.
This issue has come back to rear its ugly head again.
I had gotten disgusted with my GPS dongle and have removed it from the system. Only to find that /dev/ttyUSB0 still disappears from the /dev/ directory listing only to find /dev/ttyUSB1 appearing in its place, even without the dongle.
I am attaching a file containing dmesg output. Perhaps it will suggest something,
I would call your attention to lines 567-580, Maybe you can help me understand what they mean.
[Thu Apr 25 21:02:33 2024] pl2303 ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb status: -71
[Thu Apr 25 21:02:33 2024] usb 3-2: USB disconnect, device number 2
[Thu Apr 25 21:02:33 2024] usb 1-2: USB disconnect, device number 3
[Thu Apr 25 21:02:33 2024] pl2303 ttyUSB0: pl2303_read_int_callback - usb_submit_urb failed with result -19
[Thu Apr 25 21:02:33 2024] pl2303 ttyUSB0: error sending break = -19
[Thu Apr 25 21:02:33 2024] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[Thu Apr 25 21:02:33 2024] pl2303 1-2:1.0: device disconnected
[Thu Apr 25 21:02:33 2024] usb 1-2: new full-speed USB device number 5 using xhci-hcd
[Thu Apr 25 21:02:34 2024] usb 1-2: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 4.00
[Thu Apr 25 21:02:34 2024] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Thu Apr 25 21:02:34 2024] usb 1-2: Product: USB-Serial Controller D
[Thu Apr 25 21:02:34 2024] usb 1-2: Manufacturer: Prolific Technology Inc.
[Thu Apr 25 21:02:34 2024] pl2303 1-2:1.0: pl2303 converter detected
[Thu Apr 25 21:02:34 2024] usb 1-2: pl2303 converter now attached to ttyUSB1
After getting a new Raspberry Pi5 (running Astroarch), working through and solving flaky WiFi issues, flaky cable issues, I now find myself finally able to use KStars and Ekos again.
But I am immediately met with errors on my ZWO ASI533MC PRO and ZWO EAF devices. I don't know how to solve any of them.
The devices connect in EKos, but quickly develop errors that prevent anything useful from being done. I am enclosing some INDI driver logs in the hope that someone can help me understand them. Besides the question of the specific errors in the logs, I am thinking there may be a more global problem with my Pi5. Why should all these devices be failing at the same time?
Hmmm.
Humidity is NOT a problem at this time of year in Arizona. But I don’t have a better explanation for why this might be failing. I suppose this contact spray might be worth a try.
Read More...
Verdict: loose/flaky cable.
I tried a test this morning, and the camera did not even show up in lsusb.
Mattia; did not try unplugging and plugging back in, will do that today. As for the lsusb output suffice it to say that the output included an entry for the camera. I will also try removing the dongle for GPS to see if that changes anything.
Read More...
It's always SOMETHING. Spent most of the weekend fighting WiFi issues (and solving them, yay!!!) but now I have camera issues!
[2024-04-21T19:27:50.224 MST INFO ][ org.kde.kstars.ekos] - "Failed to connect to ZWO CCD ASI533MC Pro. Please ensure device is connected and powered on."
Well, my camera is connected and powered on. The light is on, so that's the power. As for connection lsusb shows me the camera.
and nothing in dmesg.
So what to check next?
Read More...
>> 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.
Read More...
After mulling my last post over, several questions come to mind. I am referring to this:
Sorry, that was a nice feature. Can it be added?
Read More...
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
[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
In Astriarch 1.7, the noVNC clipboard used to allow me to copy something from the host PC into the window, then copy it again and paste it into a window on the Pi where Astroarch is running. This would enable cut-from-host-paste-to-Pi. In Astroarch 1.8 this doesn't work. I can copy from the host-pc into the clipboard window, but when I paste in a Pi window, some other clipboard is the source of what gets pasted. It seems that there are two different clipboards in play. As I said, this was not the case in 1.7 or with Astroberry before that. Is this a bug, or is there some setting I need to set?
Read More...