Running Windows & x86 SDR Decoding Apps on the Raspberry Pi 3: Unitrunker, WinSTD-C, WXtoIMG, DSDPlus and more

There is a great advantage to running SDR decoder apps on a single board PC like a Raspberry Pi 3. For example instead of committing a whole PC to become a dedicated decoder, a cheap Pi 3 can be used instead. However, unfortunately many decoder apps are written for the x86 CPU architecture and/or Windows, making them impossible to run on ARM and/or primarily Linux devices like the Raspberry Pi 3.

That is unless you use an emulator combination like Eltechs Exagear and Wine. Exagear is an emulator that emulates an x86 environment on a device like a Raspberry Pi 3 which uses an ARM CPU. Wine is a Windows compatibility layer that allows you to run x86 Windows apps on an x86 Linux installation. So by combining Exagear together with Wine it is possible to run Windows apps on ARM Linux devices.

Exagear is not free (although there is a free trial). It currently costs $22.95 USD for a Pi 3 licence, and $16.95 USD for a Pi 2 licence and $11.45 for a Pi 1/Zero licence. They also have versions for Odroid, Cubieboard, BananaPi, Jetson and many other ARMv7 and ARMv8 devices like the super cheap and powerful Orange Pi’s. There are free alternatives out there like QEMU, however when we tested QEMU it was far too slow on the Pi 3 to even run notepad responsively, let alone a decoder. Exagear on the other hand seems to run apps at near native speeds, without much lag at all. So in this respect the price seems to be worth it.

We decided to test the Exagear + Wine combination on a Pi 3 and were successful in running a number of apps including Unitrunker, WinSTD-C, WXtoImg, DSDPlus, PC-HFDL, MultiPSK, Orbitron and Sondemonitor.

Trunking setup with Unitrunker on a Raspberry Pi 3

With Unitrunker we were able to set up a full trunk tracking system using two RTL-SDR dongles, rtl_fm, rtl_udp and a custom script to control rtl_udp.

Unitrunker running on a Raspberry Pi 3
Unitrunker running on a Raspberry Pi 3

In the future we may put up a full double checked tutorial with images, but for now a roughly written tutorial is presented below. The tutorial is fairly involved and assumes decent Linux experience. The tutorial starts from a fresh install of Raspbian.

