ha7ilm / openwebrx

Open source, multi-user SDR receiver software with a web interface
https://sdr.hu/openwebrx
GNU Affero General Public License v3.0
980 stars 462 forks source link

No configuration example available for openwebrx via SoapyRemote #114

Closed metssigadus closed 6 years ago

metssigadus commented 6 years ago

My configuration: [1(RTL-SDR)+2(SDRPlay)] <-> [SoapyRemote installation] <-> [*x(OpenWebRX installation)].

SoapySDRUtil at the client/OpenWebRX computer is correctly enumerating the remote resources from the server: SoapySDRUtil --find="remote=1.1.1.1" [..] Found device 2 driver = remote label = SDRplay Dev1 RSP1A 255 1111111111 remote = tcp://1.1.1.1:55132 remote:driver = sdrplay

In case of sdr-rtl the error msg from OpenWebRX says: "No supported devices found." "NameError: global name 'clients_mutex' is not defined". In case of sdrplay the significant error msgs are: "Found 0 antenna(s):" [..] n*"WARNING: sync read failed. -5".

The problem: no clear syntax example available about how to make OpenWebRX aware of the remote resources. No idea how to markup these resources in config_webrx.py.

Extra information for possible glues: Avahi is not an option (due to routed networks). 3x(OpenWebRX) were functioning whilst resources were locally connected. The versions are the latest (git cloned a couple of hours ago). SoapyRemote on the client computer was compiled as the last item.

ha7ilm commented 6 years ago

Hi @metssigadus,

It looks like this is not a problem with OpenWebRX. Please test your command in itself. It is outputs the I/Q samples to the standard output, then it should be working with OpenWebRX.

If you know how to interface remote SoapySDRs with OpenWebRX, then you could extend the wiki with that information.

metssigadus commented 6 years ago

Well, my problem has been solved now and everything is working as planned.

For a remote RTL-SDR dongle:

config_webrx.py snippet for RTL-SDR

start_rtl_command="rx_sdr -d driver=remote,remote=tcp://10.10.1.118:55132 -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) format_conversion="csdr convert_u8_f"

For both instances of SdrPlay:

config_webrx.py snippet for SDRPlay

soapy_device_query="driver=remote,remote=tcp://10.10.1.118:55132" start_rtl_command="rx_sdr -d {device_query} -F CF32 -s {samp_rate} -f {center_freq} -p {ppm} -g {rf_gain} -".format(device_query=soapy_device_query, rf_gain=rf_gain, center_freq=center_freq, samp_rate=samp_rate, ppm=ppm) format_conversion=""


My utmost confusion was due to the unclear semantics of rtl_tcp and rtl_sdr . (probably one will need to further clarify their purpose in manuals & help texts):

a) rtl_tcp is a server-side utility (and won't work at the client side). One of the CLEAR explanations is available here: https://www.welle.io/devices/rtl_tcp . I should say, renaming it to e.g. rtl_srv could avoid the confusion.

b) rtl_sdr seems not to take "remote device" arguments, only [[:digit:]] to enumerate the device.

And, of course, the launching order is important on both sides to achieve the situation where each frequency band will be served by a proper SDR with somewhat correct antennas for that band. I do not see the option to use serial numbers as identificators, although SoapyRemote makes these ID's available.

Anto Veldre, ES1LAU

On 2018-06-04 13:16, András Retzler wrote:

Hi @metssigadus [1],

It looks like this is not a problem with OpenWebRX. Please test your command in itself. It is outputs the I/Q samples to the standard output, then it should be working with OpenWebRX.

If you know how to interface remote SoapySDRs with OpenWebRX, then you could extend the wiki with that information.

-- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [2], or mute the thread [3].

Links:

[1] https://github.com/metssigadus [2] https://github.com/simonyiszk/openwebrx/issues/114#issuecomment-394305134 [3]

https://github.com/notifications/unsubscribe-auth/AbYyvPiSLEhqgDTWL_RMBeUxQgfpD7Geks5t5QkDgaJpZM4UYUaq

ha7ilm commented 6 years ago

I'm happy that it's solved. Thanks for sharing those informations.