From nsugino at 3way.com.ar Thu Jan 3 17:48:30 2019 From: nsugino at 3way.com.ar (Nicolas Sugino) Date: Thu, 3 Jan 2019 14:48:30 -0300 Subject: [PATCH] Add api to get index by usb bus and port number Message-ID: <20190103174826.GA10146@SujaPC> This allows to get the device index based on the usb bus and port number Signed-off-by: Nicolas Sugino --- include/rtl-sdr.h | 12 ++++++++++++ src/librtlsdr.c | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+) diff --git a/include/rtl-sdr.h b/include/rtl-sdr.h index 3ed13ae..d1e3c1e 100644 --- a/include/rtl-sdr.h +++ b/include/rtl-sdr.h @@ -60,6 +60,18 @@ RTLSDR_API int rtlsdr_get_device_usb_strings(uint32_t index, */ RTLSDR_API int rtlsdr_get_index_by_serial(const char *serial); +/*! + * Get device index by USB bus and port number + * + * \param bus bus number where the device is connected + * \param port port number where the device is connected + * \return device index of first device where the name matched + * \return -1 on libusb initialization failure + * \return -2 if no devices were found at all + * \return -3 if devices were found, but none with matching bus and port + */ +RTLSDR_API int rtlsdr_get_index_by_usb_bus_port(uint8_t bus, uint8_t port); + RTLSDR_API int rtlsdr_open(rtlsdr_dev_t **dev, uint32_t index); RTLSDR_API int rtlsdr_close(rtlsdr_dev_t *dev); diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 89ec903..eca093a 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1436,6 +1436,47 @@ int rtlsdr_get_index_by_serial(const char *serial) return -3; } +int rtlsdr_get_index_by_usb_bus_port(uint8_t bus, uint8_t port) +{ + int r = -2, index = -3; + int i; + libusb_context *ctx; + libusb_device **list; + struct libusb_device_descriptor dd; + uint8_t reg, dev_bus, dev_port; + ssize_t cnt; + + r = libusb_init(&ctx); + if(r < 0){ + return -1; + } + + cnt = libusb_get_device_list(ctx, &list); + if (!cnt) { + libusb_exit(ctx); + return -2; + } + + for (i = 0; i < cnt; i++) { + dev_bus = libusb_get_bus_number(list[i]); + dev_port = libusb_get_port_number(list[i]); + + libusb_get_device_descriptor(list[i], &dd); + + if (find_known_device(dd.idVendor, dd.idProduct) && + bus == dev_bus && port == dev_port) { + index = i; + break; + } + } + + libusb_free_device_list(list, 1); + + libusb_exit(ctx); + + return index; +} + int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) { int r; -- 2.13.6 From nsugino at 3way.com.ar Mon Jan 7 18:55:18 2019 From: nsugino at 3way.com.ar (Nicolas Sugino) Date: Mon, 7 Jan 2019 15:55:18 -0300 Subject: [PATCH v2] Add api to get index by usb bus and port number Message-ID: <20190107185514.GA16402@SujaPC> This allows to get the device index based on the usb bus and port number Signed-off-by: Nicolas Sugino --- include/rtl-sdr.h | 12 ++++++++++++ src/librtlsdr.c | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+) diff --git a/include/rtl-sdr.h b/include/rtl-sdr.h index 3ed13ae..d1e3c1e 100644 --- a/include/rtl-sdr.h +++ b/include/rtl-sdr.h @@ -60,6 +60,18 @@ RTLSDR_API int rtlsdr_get_device_usb_strings(uint32_t index, */ RTLSDR_API int rtlsdr_get_index_by_serial(const char *serial); +/*! + * Get device index by USB bus and port number + * + * \param bus bus number where the device is connected + * \param port port number where the device is connected + * \return device index of first device where the name matched + * \return -1 on libusb initialization failure + * \return -2 if no devices were found at all + * \return -3 if devices were found, but none with matching bus and port + */ +RTLSDR_API int rtlsdr_get_index_by_usb_bus_port(uint8_t bus, uint8_t port); + RTLSDR_API int rtlsdr_open(rtlsdr_dev_t **dev, uint32_t index); RTLSDR_API int rtlsdr_close(rtlsdr_dev_t *dev); diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 89ec903..12a196f 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1436,6 +1436,47 @@ int rtlsdr_get_index_by_serial(const char *serial) return -3; } +int rtlsdr_get_index_by_usb_bus_port(uint8_t bus, uint8_t port) +{ + int r = -2, index = -3; + int i; + libusb_context *ctx; + libusb_device **list; + struct libusb_device_descriptor dd; + uint8_t reg, dev_bus, dev_port; + ssize_t cnt; + + r = libusb_init(&ctx); + if(r < 0){ + return -1; + } + + cnt = libusb_get_device_list(ctx, &list); + if (!cnt) { + libusb_exit(ctx); + return -2; + } + + for (i = 0; i < cnt; i++) { + libusb_get_device_descriptor(list[i], &dd); + + if (find_known_device(dd.idVendor, dd.idProduct)) { + index == -3 ? index = 0 : index++; + dev_bus = libusb_get_bus_number(list[i]); + dev_port = libusb_get_port_number(list[i]); + if(bus == dev_bus && port == dev_port) { + break; + } + } + } + + libusb_free_device_list(list, 1); + + libusb_exit(ctx); + + return index; +} + int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) { int r; -- 2.13.6 From markisrt4 at gmail.com Mon Jan 7 22:01:37 2019 From: markisrt4 at gmail.com (Mark Russell) Date: Mon, 7 Jan 2019 17:01:37 -0500 Subject: RTL_FM on the fly updates Message-ID: Good evening - I am trying to make modifications to rtl_fm so that I can change frequencies, gains, modulation types, and squelch values on the fly (and thus avoiding a restart). Its unclear to me what functions need to be called in order to apply changes to the sdr device so that I can do the above. The rtl_fm code isnt documented so I dont have much to go off of... GQRX doesnt run reliably on any RPi3's I've tried so I hoping to use a modified rtl_fm in its place. Any help would be appreciated. Thanks :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at tswartz.net Mon Jan 7 23:16:45 2019 From: tom at tswartz.net (tom at tswartz.net) Date: Mon, 7 Jan 2019 18:16:45 -0500 Subject: RTL_FM on the fly updates In-Reply-To: References: Message-ID: <20190107231645.GA1336@gmail.com> Any reason that you couldn't use rtl_tcp instead? It's pretty common to run rtl_tcp on a remote RPi server, then use a different, local computer to host GQRX. Squelch, frequency changing, and other features should be available via that protocol presently. -- Tom Swartz On Mon, Jan 07, 2019 at 05:01:37PM -0500, Mark Russell wrote: > Good evening - > I am trying to make modifications to rtl_fm so that I can change > frequencies, gains, modulation types, and squelch values on the fly (and > thus avoiding a restart).? > > Its unclear to me what functions need to be called in order to apply > changes to the sdr device so that I can do the above. The rtl_fm code isnt > documented so I dont have much to go off of... > > GQRX doesnt run reliably on any RPi3's I've tried so I hoping to use a > modified rtl_fm in its place. Any help would be appreciated. > Thanks :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From markisrt4 at gmail.com Mon Jan 7 23:55:13 2019 From: markisrt4 at gmail.com (Mark Russell) Date: Mon, 7 Jan 2019 18:55:13 -0500 Subject: RTL_FM on the fly updates In-Reply-To: <20190107231645.GA1336@gmail.com> References: <20190107231645.GA1336@gmail.com> Message-ID: At first I thought rtl_tcp was the way to go, but after looking at the code, it doesnt seem to support wide band FM, which led me to rtl_fm instead. Also, when using rtl_tcp as a server, I found my signal strengths were weaker when connecting to the rtl_tcp server with GQRX. I changed gqrx back to use the USB dongle directly and then i click the hardware agc checkbox - which gives me better signal strength. Is that not typical behavior? Maybe I'm not configuring something correctly? Thanks :) On Mon, Jan 7, 2019, 18:16 Any reason that you couldn't use rtl_tcp instead? > > It's pretty common to run rtl_tcp on a remote RPi server, > then use a different, local computer to host GQRX. > Squelch, frequency changing, and other features should be > available via that protocol presently. > > -- > Tom Swartz > > On Mon, Jan 07, 2019 at 05:01:37PM -0500, Mark Russell wrote: > > Good evening - > > I am trying to make modifications to rtl_fm so that I can change > > frequencies, gains, modulation types, and squelch values on the fly (and > > thus avoiding a restart). > > > > Its unclear to me what functions need to be called in order to apply > > changes to the sdr device so that I can do the above. The rtl_fm code > isnt > > documented so I dont have much to go off of... > > > > GQRX doesnt run reliably on any RPi3's I've tried so I hoping to use a > > modified rtl_fm in its place. Any help would be appreciated. > > Thanks :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at tswartz.net Tue Jan 8 00:36:56 2019 From: tom at tswartz.net (tom at tswartz.net) Date: Mon, 7 Jan 2019 19:36:56 -0500 Subject: RTL_FM on the fly updates In-Reply-To: References: <20190107231645.GA1336@gmail.com> Message-ID: <20190108003656.GB1336@gmail.com> Hey Mark: I'd happily be corrected, if it proves otherwise but I just gave it a shot locally. My setup was: rtl_tcp streaming over ethernet to a LAN host running GQRX 2.11.5 Wide FM worked as expected, tuned up to a local broadcast FM station no issues. NFM also worked, and I received a local ham repeater on 2m band. I did notice that the gain values were different in GQRX's GUI when switching between rtl_tcp and rtl_sdr drivers. Perhaps that subtle difference in gain values were what you had seen? I was not using Hardware AGC in either instance, but I set the values via the slider. rtl_tcp reported: `set gain 372` (and other values) when I adjusted the GQRX gain sliders. Perhaps someone else with better knowledge of the agc/gain settings can speak to why you may have been seeing a difference with the AGC enabled. -- Tom Swartz On Mon, Jan 07, 2019 at 06:55:13PM -0500, Mark Russell wrote: > At first I thought rtl_tcp was the way to go, but after looking at the > code, it doesnt seem to support wide band FM, which led me to rtl_fm > instead.? > > Also, when using rtl_tcp as a server, I found my signal strengths were > weaker when connecting to the rtl_tcp server with GQRX.? I changed gqrx > back to use the USB dongle directly and then i click the hardware agc > checkbox - which gives me better signal strength.?? > > Is that not typical behavior? Maybe I'm not configuring something > correctly? > > Thanks :) > > On Mon, Jan 7, 2019, 18:16 > Any reason that you couldn't use rtl_tcp instead? > > It's pretty common to run rtl_tcp on a remote RPi server, > then use a different, local computer to host GQRX. > Squelch, frequency changing, and other features should be > available via that protocol presently. > > -- > Tom Swartz > > On Mon, Jan 07, 2019 at 05:01:37PM -0500, Mark Russell wrote: > > Good evening - > > I am trying to make modifications to rtl_fm so that I can change > > frequencies, gains, modulation types, and squelch values on the fly > (and > > thus avoiding a restart).? > > > > Its unclear to me what functions need to be called in order to apply > > changes to the sdr device so that I can do the above. The rtl_fm > code isnt > > documented so I dont have much to go off of... > > > > GQRX doesnt run reliably on any RPi3's I've tried so I hoping to use > a > > modified rtl_fm in its place. Any help would be appreciated. > > Thanks :) > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laforge at gnumonks.org Tue Jan 8 14:25:22 2019 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 8 Jan 2019 15:25:22 +0100 Subject: gr-osmosdr / no tagged versions since 2014 In-Reply-To: <20180603181731.GU3699@nataraja> References: <20180603181731.GU3699@nataraja> Message-ID: <20190108142522.GI9802@nataraja> Dear Dimitri and Steve, On Sun, Jun 03, 2018 at 08:17:31PM +0200, Harald Welte wrote: > today I discovered that the gr-osmosdr package in debian unstable contains > a whooping list of 96 patches. This is due to the fact that since November > 2014 there hasn't been any tagged versions in the repository. > > I'd like to suggest to tag releases a bit more often. > > @horizon: What about jumping to 1.0.0 right away? is there anything we can do about the status/progress of gr-osmosdr, particularly in terms of tagging new releases? I understand that people do have a life and other priorities, and that those priorities change. But the fact that there's a Osmocom sub-project which is heavily used by people out there, and which is packaged by distributions yet we don't tag any releases for more than four years is also problematic. What can I do (or anyone else do) to change this? Sure, I could just push a tag to the repository, but I'm not a developer of gr-osmosdr and hence I feel neither qualified nor have any authority. Thanks for your time and help! Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From sm6hoc at telia.com Mon Jan 14 18:18:01 2019 From: sm6hoc at telia.com (sm6hoc at telia.com) Date: Mon, 14 Jan 2019 19:18:01 +0100 (CET) Subject: Openwebrx and direct sampling mode crash Message-ID: <274498045.2241266.1547489881335.JavaMail.defaultUser@defaultHost> Hi my friends I'w got a problem wen install direct sampling mode. When install openwebrx everything is ok up and running. The problem is when I install the direct sampling mode (Have install 3 other and no problem). This is the first Ubuntu 18.04. I copy the log here but it is only from startup script. [openwebrx-main] Configuration script not specified. I will use: "config_webrx.py" [openwebrx-main] nmux_bufsize = 602112, nmux_bufcnt = 84 [openwebrx-main] Started rtl_thread: rtl_sdr -s 2400000 -f 144250000 -p 0 -g 5 -| nmux --bufsize 602112 --bufcnt 84 --port 4951 --address 127.0.0.1 [openwebrx-main] Waiting for I/Q server to start... rtl_sdr: symbol lookup error: rtl_sdr: undefined symbol: rtlsdr_set_dithering nmux: listening on 127.0.0.1:4951 nmux: (main thread/for) end input stream, exiting. Lars SM6HOC From nsugino at 3way.com.ar Wed Jan 16 15:40:33 2019 From: nsugino at 3way.com.ar (Nicolas Sugino) Date: Wed, 16 Jan 2019 12:40:33 -0300 Subject: [PATCH v3] Add api to get index by usb bus and port number Message-ID: <20190116154028.GA660@SujaPC> This allows to get the device index based on the usb bus and port number Signed-off-by: Nicolas Sugino --- include/rtl-sdr.h | 12 ++++++++++++ src/librtlsdr.c | 42 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 54 insertions(+) diff --git a/include/rtl-sdr.h b/include/rtl-sdr.h index 3ed13ae..d1e3c1e 100644 --- a/include/rtl-sdr.h +++ b/include/rtl-sdr.h @@ -60,6 +60,18 @@ RTLSDR_API int rtlsdr_get_device_usb_strings(uint32_t index, */ RTLSDR_API int rtlsdr_get_index_by_serial(const char *serial); +/*! + * Get device index by USB bus and port number + * + * \param bus bus number where the device is connected + * \param port port number where the device is connected + * \return device index of first device where the name matched + * \return -1 on libusb initialization failure + * \return -2 if no devices were found at all + * \return -3 if devices were found, but none with matching bus and port + */ +RTLSDR_API int rtlsdr_get_index_by_usb_bus_port(uint8_t bus, uint8_t port); + RTLSDR_API int rtlsdr_open(rtlsdr_dev_t **dev, uint32_t index); RTLSDR_API int rtlsdr_close(rtlsdr_dev_t *dev); diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 89ec903..0d0804d 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1436,6 +1436,48 @@ int rtlsdr_get_index_by_serial(const char *serial) return -3; } +int rtlsdr_get_index_by_usb_bus_port(uint8_t bus, uint8_t port) +{ + int r = -2, index = 0; + int i, found = 0; + libusb_context *ctx; + libusb_device **list; + struct libusb_device_descriptor dd; + uint8_t reg, dev_bus, dev_port; + ssize_t cnt; + + r = libusb_init(&ctx); + if(r < 0){ + return -1; + } + + cnt = libusb_get_device_list(ctx, &list); + if (!cnt) { + libusb_exit(ctx); + return -2; + } + + for (i = 0; i < cnt; i++) { + libusb_get_device_descriptor(list[i], &dd); + + if (find_known_device(dd.idVendor, dd.idProduct)) { + dev_bus = libusb_get_bus_number(list[i]); + dev_port = libusb_get_port_number(list[i]); + if(bus == dev_bus && port == dev_port) { + found = 1; + break; + } + index++; + } + } + + libusb_free_device_list(list, 1); + + libusb_exit(ctx); + + return found ? index : -3; +} + int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) { int r; -- 2.13.6 From christandlg at yahoo.com Mon Jan 21 14:39:06 2019 From: christandlg at yahoo.com (gregor christandl) Date: Mon, 21 Jan 2019 15:39:06 +0100 Subject: Building gr-osmosdr from source fails Message-ID: <3e7c3e95-dbde-a6e8-711e-d0f27c9d9c42@yahoo.com> Hi, I'm having trouble installing gr-osmosdr via pybombs so I checked out the master branch from git.osmocom.org/gr-osmosdr, but building still fails with the same error: > gregor at gregor-laptop ~/temp/gr-osmosdr/build $ cmake ../ > -- Build type not specified: defaulting to release. > -- Extracting version information from git describe... > -- Configuring Boost C++ Libraries... > -- Boost version: 1.58.0 > -- Found the following Boost libraries: > --?? thread > --?? system > --?? chrono > --?? date_time > --?? atomic > -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1") > Checking for GNU Radio Module: RUNTIME > -- Checking for module 'gnuradio-runtime' > --?? Found gnuradio-runtime, version 3.7.13.4 > ?* INCLUDES=/home/gregor/prefix/include > ?* > LIBS=/home/gregor/prefix/lib/libgnuradio-runtime.so;/home/gregor/prefix/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so > -- Found GNURADIO_RUNTIME: > /home/gregor/prefix/lib/libgnuradio-runtime.so;/home/gregor/prefix/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so > > GNURADIO_RUNTIME_FOUND = TRUE > Checking for GNU Radio Module: BLOCKS > -- Checking for module 'gnuradio-blocks' > --?? Found gnuradio-blocks, version 3.7.13.4 > ?* INCLUDES=/home/gregor/prefix/include > ?* > LIBS=/home/gregor/prefix/lib/libgnuradio-blocks.so;/home/gregor/prefix/lib/libgnuradio-runtime.so;/home/gregor/prefix/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so > -- Found GNURADIO_BLOCKS: > /home/gregor/prefix/lib/libgnuradio-blocks.so;/home/gregor/prefix/lib/libgnuradio-runtime.so;/home/gregor/prefix/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so > > GNURADIO_BLOCKS_FOUND = TRUE > Checking for GNU Radio Module: PMT > -- Checking for module 'gnuradio-runtime' > --?? Found gnuradio-runtime, version 3.7.13.4 > ?* INCLUDES=/home/gregor/prefix/include > ?* > LIBS=/home/gregor/prefix/lib/libgnuradio-runtime.so;/home/gregor/prefix/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so > -- Found GNURADIO_PMT: > /home/gregor/prefix/lib/libgnuradio-runtime.so;/home/gregor/prefix/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so > > GNURADIO_PMT_FOUND = TRUE > -- Checking for module 'gnuradio-iqbalance' > --?? Found gnuradio-iqbalance, version 0 > -- Found GNURADIO_IQBALANCE: > /home/gregor/prefix/lib/libgnuradio-iqbalance.so > -- Found UHD: /home/gregor/prefix/lib/libuhd.so > -- Checking for module 'gnuradio-uhd' > --?? Found gnuradio-uhd, version 3.7.13.4 > -- Found gnuradio-uhd: /home/gregor/prefix/include, > /home/gregor/prefix/lib/libgnuradio-uhd.so > -- Found GNURADIO_UHD: /home/gregor/prefix/lib/libgnuradio-uhd.so > -- Checking for module 'gnuradio-fcd' > --?? Found gnuradio-fcd, version 3.7.13.4 > -- Found gnuradio-fcd: /home/gregor/prefix/include, > /home/gregor/prefix/lib/libgnuradio-fcd.so > -- Found GNURADIO_FCD: /home/gregor/prefix/lib/libgnuradio-fcd.so > -- Checking for module 'gnuradio-fcdproplus' > --?? No package 'gnuradio-fcdproplus' found > -- gnuradio-fcdproplus not found. > -- Could NOT find GNURADIO_FCDPP (missing: GNURADIO_FCDPP_LIBRARIES > GNURADIO_FCDPP_INCLUDE_DIRS) > -- Checking for module 'libosmosdr' > --?? Found libosmosdr, version > -- Found libosmosdr: /home/gregor/prefix/include, > /home/gregor/prefix/lib/libosmosdr.so > -- Checking for module 'librtlsdr' > --?? Found librtlsdr, version 0.6.0-2-gf68bb > -- Found librtlsdr: /home/gregor/prefix/include, > /home/gregor/prefix/lib/librtlsdr.so > -- Checking for module 'libmirisdr' > --?? No package 'libmirisdr' found > -- libmirisdr not found. > -- Checking for module 'libhackrf' > --?? Found libhackrf, version 0.5 > -- Found LIBHACKRF: /home/gregor/prefix/lib/libhackrf.so > -- Checking for module 'libairspy' > --?? Found libairspy, version 1.0 > -- Found LIBAIRSPY: /home/gregor/prefix/lib/libairspy.so > -- Checking for module 'volk' > --?? Found volk, version 1.4 > -- Found VOLK: /home/gregor/prefix/lib/libvolk.so > -- Checking for module 'libbladeRF' > --?? Found libbladeRF, version 2.2.0-git-e4bf84a > -- Found libbladeRF: /home/gregor/prefix/include, > /home/gregor/prefix/lib/libbladeRF.so > -- Checking for module 'libfreesrp' > --?? No package 'libfreesrp' found > -- libfreesrp not found. > -- Found Doxygen: /usr/bin/doxygen (found version "1.8.11") > -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found > suitable version "2.7.12", minimum required is "2") > -- > -- Checking for module SWIG > -- Found SWIG version 3.0.8. > -- Found SWIG: /usr/bin/swig3.0 > -- Minimum SWIG version required is 1.3.31 > -- > -- The build system will automatically enable all components. > -- Use -DENABLE_DEFAULT=OFF to disable components by default. > -- > -- Configuring Python support support... > --?? Dependency PYTHONLIBS_FOUND = TRUE > --?? Dependency SWIG_FOUND = TRUE > --?? Dependency SWIG_VERSION_CHECK = TRUE > --?? Enabling Python support support. > --?? Override with -DENABLE_PYTHON=ON/OFF > -- > -- Configuring high resolution timing... > -- Performing Test HAVE_CLOCK_GETTIME > -- Performing Test HAVE_CLOCK_GETTIME - Success > -- Performing Test HAVE_MACH_ABSOLUTE_TIME > -- Performing Test HAVE_MACH_ABSOLUTE_TIME - Failed > -- Performing Test HAVE_QUERY_PERFORMANCE_COUNTER > -- Performing Test HAVE_QUERY_PERFORMANCE_COUNTER - Failed > --?? High resolution timing supported through clock_gettime. > -- > -- Configuring Osmocom IQ Imbalance Correction support... > --?? Dependency GNURADIO_IQBALANCE_FOUND = TRUE > --?? Enabling Osmocom IQ Imbalance Correction support. > --?? Override with -DENABLE_IQBALANCE=ON/OFF > -- > -- Configuring sysmocom OsmoSDR support... > --?? Dependency LIBOSMOSDR_FOUND = TRUE > --?? Enabling sysmocom OsmoSDR support. > --?? Override with -DENABLE_OSMOSDR=ON/OFF > -- > -- Configuring FUNcube Dongle support... > --?? Dependency GNURADIO_FCD_FOUND = TRUE > --?? Enabling FUNcube Dongle support. > --?? Override with -DENABLE_FCD=ON/OFF > -- > -- Configuring FUNcube Dongle Pro+ support... > --?? Dependency GNURADIO_FCDPP_FOUND = FALSE > --?? Disabling FUNcube Dongle Pro+ support. > --?? Override with -DENABLE_FCDPP=ON/OFF > -- > -- Configuring IQ File Source & Sink support... > --?? Dependency GNURADIO_BLOCKS_FOUND = TRUE > --?? Enabling IQ File Source & Sink support. > --?? Override with -DENABLE_FILE=ON/OFF > -- > -- Configuring Osmocom RTLSDR support... > --?? Dependency LIBRTLSDR_FOUND = TRUE > --?? Enabling Osmocom RTLSDR support. > --?? Override with -DENABLE_RTL=ON/OFF > -- > -- Configuring RTLSDR TCP Client support... > --?? Dependency GNURADIO_BLOCKS_FOUND = TRUE > --?? Enabling RTLSDR TCP Client support. > --?? Override with -DENABLE_RTL_TCP=ON/OFF > -- > -- Configuring Ettus USRP Devices support... > --?? Dependency UHD_FOUND = TRUE > --?? Dependency GNURADIO_UHD_FOUND = TRUE > --?? Enabling Ettus USRP Devices support. > --?? Override with -DENABLE_UHD=ON/OFF > -- > -- Configuring Osmocom MiriSDR support... > --?? Dependency LIBMIRISDR_FOUND = FALSE > --?? Disabling Osmocom MiriSDR support. > --?? Override with -DENABLE_MIRI=ON/OFF > -- > -- Configuring HackRF & rad1o Badge support... > --?? Dependency LIBHACKRF_FOUND = TRUE > --?? Enabling HackRF & rad1o Badge support. > --?? Override with -DENABLE_HACKRF=ON/OFF > -- Looking for hackrf_device_list > -- Looking for hackrf_device_list - found > -- HackRF multiple device support enabled > -- > -- Configuring nuand bladeRF support... > --?? Dependency LIBBLADERF_FOUND = TRUE > --?? Enabling nuand bladeRF support. > --?? Override with -DENABLE_BLADERF=ON/OFF > -- > -- Configuring RFSPACE Receivers support... > --?? Enabling RFSPACE Receivers support. > --?? Override with -DENABLE_RFSPACE=ON/OFF > -- > -- Configuring AIRSPY Receiver support... > --?? Dependency LIBAIRSPY_FOUND = TRUE > --?? Enabling AIRSPY Receiver support. > --?? Override with -DENABLE_AIRSPY=ON/OFF > -- > -- Configuring SoapySDR support support... > --?? Dependency SoapySDR_FOUND = 1 > --?? Enabling SoapySDR support support. > --?? Override with -DENABLE_SOAPY=ON/OFF > -- > -- Configuring Red Pitaya SDR support... > --?? Enabling Red Pitaya SDR support. > --?? Override with -DENABLE_REDPITAYA=ON/OFF > -- > -- Configuring FreeSRP support support... > --?? Dependency LIBFREESRP_FOUND = FALSE > --?? Disabling FreeSRP support support. > --?? Override with -DENABLE_FREESRP=ON/OFF > -- Found PythonInterp: /usr/bin/python2 (found suitable version > "2.7.12", minimum required is "2") > -- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE > -- Performing Test HAVE_WNO_UNUSED_BUT_SET_VARIABLE - Success > -- > -- ###################################################### > -- # Gnuradio enabled components > -- ###################################################### > --?? * Python support > --?? * Osmocom IQ Imbalance Correction > --?? * sysmocom OsmoSDR > --?? * FUNcube Dongle > --?? * IQ File Source & Sink > --?? * Osmocom RTLSDR > --?? * RTLSDR TCP Client > --?? * Ettus USRP Devices > --?? * HackRF & rad1o Badge > --?? * nuand bladeRF > --?? * RFSPACE Receivers > --?? * AIRSPY Receiver > --?? * SoapySDR support > --?? * Red Pitaya SDR > -- > -- ###################################################### > -- # Gnuradio disabled components > -- ###################################################### > --?? * FUNcube Dongle Pro+ > --?? * Osmocom MiriSDR > --?? * FreeSRP support > -- > -- Building for version: v0.1.4-127-g4d83c606 / 0.1.5git > -- Using install prefix: /usr/local > -- Configuring done > -- Generating done > -- Build files have been written to: /home/gregor/temp/gr-osmosdr/build > gregor at gregor-laptop ~/temp/gr-osmosdr/build $ make > Scanning dependencies of target gnuradio-osmosdr > [? 2%] Building CXX object > lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o > In file included from > /home/gregor/temp/gr-osmosdr/lib/bladerf/bladerf_source_c.h:26:0, > ???????????????? from /home/gregor/temp/gr-osmosdr/lib/source_impl.cc:72: > /home/gregor/temp/gr-osmosdr/lib/bladerf/bladerf_common.h:291:50: > error: ?>>? should be ?> >? within a nested template argument list > ?? static std::list> _devs;? /**< dev > cache */ > ????????????????????????????????????????????????? ^ > In file included from > /home/gregor/temp/gr-osmosdr/lib/source_impl.cc:72:0: > /home/gregor/temp/gr-osmosdr/lib/bladerf/bladerf_source_c.h:141:32: > warning: non-static data member initializers only available with > -std=c++11 or -std=gnu++11 > ?? const float SCALING_FACTOR = 2048.0f; > ??????????????????????????????? ^ > lib/CMakeFiles/gnuradio-osmosdr.dir/build.make:62: recipe for target > 'lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o' failed > make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o] > Error 1 > CMakeFiles/Makefile2:135: recipe for target > 'lib/CMakeFiles/gnuradio-osmosdr.dir/all' failed > make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2 > Makefile:138: recipe for target 'all' failed > make: *** [all] Error 2 I'm running Linux Mint 18.3 Sylvia and am trying to compile for GNU Radio 3.7 (which I installed via pybombs), gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11). From kantooon at gmail.com Thu Jan 24 20:12:17 2019 From: kantooon at gmail.com (Adrian Musceac) Date: Thu, 24 Jan 2019 22:12:17 +0200 Subject: advice on ham radio operation In-Reply-To: References: Message-ID: Hi Joseph, I'm also a ham and I tried to do some work in this area with GNU radio and resulted in this: https://github.com/kantooon/qradiolink (http://qradiolink.org) But the code and build process is a mess because I tried to do too many things at the same time with too little time. You might find it useful, but it's not really something production quality and I'm not very proud of the code. More like a toy really. Cheers, Adrian On 12/20/18, Joseph Hutchins wrote: > Hi, after I make the appropriate bandpass filters, I wanted to attach the > device to an antenna and try some SSB HF, maybe 10 or 20 meter band. I > noticed there are no SSB examples and so I will need to write the program > myself. > > I was contacting to ask if there is any reason that the examples use > standalone binaries to interact with the fresco chip rather than writing a > library for gnuradio. Did something about gnuradio make the fresco's > integration with it impractical? Would I be better off proceeding by > writing a gnuradio block for the Fresco sink or a standalone SSB-tx > program? > > The novelty of demonstrating that such a cheap setup is feasible really > appeals to me. > > Thanks, > > Joseph Hutchins > From 246tnt at gmail.com Fri Jan 25 09:07:04 2019 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 25 Jan 2019 10:07:04 +0100 Subject: advice on ham radio operation In-Reply-To: References: Message-ID: Hi, I'm assuming you're talking about fl2k here ? Please always be explicit, this mailing list is used by several different SDR projects and not just fl2k. > I was contacting to ask if there is any reason that the examples use standalone binaries to interact with the fresco chip rather than writing a library for gnuradio. Did something about gnuradio make the fresco's integration with it impractical? Would I be better off proceeding by writing a gnuradio block for the Fresco sink or a standalone SSB-tx program? I think it's the other way around ... the fl2k stuff is mostly a pretty big hack and it eats up huge amount of CPU and that makes it quite impractical. I think the examples are all very specific cases because that allow to optimize them for _exactly_ that application and use a bunch of tricks to try and reduce the CPU usage to levels that you can actually sustain. Making a generic GR block sure is possible, but it definitely will end up being very CPU intensive and as such require beefy machine to sustain the rate. Cheers, Sylvain From laforge at gnumonks.org Sat Jan 26 18:15:33 2019 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 26 Jan 2019 19:15:33 +0100 Subject: gr-osmosdr and libbladerf compile failures Message-ID: <20190126181533.GL3930@nataraja> Hi Rey + Robert, I've just also been hit by a bug that was already filed some 5 months ago in the osmocom.org bug tracker: http://osmocom.org/issues/3512 It seems that the bladerf support to gr-osmosdr added in 2018 unconditionally accepts any libbladerf version installed and subseequently enables the support for it, only then to fails to compile as it actually appears to require a minimum version of 2.0.0 for which it doesn't check during the cmake step. I don't know much about Cmake and hence it would be great if you as the authors of the related code could find a minute to ensure that gr-osmosdr will simply not try to build bladerf support if the version of libbladerf is too old. I'm aware that I can of course manually disable bladerf support, but that's more a work-around than a proper solution, IMHO. Thanks in advance! Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From vvvelichkov at gmail.com Tue Jan 29 21:08:56 2019 From: vvvelichkov at gmail.com (Vasil Velichkov) Date: Tue, 29 Jan 2019 23:08:56 +0200 Subject: Building gr-osmosdr from source fails In-Reply-To: <3e7c3e95-dbde-a6e8-711e-d0f27c9d9c42@yahoo.com> References: <3e7c3e95-dbde-a6e8-711e-d0f27c9d9c42@yahoo.com> Message-ID: Hi Gregor, On 21/01/2019 16.39, gregor christandl wrote: >> gregor at gregor-laptop ~/temp/gr-osmosdr/build $ make >> Scanning dependencies of target gnuradio-osmosdr >> [? 2%] Building CXX object >> lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o >> In file included from >> /home/gregor/temp/gr-osmosdr/lib/bladerf/bladerf_source_c.h:26:0, >> ???????????????? from >> /home/gregor/temp/gr-osmosdr/lib/source_impl.cc:72: >> /home/gregor/temp/gr-osmosdr/lib/bladerf/bladerf_common.h:291:50: >> error: ?>>? should be ?> >? within a nested template argument list >> ?? static std::list> _devs;? /**< dev >> cache */ > > I'm running Linux Mint 18.3 Sylvia and am trying to compile for GNU > Radio 3.7 (which I installed via pybombs), gcc version 5.4.0 20160609 > (Ubuntu 5.4.0-6ubuntu1~16.04.11). It seems it can't be compiled with certain gcc versions. You could manually apply the following changes from https://github.com/Nuand/bladeRF/issues/684#issuecomment-434389842 > Quick fix would be to edit bladerf_common.h:291 (and any other lines > it errors out on) to change: > > |static std::list> _devs; /**< dev > cache */| > > to: > > |static std::list > _devs; /**< dev > cache */| > > These three lines in bladerf_common.cc will likely also need changing: > > |bladerf_common.cc:54:std::list> > bladerf_common::_devs; bladerf_common.cc:1112: > _devs.push_back(static_cast>(dev)); > bladerf_common.cc:1120: std::list bladerf>>::iterator it(_devs.begin()); | Or you could try to update your compiler to a more recent version. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.mueller at ettus.com Thu Jan 31 08:29:31 2019 From: marcus.mueller at ettus.com (Marcus =?ISO-8859-1?Q?M=FCller?=) Date: Thu, 31 Jan 2019 09:29:31 +0100 Subject: Building gr-osmosdr from source fails In-Reply-To: References: <3e7c3e95-dbde-a6e8-711e-d0f27c9d9c42@yahoo.com> Message-ID: in templates, things like "vector of complex of float" used to be written as vector > with a space between the > and >, because that avoids the ambiguity with >> (the right-shift operator). This should be remedied in C++11, i.e. "just work" with or without the space; I guess the original authors used C++11 by default. CMake makes such decisions on the fly, depending on (way too) many factors. I must admit I don't know the language version policy for gr-osmosdr, but my guess is that setting the C++ standard to C++11 should work; however, since we're passing std::string around, and that changed its ABI between C++98 and 11, I'd like to recommend that you use the same C++ standard as your GNU Radio uses. GNU Radio uses C++11 on the master branch, or 98 on the maint-3.7 branch. Don't know which one you've built! So, as Vasil pointed out, the easiest way out is to simply add these spaces where necessary, and thus making gr-osmosdr compatible to both C++ versions Best regards, Marcus On Tue, 2019-01-29 at 23:08 +0200, Vasil Velichkov wrote: > Hi Gregor, > On 21/01/2019 16.39, gregor christandl wrote: > > > gregor at gregor-laptop ~/temp/gr-osmosdr/build $ make > > > Scanning dependencies of target gnuradio-osmosdr > > > [ 2%] Building CXX object lib/CMakeFiles/gnuradio- > > > osmosdr.dir/source_impl.cc.o > > > In file included from /home/gregor/temp/gr- > > > osmosdr/lib/bladerf/bladerf_source_c.h:26:0, > > > from /home/gregor/temp/gr- > > > osmosdr/lib/source_impl.cc:72: > > > /home/gregor/temp/gr-osmosdr/lib/bladerf/bladerf_common.h:291:50: > > > error: ?>>? should be ?> >? within a nested template argument > > > list > > > static std::list> _devs; /**< > > > dev cache */ > > > > I'm running Linux Mint 18.3 Sylvia and am trying to compile for GNU > > Radio 3.7 (which I installed via pybombs), gcc version 5.4.0 > > 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11). > > It seems it can't be compiled with certain gcc versions. You could > manually apply the following changes from > https://github.com/Nuand/bladeRF/issues/684#issuecomment-434389842 > > Quick fix would be to edit bladerf_common.h:291 (and any other > > lines it errors out on) to change: > > static std::list> _devs; /**< dev > > cache */ > > to: > > static std::list > _devs; /**< dev > > cache */ > > These three lines in bladerf_common.cc will likely also need > > changing: > > bladerf_common.cc:54:std::list> > > bladerf_common::_devs; > > bladerf_common.cc:1112: _devs.push_back(static_cast > r>(dev)); > > bladerf_common.cc:1120: std::list > bladerf>>::iterator it(_devs.begin()); > Or you could try to update your compiler to a more recent version. From keylo99official at gmail.com Mon Jan 28 12:31:58 2019 From: keylo99official at gmail.com (KeyLo99) Date: Mon, 28 Jan 2019 15:31:58 +0300 Subject: rtl_map project [RTL-SDR] Message-ID: I'm a RTL-SDR researcher and DSP learner currently working on a project for properly figuring RTL2832 and I/Q fundamentals out. The project is about reading raw I/Q samples, processing samples and creating FFT graph from them. I tried to explain what I'm doing in detail with comment lines. I'm hoping that I will be helpful to RTL-SDR beginners with this rtl_map [C] project. Another purpose of the rtl_map project is making a frequency scanner application for signal security researches. Another information about the project, installation instructions and example usages exist at the GitHub repository. https://github.com/KeyLo99/rtl_map -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Thu Jan 31 13:54:57 2019 From: gdt at lexort.com (Greg Troxel) Date: Thu, 31 Jan 2019 08:54:57 -0500 Subject: Building gr-osmosdr from source fails In-Reply-To: ("Marcus =?utf-8?Q?M=C3=BCller=22's?= message of "Thu, 31 Jan 2019 09:29:31 +0100") References: <3e7c3e95-dbde-a6e8-711e-d0f27c9d9c42@yahoo.com> Message-ID: From gdt at lexort.com Thu Jan 31 13:57:20 2019 From: gdt at lexort.com (Greg Troxel) Date: Thu, 31 Jan 2019 08:57:20 -0500 Subject: Building gr-osmosdr from source fails In-Reply-To: ("Marcus =?utf-8?Q?M=C3=BCller=22's?= message of "Thu, 31 Jan 2019 09:29:31 +0100") References: <3e7c3e95-dbde-a6e8-711e-d0f27c9d9c42@yahoo.com> Message-ID: Marcus M?ller writes: > I must admit I don't know the language version policy for gr-osmosdr, > but my guess is that setting the C++ standard to C++11 should work; > however, since we're passing std::string around, and that changed its > ABI between C++98 and 11, I'd like to recommend that you use the same > C++ standard as your GNU Radio uses. GNU Radio uses C++11 on the master > branch, or 98 on the maint-3.7 branch. It is unfortunate that compilers default to different language standards. It seems each program should declare the standards supported in the README, and the configure.ac should check that the --std= argument is acceptable to the compiler and then add it to CXXFLAGS. (Agreed that one must compile C++ programs with the same --std. Also, due to libstdc++ ABI changes, one should use the same compiler for all programs too.)