Dear fellow Osmocom developers,
as you all know, we've sadly had to skip OsmoDevCon 2020 and 2021,
trying to compensate it at least to some extent with our OsmoDevCall
every two weeks.
The COVID-19 pandemic is far from over, and we don't know what the
upcoming winter season will bring.
Nevertheless, I think it would be a good idea to start a discussion of
whether we should plan for an OsmoDevCon in 2022.
I personally would say let's plan for the usual late April 2022 time frame,
and if the pandemic situation deteriorates, we can still cancel it with
something like one month lead time.
I would also personally suggest to limit attendance to people who are fully
vaccinated, and in addition do a self-test for all participants every
morning.
In terms of venue, we might also consider to move to a venue that allows better
ventilation. Irrespective of the above we can also bring the air filters from
the sysmocom office.
So with that as an input statement, I would like to hear your opinion
on the above proposals. Who would want to attend? Any complaints against
the "vaccinated only plus daily self-tests in the morning" approach?
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)
Please find below a patch as per suggestion of Martin Ling: call libusb_interrupt_event_handler in rtlsdr_cancel_async to trigger the event loop handler to look at the async_cancel variable.
(https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/thr…)
I have tested timings on a windows 11 machine with and without the patch when running a async transfer at two different sampling rates:
sample rate with without theory
1536K 0 - 2 ms 0 - 84 ms 85 ms
288K 0 - 4 ms 0 - 457 ms 455 ms
The table shows the range of timings to cancel the async transfer as measured over a couple of runs.
The "theory" column shows the theoretical time to complete one transfer at the particular sampling rate (i.e. driven by the size of a transfer buffer). And indeed, on some machines it appears that cancelling the async transfer, if unlucky, can take as much time as waiting for a full transfer to complete. The call to libsub_intertrupt_event_handler fixes that. For large transfer buffers and/or low sample rates this can make a difference.
Thanks to Martin for sharing the insight.
Jasper
Author: jvde.github <jvde.github(a)gmail.com>
Date: Wed Jan 26 19:00:55 2022 +0100
call interrupt_event_handler in cancel_async
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 67e30c4..b949692 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1948,6 +1948,9 @@ int rtlsdr_cancel_async(rtlsdr_dev_t *dev)
if (RTLSDR_RUNNING == dev->async_status) {
dev->async_status = RTLSDR_CANCELING;
dev->async_cancel = 1;
+
+ libusb_interrupt_event_handler(dev->ctx);
+
return 0;
}
Good day!
I was struggling with an occasional crash of the rtl-sdr tools on
windows when closing the device after pressing CTRL-C. Both with the
versions as provided with VCPKG and when directly compiling the latest
version in MSVC (with latest of libusb). It is a bit difficult to spot
a crash at close as usually it is silent but you can see it running it
from MSVC or in a debugger. It does not happen always but frequent
enough.
Also, consider this example for the binary versions from Jan 2
(https://ftp.osmocom.org/binaries/windows/rtl-sdr/):
C:\>rtl_adsb.exe
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
....
Signal caught, exiting!
User cancel, exiting...
C:\>echo %ERRORLEVEL%
-1073741819
After investigation of the libusb logs and experimentation I think
this crash can be avoided by 1) defining zerotv in rtlsdr_read_async
as 1 ms instead of zero (see libusb/libusb#1043) or 2) include a short
call to Sleep to allow async operations to finish. Please find below a
patch for the latter fix for your consideration.
More information, here: https://github.com/osmocom/rtl-sdr/pull/18 and
here: https://github.com/libusb/libusb/issues/1043
Thanks for your great work on the rtlsdr library and kind regards.
Author: jvde.github <jvde.github(a)gmail.com>
Date: Sat Jan 8 13:30:34 2022 +0100
force wait state after cancel of usb transfer and before handling usb events
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 0146298..2682d77 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1930,6 +1930,9 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev,
rtlsdr_read_async_cb_t cb, void *ctx,
/* handle events after canceling
* to allow transfer status to
* propagate */
+#ifdef _WIN32
+ Sleep(1);
+#endif
libusb_handle_events_timeout_completed(dev->ctx,
&zerotv, NULL);
if (r < 0)
Hi all, on some systems building librtlsdr can fail when libusb-1.0 is not installed in the standard library locations (e.g. macOS with libusb installed via homebrew can have the shared library in /usr/local/Cellar/libusb/1.0.24/lib).
The below patch includes LIBUSB_LIBRARY_DIRS in the search path for the linker to correct this issue.
For your kind consideration. Thanks, Jasper
Author: jvde.github <jvde.github(a)gmail.com>
Date: Mon Jan 24 19:21:44 2022 +0100
fix build for macOS
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 7b47309..3b8060b 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -21,6 +21,7 @@
add_library(rtlsdr SHARED librtlsdr.c
tuner_e4k.c tuner_fc0012.c tuner_fc0013.c tuner_fc2580.c tuner_r82xx.c)
target_link_libraries(rtlsdr ${LIBUSB_LIBRARIES} ${THREADS_PTHREADS_LIBRARY})
+target_link_directories(rtlsdr PUBLIC ${LIBUSB_LIBRARY_DIRS})
target_include_directories(rtlsdr PUBLIC
$<BUILD_INTERFACE:${CMAKE_SOURCE_DIR}/include>
$<INSTALL_INTERFACE:include> # <prefix>/include
From: Clayton Smith <argilo(a)gmail.com>
Librtlsdr has a workaround for libusb versions that lack
libusb_handle_events_timeout_completed, which was added in version 1.0.9
(released 2012-04-02). The workaround is always applied unless the
HAVE_LIBUSB_HANDLE_EVENTS_TIMEOUT_COMPLETED macro is set, but the cmake
code that sets this macro was removed in
849f8efca42b659bf7e8fe17156ee0aa67b47233. As a result, the workaround is
now always applied. This results in an extra 1-second delay whenever a
GNU Radio flowgraph containing an RTL-SDR block is stopped, which makes
operations like switching between demodulators in Gqrx annoyingly slow.
To solve this problem, I've simply removed the workaround, as it should
no longer be needed.
I wonder if perhaps the workaround recently applied in
2659e2df31e592d74d6dd264a4f5ce242c6369c8 might stem from the same bug.
---
src/librtlsdr.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 2682d77ec2..096abaeffc 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -39,12 +39,6 @@
#define LIBUSB_CALL
#endif
-/* libusb < 1.0.9 doesn't have libusb_handle_events_timeout_completed */
-#ifndef HAVE_LIBUSB_HANDLE_EVENTS_TIMEOUT_COMPLETED
-#define libusb_handle_events_timeout_completed(ctx, tv, c) \
- libusb_handle_events_timeout(ctx, tv)
-#endif
-
/* two raised to the power of n */
#define TWO_POW(n) ((double)(1ULL<<(n)))
--
2.25.1
Error codes from libhackrf are not very legible, and in the case of
HACKRF_ERROR_LIBUSB, don't uniquely describe the cause of the error.
Calling hackrf_error_name() provides a human-readable message, and
in the case of libusb errors, identifies the actual cause rather than
just indicating that the error came from libusb.
This came up whilst trying to diagnose a libhackrf bug which showed
up when using libhackrf, via gr-osmosdr, via gqrx:
https://github.com/greatscottgadgets/hackrf/issues/883
---
lib/hackrf/hackrf_source_c.cc | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/hackrf/hackrf_source_c.cc b/lib/hackrf/hackrf_source_c.cc
index 03ea3bd..2826924 100644
--- a/lib/hackrf/hackrf_source_c.cc
+++ b/lib/hackrf/hackrf_source_c.cc
@@ -170,7 +170,8 @@ bool hackrf_source_c::start()
hackrf_common::start();
int ret = hackrf_start_rx( _dev.get(), _hackrf_rx_callback, (void *)this );
if ( ret != HACKRF_SUCCESS ) {
- std::cerr << "Failed to start RX streaming (" << ret << ")" << std::endl;
+ const char *msg = hackrf_error_name( (enum hackrf_error) ret );
+ std::cerr << "Failed to start RX streaming (" << ret << ": " << msg << ")" << std::endl;
return false;
}
return true;
@@ -184,7 +185,8 @@ bool hackrf_source_c::stop()
hackrf_common::stop();
int ret = hackrf_stop_rx( _dev.get() );
if ( ret != HACKRF_SUCCESS ) {
- std::cerr << "Failed to stop RX streaming (" << ret << ")" << std::endl;
+ const char *msg = hackrf_error_name( (enum hackrf_error) ret );
+ std::cerr << "Failed to stop RX streaming (" << ret << ": " << msg << ")" << std::endl;
return false;
}
return true;
--
2.30.2
Dear Osmocom community,
today our mailing list server lists.osmocom.org has finally been migrated
from mailman2-on-freebsd to mailman3-on-linux. This also included a variety
of changes to DNS. I'll spare you the details, but everything _should_ be up
and running now.
* The List-Id headers should not have changed.
* all list subscriptions + user accounts have been converted.
* old 'static html' archives are still available (read only) at URLs like
https://lists.osmocom.org/pipermail/baseband-devel/
* old List URLs like https://lists.osmocom.org/mailman/listinfo/baseband-devel
are redirected to their respective modern counterparts
In case you notice any mailing list related problem, please don't hesitate to
contact me.
Happy hacking,
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)
o decode the VOR's morse code station ID. From that, I will have a shor=
t list of VORs that I can currently receive. From those, if the geometry is=
appropriate (I know the VORs positions from a database) I can calculate a =
position.<u></u><u></u></p>
</div><div><p class=3D"MsoNormal"><u></u> <u></u></p></div><div><p cla=
ss=3D"MsoNormal">The software then just round-robin tunes the VORs in range=
and continually tries to calculate positions. If too many drop out, it ret=
urns to the initial scan mode.<u></u><u></u></p>
</div><div><p class=3D"MsoNormal"><u></u> <u></u></p></div><div><p cla=
ss=3D"MsoNormal">Not being able to receive this VOR or that VOR is not gene=
rally a problem, but obviously, the more the better. With extra VORs I have=
better options for choosing the closest ones or the ones with the best geo=
metry.<u></u><u></u></p>
</div><div><p class=3D"MsoNormal"><u></u> <u></u></p></div><div><p cla=
ss=3D"MsoNormal"><u></u> <u></u></p></div><div><p class=3D"MsoNormal">=
This is actually quite difficult to test, because VORs can generally only b=
e received line-of-sight -- which means in the air. I'm a private pilot=
but I found that flying and noodling with a laptop is too much trouble. Fr=
om my office window, on a high floor in Oakland, CA, I can receive one VOR =
from the Oakland airport. And I have now discovered a ridge near my home wi=
th a scenic overlook from which I can receive two.<u></u><u></u></p>
</div><div><p class=3D"MsoNormal"><u></u> <u></u></p></div><div><p cla=
ss=3D"MsoNormal">I've tested the software enough to know that the initi=
al scan function seems to work, and the morse decoding kind of works, but I=
am not confident I'll get it to work very well. (One transmitter's=
dit looks a lot like another's dah.) The nav signal decoding is simple=
. (A 30 Hz AM modulated tone is phase compared with a 30 Hz tone FM modulat=
ed at 9960 Hz. The phase obtained is the azimuth to the station.)<u></u><u>=
</u></p>
</div><div><p class=3D"MsoNormal"><u></u> <u></u></p></div><div><p cla=
ss=3D"MsoNormal"><u></u> <u></u></p></div><div><p class=3D"MsoNormal">=
If I ever get this working, I looking forward to sharing it with the commun=
ity. In the process of building this, I created a simple SDR toolkit of DSP=
functions. It's like Gnuradio in concept, but 16b fixed-point, and has=
no external dependencies, and C89, so is easier to build on weird and limi=
ted platforms. It also has perl bindings. Compared to GR, it looks like the=
work of a rank amateur just learning DSP, but I do like the concept of the=
re being a GR-like library out there, lightweight and embedded-friendly.<u>=
</u><u></u></p>
</div><div><p class=3D"MsoNormal"><u></u> <u></u></p></div><div><p cla=
ss=3D"MsoNormal"><u></u> <u></u></p></div><div><p class=3D"MsoNormal">=
Regards,<u></u><u></u></p></div><div><p class=3D"MsoNormal">Dave J<u></u><u=
></u></p></div>
<div><div><div><p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u=
> <u></u></p><div><p class=3D"MsoNormal">On Tue, Oct 22, 2013 at 3:06 =
AM, jdow <<a href=3D"mailto:jdow@earthlink.net" target=3D"_blank">jdow@e=
arthlink.net</a>> wrote:<u></u><u></u></p>
<p class=3D"MsoNormal">He sent me two frequencies in private email. These w=
ere in the FM<br>broadcast band (in the US). He probably needs to notch the=
m out<br>in order to get adequate response.<br><br>As for wanting narrow ba=
ndwidth - I am not quite sure why he thinks<br>
that is a benefit. I use a large FFT (about 10 Hz per bin) and use<br>the z=
oom control to see fine detail. (Different FFT settings suite<br>different =
uses. This one seems to be a good compromise with my two<br>needs. I'm =
too lazy to change it.)<br>
<br>{^_^}<u></u><u></u></p><div><div><p class=3D"MsoNormal"><br><br><br>On =
2013/10/22 02:08, Sylvain Munaut wrote:<u></u><u></u></p><blockquote style=
=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;m=
argin-left:4.8pt;margin-right:0cm">
<p class=3D"MsoNormal">Effective filtering must occur between antenna and r=
eceiver. All the<br>problems that a saturated preamp and ADC cause can&rsqu=
o;t be repaired by<br>software. Never.<u></u><u></u></p></blockquote><p cla=
ss=3D"MsoNormal" style=3D"margin-bottom:12.0pt">
<br>But his original problem is not with saturated preamps or ADC ... it=
9;s<br>aliasing ... and that can be solved in the digital domain provided<b=
r>fast enough ADC.<br><br>Cheers,<br><br> Sylvain<br><br><u></=
u><u></u></p>
</div></div></div><p class=3D"MsoNormal"><u></u> <u></u></p></div></di=
v></div></div></div><p class=3D"MsoNormal"><u></u> <u></u></p></div></=
div></div></div></div></div></blockquote></div><br></div>
--001a11346d7c0fd5fd04f20c4ef9--