The basic idea of operation is based around the fact that the RTL-SDR cannot be used directly within Wine (or so it seems). So the control signal audio is routed from rtl_fm running on one dongle into Unitrunker on Wine using alsa loopback. Then we use the old Unitrunker remote.dll method to generate a sdrsharptrunking.log file which is a text file that contains the current frequency that the voice receiver should tune to. A simple shell script continuously reads this file and extracts the frequency, and then commands an instance of rtl_udp running with the second dongle to tune to that frequency.

  1. Install the RTL-SDR drivers using “sudo apt-get rtl-sdr” or install from source.
  2. Do a git clone on the rtl_udp repo, and then compile the code. You may also need to use apt-get install to install cmake and libusb-dev and libusb-1.0-dev first. Note that we recommend not using make install as the final step, as the standard osmocom rtl_fm seems to run with less audio underruns.
  3. Purchase and install Exagear onto your system following their instructions. Note that we recommend not enabling FullGL as they suggest, as it seems to break too many things.
  4. Open an Exagear shell by typing in “exagear” within a regular shell. 
  5. Install wine with “sudo apt-get install wine”. Make sure to install wine within the Exagear shell, as Exagear repos provide a special version for the Pi.
  6. Now use a web browser to download the latest Unitrunker preview build. At the time of testing we used Unitrunker 33.6.
  7. Now in your Exagear shell browse to the .msi file, and use “wine msiexec /i UniTrunker-” to install it. You should be able to install it normally now.
  8. Next if you were to run Unitrunker right now it would probably complain about missing WinUSB.dll. In a web browser go to, and download a 32-bit version of winusb.dll. Note be careful on this website as there are a bunch of misleading ads. Just scroll down and click on the text download, not any of the images.
  9. Place this DLL into the ~/.wine/drive_c/windows/system32 folder.
  10. Now in your Exagear shell browse to “~/.wine/drive_c/Program\ Files/Unitrunker”, and try to run Uniform.exe with “wine Uniform.exe”. It may run, or you may get some errors stating that there are some further missing dlls. If there are missing dlls, search for them on the website, download the 32-bit versions and copy them into the system32 folder. Once you’ve copied all those dlls you should be able to open Unitrunker.
  11. But if you open Unitrunker now you’ll probably see that the buttons are all messed up. This is because Unitrunker uses the Windows Wingdings and Webdings fonts for its icons. To fix this use a real Windows PC to copy all the Wingdings and Webdings fonts over to your Pi (you might find downloads of these fonts online too). Place them in the ~/.wine/drive_c/windows/Fonts folder. Now you’ll probably need to restart your Exagear shell, or maybe the whole Pi to get these fonts registered.
  12. Now Unitrunker should run and the icons should look normal.
  13. Next plug in your two RTL-SDRs, and run in a regular non-exagear shell “sudo modprobe aloop”, this will set up a loopback audio device, like Stereo Mix in Windows.
  14. Next install sox with “sudo apt-get install sox”
  15. In another non-exagear shell run:
    rtl_fm -M fm -f FREQ -s 12.5k -g 20 -F 0 | sox -r 12.5k -t raw -e s -b 16 - -traw -r 48k -e s -b 16 -c 1 - | aplay -r 48k -f S16_LE -t raw -c 1 -D hw:Loopback,0,0", 

    replacing FREQ with your control channel. Remember to change the gain to what’s best for your RF environment, and set a PPM adjustment if necessary. This command line code takes the output of rtl_fm, converts it into a 48k sample rate, and then sends it to the loopback device silently. Using the standard rtl_fm -r resampler does not appear work.

  16. Open up Unitrunker and create a new Signal receiver, with the audio input as the Loopback device. If you’re tuned to a valid control channel the site box should pop up.
  17. Create a new Debug receiver, and set its mode to Voice.
  18. This should create some folders in your “~/.wine/drive_c/users/pi/Application Data/Unitrunker” folder that start with R and have a few numbers after. e.g. “R000001”
  19. Place the remote.dll from the Unilogger 1.5 zip file on this site (scroll down to the bottom) into those directories starting with R. Doing this will tell Unitrunker to generate the required sdrsharptrunking.log file.
  20. After doing this you may need to restart Unitrunker to get it to see the dlls. After restarting confirm that the sdrsharptrunking.log file is created in the “~/.wine/drive_c/users/pi/Application\ Data/Unitrunker/” folder.
  21. Next in your rtl_udp folder, create a shell script with the following (thanks to Jack McHugh’s video for the general idea). Edit the number after grep -i to be the first number in the voice frequencies that you are monitoring. Save it as
    while true
       freq=$(cat ~/.wine/drive_c/users/pi/Application\ Data/Unitrunker/sdrsharptrunking.log | grep -i 8 | sed 's/[^0-9]*//g' | cut -c1-9)
       if [ "$lastFreq" -ne "$freq" ]; then
          ./ freq $freq
  22. In another non-exagear shell browse to your “rtl_udp/build/src” directory and run: 
    ./rtl_udp -N -f 416.5875M -g 20 -d 1 -s 15k -l 50 | sox -r 15k -t raw -e s -b 16 -c 1 - -t raw -r 48k -e s -b 16 -c 1 - lowpass 750 vol 5 | aplay -r 48k -f S16_LE -t raw -c 1. 

    Setting the frequency correctly here is not critical because this will be changed by Unitrunker to the voice frequency. This outputs the audio to your speakers on the Pi 3 (HDMI or Analogue according to what you’ve set – HDMI is default if you have a HDMI monitor plugged in).

  23. In another non-exagear shell browse to your rtl_udp folder and run “sh”.

The shell script should now be using data from the sdrsharptrunking.log file to tune rtl_udp.

There are still some problems with this approach. First it seems that the rtl_fm and rtl_udp instances produce some audio underruns which cause choppy audio. They are not so prevalent as to stop decoding, but may sound slightly annoying. Secondly, the CPU usage with everything running seems to hover at around 75%. After running for a while the Pi 3 generates the thermometer icon on the top right, which indicates that it is close to overheating. A fan or heatsink may be beneficial.

It should also be possible to get this setup to interface with DSD+ for digital P25/DMR etc signals as well (DSD+ works in exagear+wine). But as of yet we haven’t figured out the audio routing for a third program. If anyone gets it working please let us know in the comments. We’ve tried Pulseaudio, but using Pulseaudio seems to crash Unitrunker and prevent it from running.

Another possibility could be using this to stream the voice online to RadioReference, Broadcastify etc.

Of course in the end it might be easier to use SDRTrunk instead, although it seems that many people still prefer Unitrunker.

Other Tested Software

WinSTD-C: We’ve also managed to get the Inmarsat STD-C decoder WinSTD-C running and decoding SafetyNET messages. To do this simply enable the loopback with “sudo modprobe snd-aloop”, then use the standard Osmocom rtl_fm and set the mode to “-m usb”. The latest version of the Osmocom RTL-SDR package even supports the bias tee on our RTL-SDR V3 with the “-T” flag, so it is easy to use an L-band LNA with it.

