search

fairwaves / UHD-Fairwaves

Fairwaves version of the UHD drivers, tweaked to support Fairwaves UmTRX.
http://umtrx.org
24 stars 21 forks source link

UHD 4 port #30

Closed dsseng closed 9 months ago

dsseng commented 9 months ago

Fix incompatibilities from UHD version 4 to make UHD-Fairwaves build with UHD 4.

~Might break compatibility to libuhd 3.~ ~That was obvious 58b4d869d48cf7b44ba4cb90cbf3f0e7f6f27100 broke libuhd 3. If the upstream project is alive and willing to accept this, I'm going to make build process changes to detect libuhd 3 and change pointer types between std and Boost.~ Now fixed.

Build-tested on Fedora's libuhd UHD_4.4.0.0 with GCC 13 and Clang 16 and UHD 4.5 from repos and 3.15 from git on Arch with GCC 13.

~uhd_find_devices detection is broken~ was doing in a wrong prefix. Works like a charm now. Testing is not comprehensive, but looks ok. Radio RX, uhd_find_devices, uhd_usrp_probe, latency_test, usrp_list_sensors all work.

Thanks for UmTRX, it's an amazing tool!

chemeris commented 9 months ago

Would be happy to accept if you could fix the UHD3 compatibility

dsseng commented 9 months ago

Oh, nice to hear back! Will do so (via CMake defines probably), its anyway better than maintaining my fork.

dsseng commented 9 months ago

@chemeris Done, feel free to review and check (maybe run more comprehensive tests to check all the functions on both uhd3 and uhd4). This shouldn't really regress as it's mostly cosmetic if UHD_VERSION is less than 4000000. On my side it worked with my customized 3.15 build and Arch 4.5.

Please don't merge with squash. If it's an absolute necessity, I can manually rebase and squash UHD3 compat commits into corresponding ones.

dsseng commented 9 months ago

srsRAN seems to hang on exit now. Will investigate if this is related in some time

That's likely https://github.com/fairwaves/UHD-Fairwaves/issues/29, validating with 3.15 to ensure

dsseng commented 9 months ago

Yes, on 3.15 it makes no difference in behavior whether master or uhd4 is being used, it still finishes with a timeout

dsseng commented 9 months ago

@chemeris is this acceptable now? I've tested it with GNU Radio receive and transmit examples. Calibration doesn't work due to Python errors (is it Python2?)

dsseng commented 9 months ago

We managed to configure and run an OsmoBTS node using UmTRX and UHD version 4.5 on Arch Linux. The only annoyance is #29 making us to kill the osmo-trx-uhd process, which isn't a regression (I didn't manage to troubleshoot it in my time). I think this PR is now tested well enough.

I have no time for Python fixes currently, but will consider sending them out later. Anyway, they are independent from C++ ones.

dsseng commented 9 months ago

Thanks!