Losing contact with mount - USB Hub Problem?

[K Michael McDowell]

Hi Bob - Tuesday night everything worked fine. Collected 48 ten-minute sub-frames, 24 on each of two objects. Last night not so good. Got part way through the first object then lost contact with the mount again and shut down. This time I was running the Hyperion software that talks to the telescope and as I said before controls the focuser, rotator, and fans on the scope. That was still connected to the scope this morning when I got to the observatory. So that seems to indicate that the Hyperion software was working just fine. Also, as I noted before, the rotator has remained connected to ACP when it has lost track of the mount in past instances of this issue. Therefore, I think somehow ACP is losing contact with the mount. The last two night I have had the mount USB connected directly to the computer, not through the USB hub. So, I am flummoxed. See attached log.
BTW - ACP was no longer running when I got to the scope this morning. Everything else was still running (MaxIm, APCC, FocusMax, Hyperion) but no ACP, it had shut itself down completely. This has happened before as well. Is this normal?

[K Michael McDowell]

Hi Eric - In my continuing efforts to eliminate the issued I am having; I ordered a StarTech industrial USB hub that hopefully with be good. I am also curious about what you consider to be a worthy USB cable. So, if you have a specific brand or grade of cable that you think is best for our application? I would appreciate your thoughts on how to get good cables. Most of the cables I am using came with the device to which they are attached. But other than that, I presumed that most all cables were more or less equal. You clearly have a different opinion about that so I would like to know what you consider to be good cables.
Thanks, Mike

[Eric Dose]

Speaking from my own experience, so grains of salt and all that:

I used to count on Belkin Gold or Belkin Pro cables for everything, as I've never had one fail, not even under abuse like repetitive torsion (as through a very tight MX+ mount pass-through). I can't find Belkin Gold or Pro any more, but it's worth hunting them. Recently I've used StarTech cables to good effect in the cold.

Cables already packaged with higher-end equipment are usually matched to the task. I count on this being especially true for equipment whose makers also make good cables, like StarTech...though 3 years ago and to my surprise I did have one USB 3.0 cable from StarTech fail, so I guess it can happen from any vendor.

By contrast, those cheap vinyl-and-foil cables that come with low-end hubs etc--yuck, I usually bag them separately and never use them. I think the main thing is just not to use those. And personally I don't buy cables on eBay--who knows what those really are.

On failure, consider that it may be the USB port, not the cable, that is damaged. My experience is that high-end cables are more tolerant of previously abused/loose ports--and strain relief improves reliability, too.

Cheers

[K Michael McDowell]

Thanks for sharing your thoughts.
Mike

[Peter Prendergast]

I can so zero problems with multiple scopes on one LAN. SRO has tons of stuff on their LAN and no issue. Further, in my house I have 27 different devices on the LAN and no issue, some are very
heavy users as well.

[Eric Dose]

Yes, we all have big LANs at home. The ethernet device count is not the problem.

The hosting problem would be the number of users, dozens of non-tech amateurs being confused on and duplicating IP addresses, ports, NAT, etc etc. Dozens of individuals' cameras, mounts, focusers etc etc, all plugged into ethernet free-form expecting the same independence they've enjoyed with USB for many years. The thought of 15 high-cadence CMOS cameras downloading data through the LAN. Colossal Nope.

So each hosting facility would have to rule the IP space (virtual or not) with a ruthless iron fist. Adding a focuser or guider would require permission from the hosting facility. Possible of course, but a new level of management required of hosting facilities, and new restrictions on users. Maybe SRO already rules individual-device IP space with an iron fist. Great. But that will have to become the model for other hosting facilities as well, at least for those that want to survive.

And, toy surprise: if users turn out to want Wi-fi as well, add in cross-talk, channel chaos, multipath reflections off the broad metal roofs, with 15 scopes in a building. Nightmare.

[Peter Prendergast]

Yes, we all have big LANs at home. The ethernet device count is not the problem.

The hosting problem would be the number of users, dozens of non-tech amateurs being confused on and duplicating IP addresses, ports, NAT, etc etc. Dozens of individuals' cameras, mounts, focusers etc etc, all plugged into ethernet free-form expecting the same independence they've enjoyed with USB for many years. The thought of 15 high-cadence CMOS cameras downloading data through the LAN. Colossal Nope.

So each hosting facility would have to rule the IP space (virtual or not) with a ruthless iron fist. Adding a focuser or guider would require permission from the hosting facility. Possible of course, but a new level of management required of hosting facilities, and new restrictions on users. Maybe SRO already rules individual-device IP space with an iron fist. Great. But that will have to become the model for other hosting facilities as well, at least for those that want to survive.

And, toy surprise: if users turn out to want Wi-fi as well, add in cross-talk, channel chaos, multipath reflections off the broad metal roofs, with 15 scopes in a building. Nightmare.

you made me laugh because I just know your tight
Peter

[Bob Denny]

Yes, we all have big LANs at home. The ethernet device count is not the problem.

The hosting problem would be the number of users, dozens of non-tech amateurs being confused on and duplicating IP addresses, ports, NAT, etc etc. Dozens of individuals' cameras, mounts, focusers etc etc, all plugged into ethernet free-form expecting the same independence they've enjoyed with USB for many years. The thought of 15 high-cadence CMOS cameras downloading data through the LAN. Colossal Nope.

So each hosting facility would have to rule the IP space (virtual or not) with a ruthless iron fist. Adding a focuser or guider would require permission from the hosting facility. Possible of course, but a new level of management required of hosting facilities, and new restrictions on users. Maybe SRO already rules individual-device IP space with an iron fist. Great. But that will have to become the model for other hosting facilities as well, at least for those that want to survive.

And, toy surprise: if users turn out to want Wi-fi as well, add in cross-talk, channel chaos, multipath reflections off the broad metal roofs, with 15 scopes in a building. Nightmare.

Eric you are soooo right. On the Alpaca front, we’ve gotten sniped at for not providing high security at the device level. We looked at the problem back in 2018, and we received input from university and government astronomy orgs that they would never trust the security that might be built into a focuser etc.

Short of air-gapping the LAN within which the control software and devices operate, the next best thing is to isolate the LAN from everything else. We expect to be the ones on whose backs the LAN traffic and security issues fall, and we’re already preparing. One of the guys is spinning up on an enterprise switch with which one can create isolated LANs / VLANs. There is a limit of course to which a small group of volunteers can help shared host operations but we’ll at least try. You can lead a horse to water but you can’t make him drink.

Those shared facility people often operate fast and loose with their networks. One I know of got hit bad with a worm that was let into a tenant’s system then propagated through the extended LAN to other systems. You know the problem(s): Non-tech amateurs indeed, “If it ain’t broke don’t fix it” people, refusals to update Windows (and you know why) ... a free field of fire for a zero-day worm.