Jump to content

Banner.jpg.b83b14cd4142fe10848741bb2a14c66b.jpg

RDP & VNC on Raspberry Pi 4


astro_al

Recommended Posts

Hi all.

I have been dabbling with a ZWO camera for solar imaging and for viewing live vs my binoviewers. I started with a laptop but didn't want to run a mains extension to the pier so bought a Raspberry Pi 4 with 8GB RAM and an SSD. I installed Astroberry and have everything working. Firecapture seems pretty good with a ROI of 1024 x 768 giving over 100 FPS with a 9ms exposure which is what I use with my Ha scope.

So all was looking good through a directly attached monitor but then I connected remotely via VNC and it is awful. The image from the ZWO refreshes about once every 3 seconds and even just navigating the Pi when Firecapture is closed is not great. I tried RDP which was marginally better, but still nowhere near RDP refresh rates between PCs. Am I expecting too much from the setup? I am using a wired connection at both ends at the moment.

The remote connection was one thing I didn't really think I would have an issue with. If anyone else is using a PI with/without Astroberry and has a different experience, or has any help in general, then that would be appreciated. Thanks.

Al

Link to comment
Share on other sites

You're realistically never going to get live video out of VNC, and 1-2 FPS is pretty "normal". RDP can do partial updates which will help a bit, but even that isn't very good for video (which is what you're talking here). RDP from Windows to Windows will work better because of the deeper integration of RDP with the Windows compositors etc (and it's a "better" though proprietary protocol in other ways), but it's still taking photos of window contents and sending them over the network. None of this stuff is terribly efficient for fast update rates of real video compared to e.g. video encoders!

Pis can work great for AP - solar/planetary/lunar is probably their weakest side because of the higher volumes of data, and it's where a NUC or similar will be an easier thing to deal with. If you're just using VNC to monitor unattended capture it's OK, but if you want high update rates you're going to need a directly attached monitor or some form of external video/display encoder/long cable to move HDMI video from A to B.

Link to comment
Share on other sites

  Does the low refresh rate seen in your RDP/VNC window affect the speed at which frames are captured? I've recorded a number of occultations using oaCapture at the far end of a VNC connection several times over the past year, and while the update rate for the video image is sometimes quite low, the number of images written to disk each second is unaffected. I'm running conventional Core i5 or better machines at both ends, though. It may be the case that the RPi runs out of CPU or I/O bandwidth trying to keep up with both the camera and network simultaneously.

Link to comment
Share on other sites

16 hours ago, discardedastro said:

If you're just using VNC to monitor unattended capture it's OK, but if you want high update rates you're going to need a directly attached monitor or some form of external video/display encoder/long cable to move HDMI video from A to B.

Thanks @discardedastro - your last sentence sums it up. I had thought that if I got the PI performant enough for capture then just viewing the screen would be the easy part. I have had a great experience doing this with a PC host and a Mac client over RDP and was looking for a lower power option. Although the Pi is a lower spec than either of those devices I am still surprised at how bad the remote experience is, even for basic operation of the Pi without any capture running. One of my aims is to be able to view the data from inside where it is cool and shaded so a local monitor is not on the cards. I also don't want to run any more cables down to the pier. The NUC option looks interesting but the power requirement is much higher - just like my laptop. I think I will probably see if I can use a 12v adaptor/inverter to use the 13.8v at the pier for my laptop, assuming I have enough amps. If that works out I may consider the NUC.

Thanks for your help :) 

Link to comment
Share on other sites

11 hours ago, MCinAZ said:

Does the low refresh rate seen in your RDP/VNC window affect the speed at which frames are captured?

It doesn't, but I can tell already that focussing and panning remotely would be a real pain. At the moment I am more interested in viewing the feed live than capturing data for post-processing. I may capture some 8bit AVIs for a record, but no 16bit SERs. Thanks.

Link to comment
Share on other sites

12 hours ago, astro_al said:

