Well, that turned out okay after all. I dropped the hub and connected directly to the mount and ASI1600 using that latter as the hub for the filter wheel and guider. I did continue to get USB resets, as you said, on every exposure, but nothing every locked up or failed and I wasn't forced to power cycle or physically reconnect anything.
so I guess I'll need a new hub it I want to move further away from my mount.
I have to say that this still feels. wrong. It sounds like either there's an issue with the ZWO driver or the API isn't being used correctly because I can't see how normal, correct use should result in a device reset on every exposure :-/
Well, that's not a happy thing to hear Because the only other references to this slew of failures I can find suggest an issue with the USB controller on the motherboard of my laptop.
I think I can try without a hub by using the ASI2600mm as a hub for the filter and guider then a different cable direct to my laptop for the scope. I'll give that a try this evening.
Last night I set up with my AT6RC and ASI1600mm for the first time in a long time. I have an ASI174mm mini for a guide imager. Things seemed okay at first, and polar alignment went smoothly.
I'm running on an old laptop (Thinkpad T420s) running Ubuntu 20.04.
Then, I started getting various USB errors. I would lose my connection to the scope. I would lose my connection to the main camera. I would have to unplug everything and restart. Eventually I tailed syslog and saw a constant stream of usb reset messages. Once those started, everything would go downhill rapidly.
roland@astro-02:~$ lsusb Bus 002 Device 004: ID 17ef:1003 Lenovo Integrated Smart Card Reader Bus 002 Device 003: ID 8086:0187 Intel Corp. Bus 002 Device 046: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO) Bus 002 Device 042: ID 2109:2817 VIA Labs, Inc. Bus 002 Device 045: ID 03c3:1749 Bus 002 Device 044: ID 03c3:1f01 Bus 002 Device 043: ID 03c3:1604 Bus 002 Device 041: ID 04b4:6572 Cypress Semiconductor Corp. Unprogrammed CY7C65642 hub Bus 002 Device 040: ID 2109:2817 VIA Labs, Inc. Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 004: ID 0a5c:217f Broadcom Corp. BCM2045B (BDC-2.1) Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 045: ID 03c3:1749 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x03c3 idProduct 0x1749 bcdDevice 0.00 iManufacturer 1 ZWO iProduct 2 ASI174MM Mini iSerial 0 bNumConfigurations 1 Configuration Descriptor: ...
And the 3A is enough? I saw those and wasn't sure. I actually had some problems with the power supply that came with the SM but maybe it's not actually working correctly.
I see from
that the StellarMate package now includes a cable for this, but I have an older one that didn't include that cable. Anyone know of a 3rd party cable for this? I've tried supplying directly from a USB 3 hub that is supplied by 12V, but that won't do it.
Some mounts have a setting to do this, but many (most?) do not. And I'd guess this ends up be a per-driver thing, though in principle it doesn't have to be. As a former ACP user, I know they can do it for mounts that have no built-in support for consistent approach slewing.
So the question is, is this already hiding someplace in INDI/Ekos, or would it be a new feature that has to be added?
One thing that has lead to me to wanting this is that I'm trying to figure out a way to do dithering via pointing for when backlash is an issue; and yes, I've got too much backlash to do dithering well via guiding, especially in Dec. And my Canon T6i cameras show some horizontal banding that I suppose I could work around by rotating the cameras, but I kind of like the camera axes to line up with RA and Dec....
If I treat the problem as it I were building a mosaic that overlaps about 95% and had consistent approach slewing with some sloppy tolerances, I think I can end up with an effective workaround. But consistent approach slewing would be good in general since it would mean there should be little backlash to deal with at the end of pointing.
Last night PhD was guiding perfection. Today it kept losing the connection with the camera. Somehow, I had managed to make exactly this mistake and apparently reset something so it was trying to use the native driver instead of the INDI connection. I had turned off autoguiding to get imaging done while I came inside to try to find out what was going on. This post and thread saved me a lot of grief. I went back outside, found that was exactly the problem and voile, guiding worked again.
Of course, that's when the clouds rolled in.
hades wrote: For me it seems that you are too away from NCP, that's why the vector is out of the screen.
I don't think it was the cable; updating ubuntu (which included a libindi update) fixed things. Whether or not that was coincidental or due to a broken previous upgrade, I'm not sure. But at this point, same cables, same everything else, and it's back to working normally.