From: Clayton Smith <argilo(a)gmail.com>
This removes gr-iqbal's second-last dependence on Boost. All that
remains is boost::shared_ptr, which will have to stay until GNU Radio
3.9.
---
lib/fix_cc.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/fix_cc.cc b/lib/fix_cc.cc
index af79d7db26..628421db3e 100644
--- a/lib/fix_cc.cc
+++ b/lib/fix_cc.cc
@@ -43,7 +43,7 @@ iqbalance::fix_cc::fix_cc(float mag, float phase)
{
message_port_register_in(pmt::mp("iqbal_corr"));
set_msg_handler(pmt::mp("iqbal_corr"),
- boost::bind(&iqbalance::fix_cc::apply_new_corrections, this, boost::placeholders::_1));
+ std::bind(&iqbalance::fix_cc::apply_new_corrections, this, std::placeholders::_1));
}
--
2.25.1
Dear Maintainers,
The attached patch adds XTRX SDR support to Gr-Osmosdr. It mostly contains the out-of tree patches added in the libxtrx branch here: https://github.com/xtrx-sdr/gr-osmosdr , also the patches upstreamed to be compatible with Gnu-Radio 3.8 and the latest master branch of gr-osmosdr.
It compiles and works fine with Gnu-Radio 3.8 and Gr-Osmosdr master (tested on Ubuntu 20.04.01 LTS 64bit).
Hopefully I will have time to test it against other Osmocom projects in the near future.
Please let me know if the patch needs any modifications or further work.
Regards,
Csaba
Dear fellow Osmocom developers,
as you all know, we've sadly had to postpone OsmoDevCon 2020 back in
April this year. At the time, we discussed to re-visit the situation
in October 2020.
While legally it is no problem at all to host an event with ~ 20
participants in Berlin/Germany (specific regulations really only start
from 50+ participants) - I'm not entirely convinced it would be the
smartest move.
Legality and public health regulations are only one part of the equation
- common sense and profound care for the key members of our community
for sure are more relevant considerations to me.
I'm not 100% in favour and not 100% against. Hence, I would like to get
your input. Should we
a) try to get an event organized on-site in Berlin? We'd have to move
to a larger venue than IN-Berlin with proper ventilation and sufficient
space so we can keep physical distance, but I think that's
manageable for sysmocom as organizer.
b) simply postpone to 2021? I'm convinced the situation will not change
significantly (in a positive way) until late April 2021, so it's not
really a "solution" as it will likely mean we have to think of late
2021 or 2022.
c) plan some kind of online conference? To be honest, I think this
model works fine for events where a single speaker wants to give
lectures to hundreds or thousands of participants. But OsmoDevCon
is much more interactive. We could record or live-stream some talks
or screencasts from home, sure. But that only captures one part of
the event. We could also try to set a date for a collaborative
mumble, or the like - for the "hallway track".
What are your thoughts? Let's avoid cross-posting the discussion to all
of the mailing lists and simply have it on openbsc(a)lists.osmocom.org.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello,
attached is a patch to fl2k_file that introduces the -3 command line
option. If this option is in use, fl2k_file will treat the input file
as a sequence of frames of 3 samples for each of the red, green, and
blue output channels.
This implementation is not exactly optimal in CPU use, since the patch
de-interleaves the input first, and the underlying library then
proceeds to re-interleave it (in the weird hardware-specific order).
This is because I didn't feel comfortable trying to redesign the
fl2k_data_info_t structure to support interleaved data without
guidance from the architect. But with a more flexible structure, these
stages could be combined, improving the throughput.
--
Riley Faelan
Howdy guys.
I see some work around getting gr-osmosdr working nicely with GR 3.8, but
have there been any discussions around GR 3.9 (really current 'master')?
I recently decided to pick GNU Radio back up and hook up my rtl dongle. In
particular, I wanted to dust off my C++ chops that I haven't been able to
exercise in my current $DAYJOB. Naturally then I started with GNU Radio
master! It looks like one major change is that they have replaced swig with
pybind, which means that the current gr-osmosdr can't even begin to work.
So has there been any discussion about the porting effort necessary to move
it over?
I'm interested in starting to poke at getting it working under current GR
3.9/master, but had a few questions before I started:
1) Has anyone else started on the changes that I could coordinate with?
2) Is there generally any attempt at tracking gr master, or do you
typically only target release branches?
3) Am I putting the cart before the horse and really need to focus any of
my willingness to help on getting the GR 3.8 solid (if it isn't already)?
Thanks for time,
Troy
The LUT changes in 2e7d343fed inadvertently started interpreting
samples as unsigned. This change puts it back to signed (and fixes an
outdated comment).
This fixes the template syntax that removes a set of variables from sink
blocks. Previously, this was causing NameErrors when trying to generate
a flowgraph containing a sink block.
There is an urgent need to migrate our most important public
infrastructure to a new server, and I will be doing that on
*Sunday, July 19 2020*, starting about 9am CEST.
The migration involves redmine (main osmocom.org website), jenkins, gerrit,
git, and cgit.
In theory, the migration should be quick. I would expect (significantly)
less than one hour of downtime. However, we all know Murphys law.
Services not affected are mail (including mailman lists), ftp, dns. So in case
of doubt, we can still use mailing lists to communicate.
In case anyone urgently needs osmocom source code on Sunday morning
during the downtime: There are public mirrors available on github.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hello I'm trying to use rtl_fm to listen to a local
radio station but the software is not running to the
frequency specified on the command line. The program
output says it is tuning 256kHz higher.
Command line:
rtl-sdr-64bit-20200712> .\rtl_fm.exe -f 95.9M -E deemp -g 0 -s 128000 -r
22050 test2.raw
Found 1 device(s):
0: RTLTXCO1, RTLTXCO1, SN: 00000001
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Tuner gain set to 0.00 dB.
Tuned to 96156000 Hz.
Oversampling input by: 8x.
Oversampling output by: 1x.
Buffer size: 8.00ms
Sampling at 1024000 S/s.
Output at 128000 Hz.
Signal caught, exiting!
User cancel, exiting...
--
BT
73s
Signed/Jacob Edwards Wiese/KD9LWR/Cell 219 221 0486//
CoCoRaHS ID/IN-LP-65//
PGP KEY ID/0xB842BA9690A408D3//
NNNN
I'm using a Raspberry with two similar devices but different antennas.
Specifying the device via index didn't work, because the enumeration of
devices changed from time to time. Therefore I implemented functions to
give a USB path instead. This path looks the same as the Linux kernel
uses (eg. "4-1.2") and contains the USB bus and port numbers.
I'll hope you'll find my patch acceptable.
Best Regards,
Alex
Add functions to query devices via path, and path from a device.
The path is formatted similar to Linux USB device names (bus number,
hyphen, ports separated by dots, eg. "4-1.2").
---
include/rtl-sdr.h | 25 +++++++
src/convenience/convenience.c | 10 +++
src/librtlsdr.c | 121 ++++++++++++++++++++++++++++++++++
3 files changed, 156 insertions(+)
diff --git a/include/rtl-sdr.h b/include/rtl-sdr.h
index d64701e..e6ce33a 100644
--- a/include/rtl-sdr.h
+++ b/include/rtl-sdr.h
@@ -49,6 +49,31 @@ RTLSDR_API int rtlsdr_get_device_usb_strings(uint32_t index,
char *product,
char *serial);
+/*!
+ * Get device index by USB path string.
+ *
+ * The path string has the format "bus-port.port..."
+ * (i.e. the bus number, followed by a hyphen, then
+ * followed by the port numbers separated by dots).
+ *
+ * \param path path string of the device
+ * \return device index of the device with the given path
+ * \return -1 if no matching device was found.
+ */
+RTLSDR_API int rtlsdr_get_index_by_path(const char *path);
+
+/*!
+ * Get the USB path.
+ *
+ * NOTE: The buffer should provide space for at least 32 bytes.
+ *
+ * \param index the device index
+ * \param buf buffer where the path will be written
+ * \param len size of the buffer
+ * \return 0 on success
+ */
+RTLSDR_API int rtlsdr_get_device_path(uint32_t index, char *buf, size_t len);
+
/*!
* Get device index by USB serial string descriptor.
*
diff --git a/src/convenience/convenience.c b/src/convenience/convenience.c
index 00cc2cc..55f82e2 100644
--- a/src/convenience/convenience.c
+++ b/src/convenience/convenience.c
@@ -268,6 +268,16 @@ int verbose_device_search(char *s)
device, rtlsdr_get_device_name((uint32_t)device));
return device;
}
+ /* does string match a path */
+ if (s2[0] == '-') {
+ i = rtlsdr_get_index_by_path(s);
+ if (i >= 0) {
+ device = i;
+ fprintf(stderr, "Using device %d: %s\n",
+ device, rtlsdr_get_device_name((uint32_t)device));
+ return device;
+ }
+ }
/* does string exact match a serial */
for (i = 0; i < device_count; i++) {
rtlsdr_get_device_usb_strings(i, vendor, product, serial);
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 0146298..e3f03d7 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1414,6 +1414,127 @@ int rtlsdr_get_device_usb_strings(uint32_t index, char *manufact,
return r;
}
+static void get_device_path(libusb_device *dev, char *buf, size_t len)
+{
+ uint8_t port_numbers[16];
+ int port_entries;
+ int i, count;
+
+ count = snprintf(buf, len, "%d-", (int)libusb_get_bus_number(dev));
+ if (count < 0) {
+ buf[0] = 0;
+ return;
+ }
+ else if ((size_t)count >= len) {
+ buf[len-1] = 0;
+ return;
+ }
+
+ len -= count;
+ buf += count;
+
+ port_entries = libusb_get_port_numbers(dev, port_numbers, sizeof(port_numbers)/sizeof(port_numbers[0]));
+ if (port_entries < 0)
+ return;
+
+ for (i = 0; i < port_entries; i++) {
+ count = snprintf(buf, len, i ? ".%d" : "%d", (int) port_numbers[i]);
+
+ if (count < 0) {
+ buf[0] = 0;
+ break;
+ }
+ else if ((size_t)count >= len) {
+ buf[len-1] = 0;
+ break;
+ }
+
+ len -= count;
+ buf += count;
+ }
+
+ if (!port_entries && len > 1) {
+ buf[0] = '0';
+ buf[1] = 0;
+ }
+}
+
+int rtlsdr_get_index_by_path(const char *path)
+{
+ libusb_context *ctx;
+ libusb_device **list;
+ struct libusb_device_descriptor dd;
+ ssize_t cnt;
+ int i,r,pos;
+
+ r = libusb_init(&ctx);
+
+ if(r < 0)
+ return -1;
+
+ cnt = libusb_get_device_list(ctx, &list);
+
+ pos = 0;
+ for (i = 0; i < cnt; i++) {
+ libusb_get_device_descriptor(list[i], &dd);
+
+ if (find_known_device(dd.idVendor, dd.idProduct)) {
+ char buf[64];
+ get_device_path(list[i], buf, sizeof(buf));
+
+ if (!strncmp(path, buf, sizeof(buf))) {
+ libusb_free_device_list(list, 1);
+ libusb_exit(ctx);
+
+ return pos;
+ }
+
+ pos++;
+ }
+ }
+
+ libusb_free_device_list(list, 1);
+ libusb_exit(ctx);
+
+ return -1;
+}
+
+int rtlsdr_get_device_path(uint32_t index, char *buf, size_t len)
+{
+ libusb_context *ctx;
+ libusb_device **list;
+ struct libusb_device_descriptor dd;
+ int i,r;
+ uint32_t device_count = 0;
+ ssize_t cnt;
+
+ r = libusb_init(&ctx);
+ if(r < 0)
+ return r;
+
+ cnt = libusb_get_device_list(ctx, &list);
+
+ r = LIBUSB_ERROR_NO_DEVICE;
+ for (i = 0; i < cnt; i++) {
+ libusb_get_device_descriptor(list[i], &dd);
+
+ if (find_known_device(dd.idVendor, dd.idProduct)) {
+ device_count++;
+
+ if (index == device_count - 1) {
+ get_device_path(list[i], buf, len);
+ r = 0;
+ break;
+ }
+ }
+ }
+
+ libusb_free_device_list(list, 1);
+ libusb_exit(ctx);
+
+ return r;
+}
+
int rtlsdr_get_index_by_serial(const char *serial)
{
int i, cnt, r;
--
2.20.1
Dear all,
I found that the fix for the USB issue on ARM systems has finally made
it into the Linux kernel, 5.6.14 and 5.7-rc6. Today I installed the
latest Manjaro 64 unstable mainline kernel on my rpi4 and made some
quick tests with fl-wspr (https://github.com/tejeez/fl2k-tool).
There are no more USB errors*, but I still get underflow errors at high
sample rates. In my quick tests the maximum reliable sample rate was about
20 MHz when running in an X session with other programs. When I
stopped the X server and ran in a text console I could go above 30 MHz
without underflows.
This means that the rpi4 is fine as an SDR transceiver for many
purposes- but it would be nice to know if it is possible to tune the
system for a bit higher sample rates!
All the best
SM2YHP Fredrik
* Installed AUR package libosmo-fl2k-git to fix other USB
device issues
--
------------------
Carl-Fredrik Enell
Föraregatan 26B
SE-98139 Kiruna
+46705508256
-----------------
I'm using an Airspy HF+ Discovery with the Soapy driver. Whenever I turn
AGC off it stops receiving samples.
On closer inspection, switching AGC off results in samples stalling for
an extended period (hundreds of milliseconds). As such, we hit the
timeout in SoapyAirspyHF::readStream() and return SOAPY_SDR_TIMEOUT (-1).
Things go wrong at this point. It takes a long time before readStream()
is called again, presumably because we returned 0 from work(). By this
time our buffers have overflown, readStream() returns SOAPY_SDR_OVERFLOW
(-2) and work() returns 0. We loop forever, continually overflowing
buffers.
Fix this by looping in soapy_source_c::work() when ->readStream() returns
SOAPY_SDR_OVERFLOW so that we consume the buffers straight away.
Signed-off-by: Anton Blanchard <anton(a)ozlabs.org>
---
lib/soapy/soapy_source_c.cc | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/soapy/soapy_source_c.cc b/lib/soapy/soapy_source_c.cc
index a645361..9dcc885 100644
--- a/lib/soapy/soapy_source_c.cc
+++ b/lib/soapy/soapy_source_c.cc
@@ -96,9 +96,13 @@ int soapy_source_c::work( int noutput_items,
{
int flags = 0;
long long timeNs = 0;
- int ret = _device->readStream(
- _stream, &output_items[0],
- noutput_items, flags, timeNs);
+ int ret;
+
+ do {
+ ret = _device->readStream(
+ _stream, &output_items[0],
+ noutput_items, flags, timeNs);
+ } while (ret == SOAPY_SDR_OVERFLOW);
if (ret < 0) return 0; //call again
return ret;
--
2.25.2
Hi everyone,
thanks in advance for the support, where I can modify the subject value.
I have found the variable inside rds_mod.c but I didn't find anywhere they
are set.
The request is made because seems the windows binaries has them but they
were set and compiled or it's me that I didn't find where they are?
Kind regards,
Marco
I believe there is a bug in rtl_sdr.c at lines 89 and 242. When
bytes_to_read == len (or n_read), then bytes_to_read becomes 0 at lines
101 and 258 and the read never terminates since 0 means infinite read.
I believe the fix is to change lines 89 and 242 to read:
if ((bytes_to_read > 0) && (bytes_to_read <= len)) { // Versus
bytes_to_read < len
if ((bytes_to_read > 0) && (bytes_to_read <= (uint32_t)n_read)) { //
Likewise
John Tiller
Hi,
I looked at the forum for answers before posting, but I
unfortunately couldn't get answers to what I was looking for. I looked into
particular
https://www.mail-archive.com/openbsc@lists.osmocom.org/msg09819.html for
solving my issue.
Issue: I cannot connect BTS,TRX and BSC. The other modules of the network
are able to connect to each other. I have the RSP POWEROFF message
originating in log from TRX-UHD module and the BTS module is
shuttiing down. BTS connects via OML but fails to connect RSL. I looked
through the configuration files and seem correct to me. As per the previous
email archive, I wanted to login to VTY and check the logs, but, it logs
out as the BTS module shuts down (I cannot connect and see what's
happening).
Any suggestions would be appreciated on solving the issue. I am trying to
create a test 2G OSMOCOM network. Logs are written below and configuration
as attachments.
Thanks for your help!
*OSMO_BTS_TRX log:*
systemd[1]: Started Osmocom osmo-bts for osmo-trx.
osmo-bts-trx[23221]: <0017> control_if.c:911 CTRL at 127.0.0.1 4238
osmo-bts-trx[23221]: <0010> telnet_interface.c:104 Available via telnet
127.0.0.1 4241
osmo-bts-trx[23221]: <0012> input/ipaccess.c:1024 enabling ipaccess BTS
mode, OML connecting to 192.168.0.9:3002
osmo-bts-trx[23221]: <000b> trx_if.c:1174 phy0.0: Open transceiver
osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response
from transceiver(CMD POWEROFF)
osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response
from transceiver(CMD POWEROFF)
osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response
from transceiver(CMD POWEROFF)
osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response
from transceiver(CMD POWEROFF)
osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response
from transceiver(CMD POWEROFF)
osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response
from transceiver(CMD POWEROFF)
osmo-bts-trx[23221]: <000d> abis.c:142 Signalling link down
osmo-bts-trx[23221]: <0001> bts.c:292 Shutting down BTS 0, Reason Abis close
osmo-bts-trx[23221]: <000b> trx_if.c:185 phy0.0: No satisfactory response
from transceiver(CMD POWEROFF)
osmo-bts-trx[23221]: Shutdown timer expired
osmo-bts-trx[23221]: ((*))
osmo-bts-trx[23221]: |
osmo-bts-trx[23221]: / \ OsmoBTS
*OSMO_TRX_UHD log:*
osmo-trx-lms[7995]: DTRXCTRL <0001> Transceiver.cpp:773
[tid=140437098583808][chan=0] command is 'POWEROFF'
osmo-trx-lms[7995]: DTRXCTRL <0001> Transceiver.cpp:918
[tid=140437098583808][chan=0] response is 'RSP POWEROFF 0'
Good day! I am Jenrica from the Philippines and I am currently developing a
low-cost SDR ground radio receiver for L/S band satellites. I personally
emailed you to ask for your build steps for rtlsdr on gnu radio
installation (ubuntu 18.04). I have tried many ways already but I still
can't find the rtl-sdr source in the GRC. Your positive response is highly
appreciated.
Thank you
Hello,
I am working on making a binary format for rtl_power to save space on
my server for observing the spectrum. I am wondering if anyone else would
be interested in this idea.
I am hoping keep the same format in terms of how the data is organized in
the file but instead of using text use some form of binary format. For
example for the date and time I think using a unix epoch timestamp would
work.
I am hoping to receive any comments or criticism.
Thanks, KD9KCK
I can not transmit signal please help ? I am taking a low signal 165MHz after device is stopping to send signal. Why ? Please Help? İn this picture I take a very low signal after device stopped to send signal . Why I dont understand ?
I started application but dont transmit any signal ? Why ? I dont understand ?
I am listening in rtl sdr but dont transmit any signal . What is my error ? I dont contact any antenna to the device .
murat@murat-VivoBook-14-ASUS-Laptop-X407MA-X407MA:~$ pacat -r -d alsa_output.pci-0000_00_0e.0.analog-stereo.monitor | \
> pv -B 256k | \
> sox -t raw -r 44100 -e signed-integer -L -b 16 -c 2 - -c 1 -e signed-integer -b 16 -t raw - \
> biquad 4.76963 -2.98129 0 1 0.78833 0 sinc -15k loudness 5 | \
> fl2k_fm - -s 130e6 -c 30e6 -i 44100
Samplerate: 130.00 MHz
Carrier: 30.00 MHz
Frequencies: 100.00 MHz, 160.00 MHz
Failed to switch interface 0 to altsetting 1, trying to use interface 1
Allocating 6 zero-copy buffers
^C24,2MiB 0:18:45 [0,00 B/s] [ <=> ]
Signal caught, exiting!
^CSignal caught, exiting!
Dear all,
I just subscribed to this list since I encountered an issue after
pulling the latest git commits.
> lib: use interface 0 altsetting 1 instead of interface 1 ...
> This makes osmo-fl2k work again with Linux 5.5.0-rc6 or later,
On my system (Debian stable, kernel 4.19) this change results in
"Error enabling IF 0 altsetting 1". Reverting to the
previous version (with Interface 1) solved the problem for me.
I will investigate a bit more whether it is related to kernel or
libusb versions. Or have I missed some other required configuration?
Best regards,
Carl-Fredrik SM2YHP
--
------------------
Carl-Fredrik Enell
Föraregatan 26B
SE-98139 Kiruna
+46705508256
-----------------
Hi all:
I'm trying to build the latest gr-osmosdr package from the gr3.8 branch, but I'm
seeing some unusual errors, and I'm not quite sure what the deal is.
I'll note the following:
- I had errors related to existing python2 packages, so I tried building with Python3.
I'd be less than surprised if someone says that this is the cause of the issues, but
personally, I'd like to roll with the Py3 products from now on, what with Py2 being EOL…
- OS is Arch.
My cmake command was:
```
cmake \
-DCMAKE_BUILD_TYPE=Release \
-DPYTHON_EXECUTABLE=$(which python3) \
-DPYTHON_INCLUDE_DIR=$(echo /usr/include/python3*) \
-DPYTHON_LIBRARY=$(echo /usr/lib/libpython3.*.so) \
-DENABLE_DOXYGEN=1 \
-DCMAKE_INSTALL_PREFIX=/usr ../
```
Output from cmake:
```
-- ######################################################
-- # Gnuradio enabled components
-- ######################################################
-- * Python support
-- * sysmocom OsmoSDR
-- * IQ File Source & Sink
-- * Osmocom RTLSDR
-- * RTLSDR TCP Client
-- * Ettus USRP Devices
-- * Osmocom MiriSDR
-- * HackRF & rad1o Badge
-- * nuand bladeRF
-- * RFSPACE Receivers
-- * AIRSPY Receiver
-- * SoapySDR support
-- * Red Pitaya SDR
--
-- ######################################################
-- # Gnuradio disabled components
-- ######################################################
-- * Osmocom IQ Imbalance Correction
-- * AIRSPY HF+ Receiver
-- * FreeSRP support
--
-- Building for version: 0.2.0.0 / 0.2.0
-- Using install prefix: /usr
-- Configuring done
CMake Error at lib/CMakeLists.txt:43 (add_library):
Target "gnuradio-osmosdr" links to target "gnuradio::filter" but the target
was not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
CMake Error at /usr/lib64/cmake/gnuradio/UseSWIG.cmake:573 (add_library):
Target "osmosdr_swig" links to target "gnuradio::filter" but the target was
not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
Call Stack (most recent call first):
/usr/lib64/cmake/gnuradio/GrSwig.cmake:133 (swig_add_library)
swig/CMakeLists.txt:42 (GR_SWIG_MAKE)
CMake Error at lib/CMakeLists.txt:43 (add_library):
Target "gnuradio-osmosdr" links to target "gnuradio::filter" but the target
was not found. Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.
```
Any feedback would be appreciated.
Thanks,
--
Tom Swartz
I can not compile the block gr-osmosdr, obtained block of errors ,if you
can help me solve the problem ,please.Sincerely thebugslayers
The following are the errors
-- The CXX compiler identification is GNU 7.4.0
-- The C compiler identification is GNU 7.4.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Found Git: /usr/bin/git (found version "2.17.1")
-- Extracting version information from git describe...
-- Configuring Boost C++ Libraries...
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Boost version: 1.65.1
-- Found the following Boost libraries:
-- thread
-- system
-- chrono
-- date_time
-- atomic
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'gruel'
-- No package 'gruel' found
-- Could NOT find GRUEL (missing: GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS)
-- Checking for module 'gnuradio-core'
-- No package 'gnuradio-core' found
-- Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES
GNURADIO_CORE_INCLUDE_DIRS)
-- Checking for module 'gnuradio-iqbalance'
-- Found gnuradio-iqbalance, version 0
-- Could NOT find GNURADIO_IQBALANCE (missing:
GNURADIO_IQBALANCE_INCLUDE_DIRS)
-- Checking for module 'uhd'
-- No package 'uhd' found
-- Could NOT find UHD (missing: UHD_LIBRARIES UHD_INCLUDE_DIRS)
-- Checking for module 'gnuradio-uhd'
-- Found gnuradio-uhd, version 3.9.0
-- gnuradio-uhd not found.
-- Could NOT find GNURADIO_UHD (missing: GNURADIO_UHD_INCLUDE_DIRS)
-- Checking for module 'gnuradio-fcd'
-- No package 'gnuradio-fcd' found
-- gnuradio-fcd not found.
-- Could NOT find GNURADIO_FCD (missing: GNURADIO_FCD_LIBRARIES
GNURADIO_FCD_INCLUDE_DIRS)
-- Checking for module 'gnuradio-fcdproplus'
-- Found gnuradio-fcdproplus, version 3.7.11
-- Found gnuradio-fcdproplus: /usr/include,
/usr/lib/x86_64-linux-gnu/libgnuradio-fcdproplus.so
-- Found GNURADIO_FCDPP: /usr/lib/x86_64-linux-gnu/libgnuradio-fcdproplus.so
-- Checking for module 'libosmosdr'
-- No package 'libosmosdr' found
-- libosmosdr not found.
-- Checking for module 'librtlsdr'
-- No package 'librtlsdr' found
-- librtlsdr not found.
-- Checking for module 'libmirisdr'
-- No package 'libmirisdr' found
-- libmirisdr not found.
-- Checking for module 'libhackrf'
-- Found libhackrf, version 0.5
-- Found LIBHACKRF: /usr/local/lib/libhackrf.so
-- Checking for module 'libairspy'
-- No package 'libairspy' found
-- Could NOT find LIBAIRSPY (missing: LIBAIRSPY_LIBRARIES
LIBAIRSPY_INCLUDE_DIRS)
-- Checking for module 'libbladeRF'
-- No package 'libbladeRF' found
-- libbladeRF not found.
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
CMake Error at CMakeLists.txt:166 (message):
Gruel required to build gr-osmosdr
-- Configuring incomplete, errors occurred!
See also "/home/shan/gr-osmosdr/build/CMakeFiles/CMakeOutput.log".
See also "/home/shan/gr-osmosdr/build/CMakeFiles/CMakeError.log".
Thanks:)
Hello Team,
This is Abhishek Sharma a infosec researcher from India.
It was stange that I was getting an error constantly i.e. "no free
transfer, skipping input buffer" even though I setup the sample rate to
minimum but still getting the same error.
IT WOULD BE GREAT IF YOU CAN HELP IN RESOLVING THIS ISSUE
Waiting for your response
Below is the screen grab for reference:
[image: image.png]
--
Thanks
Regards
Abhishek Sharma
Mobile: (+91) 9458406845
*while building the gr-osmosdr i received a bulk of errors*
*I'm using Ubuntu 18.4 and gnuradio v3.9.*
*The following are the errors*
-- The CXX compiler identification is GNU 7.4.0
-- The C compiler identification is GNU 7.4.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Found Git: /usr/bin/git (found version "2.17.1")
-- Extracting version information from git describe...
-- Configuring Boost C++ Libraries...
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Boost version: 1.65.1
-- Found the following Boost libraries:
-- thread
-- system
-- chrono
-- date_time
-- atomic
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'gruel'
-- No package 'gruel' found
-- Could NOT find GRUEL (missing: GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS)
-- Checking for module 'gnuradio-core'
-- No package 'gnuradio-core' found
-- Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES
GNURADIO_CORE_INCLUDE_DIRS)
-- Checking for module 'gnuradio-iqbalance'
-- Found gnuradio-iqbalance, version 0
-- Could NOT find GNURADIO_IQBALANCE (missing:
GNURADIO_IQBALANCE_INCLUDE_DIRS)
-- Checking for module 'uhd'
-- No package 'uhd' found
-- Could NOT find UHD (missing: UHD_LIBRARIES UHD_INCLUDE_DIRS)
-- Checking for module 'gnuradio-uhd'
-- Found gnuradio-uhd, version 3.9.0
-- gnuradio-uhd not found.
-- Could NOT find GNURADIO_UHD (missing: GNURADIO_UHD_INCLUDE_DIRS)
-- Checking for module 'gnuradio-fcd'
-- No package 'gnuradio-fcd' found
-- gnuradio-fcd not found.
-- Could NOT find GNURADIO_FCD (missing: GNURADIO_FCD_LIBRARIES
GNURADIO_FCD_INCLUDE_DIRS)
-- Checking for module 'gnuradio-fcdproplus'
-- Found gnuradio-fcdproplus, version 3.7.11
-- Found gnuradio-fcdproplus: /usr/include,
/usr/lib/x86_64-linux-gnu/libgnuradio-fcdproplus.so
-- Found GNURADIO_FCDPP: /usr/lib/x86_64-linux-gnu/libgnuradio-fcdproplus.so
-- Checking for module 'libosmosdr'
-- No package 'libosmosdr' found
-- libosmosdr not found.
-- Checking for module 'librtlsdr'
-- No package 'librtlsdr' found
-- librtlsdr not found.
-- Checking for module 'libmirisdr'
-- No package 'libmirisdr' found
-- libmirisdr not found.
-- Checking for module 'libhackrf'
-- Found libhackrf, version 0.5
-- Found LIBHACKRF: /usr/local/lib/libhackrf.so
-- Checking for module 'libairspy'
-- No package 'libairspy' found
-- Could NOT find LIBAIRSPY (missing: LIBAIRSPY_LIBRARIES
LIBAIRSPY_INCLUDE_DIRS)
-- Checking for module 'libbladeRF'
-- No package 'libbladeRF' found
-- libbladeRF not found.
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
CMake Error at CMakeLists.txt:166 (message):
Gruel required to build gr-osmosdr
-- Configuring incomplete, errors occurred!
See also "/home/shan/gr-osmosdr/build/CMakeFiles/CMakeOutput.log".
See also "/home/shan/gr-osmosdr/build/CMakeFiles/CMakeError.log".
*Thanks:)*
Hi Sylvain,
Resent it to the list as requested.
I tried to use the 'gr3.7-qt5' branch today, and after successful
compilation, I am getting this error message on the terminal:
[+] Available device: 0:0 <NVIDIA Corporation> NVS 4200M
[+] Selected device: NVS 4200M
[!] CL Error (-59, /root/gr-fosphor/gr-fosphor/lib/fosphor/cl.c:438):
Unable to queue clear of spectrum buffer
I attached the complete output of the event, if you want to take a look. I
also attached the screen how it looks during the run.
OpenCL works fine otherwise, and I used gr-fosphor successfully on this
same machine before. I am on Ubuntu 18.04.03 LTS with the proprietary
Nvidia driver (v390). The gnuradio is 3.7.13.5 (comes with the ubuntu repo,
not compiled from source).
If you have any idea, or you need more info, debug log etc. please let me
know.
Regards,
Csaba
Dear fellow Osmocom developers,
I would like to invite all developers and contributors to Osmocom [sub]projects
to register for OsmoDevCon 2020 (held on April 24th-27th, 2020 in Berlin).
For details known so far, please check
http://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020
Please enter your name at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020#Requested
in case you would like to attend. Registering early allows proper
planning. Thanks!
Looking forward to meeting old and new Osmocom developers in April 2020.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
>Yeah, the nVidia driver is annoying ... it used to work and they broke
>it a few years ago and they don't care enough to fix it.
>And since I got a new laptop a few years back, I don't have a nvidia
>card to debug or work around it.
I compared fosphor to the nVidia OpenCL Simple OpenGL Interop example [1]
and noticed that fosphor calls glMapBuffer/glUnmapBuffer to clear the
spectrum vbo between the calls to glBufferData and clCreateFromGLBuffer.
If I eliminate the map/memset/unmap here by removing the call to
gl_vbo_clear in gl_deferred_init [2], then clCreateFromGLBuffer returns
CL_SUCCESS and fosphor appears to work with CL/GL sharing. It is not clear
to me if clearing the vbo_spectrum is necessary here, since
cl_queue_clear_buffers later initializes the mem_spectrum buffer to the
noise floor.
I'm using an nvidia GTX 1650 with version 430.50 of the nvidia drivers
under Linux Mint 18. A friend of mine tested the GTX 1060 and also had
success with this workaround.
Aaron
[1]
http://developer.download.nvidia.com/compute/DevZone/OpenCL/Projects/oclSim…
[2]
https://git.osmocom.org/gr-fosphor/tree/lib/fosphor/gl.c#n235
Dear friends and fans of software-defined radio,
the SDR track at next year's FOSDEM still has some slots left! We already
have
some submissions and we are in the process of ranking those, but we will
gladly
add YOUR presentation to the list!
If you have anything related to the field of free software radio, please
head to:
https://penta.fosdem.org/submission/FOSDEM20
and submit your short abstract! We're looking very much forward to your
submission.
For the committee,
Nicolas Cuervo
On Wed, Oct 16, 2019 at 8:19 PM Nicolas Cuervo Benavides <
cuervonicolas(a)gmail.com> wrote:
> Dear friends and fans of software-defined radio and free/open-source radio
> topics in general,
>
> FOSDEM 2020 (the free and open-source developer's meeting in Brussels,
> Europe) will, once again, feature a track on Software Defined Radio, and
> any other radio-related topics in the (now known as) *Free Software Radio* devroom.
> Therefore, we invite developers and users from the free software radio
> community to join us for this track and present your talks or demos.
>
>
> Software Radio has become an important tool to allow anyone to access the
> EM spectrum. Using free software radio libraries and applications and cheap
> hardware, anyone can now start hacking on wireless communications, remote
> sensing, radar, fun hacks of all sorts, or other applications. At FOSDEM,
> we hope to network all these projects and improve collaboration, bring new
> ideas forward and get more people involved.
>
>
> The track's web site resides at the link below. The final schedule will be
> available through Pentabarf and the official FOSDEM website.
>
> https://fosdem.org/2020/schedule/track/free_software_radio/
>
>
> Additional Information will be also available at:
> https://wiki.gnuradio.org/index.php/FOSDEM_2020
>
>
> ** Submit your presentations
>
> To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM20 and
> follow the instructions (you need an account, but can use your account from
> last year if you have one). You need to create an 'Event'; make sure it's
> in the Free Software Radio track! Lengths aren't fixed, but give a
> realistic estimate and please don't exceed 30 minutes unless you have
> something special planned (in that case, contact one of us). Also, don't
> forget to include time for Q&A.
> We will typically go for 30-minute slots -- shorter talks, unless they're
> really short, usually tend to screw up the schedule too much.
>
> You aren't limited to slide presentations, of course. Be creative.
> However, FOSDEM is an open-source conference, therefore we ask you to stay
> clear of marketing presentations and present something relevant to
> free/open software. We like nitty-gritty technical stuff.
>
> Topics discussed in this devroom include:
>
> * SDR Frameworks + Tools
> * Cellular/telecoms software
> * Free/Open SDR hardware
> * Wireless security
> * Random fun wireless hacks
> * SDR in education
> * Satellite/spacecraft communication
> * Ham radio related topics
>
>
> ** Important Dates
>
> FOSDEM is February 1st and 2nd, 2020. The Free Software Radio devroom is
> happening on Sunday, the 2nd of February.
>
> The submission deadline is Friday, December 6th. A complete schedule for
> the presentations in the devroom will be available on the 15th of December.
>
>
> In the last years we were always full to the brim with presentations, so
> if you want to present, please make sure to submit your abstracts soon!
>
> ** Steering Committee
> The track committee consists of:
>
> * Phil Balister - "Crofton"
> * Sylvain Munaut -"tnt"
> * Derek Kozel - "dkozel"
> * Nicolas Cuervo - "primercuervo"
> * Martin Braun - "mbr0wn" (Emeritus)
>
>
> Hope to hear from you soon! And please forward this announcement.
>
Hi,
Im an engineering student and would love to see gr-osmosdr working again.
Is there anyone working on gr-osmosdr at present?
I'm thinking that it will be a great feature to work on, and i can try to help to maintiain the feature if you solve my doubts and my newbie errors. I don't think that this is a newbie to gnu dev task but i really would love to see gr-osmocom working again.
César.
Hi,
Im an engineering student and would love to see gr-osmosdr working again.
Is there anyone working on gr-osmosdr at present?
I'm thinking that it will be a great feature to work on, and i can try to help to maintiain the feature if you solve my doubts and my newbie errors. I don't think that this is a newbie to gnu dev task but i really would love to see gr-osmocom working again.
César.
I just got an email from someone at RedHat; they seem to think that I am one of the gr-iqbal maintainers since I have the most recent commit ;).
Apparently they have their own patch for Python 3 and Gnuradio 3.8, but wanted to know if upstream would be supporting the migration. Since I am not really upstream, I thought I'd forward the patch along.
https://src.fedoraproject.org/rpms/gr-iqbal/blob/master/f/gr-iqbal-0.37.2-g…
--
Brian M. Waters
brian(a)brianmwaters.net
Clang doesn't automatically define the "complex" keyword like old versions of GCC apparently used to. Appending this little check enabled compiling gr-iqbal w/ Clang, which is now the default compiler on OpenBSD and I think FreeBSD too.
diff --git a/lib/optimize_c.cc b/lib/optimize_c.cc
index 2cad998..6c8b706 100644
--- a/lib/optimize_c.cc
+++ b/lib/optimize_c.cc
@@ -31,7 +31,7 @@
__GNUC_PATCHLEVEL__ \
)
-#if GCC_VERSION >= 40800
+#if GCC_VERSION >= 40800 || defined(__clang__)
# define complex _Complex
# undef _GLIBCXX_HAVE_COMPLEX_H
#endif
--
Brian M. Waters
brian(a)brianmwaters.net