Automation/remote control?

[dougw9wi]

My SDRplay arrived on Monday -- seems to work nicely. Even caught a bit of FM BCB Es Tuesday night..

The trigger for buying the unit is the August 21st solar eclipse. I live well within the zone of totality; the center of the path passes about 20km north of my house. Unfortunately, for reasons beyond my control, I cannot be home during the eclipse.

The last time I experienced a solar eclipse, interesting things happened on the 80- and 160-meter ham bands and the AM BCB.

My intent.. is to record 200-2200KHz for a 30-minute period straddling totality. Then, explore the recordings at leisure once I'm able to get home.

The computer in use is a HP Z400 running Windows 10.

- Has anyone used a scheduling tool to cause spectrum recordings to start at a specific time and run for a specific period?
- I've seen sample C code for a command-line tool which could do this. Do binaries exist? My success building code for Windows is limited...
- Any recommendations for remote-access software? I'll have access to the Internet where I'll be during the eclipse, and can bring a laptop to remote in to the home machine & make sure the recordings are happening.

Thanks!

[OH2BUA]

Hi,

interesting use case you have:)

HDSDR can perform scheduled recordings nicely. I hope that some day also SDRuno will.

I operate remote-only. Even if i'm at my summer cottage (my remote site), i need to operate "remotely", and i've also done that from 10 000 kilometers distances.

For windows environments i recommend to use MS RDP as the remote access software, helped with RemAud to handle audio matters. I recommend _NOT_ to use Teamviewer.

73, Jukka oh2bua

[dougw9wi]

Really, the more I think about it, even if I *was* home during the eclipse it would have made sense to acquire the RSP1. Record the spectrum with the SDR while monitoring in real-time with the "big" radio -- or actually go out & *watch* the eclipse:)

An initial attempt to install HDSDR failed as Windows 10 insisted it was malware... I'll give it another shot. I suppose it's not the end of the world if I can't get scheduled recording working -- I can launch it manually -- I just fear someone will call me away at just the wrong moment...

I'm afraid I don't understand how one makes MS RDP work across a consumer router? (keeping in mind while I will have Internet access where I'll be during the eclipse, I will have no control over the router on that end) I've used MS RDP extensively at work, but that's always within the same network.

I did just finish testing TeamViewer & it does seem to work. For some reason it isn't passing audio but to be honest, for this application I don't care and I've spent absolutely NO time troubleshooting. As long as I see a waterfall full of signals and see the Record tool running, I'll be happy.

May I ask why you don't recommend TeamViewer?

I spent a few hours trying to get OpenVPN working, afraid my IT skills aren't quite up to that:(

[dougw9wi]

Please ignore my comment about HDSDR. Apparently one of the Windows Updates pushed in the last couple of days fixed the false positives. Windows 10 no longer believes HDSDR is malware:)

Ran a test recording across the same bandwidth I plan to use on Eclipse Day & it seems to work well. (there's a contest in progress on 160 meters & along with the BCB signals it grabbed the hams..)

There's a pretty steep learning curve to HDSDR. It's not as obvious as SDRUno. But the recording provisions make sense & work nicely.

(thanks for the hint!)

[OH2BUA]

Hi agn,

to get RDP working you don't need to tamper the firewall in the local end, but in the remote end yes.

- You need to allow incoming TCP and UDP traffic towards port 3389 (default).
- And you need to map/route/pat/redirect (whichever term is used) that traffic to the particular remote host computer in your private network.

Spreading the word about how unsuitable teamviewer is for radio-related things is my favourite subject - so thanks for asking:) Here comes the initial doze:

- It is a three-party solution. Each and every bit travels via third party server site. Much unwanted latency added!
- It is very resource-hungry, both at remote and local ends.
- It violently scales the display of the remote end to resolution of the local end. Not good. (With RDP your desktop resolution is always the local's resolution. Eg., if your remote happens to be 800x600, and your local happens to be 3840x2160, you will get 3840x2160. For desktop, waterfall and all. Way to go.)

RDP gives the best possible desktop experience, low latency, as it is not based on just-copy-every-pixel-over-the-net idea, but uses much clever way to do that.

Ok, they are some things also in RDP which are good to know:

- The local-side software is included in every version of windows from XP onwards (ios, android and linux also available), but remote side sw is present in Pro/Enterprise/Server versions of windows only.
- Yep it needs tampering of the remote-end firewall (beacuse it is not a three-party thing).
- The audio architecture in RDP is hmm a little bit strange:-o Everything is easy if you just need to listen your remote at the local. But if you also like to run some digital encoding software like WSJT-X, or CWskimmer etc., and also listen at the same time, things get a little bit complicated... But, luckily a software called RemAud by DF3CB is a good solution for that.

RemAud handles two-way audio between the remote and local. AND, it handles the PTT, if you happen to need that. You can even have a foot switch at your local and run phone QSO's like being there yourself.

73, Jukka oh2bua

[dougw9wi]

Success. (thanks!)

I started by getting RDP working over the local network, inside the local firewall. Once that was done, configured the router to pass port 3389 TCP/UDP to the local IP of the machine with the RSP1 attached. Grabbed the WAN address from the router's status page. Set up my phone as a hotspot. (I live in a rural area, no neighbors close enough to "borrow" an outside Internet connection:) ) Pointed the laptop at the phone, ran RDP, entered the external IP of the router -- and it came right up. Once I remembered the username on the RSP machine is different from the one on the laptop I was able to login & get my desktop.

And as you say, it plays the audio through the laptop by default.

It did by default bring up HDSDR in a rather large window. Had to drag it so the maximize button was visible, then click it -- and it sized itself to the laptop screen. Not at all difficult.

Points well taken about TeamViewer. Again, for my rather narrow application it wouldn't have been a problem but for more extensive use I certainly see where RDP is a better option. And even for this application, it provides the extra peace of mind of being able to hear the signals.

The note about DF3CB RemAud is appreciated. I'm not looking at running any digital modes right now but I can see that being a future goal.

So, it looks like I've got everything working for August 21st. Once we get this Tropical Storm Cindy out of the way (so I don't have to worry about lightning if I leave the antenna connected while at work) I'll do a dry run & set aside the recordings as a "baseline". Looking forward to it!

[DanubeBCL]

Points well taken about TeamViewer. Again, for my rather narrow application it wouldn't have been a problem but for more extensive use I certainly see where RDP is a better option.

Give AnyDesk a try. It's from former Teamviewer staff members and many tests confirmed fast response and high data compression (less network stress).
https://anydesk.com/remote-desktop
I only use it for LAN purposes, a remote receiving station is not in sight. Too many costs. No noise free real estate with electric power available so far which I could afford.
73s, Heinrich