SpyServer: Airspy Streaming Server Now Released
SDR# has just been updated to version 1525 (changelog) and it now includes a new program called ‘SpyServer’. SpyServer is a Windows based streaming server for Airspy devices, and is somewhat similar to what rtl_tcp is for RTL-SDR devices. To run the server, all that you need to do is plug in the Airspy on the server PC and open the server software. Then on the remote PC select the ‘SpyServer’ radio source in SDR# and enter the server IP and default port.
We tested SpyServer with our Airspy R2 and found that it worked perfectly, however due to the very high data rates the maximum bandwidth cannot be used over a slow network. On a standard WiFi connection we were able to use a bandwidth of up to 250 kHz, and on a remote test server over the internet only 37.5 kHz. The author of SDR#, Youssef Touil however has mentioned that a gigabit network can support the maximum 10 MSPS bandwidth option with no problems. We assume that SpyServer will eventually be updated to include low bandwidth options which only stream compressed demodulated audio and waterfall data.
The SpyServer is also implemented with a special multi client DDC architecture. This allows for many clients to connect to a single server, and they can each have a different frequency and bandwidth (within the current active bandwidth around the center frequency).
We think that the SpyServer should also work well with the upcoming Airspy HF+, an HF optimized SDR.
Any solution for working under 24 mhz with rtl-sdr ?
Would be nice to just integrate with SoapyRemote. It is way nicer than rtl-tcp and simmilar solutions, and widely supported
SDRPlay does not work with version 1525.
Simple fix: decompile the SDRPlay frontend DLL and implement canTune, minimumFrequencyTunable & maximumFrequencyTunable yourself (just as its defined in AirspyIO).
It’s a good idea to provide this kind of server.
A linux version would be fine, to use a airspy or airspy mini over network with raspberry pi.
mini @ 6MSPS will generate 24MB/second
mini @ 3MSPS will generate 12MB/second
100Mbit/sec NIC is 12.5MB/sec (if you include all packet overheads, or ~11.9MB/sec if you exclude all the packet overheads and are just looking at actual data)
So do you see any problem ? Squeezing 24, or even 12, into 11.9 – it just does not fit!
And there are other problems in using RPi hardware which only has one real actual USB 2.0 port uses a internal HUB chip (Microchip LAN9514) that also provides the 100Mbit/sec networking.
To run devices at full speed would require gigabit. When it comes to shoving large amounts of data about fast, just above an Arduino’s on my personal list would be the Raspberry Pi line of hardware. It was designed to be as cheap as possible, and many decisions were made to achieve that goal.
You’re right Bertie, but as mentioned on the blog post, if we use reuced bandwith it should be fine. Ex: a 250 khz bandwith served by a raspberry pi 2 or 3.
On a R Pi-3 with an 820T SDR and 802.11N wifi usb stick connected at 300Mbps I’ve been pulling 3.2 Ms or just under 7 MBytes/sec fwiw
and btw that’s with the ol’ RTL_TCP server on the pi
To me it seems, the “modrtlsdr” frontend plugin stopped working, after installing this version. SDR# does not even detect the plugin, despite my attempts to force it to load. Previosly I had not even added the line to “Frontends”, it worked anyway. Adding it does not help.
rgds
Peter SM5GXQ
Same here, I am struggling with this problem this version unable to detect modertlsdr plugin. What to do now?
From what I have read the frontend interface has changed, Vasili will need to update the plugin on rtl-sdr.ru to provide new properties before it will work with the latest version of SDR#. So use an older version for now or wait are the options.
Vasili has fixed this now!
rgds
Peter
Am I right that with this driver there is a gap in near 11 to 14 mhz? With this driver I can go down to 666khz but at 1 to 7Mhz there is to much static noise, I am using random copper wire to pickup hf, is there any way to make noise floor smooth as vhf mode.
Any word on an update to Astrospy?
Dear Youssef, Please could you tell us is the AIRSPY is working with Matlab to receive data as the others RTL,
How can I do that. Warm regards
I’m not Youssef, but to get an Airspy to work with Matlab will require someone to write Matlab simulink interface files. Which with all the examples available for other SDR devices, should be easy enough for someone to write if they own Matlab and have purchased licenses for Simulink.
e.g
RTL-SDR Matlab simulink interface files – https://github.com/kit-cel/simulink-rtl-sdr
HackRF Matlab interface files – https://github.com/kit-cel/simulink-hackrf
BladeRF Matlab interface files – https://github.com/Nuand/bladeRF/tree/master/host/libraries/libbladeRF_bindings/matlab
LimeSDR Matlab interface files – https://github.com/jocover/Simulink-MATLAB-LimeSDR
And also if you do not need real time access to hardware, and are able to work with historic recordings. You could always read in IQ files and process them (provided you have enough memory or small enough recordings) – http://gnuradio.org/redmine/projects/gnuradio/wiki/Octave
Me personally I do not think that developing MEX interfaces files for Matlab is something that Youssef should be doing.
Youssef Touil, please design more functions in the spectrum spy utility…found frequency extraction to a list, frequency mask triggering for recording (like the real time spectrum analysers) or block out areas…
with multiple scan ranges in one window. waterfall saving and scrolling at variable speed. alert sound when a signal is detected…triggered sdr# and more…