./rtl_fm -M fm -f 1541.449M -s 6k -g 40 -T | sox -r 6k -t raw -e s -b 16 - -traw -r 48k -e s -b 16 -c 1 - | aplay -r 48k -f S16_LE -t raw -c 1 -D hw:Loopback,0,0

We tried the Windows based Tekmanoid and STD-C decoders, but were unable to get those running on wine. The Tekmanoid program is Java based, so it should be possible to run that without emulation, but the author has not yet released a Linux version. For now it may also run on Wine, but we have not attempted to install Java on Wine yet.

Below is an image of the WinSTD-C software running on the Pi 3. We used the Outernet active ceramic patch antenna and a V3 dongle with bias tee on. As far as we know, this is the only way to get STD-C decoding operational on a Linux device, let alone Pi 3, since all the apps are written for Windows.

WinSTD-C Decoding Inmarsat STD-C on a Raspberry Pi 3
WinSTD-C Decoding Inmarsat STD-C on a Raspberry Pi 3

DSDPlus: DSD+ runs well on Exagear + Wine. Again to get going just like in the above examples first enable the loopback with “sudo modprobe snd-aloop”. Then open DSDPlus.exe with “wine DSDPlus.exe” from within an Exagear shell.

Using the Osmocom rtl_fm run the following line in a terminal. Note that here we used the -F flag to get a higher quality audio output. In our case on a DMR signal, running -F 9 seems to be necessary to get audio quality good enough for DSD to decode.

rtl_fm -M fm -f 416.5875M -s 12.5k -g 20 -F 9 | sox -r 12.5k -t raw -e s -b 16 - -traw -r 48k -e s -b 16 -c 1 - | aplay -r 48k -f S16_LE -t raw -c 1 -D hw:Loopback,0,0

WxToIMG: There is actually a Linux version of WxToImg, but it is compiled for the x86 architecture, so normally it cannot be run on ARM devices. But with Exagear it runs, and runs smoothly. We haven’t been able to set the audio pipes up correctly yet, but the GUI and terminal versions run fine with a .wav file input.

MultiPSK: Runs, but is quite slow, and seems to be a bit buggy.

PC-HFDL: Runs well.

Orbitron: Runs well.

SondeMonitor: Runs well.

SDRSharp: Unable to get working. Maybe require some work with installing Mono.

Orbitron & SondeMonitor Running
Orbitron & SondeMonitor Running on the Raspberry Pi 3

Other Notes

Exagear is available for Android as well, so it’s possible that some of these apps may also run on Android phones and tablets.

It should be possible to use Pulseaudio to create a full digital decoding system with Unitrunker. But currently using Pulseaudio seems to cause Unitrunker to not open.

rtl_fm generates some audio underruns. They only happen every 10-20 seconds though and don’t affect digital decoding much.

If there are any other Windows only or x86 only apps you’d like us to test, please let us know in the comments.

Notify of

Inline Feedbacks
View all comments

Haaaaaaaaaaallooo Admin. Jemand zuhause???

Your tutorial does NOT work!!!!

Example for DSD+ brimgs:

rtl_fm -M fm -f 416.5875M -s 12.5k -g 20 -F 9 | sox -r 12.5k -t raw -e s -b 16 – -traw -r 48k -e s -b 16 -c 1 – | aplay -r 48k -f S16_LE -t raw -c 1 -D hw:Loopback,0,0
aplay: main:612: invalid rate argument ’48k’
Found 1 device(s):
0: DE8MSH, R820T2, SN: 160318 65p

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Tuner gain set to 19.70 dB.
Tuned to 416987500 Hz.
Oversampling input by: 128x.
Oversampling output by: 1x.
Buffer size: 5.12ms
Allocating 15 zero-copy buffers
Sampling at 1600000 S/s.
Output at 12500 Hz.
Signal caught, exiting!

User cancel, exiting…

Which sox / aplay tools / version are you using?????


I did all things like described above. I testet DSD+, MixW32, Sondemonitor, etc. p. p.

Not only one program get sound from rtl_fm. Not only one spectrum shows signals.


…and BTW: Is is possible to use HDSDR and the RTLSDR together? Not the RTL_FM pipe, the direct use of the RTLSDL dll for the RTLSDR stick.


 admin: Must I choose Osmocom RTLSDR repo? I choosed Keenerds. Is Kennerds RTL_FM different from Osmocoms?

As I wrote: I had no luck with all oft the mentioned ham radio tools.


First, do you think it might be worth rebuilding some of the supporting software (like sox, the rtl-sdr drivers, or wine) with maximum optimizations (say, for an RPI3 in particular)?

Also, curious if similar could be shown with an SDRPlay RSP1, now with the price drop. Wouldn’t its 12bit ADC put more data throughput strain on the Pi?
(I found a relevant but old source to start with: )

Finally, Microsoft has some plans (probably already mostly working in lab?) for highly optimized windows for arm that’ll run x86 code seamlessly…


