Date   

Re: Spikes in Dec

 

You want to enable DEC compensation here

This adjusts the guiding based on your sky position, which doesn't change (unless you are going to say you have a space telescope)

>>>I realize this is more a question for the PHD forum, (sorry about that) but I thought it could be of general interest here as well if you have the answer at hand.

that's fine - happy to help. Maybe you can shoot me some of your logs direct via email and I can review them. 

I'm not sure I saw what Howard mentioned, but guiding with high quality encoders is a relatively new thing, so anything is possible. lowpass2 was introduced only a few years ago iirc

 
Brian


On Thu, May 6, 2021 at 1:45 PM Seb@stro <sebastiendore1@...> wrote:
Hi Brian,

For the DEC, yes, you recalled right, Lowpass2. For RA, I have Hysterersis selected. 

I see there's also the possibility to select lowpass2 for RA, but I believe I read somewhere not to use it for that axis (possibly in the PHD2 manual). Anyway, I didn't seem to have any guiding problems in RA, so I'd leave it there for now.

Just looking around at other settings, I realize that I have the "Use DEC compensation" checked in the Guiding tab,  Calibration section. Help file says that it usually should stay checked unless in "unsual" cases, like when a mount's controller would apply a compensation automatically. Should I assume that a mount with abs encoders correspond to that definition and uncheck the box? Do you think, this could explain the issue reported by Howard/Roland ?

I realize this is more a question for the PHD forum, (sorry about that) but I thought it could be of general interest here as well if you have the answer at hand.



Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Brian Valente <bvalente@...>
Envoyé : 6 mai 2021 17:01
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] Spikes in Dec
 
Seb i seem to recall you using lowpass2 in PHD which is the correct algorithm for high res encoders



--
Brian 



Brian Valente


ADATRI on Losmandy HD Tripod

yanzhe liu
 

Can I attach ADATRI directly to Losmandy HD tripod?
I think I can do it with 3 1/4" screws, not receommeded 5/8" ones. Is there any concern by doing so?

Yanzhe


Re: Spikes in Dec

Seb@stro
 

Hi Brian,

For the DEC, yes, you recalled right, Lowpass2. For RA, I have Hysterersis selected. 

I see there's also the possibility to select lowpass2 for RA, but I believe I read somewhere not to use it for that axis (possibly in the PHD2 manual). Anyway, I didn't seem to have any guiding problems in RA, so I'd leave it there for now.

Just looking around at other settings, I realize that I have the "Use DEC compensation" checked in the Guiding tab,  Calibration section. Help file says that it usually should stay checked unless in "unsual" cases, like when a mount's controller would apply a compensation automatically. Should I assume that a mount with abs encoders correspond to that definition and uncheck the box? Do you think, this could explain the issue reported by Howard/Roland ?

I realize this is more a question for the PHD forum, (sorry about that) but I thought it could be of general interest here as well if you have the answer at hand.



Sébastien


De : main@ap-gto.groups.io <main@ap-gto.groups.io> de la part de Brian Valente <bvalente@...>
Envoyé : 6 mai 2021 17:01
À : main@ap-gto.groups.io <main@ap-gto.groups.io>
Objet : Re: [ap-gto] Spikes in Dec
 
Seb i seem to recall you using lowpass2 in PHD which is the correct algorithm for high res encoders


Unguided Imaging with a Tracking Model

W Hilmo
 

A few weeks ago, I posted a thread where I noticed that my Pegasus Astro Ultimate Powerbox V2 was reporting temperature incorrectly, which potentially affected the tracking model.  I also noticed that I had refraction correction disabled.  Correcting the temperature and enabling tracking correction improved my situation, but still wasn't giving me completely round stars.

We've had mostly overcast skies since then, but we did get one clear night a few nights ago.  I tried an experiment where instead of creating an all-sky model with APPM, I made a model with points only along the declination for my target object.  Normally, my all-sky model isn't that dense, with between 150 and 300 points total.  To do the declination only model, I did samples every two degrees of RA.  I limited hour angles to only those where my target would be up during darkness hours.  Since my object transits fairly early (and it took me some time to set things up the way I wanted), I ended up with only 4 points on the eastern side, with 44 points on the western side.

