Re: Losing Communications with the Mount

Christopher Erickson

TCP is more reliable than UDP if there are a bunch of lost packets on your network for some reason. Bad cable someplace, congestion, etc.In other words, TCP can hide a network problem that UDP does not. If UDP doesn't work, it is worthwhile trying to find out why and fixing it.

Also check your Ethernet cable lengths. Any cable over 100m can cause timeouts, retransmission congestion and packet loss.

Mixing different brands and vintages of Ethernet switches can sometimes cause problems. Different vintage Ethernet transceiver chips, different protocol capabilities, etc.

Get rid of any old Ethernet hubs.

Home made cables can have various issues due to bad crimps, crossed pairs, etc.

Check all cable connectors & sockets for oxidation, corrosion, bent pins, etc.

Make sure there is only one DHCP server on your network.

Always use Ethernet instead of WiFi, when you can.

The most robust and reliable mount communications option of all is RS-232 to a real serial port on your observatory computer. Second-best option is USB. Third is Ethernet and last place goes to WiFi. Ethernet is less reliable than USB because Ethernet and TCP use connectionless, multi-point protocols that make any device-to-device communications more vulnerable to disruption by a multitude more things. Also, most USB connectors are total, unreliable cr*p.

Wireshark is a free, open-source network diagnostic tool that can give you insights into your network. It is very powerful and does have a bit of a learning curve.

PingPlotter is a great, simple diagnostic tool that can be used to track down network congestion and packet loss in your network and your Internet connection.

Make sure you aren't suffering from duplicate IP addresses on your network. The WiFi and Ethernet ports MUST have different IP addresses from each other. Same goes for every single device port on your network.

If you have smart Ethernet switches that let you lock Ethernet ports to soecific, lower protocol speeds, try lowering them all to 10 or 100 MBPS and see if your network problems go away. Could be an auto-negotiation incompatibility issue between the switch and your CP4. Also if you have a smart switch, check its port statistics for clues.

I hope this helps.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738

On Wed, May 5, 2021, 2:35 PM Ray Gralak <iogroups@...> wrote:
> 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 APCC is in use, its Safety Park feature will cause the mount to stop tracking if the mount does not receive regular messages from APCC.

So, that the mount stopped tracking indicates that communication failed in some way.


> -----Original Message-----
> From: [] On Behalf Of alex
> Sent: Wednesday, May 5, 2021 3:41 PM
> To:
> Subject: Re: [ap-gto] Losing Communications with the Mount
> 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?
> 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.
> Alex

Join to automatically receive all group messages.