Although the Pi is a lower spec than either of those devices I am still surprised at how bad the remote experience is, even for basic operation of the Pi without any capture running.

This is largely unrelated to the power of the device, and more about the limits of VNC and Linux RDP implementations, which aren't great. There is some great progress being made to unpick some of the older bits of the Linux display composition stack (X11) and replace it with something a bit more modern (Wayland) which should help fix this but it's likely to be a while before that lands in many distributions. If you've got a Linux box at the far end then X11 forwarding can be pretty performant - I've used this in the past without issue. But yes, for focusing with live video VNC is not fast enough today. No issue for DSO stuff where you're doing 1-2 second exposures for focus, mind - it's only a limiting factor for stuff with high frame rates.

On 23/07/2021 at 22:36, MCinAZ said:

It may be the case that the RPi runs out of CPU or I/O bandwidth trying to keep up with both the camera and network simultaneously.

This used to be much more of an issue than it is today - the Pi4 ditched the USB-based Ethernet controller in favour of a chip with the Ethernet side of things directly integrated, so all the infamous overhead of USB interrupts etc that limited Pis to about 200-300Mbps throughput and caused fun with some real-time applications is now essentially dead and gone, happily!

  • Thanks 1
Link to comment
Share on other sites

I have a variety of Pi setups for my scopes.  Basically, if you use VNC over WiFi for the connectivity, the refresh rate will be awful.  Ethernet networking is better, but I get the best results running a pair of KVM-over-ethernet adapters into the house to a remote screen, keyboard and mouse.  You do need one ethernet cable (as you would with an ethernet network connection), but the speed is "just like being there," because you are actually on the Pi.  You aren't moving the data after it loads from the camera to the Pi.

KVM-over-ethernet adapters are readily available on Amazon, eBay and other Internet sources and run from about $55.00 to $200.00.  Frankly, I find very little difference in quality or operation relative to cost.  I do prefer the models that do POE (power over ethernet), so you only have to  power to one device which, in turn, powers the other device over the same ethernet cable. I usually power the inside-the-house unit.

This model has worked well for me:

AV Access HDMI USB KVM Extender

tTo be clear, I am running the capture software on the Pi and using a the KVM to export the Pi monitor, keyboard and mouse to a monitor, keyboard and mouse in the house.  I run mostly Pi4's for this and install either Kstars/EKOS or CCDciel/SkyChart  with indiserver on the Pi4, so I don't require an additional laptop or desktop for the capture session.  The only time I move data off the Pi is for stacking and post-processing, and then I usually do this transfer via a USB stick.

There are other options for capture software that will run on the Pi.  If you must run software (such as PixInsight) on a remote machine, then I strongly suggest using ethernet cable networking for the best performance.  You can connect a single cable with no router between a Pi and desktop or laptop with an ethernet port, configure a simple private network and get performance over VNC that is significantly better than WiFi.

Edited by JonCarleton
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Many thanks to all those who replied, great information. For now I am going to try and power my laptop from the 13.8V supply at the pier as this means no new cables. I do like the idea of the single ethernet cable for the KVM option though so I may look into that more. I would probably replace the old USB 2.0 cable with ethernet and patch that into the wall box inside the house.

Regards

Al

Link to comment
Share on other sites

I have a similar setup using a Raspberry Pi4 on my mount running KStars to control everything.  I boot and run the RPI from a 100GB SSD attached by the USB3 port which makes a huge speed improvement over an SD card

As I have to set up each time I have used a WiFi extender to allow me to be inside the warm house and control the RPi using VNC.  

I store all the images taken on the RPi and only transfer them to my iMac the following day.  It works most of the time but the connection is fairly slow and does drop out but at least the RPI carries on until the connection reestablishes.  This year I decided to buy 40 Metres of cat 5 ethernet cable and connect that to the RPi directly on the mount and run it back to a small router in my study with another short ethernet cable from the router to the BTHub tucked away in a cupboard.  The speed improvement is amazing and it works brilliantly.  Yes it means I have another cable going up to the RPi on the mount but its well with it and no drop outs.

 

