View Single Post
  #1  
Old 04-06-2015, 09:24 AM
Garbz (Chris)
Registered User

Garbz is offline
 
Join Date: May 2012
Location: Brisbane
Posts: 644
Exclamation Confirmed: Windows RDP causing guiding problems

I want to share with you some guiding problems I’ve found which I have determined to be the result of Window’s Remote Desktop Protocol. I have been battling with this problem over the past year and managed to resolve it by switching to TeamViewer or VNC for remote control of the guide computer.

Problem description

From the screenshots below you can see quite a clear difference in guide performance. The good shots were done with TeamViewer and the bad shots were done with Remote Desktop Protocol. Basically it looks like the guide commands to the scope are hanging and causing the scope to start taking off massively in one direction or another. In many cases this introduced an error in excess of 6 arcsec naturally ruining the photo. From the zoomed in example below you can see a small guide in the direction of the massive overshoot.

Also if you look at the calibration chart, the last east step appears to have massively overshoot compared to all the other steps. This shouldn’t be as the step spacing should be consistent between all commands in a specific direction. Even if the mount is massively misaligned it should only result in the steps not returning to the centre at the end, or the east/west and north/south combination not tracing over itself. There’s nothing that can explain a step suddenly overshooting, except for the first step where backlash is involved.

Also I don’t believe this to be a problem associated with PHD2 as I have experienced similar behaviour when slewing using my game controller. I originally thought that was Bluetooth acting up but it did it via USB too, every so often a button seemed to be “sticking” and the scope would dramatically overshoot where I was aiming.

History

The history of when and how this happened has been the source of my grief. Early last year I changed everything. Switched from laptop guiding to using a Fit-PC, switched from VNC to Remote Desktop Protocol, switched Windows XP to Windows 7 and updated all the software. So basically nothing was the same. Over the past year I’ve tried various combinations of drivers, and rolling back to earlier versions of software and even using the laptop again thinking the FitPC itself was the source of the issue, but none of that resolved it. At one point I blamed the mount itself but the problem persisted even after mount modification (belt drive) and hypertuning.

Recently I found a random post in Stargazers Lounge about someone asking about remote desktop programs and one person mentioned he had issues with RDP affecting performance of his mount, so I decided to try and see if this was the issue and switched to TeamViewer. It seemed to work and last night I decided to give it a decent controlled before and after test.

Testing methodology

I should start by saying there was zero wind yesterday, guiding SNR was good, stars were visible, no clouds, and no there was no possum playing with my telescope for the first half of the night.

I started the night by logging into the fit-pc with remote desktop and pointed the telescope at a-crux. This was at about the 11’ on the RA axis. I then proceeded to calibrate and guide on a star near a-crux (overly bright stars can’t be guided on). I left this running unattended for about 40min monitoring it from remote desktop and noted several spikes in the guiding. I also disconnected the remote desktop session and when I logged in again I noted that the spikes continued (this is what led me to discount remote desktop being a problem some 6 months ago).

When I hit the meridian I stopped guiding and closed PHD. I slewed the mount back to 11’ on the RA and parked it in place. I then sent a shutdown command to the PC, walked out to the scope and power-cycled the entire setup. I then logged in again using Teamviewer, opened up all the same software and started another calibration and guide on a star with a decent SNR.

The final results speak for themselves.

So my recommendation: Don’t use RDP if you have a problem. Maybe this is fixed in Windows 8, but I can understand the technical reasons for the differences. Teamviewer and VNC do screen grab and transfers. RDP has deep hooks into not only the window manager in the operating system but also into the hardware allowing things like remote USB passthrough. It’s a shame really since RDP is far more efficient over the network and provides a far better picture than Teamviewer or VNC.
Attached Thumbnails
Click for full-size image (Cal-Bad.JPG)
60.6 KB80 views
Click for full-size image (cal-good.JPG)
66.2 KB64 views
Click for full-size image (guide-bad.JPG)
167.5 KB69 views
Click for full-size image (guide-bad-close.JPG)
67.8 KB64 views
Click for full-size image (guide-good.JPG)
168.6 KB65 views
Reply With Quote