pothosware / SoapyUHD

Soapy SDR plugins for UHD supported SDR devices
https://github.com/pothosware/SoapyUHD/wiki
GNU General Public License v3.0
55 stars 29 forks source link

uhd_usrp_probe is not working #22

Closed shahram-WINS closed 5 years ago

shahram-WINS commented 5 years ago

Hello I am trying to connect to my usrp b210 remotely. I can execute without any issue following commands: uhd_find_devices SoapySDRUtil --find and --probe and I can run them locally and remotely. The only problem i am facing right now, is when I run uhd_usrp_probe. If I run it locally: Although its works after downloading the required images by executing uhd_images_downloader.py but the SoapSDRUtil --probe is not working anymore and it gives me the following error: Expected FPGA compatibility number 14 but got 16, in order to fix this i need to download the older version of fpga images from ettus website (version 11), but, now SoapySDRUtil --probe works and if I run uhd_usrp_probe it would return the same error in the reversed version: Expected FPGA compatibility number 16 but got 14 Now if I run it remotely: if the server use the latest fpga images downloaded by the python file i will face with same error in the client:

RemoteError: RuntimeError: Expected FPGA compatibility number 14, but got 16: The FPGA build is not compatible with the host code build. Please run: "/usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"

but if I use the older fpga images in the server i will face with following error in the client:

$uhd_usrp_probe --args="driver=remote,remote=192.168.1.40,remote:type=b200"

linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; UHD_3.14.0.0-release -- Detected Device: B210 -- Operating over USB 3. -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... -- pass -- Performing register loopback test... -- pass -- Performing CODEC loopback test... -- pass -- Performing CODEC loopback test... -- pass -- Setting master clock rate selection to 'automatic'. -- Asking for clock rate 16.000000 MHz... -- -- Actually got clock rate 16.000000 MHz. -- Performing timer loopback test... -- pass -- Performing timer loopback test... -- pass / uhd_usrp_probe: /usr/include/boost/smart_ptr/shared_ptr.hpp:734: typename boost::detail::sp_member_access::type boost::shared_ptr::operator->() const [with T = uhd::property_tree; typename boost::detail::sp_member_access::type = uhd::property_tree*]: Assertion `px != 0' failed. Aborted (core dumped)

guruofquality commented 5 years ago

Probe goes through a lot of the properties, it could be exposing a bug of a property that is not filled in. Can you share a backtrace from gdb when the crash occurs?

shahram-WINS commented 5 years ago

debug.txt

guruofquality commented 5 years ago

debug.txt

Is that strace? I need to know the stack trace to know which function in soapysdr or usrp support library crashed, this is just system calls.

Make sure the fpga and firmware images are to to date and run:

gdb --args uhd_usrp_probe --args="driver=remote,remote=192.168.1.40,remote:type=b200"
>>> run
>>> #now let it crach
>>> backtrace #this gives us the stack trace for the crash
shahram-WINS commented 5 years ago

Thank you for your guidance. This is the output for the backtrace: Thread 1 "uhd_usrp_probe" received signal SIGSEGV, Segmentation fault. 0x0000000000410f34 in uhd::property& uhd::property_tree::access(uhd::fs_path const&) () (gdb) backtrace

0 0x0000000000410f34 in uhd::property& uhd::property_tree::access(uhd::fs_path const&) ()

1 0x00000000004095e5 in get_device_pp_string(boost::shared_ptr) ()

2 0x000000000040d99f in _main(int, char**) ()

3 0x0000000000404c66 in main ()

guruofquality commented 5 years ago

I could not replicate this. I have a B210 and latest master branch of UHD (UHD 3.15.0.git-1814-ge0e61a5a) and SoapyUHD.

I ran the server: sudo SoapySDRServer --bind

And ran the probe: uhd_usrp_probe --args="driver=remote,type=soapy,remote:type=b200"

no segfault

guruofquality commented 5 years ago

I hope this is just an issue with a specific version of uhd, perhaps something they fixed already. Closing for now. Please reopen if otherwise, or make a pull request.