When I made my first 10 minute exposure (at 0.88 arc seconds per pixel), the RA tracking was off.  Actually, that's an under statement.  The RA tracking was so poor that I wasn't getting elongated stars.  I was getting short star trails.  My assumption is that with only 4 points on the east side, there was significant error in the model.  When I looked at the model details, though, I saw that the Index Hour Angle for the east side was *really* strange (think minus 17,000).  As a test, I disabled the Index Hour Angle term from the model.

When I did that, the stars were *really* round for my 10 minute exposures.  They were easily as good as I would have seen with tight guiding.  The first exposure after the meridian flip was similarly excellent.  Since the west side value for the Index Hour Angle looked pretty good (around 1), I re-enabled that term.  After doing that, I saw some star elongation in the RA direction, so I disabled it again and got perfect stars.

So until APCC Pro support declination arc tracking, I think that I'll keep exploring tracking models custom created for specific targets.  My main goal is to get the kinds of results that I was seeing and with high reliability.  I'm encouraged by what I saw the other night.

For reference, the mount is an AP1600 with Absolute Encoders.  The scope and camera is an AP130GTX with a QSI690.  I know that I can easily automate this setup with OAG guiding enabled.  But I want to explore what's possible unguided, since it's a bit more efficient from a time standpoint, since it doesn't need to reacquire the guide star after a dither.  Also, I have a new ASI2600MC Pro that I want to try.  If I can get comfortable with unguided imaging, I'll set it up with no OAG or guide scope.


Re: Losing Communications with the Mount

Christopher Erickson
 

My experience with TCP comes from 30 years of telecommunications and robotics engineering. My primary concerns are much more with Layer-1 of the OSI model (cables, connectors) and Layer-2 (Ethernet frames), not Layer-3 (IP packets) or Layer-4 (TCP/UDP.) 

OSI Layers 1 & 2 are VERY opaque to the average user so consequently they are usually ignored when troubleshooting. I think this is typically a mistake. Sort of like looking for your car keys under a nice streetlight instead of next to your car, where you dropped them. 

PingPlotter is a very graphical, visual troubleshooting tool that has a free version. It is PROFOUNDLY better and more intuitive than using the DOS prompt command line Ping command. PingPlotter also incorporates a very nice, visual, graphical, dynamic traceroute. Download it and try it out. You won't go back to the nasty DOS prompt command line ever again, unless forced to on a strange machine. 

I agree Wireshark is a complicated tool. I already stated that. However I believe that the typical AP mount owner is more qualified than the average person to gain benefit from it, given some time. I would add that starting with PingPlotter instead of Wireshark would be good.

It could be bad to have a firewall or router in between the CP4/5 and the observatory PC. If there is, it might have LAN packet filtering capabilities, which I would disable, if I could.

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


On Thu, May 6, 2021, 9:04 AM Seb@stro <sebastiendore1@...> wrote:
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
 
Not sure where you got that from... Communication link reliability has little to do with the underlying protocol granted it is used in the proper context, well managed and used within a properly designed "network" architecture. 
 
Also, TCP protocol IS a connection-based protocol. It is the very reason it is considered "more reliable" that UDP, the latter being a "best-effort" protocol with no handshake and less error-correction mechanisms but typically lower latency. Both have their usecases where they shine. USB and WiFi are no different either. Some are more complex to manage for a "standard" end-user than others, that's all. 
 
The way some manufacturers implement their datalink solution is another key factor. Don't expect Ferrari performance from a Chevy van. And don't drive a Ferrari when you've always driven a Chevy van (at least not without a proper training)...
 
