UHD / USRP Support

[careyer]

Hi there,

is there a roadmap to also support UHD / USRP based SDRs like Ettus B205 / B210? Thanks!

[AlexandreRouma]

Hello,

the USRPs are already supported through the SoapySDR source.

I won't be able to add dedicated support for UHD though. I tried contacting ettus to see if they could lend me a low end model for development and contrary to every other SDR company they just told me to f* off...

[careyer]

Oh man... this is sad news! Indeed I have problems gettings the Ettus UHD/USRP driver to work correctly on my Windows 10 (always gives me that 0xc000007b windows error). Contacted ettus about that issue but they simply opt to not answer my inquiry at all. They are just ignoring me. That's what I call awesome support - made in Amerika!

Would you be be kind enough the give me some guidance on how to get SDR++ running with the help of SoapySDR? SDR++ does not offer a SoapySDR Source and installing the SoapySDR environment did not change anything. Maybe I performed some operation wrong? Any help would be greatly appreciated.

Keep up the excellent work! Cheers!

[AlexandreRouma]

All you need to do is install SoapySDR and SoapyUHD. on windows you can install PothosSDR and it'll install both automatically, and on linux you'll have to lookup the packages specific to your distro

[careyer]

I tried the "windows installer" from here https://github.com/pothosware/PothosCore/wiki/Downloads but to no avail.... it installed tons of things but no chnage on the behaviour of SDR++. Sorry... probably I am overlooking something?

[AlexandreRouma]

make sure you enabled the "Add to path" option

[AlexandreRouma]

Closing for inactivity, please reopen if the issue persists

[kistlin]

Hello,

I started integrating UHD devices. You can find the code on this branch feature/add_uhd_support.

A lot is still missing. I can find my device which is connected over USB through the built-in functionality of uhd and display it. And in addition record data. If it is working correctly I don't know yet. The reception is pretty bad at my current location. But there is a solid signal already.

Does something speak against input fields for gain, bandwidth, etc.? I would like to have a label, input field to enter the number and to the right displaying min. and max. values. Or is it not recommended with ImGui? The other source modules seem to have fixed steps in a drop-down menu.

[AlexandreRouma]

Hello, Using input fields to enter stuff is just not user friendly. Nobody needs a very specific sample rate, users will just chose what seems appropriate and don't need to dial in a specific samplerate or bandwidth. Having fixes easily divisible sample rates also improves resampling performance. Trying to resample 1945652samp/sec into 250000samp/sec for example will probably just result in a crash.

By the way, I had a look at the source code, I recommend you check out the code style requirements in the contributing.md

[careyer]

Hello,

I started integrating UHD devices. You can find the code on this branch feature/add_uhd_support.

A lot is still missing. I can find my device which is connected over USB through the built-in functionality of uhd and display it. And in addition record data. If it is working correctly I don't know yet. The reception is pretty bad at my current location. But there is a solid signal already.

Does something speak against input fields for gain, bandwidth, etc.? I would like to have a label, input field to enter the number and to the right displaying min. and max. values. Or is it not recommended with ImGui? The other source modules seem to have fixed steps in a drop-down menu.

Awesome! Goodto see that someone is working on UHD support! Is there aready a compiled version that I couldt try with my B210 UHD SDR? I'd like to help testing if needed. Cheers and keep up the good work!

[kistlin]

@careyer no there are no precompiled versions yet, sorry. Would you need a Windows version? I didn't make the CMakeLists.txt files work on Windows yet. But this shouldn't be a big issue.

For now I have to take care of the persistence (reading/writing the config), GUI and it sometimes hangs because talking with the UHD device takes some time. Especially when it automatically loads firmware onto the device. So the whole communication should probably be handled in a thread to make it more user friendly. So there is still quite some work ahead :).

@AlexandreRouma regarding the coding style.

Please use type* name for pointers.

Does this mean the asterisk is by the type, the name should not have a prefix like pName or would that be allowed or both.

Members: camelCase

Would it then be allowed to call the variables mCamelCase for members? Or should it be without prefixes in general?

[AlexandreRouma]

Avoid prefixes everywhere possible and use an underscore if really necessary. Another issue I saw is constructing members with a : after the constructor. This gets very messy and ugly, I only use it when absolutely necessary. I suggest you switch to initializeing the members directly where they are delcared everytime possible or in the constructor. Also, do like all other source modules and define the class member functions directly in the class declaration. You're already in a cpp file, defining them seperatly just makes the code more messy harder to work on (having to change stuff in two places instead of only one)

[careyer]

@careyer no there are no precompiled versions yet, sorry. Would you need a Windows version? I didn't make the CMakeLists.txt files work on Windows yet. But this shouldn't be a big issue.

Having a testversion for windows would be a dream and greatly appreciated! I can test on Linux as well but this will be limited to VirtualBox and in my case limited to USB2.0 speedss which is not ideal. Cheers!

[kistlin]

@careyer I couldn't get it to compile on windows. First there were incompatible compiler flags (/O2 and /RTC1) and after that a linker problem in frequency_select.cpp. A missing reference to window or something like that, most likely because of dllexport / dllimport statements (behind SDRPP_EXPORT)

namespace core {
    SDRPP_EXPORT GLFWwindow* window;
};

Maybe I messed it up when patching the compiler flags. I was using a recent version of MSVC 2019 64-bit and compiled Volk and UHD with the same toolchain. The rest was installed with vcpkg.

Maybe @AlexandreRouma knows something about that? I could change machines and give the exact message.

But there is progress, this is the current state.

Still open is the adaption to the coding guidelines. And I could not test the audio output.

@AlexandreRouma does the dsp streamer object take complex floats (32bit)?

[kistlin]

@AlexandreRouma do you mind looking over the code again? As a first version, this should be it atm. The code is in my view adapted to the guidelines. A simple verification would still be required.

Thank you!

[Josh-SMU]

All you need to do is install SoapySDR and SoapyUHD. on windows you can install PothosSDR and it'll install both automatically, and on linux you'll have to lookup the packages specific to your distro

This does not work, and building per the instructions with enabled USRP flags (and modifying config.json) also does not present UHD as an option in the dropdown.

How can we get this to work? Is it possible to have a build that just has all the main modules enabled by default instead of only a few? I still have not been able to make this work with my Ettus.

[kistlin]

@Josh-SMU on what platform are you?

does not present UHD as an option in the dropdown

The name UHD is from my old implementation that was not accepted. The name you should see is USRP.

Make sure you have the following entry in config.json

...
    "moduleInstances": {
        ...
        "USRP Source": {
            "enabled": true,
            "module": "usrp_source"
        }
    },
...

In the modules directory you need usrp_source.dll (or whatever the dll extension on your system is). And that usrp_source.dll can load its dependencies you need to make sure all dependent dll's are in the PATH. Meaning uhd.dll, according to the quoted comment probably somewhere in the installation directory of SoapySDR, and all its dependencies also need to be in the PATH.

Mine works and I'm currently using it on Windows. But I compiled uhd.dll myself.

[Josh-SMU]

Ok the moduleInstance is new to me and does make it appear in the list, thank you. I am on Debian Linux. However once selecting USRP it immediately crashes with erminate called after throwing an instance of 'std::runtime_error' what(): Key already exists Aborted

[Josh-SMU]

Anybody?