Yes, you can run AIRSPY SDR# (sdrsharp.exe) under Linux, using Wine . It takes a little setting up of Wine to get the correct DLLs installed, but it does work.
I've been using this for a few weeks successfully, both with a 'local' device and a remote one.
I'm a Linux guy. Pretty much always have been, since, well, pre-Linux when I was a Unix guy. It was my career. Thus, I have barely any Windows equipment in the house, and only have some Apple stuff for the hardware more than the software.
Sadly, it would seem the world of amateur radio is dominated by Windows based software in many ways. In particular it seems some of the best SDR software is Windows only.
That's not to say there is no Linux SDR software - there is, quite a lot. I was trogging along experimenting with cheap rtl-sdr dongles using both GQRX and cubicsdr. And then there is linrad, which looks to be extremely comprehensive, but with a steep learning curve, as it feels definitely aimed at the SDR experimenter.
So, why SDR#
then? Well, I acquired an airspy HF+ dual port.
I looked around for Linux support. Whilst GQRX
has support, I'm not that fond of the GQRX
UI.
Having to flip between tabs to change decode mode and zoom irks me. I like cubicsdr
, but afaict
airspy support for that never really landed.
I was working along with GQRX
fairly OK with the airspy, but was suffering a huge amount of
background noise on some bands. I looked into noise removal options, and apart from the apparently
really good option in linrad
, found few. But look, there are a myriad of options on Windows
software, and a whole bunch of plugins for SDR#
... hence, my drive
to try SDR#
, but with no Windows machine.
Go grab SDR#
from the airspy downloads page. Untar that
file into a directory somewhere. (I used ${HOME}/bin/spyserver
, as you will see in the
scripts below).
Note: I should note here - that I tried to run the community plugin enhanced version of
SDR#
here once, but it failed to run. I'm not sure why - it might be something to do with being 'skinned', and I think you can download an un-skinned version to try. Instead I hand-copied over the plugins I was interested in into my already workingSDR#
rather than try to debug it further.
The route to running Windows programs under Linux, without having to set up a virtual machine
with Windows inside it, is to try Wine - an emulator. Experience shows
that it can be a bit of a pain to set up, and sometimes it works and sometimes it does not. In
this case, it looks like it can be made to work for SDR#
!
The requirements I found to run SDR#
under wine were:
- Install .NET 48
- Install the 'verdana' font
And, iirc, that was about it. Oh, and you must use wine32
, not wine64
!
I used `winetricks to help me configure my Wine - it makes life much easier.
I used Wine version wine-5.0
. You may be able to use other versions - I've not tried.
I set up a separate Wine
config dir in order to separate out my specific setup for SDR#
rather
than share a setup with other apps. This lets me experiment whilst isolatin it from any other
Wine based apps I might have set up. I happed to use ${HOME}/prefix32
, as you'll see in the
below scripts.
First, let's run up winetricks
. I use the script:
WINEPREFIX="$HOME/prefix32" WINEARCH=win32 ./winetricks
Then install the dotnet48
DLL, and the verdana
font. You will get a lot of dialog boxes
and a lot of messages and warnings etc. I just clicked through with OK or the defaults. It should
ultimately 'complete'. Yes, it seems anything to do with Wine and installing components or running
applications is 'noisy'.
Once you are completed installing with winetricks
, quit it, and we'll move to installing
spyserver
next. Later we will run SDR#
itself under Wine
.
For reference, here are the contents of my winetricks.log
file from my working installation:
w_workaround_wine_bug-34803
remove_mono
remove_mono
winxp
dotnet40
dotnet48
andale
arial
baekmuk
verdana
Are there any limitations to this? Well, one minor-ish one that is not that big of a problem.
Ideally we'd just plug the airspy into the machine running Wine, and it would all work. Sadly
that requires the use of a Windows USB driver to communicate with the airspy, and Wine does not
support Windows drivers (but there is maybe on-going work in Wine to support that in the future).
The workaround is to run the airspy Linux spyserver
locally on the same machine, and connect
the Wine SDR#
to the local machine network and thus to the spyserver. This works fine. You may
get a slightly reduced amount of waterfall bandwidth than you would if you had a direct connection,
but no different than if you were accessing any other remote airspy server device.
Let's start with running the local spyserver. First local the download on the
airspy download page. You are almost definitely running Wine on
an x86 Linux machine, so you'll need the Linux x86
download.
You'll need to set up a spyserver.config
file. The key item is to leave the bind_host
as 0.0.0.0
to represent this machine
. Here are the non-comment lines from my config file I use
for my airspy HF dual port
:
bind_host = 0.0.0.0
bind_port = 5555-6666
list_in_directory = 0
owner_name = XXXXX
owner_email = XXXX@YYYYY
antenna_type = Home made youloop
antenna_location =
general_description =
maximum_clients = 1
allow_control = 1
device_type = Auto
device_serial = 0
fft_fps = 50
fft_bin_bits = 20
initial_frequency = 7100000
buffer_size_ms = 50
buffer_count = 10
And then running the spyserver
is as simple as:
sudo ./spyserver
It needs to be run as sudo
(the root user) to have enough permissions to both open the device
and the network connections iirc. Leave spyserver
running so we can connect SDR#
to it.
Now we can finally try and run up SDR#
under Wine. We'll initially do this via a Wine DOS/cmd
prompt, as that may help us with any necessary debugging:
WINEPREFIX="$HOME/prefix32" WINEARCH=win32 wine cmd
This should place you at a 'DOS' prompt - actually, in Wine. Navigate to where you placed
your untar'd SDR#
binaries, and try running it:
Z:>.\SDRSharp.exe
With luck you will get the airspy splash screen appear, and shortly after the UI will appear.
You will also notice there are many warning
s and fixme
s streaming up in the terminal
where you ran Wine. Yep, as I said, noisy!. Just ignore them, unless you find SDR#
is not
working.
Once in the UI, look at the top left hand side and see if your device appears to be connected
to. Locally I use the string 127.0.0.1:5555
as the connection.
Given it all works, congratulations! If it does not work, well, hmm, you may just have to debug
it. I have found that sometimes SDR#
will crash the first time you run it, but works on a second
run. It also seems to get a bit unhappy if you run it and the last spyserver you used is no longer
online. Have a play, and good luck.
Locally I run SDR#
directly and not via a cmd
prompt, by simply modifying a script to look
like:
WINEPREFIX="$HOME/prefix32" WINEARCH=win32 wine ${HOME}/work/sdrsharp/SDRSharp.exe
Here is a shot of SDR#
running connected to my local spyserer airspy HF+ dual port. It was mid
morning, connected to my home-made youloop at my desk, so the band is a little queit (but, still
some activity).
And here was the output from my local spyserver
for that connection:
sudo ./spyserver
SPY Server v2.0.1700
Copyright (C) 2016-2018 Youssef Touil - https://airspy.com
Reading the configuration file: spyserver.config
Listening for connections on 0.0.0.0:5555
Accepted client 127.0.0.1:57104 running SDR# v1.0.0.1732 on Microsoft Windows NT 6.1.7601 Service Pack 1
Device was sleeping. Wake up!
Acquired an AirspyHF+ device
Client disconnected: 127.0.0.1:57104
No clients using the device. Sleeping...
Releasing the AirspyHF+ device
I have used spyserver
on Linux for both an airspy HF+ dual port
and an
rtl-sdr V3
with my Wine SDR#
, and both
worked fine. A few details are below:
This is the device I normally run locally, and it works fine. I've not really tried optimising it by varying the waterfall refresh rates, FFT sizes or buffers. Maybe one day.
I've used the dongle in both direct
and normal
modes. You will have to modify the spyserver
config file appropriately to use the Q input for direct sample (HF) mode for instance.
Hey, np. Glad it is of use to somebody :-) tbh, I've not run this up for some time. I thought I remembered somebody commenting that if you installed some wine GPU acceleration plugins then things worked much faster - but, I cannot find that comment, so have no details to hand...