That aside, OP seems to have isolated the problem between the mount and his wired computer. And I agree IP address conflict (connected devices with same address) could be the culprit here given the symptoms. In that case, I would expect communication to re-establish by itself over a few seconds/minutes wait (without powercycling the mount) and then fail again a few seconds/minutes later and re-establish, and so on. A test to verify that would be to run a "perpetual ping" (add "-t" to the usual ping syntax from the command line, e.g. ping X.X.X.X -t, where X.X.X.X is the mount's IP address) and let it run for several minutes. Hit CTRL+C to end the ping.
 
Wireshark isn't a tool for a "standard" end-user. From the OP's posts, I'd say he probably knows a bit about networking and probably already uses it. If not, I would rather suggest to download Advanced IP Scanner (free) or similar, which will help discover every device alive (responsive) and dead (not responsive for a small amount of time) on a network. It will also show the MAC address (which is a unique hardware network identifier) of all devices discovered. Try running a scan while the mount is responsive and take note of the MAC address associated with its IP address. Run it again when it becomes non-responsive and if the tool marks it as "alive" and shows a different MAC address, it means you indeed have a duplicate IP address in your network. The "Name" and "Manufacturer" listed will also help you identify which device is using the same IP address as the mount. If the device is marked "dead" when the mount is non-responsive, then the problem is probably elsewhere.
 

 
Another useful (a bit more advanced) command, if you are familiar with your network IP addressing, is the "tracert" command ("traceroute" in linux) which will essentialy show the path (routing hop) taken by a packet from the computer from which you entered the command to the destination device. Its usage is similar to the ping command, e.g. tracert X.X.X.X, where X is the mount's IP address (wired or wireless). Some routers/firewalls might block this request though and you only get a series of *** + a timeout message, instead of actual routing hop IP addresses, which won't help you much. If you have a "flat" network architechture or only one routing instance, it will only return the destination lP address which won't help you much either (see example below).
 

 
If it goes through however, it will help identify up to which routing network component (switch, router, access point, etc.) communication is achieved properly by returning a series of IP addresses through which packets need to go through to their destination, as well as the round-trip time between hops. Over modern wired ethernet links, expect values below 100ms. Over wireless links, it can go much higher depending on multiple factors, but I'd say below 150-200ms on average would be acceptable (but not particularly good). Over those figure, you possibly have a bottleneck somewhere or a failling network component. BTW that command can even be used over the internet with domain names. Example below is between my computer and google.ca. The last line shows the destination IP address of one of the servers hosting the domain google.ca. Lines 1-8 shows the routing instances every data packet has to come across to reach that google server from my computer.
 

 
 
Note that the fact that the mount is not responsive from either interfaces (Ethernet and WiFi) at the same time is also a clue the problem comes from a common source to both, hence probably not coming from the wireless Access Point.
 
Also worth mentionning, even if you haven't said you are using one, is firewalls (sorry, I'll get a bit technical here). While it is actually often not the firewall root-causing the problem, it can be the one ending the communication by dropping data packets. New generations of firewalls (even home router - WiFi or wired - with firewalls functionnalities) have dynamic adaptative algorithms that "recognize" the type and "behavior" of data traffic that goes through them. They do that to prevent, amongst other things, DoS (denial of service) attacks which consist of an attacker flooding a computer with a massive amount of requests until it crashes by running out of memory.

Now, I've monitored Ethernet/WiFi communications between APCC/APv2 ASCOM drivers and my mount's CP5 (using Wireshark) and based on the amount of connections (not talking about physical hardware connection here, rather software connections at the OSI model layer 4) used, it could well be mis-recognized by some firewall's algorithm as a DoS attack. I'm saying this because it creates a new connection for seemingly every data exchange between the computer and mount, which occurs very often - like every second or so. They possibly implemented this that way for heartbeat or synchronization purposes, but that's only a guess. (That left me scratching my head a bit BTW as there are more memory-efficient ways of accomplishing this). Anyway, thing to note here, is there is nothing you can do about that last part as it's an inherent p
roperty of AP's communication between controlling software and mount.
 
But if you are using such a next-gen firewall with that kind of security feature, it could result in similar symptoms to what you are experiencing: communications working for a while and then stopping entirely when packets are dropped. Note here that the firewall is simply doing its job of protecting you. I therefore wouldn't recommend disabling this security feature entirely to solve the problem if that proves to be the case. Rather, I'd try creating a rule to whitelist the mount's IP address in your firewall's configuration in that regard.

