Difference Since Connecting the CP4 Directly to Computer


Steve Reilly
 

I run a remote imaging system at SRO that has a AP3600/12.5” RC and TAK TOA-150 that has been running for several years now. I discovered mid-April that the CP4 was connected to a switch instead of the second LAN connection on the computer, part of the drawback to remote imaging and not having been out to California to setup the system. Not knocking the staff at SRO, you as for something to be done and it gets done. Prior to mid -April I was noticing that maybe 85-95% of the images were well guided and the rest had issues, most often what I called star lightening where the guider seems to lose its guide star and drifts away, sometime either in the beginning or end of the image. I say that in that the dim object would sometimes be there and noticeable but the drift would be extremely obvious especially on the brightest of stars as if there is a period that guiding simply was lost but the majority was fine. Regardless of the result after discovering the LAN connection to the CP4 I had the connection corrected to the 2nd LAN on the computer and the port was configured with the proper IP address. Up until this time COM errors were always present especially during startup with a long lag before connection to the mount.

 

Now it’s almost instantly connected and the COM errors are no more. Interestingly enough as I blink through the images since that day, 4/20, I have yet to find a misguided image and wonder now if the CP4 being connected to the switch vs the computer directly was the cause (delayed/missed corrections) to the Star Lightening images? Or is this a coincidence? Either way this is a vast improvement in imaging results. I’ve only gone through the last weeks images but have yet to have a misguided image in the lot which is unheard of from the past performance. Just thought I’d ask as I can’t say for sure the reason.

 

-Steve

 


Peter Nagy
 

I have Netgear Ethernet switch and it's used to connect to CP4 and Optec FocusLynx auto focus hub and never had issues with this setup. It shouldn't matter whether you use 2 Ethernet ports from computer or Ethernet switch, both methods should behave the same way.

Peter 


Seb@stro
 

Hi Steve, 

As Peter said, ideally both connection methods should behave about the same way. But it might also depend on several factors. Like how crowded is the said switch (how many ports are used at the same time), if it is a single physical switch or a switch stack (multiple switches linked together and managed as a single logical unit), if it has a non-blocking backplane (able to forward all traffic even if all ports are used at full capacity at the same time), etc.

Misconfiguration of some network protocols could also induce high latency (not necessarily 100% of the time) depending on the network topology and redundancy mechanism (or lack of). Of course, there is also the possibility of hardware failure (port or any internal components). Switches’ OS bugs could also be the cause but it’s pretty rare in my experience unless the switch/router is running the “early adopters” version. Which in turn is not good practice in a production environment (unless you have no choice for security reasons).

 

It is also worth keeping in mind that highly time-dependent applications (like real-time with little to no buffering, such as controlling a mount for example) are the most demanding in terms of network stability.


Some bugs or bad standard implementations in the softwares you use can also make you think the network is faulty while it is not... There’s a myriad of reasons why a network link may fail or flicker but as I said in another thread recently, given components are chosen and used in a proper context, there is a good network architecture and proper management, such issues should not happen, at least most of the time - like 95% of it and actually that figure is considered to be a low reliability one. 5% unavailability is more than 18 days of downtime per year! And that’s not even counting planned maintenance windows. Usual aim in telecom is 99% or higher.


So getting com errors (assuming those are real comm errors, not software bugs) all the time is a definitive sign there is a major problem in the network path. 
Connecting two devices directly reduces the amount of single point of failure and by that alone increases the reliability figure of the overall system.

Sébastien