osmocom-sdr

Download

osmocom-sdr@lists.osmocom.org

January 2023

2 participants
2 discussions

Re: [patch] Pass additional library arguments to ld
by Paul R. Tagliamonte 10 Jan '23

10 Jan '23

I did send this to the right place! I had to go onto IRC to confirm - and someone was nice enough to start a review. May be good for others waiting for feedback to join the IRC and do the same. I suspect this ML is a bit disused for contributions. From the conversation on IRC which I'm putting into the email thread to keep everything in one place, here's what I learned: MSVC requires this manual path work, so the first patch isn't going to work, since those values need to be hardcoded for that platform. This just leaves patch #2 for review. After a bit of confusion during the review regarding cmake's behavior and how the CMake in rtl-sdr was causing the build failure not cmake itself (confusion here may explain why no one triaged?) the feedback on the review *appears* to be: | <> so something like https://pastebin.com/CxXiGakh | <> the "beauty" is that this does not just add random lib search paths to | the targets that affect the other libs (which we don't have) Pastebin contents at the bottom at [0]. I have not revised the patches to use this approach, and I don't think I plan to - I haven't gotten very positive vibes on contributing (nor any indication anyone seems to mind the build system is broken?), so I'm not driving this anymore. If the core team needs someone to do the work, maybe another contributor will step forward in a few months. There's also a related PR against the mirror as PR 68, which fixes this issue -- turns out it impacts OSX (not just OpenBSD) at https://github.com/steve-m/librtlsdr/pull/68 -- it has another solution I overlooked -- using LIBUSB_LINK_LIBRARIES. I can confirm this patch also works on OpenBSD. If someone wouldn't mind merging one of the three patches or taking none of them with an independent fix, I'd be very grateful to get this off my mental queue. As I I said on IRC I'd leave it here and help review any patches the team comes up with if they want testing before a push. I'm no longer driving these patches or trying to drive them into main. I don't even run OpenBSD; this was a fix I wanted to send in when I hit a build failure targeting a friend's OS choice figuring it'd be a helpful time-saver for the project and its users after I debugged where exactly the librtlsdr CMake was broken and fixed it locally. paultag [0]: | if(PKG_CONFIG_FOUND) | pkg_check_modules(LIBUSB libusb-1.0 IMPORTED_TARGET) | if(LIBUSB_FOUND) | find_library ( | LIBUSB_LIBRARIESX | NAMES ${LIBUSB_LIBRARIES} | PATHS ${LIBUSB_LIBRARY_DIRS} | ) | set(LIBUSB_LIBRARIES ${LIBUSB_LIBRARIESX} CACHE INTERNAL "full libusb path") | #message(WARNING ${LIBUSB_LIBRARIES}) | endif() | else() | set(LIBUSB_LIBRARIES "" CACHE STRING "manual libusb path") | set(LIBUSB_INCLUDE_DIRS "" CACHE STRING "manual libusb includepath") | endif()

1 0

gr-osmosdr bias-tx runtime switching feature request
by Paul Bongaerts 01 Jan '23

01 Jan '23

Hello everyone, I would like to know if it's possible to switch the bias-tee / phantom power to the hackrf one at runtime in the osmocom-sink block. At the moment it's possible to change the gains and switch the 14 db amp at runtime. Only the bias-tee is en/disabled with device arguments "hackrf=0,bias-tx=0|1" which must be set at startup. Would like to be able to switch this when the flowgraph is running. I haven't figured out how to change device arguments after startup. Or would this require a change on the sink block adding something like a bias-tee option? Thanks and best wishes for the new year. Paul

1 0