Edited by wornish
  • Thanks 1
Link to comment
Share on other sites

Worth mentioning that if you're using the Pi for DSO imaging, where data transfer rates are less critical, and you've got Ethernet, you can run KStars on a desktop/laptop PC and just run indiserver/indiweb on the Pi.

This is much lower burden so older Pis can work fine (though I'd definitely stick to a 4 with the faster Ethernet performance and USB3) and it means all the interaction with KStars is fast because it's local - delay is just in the download time of the images, which is pretty fast. You can also download the files "as you go" to the local device so at the end of the night the Pi has nothing on it.

In general Ethernet via cable is always going to work dramatically better but if you're stuck using WiFi then there are dedicated bridge products (e.g. Ubiquiti, Mikrotik) which will seriously outperform the integrated WiFi on a Pi (or anything else, for that matter). Some of these support 12V so can be fed without a separate power supply, and just spit out Ethernet on a wired connector at each end.

The highest-end form of this would be something like the Mikrotik Wireless Wire which is a 60GHz (unlicensed in the UK) product, e.g. https://linitx.com/product/mikrotik-wireless-wire-cube-kit-60-ghz-link-with-5ghz-failover-pre-configured-pair/16698 or https://linitx.com/product/mikrotik-wireless-wire-pre-configured-60ghz-link---rbwapg-60ad-kit/15214 - these take 12V in. Definitely a major upgrade over no cable, but no patch on a cable...

  • Thanks 1
Link to comment
Share on other sites

My 12V charger arrived today but of course it doesn't work with the Dell XPS 😡 The Dell complains that I need to provide 45W. The charger provides a maximum of 60W via the USB-C port (20V/3A) and the Dell requires 19.5V/2.31A - so I thought it should work. Maybe it is a Dell thing as it is fine in my MacBook Air. I was hoping to use the PC at the pier to utilise Firecapture's support for ASCOM for controlling the mount and the focuser but maybe I will have to use the Mac instead and rely in INDI which is fine for the mount but the driver for the focuser is not as good as using the ASCOM driver. Never easy.

 

Link to comment
Share on other sites

I use a raspberry PI run from an SSD, and i run it over VNC in 4k, and it will play 4k videos too from YouTube, BUT I do not use the built in wifi, as it’s rubbish, I have a USB 3 external dongle that runs at approx 900mbps, as opposed to internal at approx 200 at most…👍🏼

 

Link to comment
Share on other sites

One thing I do, as my kit runs from mains (all in a sealed RCD protected box) is use powerline ethernet.

So the Pi is always ethernet and VNC laptop wifi or ethernet in the house

Seems to work well.

Link to comment
Share on other sites

26 minutes ago, gaz81 said:

One thing I do, as my kit runs from mains (all in a sealed RCD protected box) is use powerline ethernet.

So the Pi is always ethernet and VNC laptop wifi or ethernet in the house

Seems to work well.

Powerline is very dependent on:

  • How your wiring is done, topologically, and how "good" the wires are as antennas
  • How much radio noise you have in the local area, and now many interferers you have injecting noise back onto your mains ring
  • The relative alignment of planets and their moons
  • How many animals you've sacrificed to the Old Ones in the last year

It can work OK, but (and we've got data from thousands of deployments of powerline at $dayjob) it's very much luck of the draw and maybe 25% of people get a nice reliable experience. Getting the really good units helps a lot with your odds, since they've had some good R&D in them, but for point A to point B WiFi bridges will always perform better and more reliably (and then cables).

Worth trying if you don't mind reselling the units if they don't work out.

Link to comment
Share on other sites

For my use it seems fine. 
 

I run my work laptop off it all day at home, constant Teams meetings… all that fun stuff. 
 

I use TP Link ones. 
 

House is just over 20 years old and had a recent new consumer unit etc. 
 

Will see how it goes 🙂

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.