Thanks, Hy.

>>Many (perhaps most?) focusers report their position to the INDI driver, which in turn sends it to Ekos.
>>So, Ekos gets told the focuser position.

I assume this happens when INDI starts and connects to the focuser. Is there any logging of what it reports?


>>Internally, the focuser firmware will very likely do as you said: "record where it last was and imagine that it's still there".

Some focusers have the ability to be twiddled manually. How would this be accounted for?

Read More...

adding usb_max_current_enable=1 to /boot/config.txt MAYBE improved things with the mount. I just did a number of daylight GOTOs and found them generally accurate. Still no reliable joy from Camera or Focuser. Sometimes it works, sometimes it doesn't.

Read More...

Does it do some kind of query to the focuser device to learn the present position? Is there some action that can force this to happen?
Or does it just record where it last was and imagine that it's still there?

Read More...

This is what I currently have . I can't tell if it's "EQMOD" or not.

Read More...

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: