Closed gasparka closed 5 years ago
In fact it leaves APT in a broken state, it tries to execute post-install scripts for anything you install/remove and always fails.
I had to manually remove the postsctipts in /var/lib/dpkg/info:
sudo rm limesuite-images18.04:amd64.postinst
Installing on Ubuntu is a total nightmare. I took next line from the guide at https://wiki.myriadrf.org/Lime_Suite, and:
$ sudo apt-get install soapysdr soapysdr-module-lms7
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package soapysdr
soapysdr is renamed to soapysdr-tools.
I now have LimeSuite installed and can open device in the GUI. SoapySDR --probe
does not see it, even thought the module reports as being installed:
~$ SoapySDRUtil --info
######################################################
## Soapy SDR -- the SDR abstraction library
######################################################
Lib Version: v0.6.1-2
API Version: v0.6.0
ABI Version: v0.6
Install root: /usr
Search path: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6
Search path: /usr/local/lib/x86_64-linux-gnu/SoapySDR/modules0.6
Search path: /usr/local/lib/SoapySDR/modules0.6
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6/libHackRFSupport.so
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6/libLMS7Support.so
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6/libRedPitaya.so
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6/libairspySupport.so
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6/libaudioSupport.so
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6/libbladeRFSupport.so
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6/libosmosdrSupport.so
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6/libremoteSupport.so
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6/librtlsdrSupport.so
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6/libuhdSupport.so
Loading modules... linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
done
Available factories...airspy, audio, bladerf, hackrf, lime, null, osmosdr, redpitaya, remote, rtlsdr, uhd,
Also tried to use Gqrx:
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.11
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
[INFO] Make connection: 'LimeSDR-USB [USB 3.0] 9060B00473821'
[INFO] Reference clock 30.72 MHz
[INFO] Device name: LimeSDR-USB
[INFO] Reference: 30.72 MHz
[INFO] LMS7002M calibration values caching Disable
FATAL: destination port 1 out of range for source_impl(47)
Trying to fill up 18446744073709551615 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.
terminate called after throwing an instance of 'std::invalid_argument'
what(): destination port 2 out of range for source_impl(47)
Aborted (core dumped)
In fact it leaves APT in a broken state, it tries to execute post-install scripts for anything you install/remove and always fails. I had to manually remove the postsctipts in /var/lib/dpkg/info:
--2018-10-18 09:28:15-- http://downloads.myriadrf.org/project/limesuite/18.04/ExtIO_LimeSDR_1.04.dll Reusing existing connection to downloads.myriadrf.org:80. HTTP request sent, awaiting response... 403 Forbidden: body content-type denied 2018-10-18 09:28:15 ERROR 403: Forbidden: body content-type denied.
It just seems like a random occurrence for some of the files, are you able to try the install again?
Trying to fill up 18446744073709551615 missing channel(s) with null source(s). This is being done to prevent the application from crashing due to gnuradio bug #528.
The osmosdr blocks may be pretty weird when they dont find any devices. Do you see the limesdr with the various tools mentioned? Or if not, does it work with sudo?
In fact it leaves APT in a broken state, it tries to execute post-install scripts for anything you install/remove and always fails. I had to manually remove the postsctipts in /var/lib/dpkg/info: --2018-10-18 09:28:15-- http://downloads.myriadrf.org/project/limesuite/18.04/ExtIO_LimeSDR_1.04.dll Reusing existing connection to downloads.myriadrf.org:80. HTTP request sent, awaiting response... 403 Forbidden: body content-type denied 2018-10-18 09:28:15 ERROR 403: Forbidden: body content-type denied.
It just seems like a random occurrence for some of the files, are you able to try the install again?
Everything went to normal after i deleted the post-install scripts, now i can remove/install the package without problems.
Trying to fill up 18446744073709551615 missing channel(s) with null source(s). This is being done to prevent the application from crashing due to gnuradio bug #528.
The osmosdr blocks may be pretty weird when they dont find any devices. Do you see the limesdr with the various tools mentioned? Or if not, does it work with sudo?
SoapySDRUtil --find="driver=lime"
finds the device. I was confused by the output of the --probe
command, which only opens the audio device. Is this expected behavior to only print info for the first device?
Also did some testing with gr-limesdr, which worked great! So i guess the Gqrx problem is Gqrx problem.
What we should do:
SoapySDRUtil --find="driver=lime" finds the device. I was confused by the output of the --probe command, which only opens the audio device. Is this expected behavior to only print info for the first device?
Its a lot of info, so it only prints the first one found. So you just need more specific arguments if you want to see a particular device, ex driver, serial number, ip address, etc
Also did some testing with gr-limesdr, which worked great! So i guess the Gqrx problem is Gqrx problem.
gqrx uses gr-osmosdr, which is different than gr-limesdr. So its probably gr-osmosdr
I dont know if the package is funny or its just an issue of command line arguments. There isnt a good command line osmo util to see what the libosmosdr sees interms of device discovery. What happens if you are explcit with the args. does "driver=lime,soapy=0" work?
Rename soapysdr to soapysdr-tools (what about older Ubuntu releases?)
I did update that on the wiki. This is rename on upstream ubuntu, so its going to be that name going forward, even when I upload new soapysdr ppa packages. Why fight it?
Something should be done differently when the post-script fails, currently it tries to execute again on every APT install/remove - essentially locks up the whole APT system.
There might be something better that can be done on error for that download script to keep apt in good shape. Presumably someones internet connection could go down, and I think there is a proper debian way to handle failure in these scripts. Maybe
https://github.com/myriadrf/LimeSuite/blob/master/debian/limesuite-images.postinst.in
Tried the install process again - works as expected. Guess i was just unlucky yesterday.
About GQRX: The default device string(below), suggested by GQRX, wont work due to the osmosdr issue.
addr=1d50:6108,driver=lime,media='USB 3.0',module=FX3,name=LimeSDR-USB,serial=0009060B00473821,soapy=2
driver=lime,soapy=0
- wont work either - device 0 is the audio driver?
driver=lime,soapy=2
- works!
Removing the 'module' and 'media' values from the default GQRX string fixes the problem:
addr=1d50:6108,driver=lime,name=LimeSDR-USB,serial=0009060B00473821,soapy=2
@csete. thoughts?
Gqrx is just a GUI and has no awareness of the hardware device. The device string is something returned by the backend.
Thanks, so it is a problem in OsmoSDR. Wondering if Lime is interested in maintaining the OsmoSDR support, now that the gr-limesdr is out?
Wondering if Lime is interested in maintaining the OsmoSDR support, now that the gr-limesdr is out?
It would certainly be possible to wrap gr-limesdr in osmosdr source/sink much like a few of the others like fun cube works this way, and uhd too.
The soapy stuff is just there for free and will support anything wrapped in soapysdr.
I dont get the soapy=index issue, the number doesn't actually matter, its just to fill in the value with something. If osmosdr source sees soapy=anything, it passes that whole string to the make_soapy_sink/source_c, which goes strait to the SoapySDR::Device::make() factory function, the same one used in the command line utility. This is the code if you see what I mean: https://github.com/osmocom/gr-osmosdr/blob/master/lib/source_impl.cc#L358
A few other device support sources/sinks is osmo will use this "support_key=number" paradigm to identify the device among multiple ones, but I never liked that since its not consistent. Serials are :-)
I have just tried installing on Ubuntu 18.04 VM, following instructions on https://wiki.myriadrf.org/Lime_Suite#Ubuntu_PPA and it installed without errors. I can see that Soapy package is now named 'soapysdr-tools' in the instruction so the instructions has been updated. For me it looks like this issue is no longer relevant. Closing.