“..has some plans (probably already mostly working in lab?) for highly optimized windows for arm that’ll run x86 code seamlessly…”

BUT some of us do NOT want anything from them. I moved to Linux 20 years ago, for a reason, both personally and professional for a reason. I want nothing to do with them. And their various actions to get Pi’s running their software is nothing but standard 1A1 of the normal EEE, Embrace, Extend, EXTINGUISH!

Thats why I want to see as much stuff decodable/operating on Pi’s or any other ARM or AMD64 for desktops on Linux. Thats what makes things like OP25, SDRTrunk , Trunk Recorder etc. GREAT! For under $100 you can decode and listen to digital trunk systems that take $300 radios to do. A little more software and its streamed out on IceCast servers for truly transparent government.

This little article is interesting, as it gets the mostly ignored and overlooked EDACS protocol, and some others on Linux hardware… but to do so you have deal with several things I prefer not starting with WINE and then to the actual decoder itself.


OP25 et al, are GREAT for P25, BUT, NOT every PS system has moved to P25.

P25 is not the only game in town right now… but for Linux users like me, we are stuck…Dedicate old physical scanners to EDACS systems, or do without.

EDACS is quite prevalent in my area from PS to a LARGE REGIONAL power company.

And many may not move for many years, especially the public safety ones. Unless they are getting grants or something. One system is combing two systems into one. One is EDACS another is partial P25. Look for the encryption nuts to creep out on this one too. The one agency already tried it and failed miserably TWICE, but they will get it this time. They’ve already claimed 2 counties in another regional system. 3 more are claimed by using another large EDACS system. Which again the transition to P25 is way down the road. You can’t listen to that one any way, FULL TIME ENCRYPTION, on everything, including ESK. ESK is defeatable, but its the point of the matter.

In the end there could be 1 statewide P25 system for state agencies and few areas which don’t have the $$$ to spend on radios..and then probably about 10-12 regionalized systems that will gobble up the various existing Motorola SmartZone/Net, EDACS and P25 systems. I’ve already got one such… one on the way, and I look for a couple others in the immediate area shortly.

So OP25 is great, but not everything is P25 or Motorola, and won’t be for a while for some.

I’d love to see some EDACS capable Linux stuff for RasPi’s and AMD64, and other ARM boards.


First, You list a “Free Trial” for the Eltechs Exagear. I went to their site and forum, and they specifically list “NO FREE TRIAL.”

Second, just so you know. UniTrunker is the result of taking an ANONYMOUS 1997 post to UseNet and then turning it into “MTrunker” and then ETrunker and ETrunk48. Neal Fildes worked on this and then Mr. Parrish came along when Neal didn’t want to continue.

I would caution dealing with Mr. Parrish and Mr. Blanton. The CLOSED source from an original OPEN SOURCE project of UniTrunker to it being winslopper only. To many other shenanigans I could outline.

TREAD CAREFULLY in dealing with that stuff! YOU’VE BEEN WARNED!


Wonder if Argo will run on it for QRSS monitoring?


Uh, nice to see my rtl_udp is used – maybe time to upgrade 🙂



Can you check these two swiss army knifes for ham radio?



Thank you very much!



Thank you for the quick test. The underrrun thing: Is it just right after the Start of the programs? Or does it stay continuesly?

Other Q: Now if can use many of out beloved ham radio and SWL software on RPi, can you mediale a price reduction for writers with Eltech? *g

Jack McHugh

if you are monitoring a system other than 800 MHz you must change the the number after grep -i 8 to whatever the first digit of the frequencie you are monitoring is i.e. 400 MHz you would have grep -i 4.


OMG. I’m so exciting about the above mentioned stuff. My favorite tools I ever dreamt of to let run on RPi!!!

Thank you so much for this text.


Honestly when it comes to the Amazing Raspberry Pi. Orange Pi with Armbian etc, If it meant modifying a Windows application to run, I would rather not bother running it.

The most important part of my HAM radio hobby is the Science of Discovery and improvement.

Unless the hardware or Software is Opensource I cannot improve it, and there for it has Zero appeal to me.


Jack McHugh

You might like SDRTRUNK then by Denny Sheirer


Came here to say that! SDRTrunk is an excellent application that does the work of Unitrunker, DSD+, VAC, BUTT all in one simple app.


Can sdrtrunk to dmr trunk following?


SDRTrunk and Trunk Recorder are EXCELLENT options for STANDARD Motorola Type II, SmartNet, and P25 Phase I and Trunk Recorder for Phase II, BUT they do NOT do EDACS.

EDACS may be EOL, but I have many systems still using it, a few are in the process of transitioning to P25, but that is years away for some of them. So that leaves LARGE systems unusable under Linux. 🙁