Hi Steve,
The answer to your question is "Yes, but..."
I have done this very successfully. Unfortunately I have not put together a tutorial yet. It is not a subject that has been well covered anywhere, so it's not surprising that your searching has not amounted to much.
There are a few general points to consider:
1. Latency of the selected remote desktop sharing method.
Most of the tools that wash the connection through third party servers so that no ports have to be opened on the router, for example Logmein, have terrible latency, usually on the order of multiple seconds. This makes it impossible to use the radio. Teamviewer is the fastest I've tried, but even it runs hot and cold. Sometimes it's performance is good, sometimes not so good.
A much better and faster approach is to go ahead and open a port on the router for forwarding and use something that provides a direct connection to the home PC. It would also be good if this approach also supports audio, which pretty much leaves out any of the popular VNC client/server implementations. This essentially leaves only a single solution: Microsoft Remote Desktop (RDP). However, RDP
requires that the server be running a "Pro" version of Windows, for example Windows 10 Pro. The remote client can be running nearly any modern version of Windows.
If you don't have the right version of the operating system at home, then you are probably better off setting up the RCForb client and server software from
http://www.remotehams.com/ This will get you low latency PTT control and audio. You can supplement this with high latency screen sharing solution for looking at the spectral display and for controls not directly supported by the RCForb connection.
2. Audio connections.
On the client side the obvious solution is a USB headset. They actually sound pretty good, even the cheap ones. I use a Microsoft Lifechat LX3000 and get very good signal reports with it.
If you are using RDP you need to turn on the correct options on the client side for sending/receiving audio on the remote client. Sometimes there are some things that go wrong with this and you may need to do some fussy registry editing to fix it. It's best to solve this problem by testing locally first and using just regular Windows programs to test, not PowerSDR.
If you are using RDP, and have got audio moving properly between the client and server in both directions, then you need to solve the problem of getting audio from the VAC interface to the remote client. You would think you could just assign PowerSDR to use the default audio devices on the server, but when the RDP session is instantiated those devices change to devices called "Remote Audio". This drives PowerSDR crazy and can cause it to not work, crash, or even not start. PowerSDR is insanely sensitive to changes in audio device states
To solve the PowerSDR issues with the RDP instantiated Remote Audio device, use Voicemeeter Banana (VMB) to insulate PowerSDR from the "real world". Point the PowerSDR VAC connections to VMB, assigned Remote Audio to a VMB channel, then make the connections in VMB. It's a minor complexity, but it solves the problem quite neatly.
If you are using RCForb, then you'll need to use something like VMB also, in order to make the connections between the PowerSDR VAC interface and the RCForb server.
3. Control connections.
If you are using RDP, it's what you see is what you get. Use MOX , VOX or the spacebar for PTT.
If you are using RCForb, then you'll need a virtual serial port program to make the requisite CAT connections between PowerSDR and RCForb.
4. Internet bandwidth/performance requirements.
If you are using RDP, if you have a blazingly fast connection you can get away with murder, i.e. do whatever you want. However, if you have a slow connection it pays to lower the panadapter and waterfall update rates to 15Hz or less, and to minimize the PowerSDR window on the server as much as possible. I have operated with internet speeds as low as 1Mb/s this way, and even over a cellular data tether. 2Mb/s is much more comfortable, though.
If you are using RCForb, since it's just low rate audio and CAT commands the internet speed requirements are quite minimal, unless of course you are also using screen sharing to supplement it.
I realize all of the above is somewhat light on details. The RDP stuff can be a bit fussy to set up, but once it is set up it is very convenient to make just one connection for screen sharing, control and audio, and performance is superb. I've actually got a real VPN router (not a software VPN) and connect to my house for remote op's via VPN from my laptop. No holes in the router firewall and so totally secure. Before that I did open a hole for RDP, but I put it on a non-traditional port (8080) because when it was on the standard RDP port I got hammered by port scanners.
73,
Scott