Hope this helps as well,
 
Sébastien


Re: Spikes in Dec

 

Seb i seem to recall you using lowpass2 in PHD which is the correct algorithm for high res encoders



On Thu, May 6, 2021 at 12:54 PM Seb@stro <sebastiendore1@...> wrote:
Hello Roland, Howard,

Thanks for the heads-up. I will hover to the PHD2 forum with this additional info as you suggest.

Strange thing is while I created the guiding profile, I did check the precise encoder mount box (or whatever it’s called). And guide speed was set to 1x. I also followed all recommendations I got from the Guiding Assistant. Maybe this isn’t enough which such highly precise mounts though, as you suggest.

There’s also the fact that I’m using the latest dev5 version (to benefit from the multi-star guiding functionality). I might revert back to the stable version for further testing.

Again, many thanks for your very professional support. Much appreciated.

Sébastien

Le 6 mai 2021 à 15:19, "chris1011@..." <chris1011@...> a écrit :


Hi Sebastien,

Howard has been going thru your log files and discovered some problems with your PHD setup:

"PHD2 is indeed commanding moves of 2 – 3 arc-seconds, all of them south.  It is also sending many moves of single digit mSecs.  There were 60 instances of  :Ms1#  in the one APCC log file.  That’s calling for a move of ~ 0.015 arc-seconds.  The screen below shows 11 move commands in a row, most or all of which were too small, followed by a ~2 arc-second move -  :Ms130#."

Basically you have PHD set up to respond to every tiny error in such a way that no movement occurs for many cycles, which is then followed by a single large movement. This type of Dec algorithm was developed for mounts that had huge backlash where the mount does not respond to move commands in a timely way, and then finally PHD sends a large correction command in order to get the mount axis moving. That's when the spike occurs.

Apparently you have set up your Min and Max moves wrong as well as choosing the wrong algorithm for a precision mount. never should guiding software send 1 millisecond ( 0.015 arc sec) move commands because the mount basically will not move at all, or so slightly that it will never register in your guide star motion. You may even have set your guide speed wrong - it should always be left at 1x sidereal, never anything else.

I would suggest that you go to the PHD group and let someone there analyze your log files and look at your settings. I am not an expert when it comes to PHD, I have only a rudimentary knowledge, so it would be est to ask the users on that group to help you. I know that the Mach2 will guide extremely well with your setup, even if you have some small unbalance. I put a 3000mm focal length 10" Mak-Cass on my observatory Mach2 last night and guiding was smooth and slick as snail snot on a door handle. I even set it purposely out of balance and still it guided the same.

And thanks to Howard here who sifted thru your log files and spotted the discrepancies.

Roland Christen
Astro-Physics Inc.





--
Brian 



Brian Valente


Re: Losing Communications with the Mount

Christopher Erickson
 

If a person is going over 2m or so between the mount and the PC, I would avoid using the USB port on the CP4.

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

On Thu, May 6, 2021, 7:49 AM Howard Hedlund <howard@...> wrote:
Using the supplied serial cable with a USB to serial converter, even the FTDI unit that we sell, will still be limited in its reliability to that of USB.  Chris is referring to a native serial port on a dedicated board inside the computer itself that avoids the Universal Serial Bus.  Our on-board USB port uses the same FTDI chipset, but it has an added advantage over an external USB to serial device.  An external device is powered solely from the bus in the computer.  Our port, however, is also powered so a power drop from the computer won't kill the USB connection because the CP4/5 will keep it alive.


Re: Losing Communications with the Mount

Christopher Erickson
 

If your PC doesn't have a native RS-232 serial port and you need to go 15' (or even 50') it would be much-better to combine a long serial cable with a short USB-to-Serial adapter at the PC. Serial can go the distance, USB can get rather flaky over about 2 meters.

And yep, I love my work!

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

On Thu, May 6, 2021, 6:16 AM Donald Gaines <onegaines@...> wrote:
Hi Christopher,
My computer has no RS-232 (Serial I think) ports, just USB.  Would the 15’ serial cable that comes with the 1100GTO mount along with the Astro-Physics Serial to USB converter, provide the same performance and reliability as the RS-232 you mention below?
BTW, Observatory Engineer.....in Hawaii.....you must really enjoy going to work!
Thanks,
Don Gaines

On Thursday, May 6, 2021, Christopher Erickson <christopher.k.erickson@...> wrote:
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
www.summitkinetics.com
   

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.

-Ray


> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of alex
> Sent: Wednesday, May 5, 2021 3:41 PM
> To: main@ap-gto.groups.io
> 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
>
>







Re: Spikes in Dec

Seb@stro
 

Hello Roland, Howard,

Thanks for the heads-up. I will hover to the PHD2 forum with this additional info as you suggest.

Strange thing is while I created the guiding profile, I did check the precise encoder mount box (or whatever it’s called). And guide speed was set to 1x. I also followed all recommendations I got from the Guiding Assistant. Maybe this isn’t enough which such highly precise mounts though, as you suggest.

There’s also the fact that I’m using the latest dev5 version (to benefit from the multi-star guiding functionality). I might revert back to the stable version for further testing.

Again, many thanks for your very professional support. Much appreciated.

Sébastien

Le 6 mai 2021 à 15:19, "chris1011@..." <chris1011@...> a écrit :


Hi Sebastien,

Howard has been going thru your log files and discovered some problems with your PHD setup:

"PHD2 is indeed commanding moves of 2 – 3 arc-seconds, all of them south.  It is also sending many moves of single digit mSecs.  There were 60 instances of  :Ms1#  in the one APCC log file.  That’s calling for a move of ~ 0.015 arc-seconds.  The screen below shows 11 move commands in a row, most or all of which were too small, followed by a ~2 arc-second move -  :Ms130#."

Basically you have PHD set up to respond to every tiny error in such a way that no movement occurs for many cycles, which is then followed by a single large movement. This type of Dec algorithm was developed for mounts that had huge backlash where the mount does not respond to move commands in a timely way, and then finally PHD sends a large correction command in order to get the mount axis moving. That's when the spike occurs.

Apparently you have set up your Min and Max moves wrong as well as choosing the wrong algorithm for a precision mount. never should guiding software send 1 millisecond ( 0.015 arc sec) move commands because the mount basically will not move at all, or so slightly that it will never register in your guide star motion. You may even have set your guide speed wrong - it should always be left at 1x sidereal, never anything else.

I would suggest that you go to the PHD group and let someone there analyze your log files and look at your settings. I am not an expert when it comes to PHD, I have only a rudimentary knowledge, so it would be est to ask the users on that group to help you. I know that the Mach2 will guide extremely well with your setup, even if you have some small unbalance. I put a 3000mm focal length 10" Mak-Cass on my observatory Mach2 last night and guiding was smooth and slick as snail snot on a door handle. I even set it purposely out of balance and still it guided the same.

And thanks to Howard here who sifted thru your log files and spotted the discrepancies.

Roland Christen
Astro-Physics Inc.




Re: Spikes in Dec

Roland Christen
 

Hi Sebastien,

Howard has been going thru your log files and discovered some problems with your PHD setup:

"PHD2 is indeed commanding moves of 2 – 3 arc-seconds, all of them south.  It is also sending many moves of single digit mSecs.  There were 60 instances of  :Ms1#  in the one APCC log file.  That’s calling for a move of ~ 0.015 arc-seconds.  The screen below shows 11 move commands in a row, most or all of which were too small, followed by a ~2 arc-second move -  :Ms130#."

Basically you have PHD set up to respond to every tiny error in such a way that no movement occurs for many cycles, which is then followed by a single large movement. This type of Dec algorithm was developed for mounts that had huge backlash where the mount does not respond to move commands in a timely way, and then finally PHD sends a large correction command in order to get the mount axis moving. That's when the spike occurs.

Apparently you have set up your Min and Max moves wrong as well as choosing the wrong algorithm for a precision mount. never should guiding software send 1 millisecond ( 0.015 arc sec) move commands because the mount basically will not move at all, or so slightly that it will never register in your guide star motion. You may even have set your guide speed wrong - it should always be left at 1x sidereal, never anything else.

I would suggest that you go to the PHD group and let someone there analyze your log files and look at your settings. I am not an expert when it comes to PHD, I have only a rudimentary knowledge, so it would be est to ask the users on that group to help you. I know that the Mach2 will guide extremely well with your setup, even if you have some small unbalance. I put a 3000mm focal length 10" Mak-Cass on my observatory Mach2 last night and guiding was smooth and slick as snail snot on a door handle. I even set it purposely out of balance and still it guided the same.

And thanks to Howard here who sifted thru your log files and spotted the discrepancies.

Roland Christen
Astro-Physics Inc.




--
Roland Christen
Astro-Physics


Re: Connecting ASIAIR Pro to a CP4 - Mach1

Kenneth Tan
 

I use the default settings for the embedded phD in the asi air pro for guiding. There are fewer settings but it usually works Without tinkering.

On Fri, 7 May 2021 at 00:53, Lee Decovnick <ursa@...> wrote:
Could you expalin the sequence of setting that up with the ASI.  PhD2 is an old friend.


Re: Losing Communications with the Mount

Seb@stro
 

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
 
Not sure where you got that from... Communication link reliability has little to do with the underlying protocol granted it is used in the proper context, well managed and used within a properly designed "network" architecture. 
 
Also, TCP protocol IS a connection-based protocol. It is the very reason it is considered "more reliable" that UDP, the latter being a "best-effort" protocol with no handshake and less error-correction mechanisms but typically lower latency. Both have their usecases where they shine. USB and WiFi are no different either. Some are more complex to manage for a "standard" end-user than others, that's all. 
 
The way some manufacturers implement their datalink solution is another key factor. Don't expect Ferrari performance from a Chevy van. And don't drive a Ferrari when you've always driven a Chevy van (at least not without a proper training)...
 
That aside, OP seems to have isolated the problem between the mount and his wired computer. And I agree IP address conflict (connected devices with same address) could be the culprit here given the symptoms. In that case, I would expect communication to re-establish by itself over a few seconds/minutes wait (without powercycling the mount) and then fail again a few seconds/minutes later and re-establish, and so on. A test to verify that would be to run a "perpetual ping" (add "-t" to the usual ping syntax from the command line, e.g. ping X.X.X.X -t, where X.X.X.X is the mount's IP address) and let it run for several minutes. Hit CTRL+C to end the ping.
 
Wireshark isn't a tool for a "standard" end-user. From the OP's posts, I'd say he probably knows a bit about networking and probably already uses it. If not, I would rather suggest to download Advanced IP Scanner (free) or similar, which will help discover every device alive (responsive) and dead (not responsive for a small amount of time) on a network. It will also show the MAC address (which is a unique hardware network identifier) of all devices discovered. Try running a scan while the mount is responsive and take note of the MAC address associated with its IP address. Run it again when it becomes non-responsive and if the tool marks it as "alive" and shows a different MAC address, it means you indeed have a duplicate IP address in your network. The "Name" and "Manufacturer" listed will also help you identify which device is using the same IP address as the mount. If the device is marked "dead" when the mount is non-responsive, then the problem is probably elsewhere.
 

 
Another useful (a bit more advanced) command, if you are familiar with your network IP addressing, is the "tracert" command ("traceroute" in linux) which will essentialy show the path (routing hop) taken by a packet from the computer from which you entered the command to the destination device. Its usage is similar to the ping command, e.g. tracert X.X.X.X, where X is the mount's IP address (wired or wireless). Some routers/firewalls might block this request though and you only get a series of *** + a timeout message, instead of actual routing hop IP addresses, which won't help you much. If you have a "flat" network architechture or only one routing instance, it will only return the destination lP address which won't help you much either (see example below).
 

 
If it goes through however, it will help identify up to which routing network component (switch, router, access point, etc.) communication is achieved properly by returning a series of IP addresses through which packets need to go through to their destination, as well as the round-trip time between hops. Over modern wired ethernet links, expect values below 100ms. Over wireless links, it can go much higher depending on multiple factors, but I'd say below 150-200ms on average would be acceptable (but not particularly good). Over those figure, you possibly have a bottleneck somewhere or a failling network component. BTW that command can even be used over the internet with domain names. Example below is between my computer and google.ca. The last line shows the destination IP address of one of the servers hosting the domain google.ca. Lines 1-8 shows the routing instances every data packet has to come across to reach that google server from my computer.
 

 
 
Note that the fact that the mount is not responsive from either interfaces (Ethernet and WiFi) at the same time is also a clue the problem comes from a common source to both, hence probably not coming from the wireless Access Point.
 
Also worth mentionning, even if you haven't said you are using one, is firewalls (sorry, I'll get a bit technical here). While it is actually often not the firewall root-causing the problem, it can be the one ending the communication by dropping data packets. New generations of firewalls (even home router - WiFi or wired - with firewalls functionnalities) have dynamic adaptative algorithms that "recognize" the type and "behavior" of data traffic that goes through them. They do that to prevent, amongst other things, DoS (denial of service) attacks which consist of an attacker flooding a computer with a massive amount of requests until it crashes by running out of memory.

Now, I've monitored Ethernet/WiFi communications between APCC/APv2 ASCOM drivers and my mount's CP5 (using Wireshark) and based on the amount of connections (not talking about physical hardware connection here, rather software connections at the OSI model layer 4) used, it could well be mis-recognized by some firewall's algorithm as a DoS attack. I'm saying this because it creates a new connection for seemingly every data exchange between the computer and mount, which occurs very often - like every second or so. They possibly implemented this that way for heartbeat or synchronization purposes, but that's only a guess. (That left me scratching my head a bit BTW as there are more memory-efficient ways of accomplishing this). Anyway, thing to note here, is there is nothing you can do about that last part as it's an inherent p
roperty of AP's communication between controlling software and mount.
 
But if you are using such a next-gen firewall with that kind of security feature, it could result in similar symptoms to what you are experiencing: communications working for a while and then stopping entirely when packets are dropped. Note here that the firewall is simply doing its job of protecting you. I therefore wouldn't recommend disabling this security feature entirely to solve the problem if that proves to be the case. Rather, I'd try creating a rule to whitelist the mount's IP address in your firewall's configuration in that regard.

Hope this helps as well,
 
Sébastien


Re: Losing Communications with the Mount

Howard Hedlund
 

Using the supplied serial cable with a USB to serial converter, even the FTDI unit that we sell, will still be limited in its reliability to that of USB.  Chris is referring to a native serial port on a dedicated board inside the computer itself that avoids the Universal Serial Bus.  Our on-board USB port uses the same FTDI chipset, but it has an added advantage over an external USB to serial device.  An external device is powered solely from the bus in the computer.  Our port, however, is also powered so a power drop from the computer won't kill the USB connection because the CP4/5 will keep it alive.


Re: AP1100/CP4 and NINA

Michael 'Mikey' Mangieri
 

OK, thanks. I'll check out the 1.11 version and experiment tonight. I use
APCC and APPM.

My normal mode of operation is to slew to the east with CW UP (based on APCC
limits allowing this) and track past meridian with no need to flip. But
when I slew east with CW DOWN the flip needs to occur at the meridian. I
expect NINA to handle this without any additional inputs or configuration
from me.

If I ever need to track past meridian with CW UP I guess that's when NINA
needs to know when to flip? That's the part I would assume you are referring
to when you state that I need to configure NINA to execute flips prior to
those limits being reached?

Mikey

-----Original Message-----
From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Dale Ghent
Sent: Thursday, May 6, 2021 12:54 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] AP1100/CP4 and NINA


Hi Michael, I'm one of the contributors to NINA and have been using my
Mach1GTO+CP3(V2) with it for over 2 years. It works fine. Plenty of other
uses use it with a CP4 and CP5 and that's also fine. It just uses the A-P
ASCOM driver like any other software.

Some general tips - If you have slew/tracking or meridian limits set up in
APCC then of course be sure that you configure NINA to execute flips prior
to those limits being reached. If you use the current in-development version
of NINA, 1.11, you can use the horizon file that APCC saves directly in
NINA's advanced sequencer to trigger actions based on your local horizon,
etc.


On May 6, 2021, at 12:38, Michael 'Mikey' Mangieri
<mjmangieri@xcalrockets.net> wrote:

I recently decided to try N.I.N.A. as a possible replacement for SGP which
I have used for years. Was wondering if the AP community has any issues
with using NINA with respect to meridian flips, CW-UP slews, and such?


Re: AP1100/CP4 and NINA

Dale Ghent
 

Hi Michael, I'm one of the contributors to NINA and have been using my Mach1GTO+CP3(V2) with it for over 2 years. It works fine. Plenty of other uses use it with a CP4 and CP5 and that's also fine. It just uses the A-P ASCOM driver like any other software.

Some general tips - If you have slew/tracking or meridian limits set up in APCC then of course be sure that you configure NINA to execute flips prior to those limits being reached. If you use the current in-development version of NINA, 1.11, you can use the horizon file that APCC saves directly in NINA's advanced sequencer to trigger actions based on your local horizon, etc.

On May 6, 2021, at 12:38, Michael 'Mikey' Mangieri <mjmangieri@xcalrockets.net> wrote:

I recently decided to try N.I.N.A. as a possible replacement for SGP which I have used for years. Was wondering if the AP community has any issues with using NINA with respect to meridian flips, CW-UP slews, and such?


Re: Connecting ASIAIR Pro to a CP4 - Mach1

Lee Decovnick
 

Could you expalin the sequence of setting that up with the ASI.  PhD2 is an old friend.


Re: Connecting ASIAIR Pro to a CP4 - Mach1

Lee Decovnick
 

Ok, thanks .I'll work on the USB to ASI AIR Pro connection. I'll check to  see If I have  an honest to goodness FIDI chip cable. I have an iPad, which I could use in place of the Windows emulation.


AP1100/CP4 and NINA

Michael 'Mikey' Mangieri
 

I recently decided to try N.I.N.A. as a possible replacement for SGP which I have used for years.  Was wondering if the AP community has any issues with using NINA with respect to meridian flips, CW-UP slews, and such?


Re: Losing Communications with the Mount

Donald Gaines
 

Hi Christopher,
My computer has no RS-232 (Serial I think) ports, just USB.  Would the 15’ serial cable that comes with the 1100GTO mount along with the Astro-Physics Serial to USB converter, provide the same performance and reliability as the RS-232 you mention below?
BTW, Observatory Engineer.....in Hawaii.....you must really enjoy going to work!
Thanks,
Don Gaines


On Thursday, May 6, 2021, Christopher Erickson <christopher.k.erickson@...> wrote:
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
www.summitkinetics.com
   

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.

-Ray


> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of alex
> Sent: Wednesday, May 5, 2021 3:41 PM
> To: main@ap-gto.groups.io
> 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
>
>







Re: Losing Communications with the Mount

 

All good advice from Christopher. Adding on to this,

 

Try increasing your timeout even more. 400ms is high for serial, and is fine for just ethernet on it’s own, but can be on the low side for wifi connections. Additionally, can you send us a picture of the setup? Sometimes a problem might not be obvious from the description alone. After that, checking all of your cables, even the power for the ethernet switch, is a good thing to do.

 

Liam

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Christopher Erickson
Sent: Thursday, May 6, 2021 1:27 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] Losing Communications with the Mount

 

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
www.summitkinetics.com
   

 

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.

-Ray


> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of alex
> Sent: Wednesday, May 5, 2021 3:41 PM
> To: main@ap-gto.groups.io
> 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
>
>





3961 - 3980 of 82303