…or “Living Without A Shack”!
The constraints of our modest home make it difficult to justify me having a dedicated radio shack. One of my current projects is setting up a receiving station in the attic and accessing this via my home network from a laptop or desktop PC as the opportunity arises. Basically this is an old desktop PC (Athlon 64 X2 4600+, dual-core, 2GB RAM), configured for remote-access, with both HF and V/UHF Software-Defined Radios (SDRs) connected.
A quick demo of the VNC window/desktop that I operate the system from:
An example, monitoring the 20m amateur band from a laptop on the sofa:
Some notes on the Radio/ SDR configurations:
- SoftRock Ensemble II Receiver (HF, 1.8-30 MHz)
- DVB-T RTL2832 + R820T USB tuner (V/UHF, 25-1700 MHz)
The PC in the loft runs Windows XP and uses the following features/ applications to make it remotely accessible over the home network (and indeed remote access via the internet is a future possibility):
- Wake-On-LAN enables the PC to to be off while not in use and be ‘woken up’ via the network when required.
- VNC is used for remote control and display of the PC’s desktop.
- A combination of Virtual Audio Cable (VAC), and RemAud is used to stream the audio between applications and from the PC onto the network.
Wake On LAN
The PC is currently based on an ABIT AV-8 3rd Eye motherboard, left over from a previous desktop PC. Surprisingly, the ABIT motherboard has no explicit mention of Wake-On-LAN (WoL) in the BIOS settings so I was initially rather puzzled as to how to enable WoL. It can in fact be enabled from the device properties of the on-board VIA Velocity NIC in Windows… Go to Device Manager, select the VIA Velocity NIC, Properties, Power Management tab, check “Allow this device to wake the computer”. Depending on the driver version there may also be relevant entries under the Advanced tab (there aren’t on my current configuration but I saw some web ‘how to’ articles that did have WoL settings there).
The PC can be switched off with the Shutdown command and wakes upon reception of a WoL ‘magic packet’ directed to its MAC address. There are many utilities available on both Windows and Linux for sending magic packets.
VNC / Remote Desktop
VNC is typically used to operate computer desktops remotely over connections of limited bandwidth and is based around detecting changes in the graphical display and sending these changes. My use of VNC in this installation involves a constantly changing display (the spectrum scope and waterfall of the SDR software) and the bandwidth available over the home network is very large (the loft PC connects via Gigabit Ethernet into the router so the connection bandwidth is limited to that achievable by the laptop used to connect via 802.11g). Some implementations of the VNC protocol allow configuration to improve performance but generally require their own client versions to be use to benefit from these improvements.
After trying several VNC implementations I seem to have settled on RealVNC. I am able to run a RealVNC client on both my Windows and Linux machines. This provides the best VNC experience I have so far found to a Linux PC.
The key to good performance of VNC over the home network appears to be the use of a Mirror Driver (included in RealVNC Server) which is used to quickly and efficiently send display updates to the VNC server. UltraVNC is another VNC implementation that can use a mirror driver (if you can find it!) but on Linux I was restricted to connecting to it via a generic VNC viewer which couldn’t use UltraVNC’s higher bandwidth modes.
Note – Windows Remote Desktop Protocol (RDP) is an alternative to VNC that generally produces good results but I am currently unable to run SDR# while connected to the PC via RDP (error “pA Device Unavailable” on launching the SDR# application). I believe this is because Windows Remote Desktop makes changes to the Windows sound properties to re-route audio over the RDP connection. When running RDP, the output devices shown in SDR# change (for instance my Realtek onboard sound card is no longer visible and the default output device for Windows becomes “Microsoft RDP Audio Driver”) and SDR# doesn’t seem to be happy about accessing them…
Some tips for optimal VNC performance:
- Some VNC clients have a setting to reduce requested colours down to 8-bit (256 colours) and set the Windows desktop background to a plain colour (no image)
- While running radio applications, the waterfall is the largest component of the screen that is changing (and therefore requiring bandwidth of VNC…) – turning off the waterfall has a big effect on speeding up the SDR# window and when turned on I have reduced its height to limit the demands on display updates but still provide a useful waterfall for seeing low signals in the noise:
- Experiment with the ‘Speed’ slider (bottom right). There is a balance here between the SDR# display speed and the speed at which VNC is required to send display changes – set too high and VNC can’t keep up with SDR#’s refresh rate so appears jerky, set too low and VNC is happy but you’re now watching a very slow display… there appears to be a reasonable balance for me at a relatively low speed, shown in the image above.
Audio Streaming – IP Sound
I now use DF3CB’s RemAud to stream audio from the remote PC to whatever client I happen to be using. RemAud runs really well in both Windows and under Wine in Linux Mint 15. RemAud runs with very little latency across the network, has good audio quality and is almost invisible on CPU load. The split of server and client applications allows streaming to multiple computers which may be useful in the future.
IP Sound was actually the first utility suggested to me by a friend, G4ELM. Like RemAud, IP Sound runs with very little latency across the network, has good audio quality and is almost invisible on CPU load. The IP Sound application also runs under Wine on my Linux laptop but sometimes suffers from delays in starting up. An excellent solution point-to-point solution for Windows PCs.
I have also tried audio streaming with VLC Media Player, NCH BroadWave Streaming Audio Server and Scannercast but have found all of these methods introduce high latency (between 5 and 10 seconds) into the audio stream which is undesirable when monitoring audio and adjusting the radio tuning. I’m sure VLC can be made to work well but I haven’t managed it in the time I’ve had available!
Connecting it together… Virtual Audio Cable
Virtual Audio Cable (VAC) is a Windows program for making audio connections between applications and devices. I’m using it in this project to bridge connections between the SDR# output signal, data mode programs requiring an input from SDR# and IP Sound which is used for sending audio over the network to the PC that I’m sat in front of.
I’d come across VAC while I was originally starting to set up audio streaming using VLC Media Player and looking for a way of streaming only the output from SDR# and subsequently found it recommended in an article in Radio User magazine by Mike Richards (January 2013).
One thought on “Network Receivers”