Recently helped a friend set up a CDK14 on a PW L350 mount for a remote observatory and we’re having continuous trouble with “external disconnect” of both telescope and focuser.
A few notes:
the telescope disconnects far more often than the focuser
both can be immediately re-connected (not a cable wrap issue)
both seem particularly prone to this behavior during autofocus (usually in the second half of the routine), but occasionally happens at other times
I can find simultaneous errors in the SGP log and the ASCOM log (provided by PWI4) for the scope disconnect, but PWI4 standard log shows no errors at the same time
SGP is the only log that records focuser errors. I cannot find any record of errors in the PWI3 or ASCOM logs.
We are running:
SGP 4.0.0.700
PWI4 4.0.10
PWI3 3.4.1 beta 2
I have uploaded screenshots of the logs below. For reference:
SGP log showing scope disconnect
ASCOM log showing scope disconnect at same time
PWI4 log showing no record of error/disconnect
SGP log showing focuser disconnect
PWI3 log showing no record of error/disconnect
*ASCOM log doesn’t show any error at that time either
Usually when folks experience issues like this it involves a USB hub of some sort. Cheap hubs can be problematic. I don’t know if this applies to you or not, but depending how the hardware itself responds to dropped messages or flaky communication, it may explicitly shut the connection down which may be the cause of the external disconnect. The reason autofocus could present itself as an issue is just simply because there is a lot of USB traffic during this process. In our experience, USB hub problems can be caused by:
Cheap USB hubs can have trouble managing traffic between simultaneous USB ports
Bad cables (most often hub to computer)
USB hub too cold (plug connectors and plugs contract at different rates)
USB hub power supply does not fit tightly and, while it never loses power, causes power fluctuations that cause flaky communications.
USB hub power supply is going bad and puts out less voltage than it should
USB power supply is for a different hub / device
Cable wrap issues (you noted this isn’t applicable to you)
Bad / old USB drivers for your computer’s USB controller
If this doesn’t apply to you, we can think on it for a minute.
We do have a USB hub inside the L350 mount, but it’s an Anker model that I’ve used on my own set at home and I’ve never had any trouble. Solid build, good cables.
Furthermore, I believe the actual mount is plugged directly into the computer, bypassing the USB hub.
I will have the guys on-site double-check the cabling/connections around the hub anyway, but assuming the mount is plugged directly into the computer, is there another specific connection point that might cause this?
The idea of simple trial-and-error with cable replacement is difficult when you’re trying to work remotely, so I’m trying narrow down what specific connections are most suspect.
Thanks in advance for any further thoughts and I’ll let you know what the guys at the site say after they double-check the gear.
Temu
Sent from my iPhone. Please excuse brevity or misspellings.
Despite build quality, hub temperature can be a real issue. Do you know if it is kept warm(-ish)?
Even good hubs go bad (TV show?). It’s not common, but hubs that are repeatedly exposed to large temperature variations are more likely to fail. USB hubs don’t often fail outright either… dropped data just starts to become more common.
Thank you, Ken. Good hubs go bad indeed! (Worst TV show ever, which is saying something.)
The USB hub is inside the mount in protected—but not airtight—compartment. There are temperature swings of about 30F from day to night (roof covering during day, of course) and swings of about 15F during the hours of actual imaging with the roof open.
We’ll keep looking at physical solutions on our end.
Am I right in assuming that outside of these possible physical issues, there’s not an obvious software or driver issue?
It’s tough to say. I’m just speaking in terms of probabilities right now and not in terms of a smoking gun that definitely identifies external factors. There is certainly a possibility the observed behavior is from software or drivers, but historically speaking, it is highly probable that connectivity issues across multiple pieces of gear in the same general time range point to things that the affected gear has in common. This list is usually pretty small and is typically just the USB signal path from hub all the way through the computer’s USB controller and then possibly a common power source. In addition to this, there is a lot of driver software involved here that we have almost 0 insight to and it may also be a contributor. For instance, it’s not out of the realm of possibility that a driver using USB has a defect that causes it to flood the data bus with data and creates a congestion that affects other (healthy) gear. Sometimes these issues are, unfortunately, more about eliminating possibilities rather than identifying them.
That said, if you want to attach the full set of logs here I can take a look. You can use the built in issue reporting tool (assuming the machine has internet access). If not, you can use the issue reporting tool to locate relevant logs and then email those to us.
Let’s eliminate the likeliest thing first, then I’ll dig back into the logs and send them in. I feared the ones I attached didn’t give enough info for any real analysis anyway.
Wanted to update you after a full re-cabling and elimination of the USB hub.
Sadly, it looks as if none of it solved the problem. New cables, no hub, yet the problem persists. I am now running power and control for the entire setup directly to the computer.
I am at a loss for what it could be, though I suspect more and more that there is a faulty ASCOM driver at play (despite re-downloading and re-installing a few times). Both SGP and PHD2 are receiving seemingly false “disconnect” issues.
Also, how can upload/attach an entire log? The upload function here limits the file types and it doesn’t include the .txt file type.
Sorry, but we can’t determine why the mount repeatedly disconnects. The error above is issued by the driver outside the control of SGPro. You might want to engage with the driver’s author to see under what conditions the driver deems it appropriate to disconnect itself.
