openwebrx working with SDRPlay RSP2 on Raspberry Pi2B
Posted: Mon Jul 31, 2017 10:54 am
openwebrx provides web browser access to a range of SDRs for multiple simultaneous remote users.
I followed the procedure set out here:
http://ha5kfu.sch.bme.hu/openwebrx-quick-setup
Branching off to accomodate the Raspberry Pi here:
https://github.com/simonyiszk/openwebrx ... berry-Pi-2
Unfortunately when attempting to run openwebrx it failed to start , returing a Soapy make error every time. It took a lot of head scratching and source code reading to find this solution:
The operating instructions for openwebrx require the editing of it's config/preferences file config_webrx.py, eg:
#>> The rx_sdr command works with a variety of SDR harware: RTL-SDR, HackRF, SDRplay, UHD, Airspy, Red Pitaya, audio devices, etc.
# It will auto-detect your SDR hardware if the following tools are installed:
# * the vendor provided driver and library,
# * the vendor-specific SoapySDR wrapper library,
# * and SoapySDR itself.
# Check out this article on the OpenWebRX Wiki: https://github.com/simonyiszk/openwebrx ... OpenWebRX/
# start_rtl_command="rx_sdr -F CF32 -s {samp_rate} -f {center_freq} -p {ppm} -g {rf_gain} -".format(rf_gain=rf_gain, center_freq=center_freq, samp_rate=samp_rate, ppm=ppm)
I found that not to be the case, it was the auto-detection that failed for me and I had to specify the sdrplay driver in the <b> rx_sdr</> parameters like so:
start_rtl_command="rx_sdr -f {center_freq} -d driver=sdrplay -g 5 -F CF32 -s {samp_rate} -p 0 -".format(rf_gain=rf_gain, center_freq=center_freq, samp_rate=samp_rate, ppm=ppm)
The resulting good bits:
1. openwebrx is very stable and works very well in the browsers I tested (macOSSierra Safari and Chrome) with more than adequate waterfall resolution and only a few milliseconds audio delay.
2. even with the optional adpcm audio and FFT waterfall compression turned off, with a sampling rate samp_rate = 500000 the Pi used only 25% of it's processing power.
3. eight simultaneous remote web users raised that to 85% and produced more than occasional audio buffer underruns. Of course you can up the buffer size in the config file at the expense of increased delay.
4. it also works surprisingly well on an iPad
The limitations:
1. the openwebrx software does not provide any mechanism for changing your sdr oscillator frequency so you are limited to "frequency bands" of a width set by your sample rate. That limit on my Pi2B was 2048000 before the Pi ran out of grunt for a single user.
2. openwebrx provides a limited set of user control in the browser (html/javascript socket messaging) for waterfall colours, audio level, etc with mouse driven frequency and waterfall manipulation.
3. changing the oscillator frequency requires a quick edit of the config file and a restart of the python script which is fine if you have local access but cannot be done remotely.
4. SDRPlay SP1 functionality only is currently supported via the config file, despite the rx_tools code internally recognising my RSP2 (using the --probe test option) and providing RSP2 support for antenna switching etc.
Conclusion:
It's really exciting to watch your SDRPlay waterfall and listen to it's audio with only a few milliseconds delay for a radio ham like me listening to any given band on my 160m loop antenna when remote from my home radio shack. I know all that is possible and more using commercial systems like Flex but to roll your own on a Pi using open source software is a great step in the right direction.
PS. I'd like to thank the SDRPlay team and it's outstanding individuals for providing such an accessibly priced and excellent piece of hardware and commend their continued success, it really really does perform well even against my best ham radio hardware.
I followed the procedure set out here:
http://ha5kfu.sch.bme.hu/openwebrx-quick-setup
Branching off to accomodate the Raspberry Pi here:
https://github.com/simonyiszk/openwebrx ... berry-Pi-2
Unfortunately when attempting to run openwebrx it failed to start , returing a Soapy make error every time. It took a lot of head scratching and source code reading to find this solution:
The operating instructions for openwebrx require the editing of it's config/preferences file config_webrx.py, eg:
#>> The rx_sdr command works with a variety of SDR harware: RTL-SDR, HackRF, SDRplay, UHD, Airspy, Red Pitaya, audio devices, etc.
# It will auto-detect your SDR hardware if the following tools are installed:
# * the vendor provided driver and library,
# * the vendor-specific SoapySDR wrapper library,
# * and SoapySDR itself.
# Check out this article on the OpenWebRX Wiki: https://github.com/simonyiszk/openwebrx ... OpenWebRX/
# start_rtl_command="rx_sdr -F CF32 -s {samp_rate} -f {center_freq} -p {ppm} -g {rf_gain} -".format(rf_gain=rf_gain, center_freq=center_freq, samp_rate=samp_rate, ppm=ppm)
I found that not to be the case, it was the auto-detection that failed for me and I had to specify the sdrplay driver in the <b> rx_sdr</> parameters like so:
start_rtl_command="rx_sdr -f {center_freq} -d driver=sdrplay -g 5 -F CF32 -s {samp_rate} -p 0 -".format(rf_gain=rf_gain, center_freq=center_freq, samp_rate=samp_rate, ppm=ppm)
The resulting good bits:
1. openwebrx is very stable and works very well in the browsers I tested (macOSSierra Safari and Chrome) with more than adequate waterfall resolution and only a few milliseconds audio delay.
2. even with the optional adpcm audio and FFT waterfall compression turned off, with a sampling rate samp_rate = 500000 the Pi used only 25% of it's processing power.
3. eight simultaneous remote web users raised that to 85% and produced more than occasional audio buffer underruns. Of course you can up the buffer size in the config file at the expense of increased delay.
4. it also works surprisingly well on an iPad
The limitations:
1. the openwebrx software does not provide any mechanism for changing your sdr oscillator frequency so you are limited to "frequency bands" of a width set by your sample rate. That limit on my Pi2B was 2048000 before the Pi ran out of grunt for a single user.
2. openwebrx provides a limited set of user control in the browser (html/javascript socket messaging) for waterfall colours, audio level, etc with mouse driven frequency and waterfall manipulation.
3. changing the oscillator frequency requires a quick edit of the config file and a restart of the python script which is fine if you have local access but cannot be done remotely.
4. SDRPlay SP1 functionality only is currently supported via the config file, despite the rx_tools code internally recognising my RSP2 (using the --probe test option) and providing RSP2 support for antenna switching etc.
Conclusion:
It's really exciting to watch your SDRPlay waterfall and listen to it's audio with only a few milliseconds delay for a radio ham like me listening to any given band on my 160m loop antenna when remote from my home radio shack. I know all that is possible and more using commercial systems like Flex but to roll your own on a Pi using open source software is a great step in the right direction.
PS. I'd like to thank the SDRPlay team and it's outstanding individuals for providing such an accessibly priced and excellent piece of hardware and commend their continued success, it really really does perform well even against my best ham radio hardware.