I had already upped the timeout to 200ms, so I’ll try 400ms. The mount is directly connected to a switch in my observatory. The only other thing plugged into that switch is my UniFi WiFi access point, which is mounted in the observatory. My computer (a piggy backed eagle 2) is the only thing using that access point, so communications is Eagle2 -> AP -> Switch -> Mount. Said switch is backhauled to my house’s main switch, and the only traffic between the house and the observatory is my Mac connecting to the Eagle2 using Microsoft Remote Desktop. The Remote Desktop connection to the eagle has been rock solid.
I had pings repeating from my wired Mac in the house, and when the problem happens, the pings start failing and stay failing until the mount is power cycled, at which point the pings start working again. APCC re-establishes communications once the mount is power cycled with no other intervention on my part.
Also, the mount stops tracking when communications starts failing. If it was just a communications failure between the computer and the mount, wouldn’t the mount continue to track? When the mount is in this mode, the GTOCP4’s power light is on and the ethernet activity lights continue to flicker.
Communications failed again as I was writing this response. The mount was parked at the time. I had bumped the timeout to 400ms and switched to UDP before hand. Pings to the mount’s hard wired ethernet IP address is failing, but curiously I can ping the mount’s WiFi IP address, though if I disconnect from the mount in APCC and try connecting it via that WiFi address, it still get’s no response from the mount. Again, a few seconds after power cycling the GTOCP4, everything is working again.
I’ll try snaking a USB cable down from the Eagle 2 to the mount and try that as backup or perhaps the primary. If that also fails, then I’ll pop open the GTOCP4 and check the daughter board seating.