Ethernet connection to GTOCP4


DiscoDuck
 

I am having an issue with trying to change from using the default IP address for my GTOCP4 to a DHCP assigned one.

I have been connecting with the default one until now (direct connection from GTOCP4 to PC via ethernet cable) with PC side set to a static IP address on the same subnet. ie CP4 is 169.254.3.178 and PC I set to 169.254.3.177. All good. (Using UDP).

I have switched to connecting both to a router running DHCP. Switching on DHCP for the PC adapter, it and the GTOCP4 seem to pick up IP addresses successfully (192.168.0.xx) - the search (magnifying glass) in APCC finds the mount at 192.168.0.3 (say). However, when I then try to connect to it in APCC with that address it does not respond (either via UDP or TCP). APCC indicates there is no response and also gives the error message (presumably a default when no response received) about the firmware needing to be at least V.  (The firmware is VCP4-P-01-11. APCC version is 1.7.1.0 btw)

I'm obviously doing something stupid given the mount has been working fine over UDP and all I've done is change its address. :-)


Mike Hanson
 

The IP address isn't your only change, you've also placed a router between the PC and mount.  Since APCC can "Find" the mount, we know that the electrical connections are good, and that APCC can communicate with the mount.  When you click the magnifying glass, and you see the mount, suggest checking the "Use numerical IP address" until you can establish that hostnames can be resolved in your system.  Then click "Select" and make sure the IP address shows up in the "Hostname/IP Address" box. Also suggest leaving UDP selected since UDP is what is used to "Find" the mount.

If the router has a connector reserved for "Internet", do not use that connector for your PC or your mount.

Make sure the timeout in APCC is long enough.  Packet delays *SHOULD* be milliseconds, but assumptions are unhelpful when troubleshooting.  The "magnifying glass" waits a couple seconds for responses before publishing results.  What happens when you set the timeout to a couple seconds?

You can also use a DOS (cmd) window and try to "ping" the mount.  You can ping to the IP address, or you can ping to the hostname.  You can ping to the hostname a couple ways, with and without the ".local" domain.  Can you ping to it?  If so, IP address only?  Or, IP address and hostname?  You can check the assigned IP address of the PC (via "ipconfig" in a DOS window). Is the router assigning addresses properly?  Unique IP addresses, but on the same subnet (as indicated by the subnet mask)? 

The green LED on the GTOCP4 ethernet connector blinks when there is traffic on the line.  After the IP address has been assigned, and you attempt to "connect" from APCC do you see any blinking on this LED?

If you still have trouble, please contact me privately.  We can use Wireshark to see what is happening.

Regards,
Mike Hanson


DiscoDuck
 

Thank you so much for the comprehensive reply, Mike.

In trying what you suggested and fiddling with a few other things, I found that it was an issue with the router (as you suggested in your first sentence! :-) ). Replacing it with another router, it all works fine.

I am not sure what was going on, but the IP address the magnifying glass found for the CP4 was not correct. I don't think DHCP was working for some reason (though it bizarrely did for the laptop!) and so I don't think the CP4 even got an address. What was adding extra confusion to the debugging was (and here's the stupid bit on my part!) doing it in the presence of a WiFi network to which the laptop auto-connected and with addresses in the same range!! Not a good recipe. The address the magnifying glass found I think was the laptop's WiFi network IP address. Don't know why APCC thinks that was a CP4 though!

Thanks again for your time and your reply. Your support is much appreciated.

Regards,
Paul 



Ray Gralak
 

Update: with the new router, though it connects fine, when running, there seem to be quite frequent packet
losses. Again, probably not the mount and probably the router. But happens on both TCP and UDP. Switching
back to direct connection from CP4 to laptop, UDP is still rock solid. Hmm. Surely not two dodgy routers?! :-)
Try increasing the timeout value in APCC to see if that reduces packet loss. It may be that the packets are not lost but are not being returned or processed quite fast enough.

-Ray


Christopher Erickson
 

Some routers have an optional security feature of blocking communications between wireless devices. That might explain the first router. It can usually turned on and off.

Second router could be an issue of wireless signal saturation. Try increasing the distance between the router and devices to see if the communication improves.

PingPlotter is a cool graphical IP ping tool that can give insights when troubleshooting network issues.

-Christopher Erickson
Observatory engineer
Waikoloa, HI 96738
www.summitkinetics.com
   

On Sat, Mar 26, 2022, 3:28 AM DiscoDuck <montagoo@...> wrote:
Update: with the new router, though it connects fine, when running, there seem to be quite frequent packet losses. Again, probably not the mount and probably the router. But happens on both TCP and UDP. Switching back to direct connection from CP4 to laptop, UDP is still rock solid. Hmm. Surely not two dodgy routers?! :-)


DiscoDuck
 
Edited

Thanks all. I will fiddle, but for now have returned to a direct connection laptop to mount. After all, the change was meant to be for increased reliability, as I was using a WiFi network to remote desktop from my desk into two laptops driving two mounts outside with a router in the middle only using WiFi - so 3 computers connecting via WiFi. There were some stability issues staring to appear with that - so I was trying switching to both mounts' laptops (and the CP4) being wired to the router and then only one WiFi connection from the remote laptop to that router. But stability of the CP4 comms is way more important than the remote desktoping for easy viewing from the comfort of my desk, since that could actually affect the imaging! :-)

But I think the common factor here is the router - so maybe just time for a new one :-)