- osmocom-sdr - lists.osmocom.org

[PATCH] Getting device fd from command line with termux-usb

by rio＠r26.me

Hello, I am working on getting rtl-sdr working on Android inside a Termux environment. Termux-usb (https://wiki.termux.com/wiki/Termux-usb) negotiates with Android to get an fd, and the fd gets passed as command line argument to the program needing the USB device. This patch adds support for it. With it, I can run termux-usb -e "./rtl-sdr/build/src/rtl_fm -f 440M -M fm -N" /dev/bus/usb/001/002 | ./direwolf/build/src/direwolf -t 0 stdin in Termux, and connecto to it from APRSDroid. --- include/rtl-sdr.h | 2 ++ src/librtlsdr.c | 92 +++++++++++++++++++++++++++++++++++++++++++++-- src/rtl_adsb.c | 21 ++++++++--- src/rtl_biast.c | 19 +++++++--- src/rtl_fm.c | 19 +++++++--- src/rtl_power.c | 19 +++++++--- src/rtl_sdr.c | 17 +++++++-- src/rtl_tcp.c | 19 +++++++--- src/rtl_test.c | 19 +++++++--- 9 files changed, 196 insertions(+), 31 deletions(-) diff --git a/include/rtl-sdr.h b/include/rtl-sdr.h index d64701e..bd88f74 100644 --- a/include/rtl-sdr.h +++ b/include/rtl-sdr.h @@ -62,6 +62,8 @@ RTLSDR_API int rtlsdr_get_index_by_serial(const char *serial); RTLSDR_API int rtlsdr_open(rtlsdr_dev_t **dev, uint32_t index); +RTLSDR_API int rtlsdr_open_fd(rtlsdr_dev_t **dev, intptr_t fd); + RTLSDR_API int rtlsdr_close(rtlsdr_dev_t *dev); /* configuration functions */ diff --git a/src/librtlsdr.c b/src/librtlsdr.c index ee13556..1c4985b 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -125,6 +125,7 @@ struct rtlsdr_dev { void rtlsdr_set_gpio_bit(rtlsdr_dev_t *dev, uint8_t gpio, int val); static int rtlsdr_set_if_freq(rtlsdr_dev_t *dev, uint32_t freq); +static int rtlsdr_init(rtlsdr_dev_t *dev); /* generic tuner interface functions, shall be moved to the tuner implementations */ int e4000_init(void *dev) { @@ -1451,7 +1452,6 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) libusb_device *device = NULL; uint32_t device_count = 0; struct libusb_device_descriptor dd; - uint8_t reg; ssize_t cnt; dev = malloc(sizeof(rtlsdr_dev_t)); @@ -1503,6 +1503,94 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) libusb_free_device_list(list, 1); + r = rtlsdr_init(dev); + if (r < 0) { + goto err; + } + + *out_dev = dev; + + return r; +err: + if (dev) { + if (dev->devh) + libusb_close(dev->devh); + + if (dev->ctx) + libusb_exit(dev->ctx); + + free(dev); + } + + return r; +} + +int rtlsdr_open_fd(rtlsdr_dev_t **out_dev, intptr_t fd) +{ + int r; + rtlsdr_dev_t *dev = NULL; + libusb_device *device = NULL; + struct libusb_device_descriptor dd; + + dev = malloc(sizeof(rtlsdr_dev_t)); + if (NULL == dev) + return -ENOMEM; + + memset(dev, 0, sizeof(rtlsdr_dev_t)); + memcpy(dev->fir, fir_default, sizeof(fir_default)); + + libusb_set_option(NULL, LIBUSB_OPTION_NO_DEVICE_DISCOVERY); + r = libusb_init(&dev->ctx); + if(r < 0){ + free(dev); + return -1; + } + + dev->dev_lost = 1; + + r = libusb_wrap_sys_device(dev->ctx, fd, &dev->devh); + if (r < 0) { + fprintf(stderr, "usb_open error %d\n", r); + if(r == LIBUSB_ERROR_ACCESS) + fprintf(stderr, "Please fix the device permissions, e.g. " + "by installing the udev rules file rtl-sdr.rules\n"); + goto err; + } + + device = libusb_get_device(dev->devh); + libusb_get_device_descriptor(device, &dd); + if (!find_known_device(dd.idVendor, dd.idProduct)) { + fprintf(stderr, "Unrecognized device\n"); + r = -1; + goto err; + } + + r = rtlsdr_init(dev); + if (r < 0) { + goto err; + } + + *out_dev = dev; + + return r; +err: + if (dev) { + if (dev->devh) + libusb_close(dev->devh); + + if (dev->ctx) + libusb_exit(dev->ctx); + + free(dev); + } + + return r; +} + +static int rtlsdr_init(rtlsdr_dev_t *dev) { + int r; + uint8_t reg; + if (libusb_kernel_driver_active(dev->devh, 0) == 1) { dev->driver_active = 1; @@ -1639,8 +1727,6 @@ found: rtlsdr_set_i2c_repeater(dev, 0); - *out_dev = dev; - return 0; err: if (dev) { diff --git a/src/rtl_adsb.c b/src/rtl_adsb.c index 8119ac8..ae5eccd 100644 --- a/src/rtl_adsb.c +++ b/src/rtl_adsb.c @@ -89,7 +89,8 @@ void usage(void) fprintf(stderr, "rtl_adsb, a simple ADS-B decoder\n\n" "Use:\trtl_adsb [-R] [-g gain] [-p ppm] [output file]\n" - "\t[-d device_index (default: 0)]\n" + "\t[-d device_index (default: 1)]\n" + "\t[-N file_desc use file descriptor instead of libusb index\n" "\t[-V verbove output (default: off)]\n" "\t[-S show short frames (default: off)]\n" "\t[-Q quality (0: no sanity checks, 0.5: half bit, 1: one bit (default), 2: two bits)]\n" @@ -372,19 +373,24 @@ int main(int argc, char **argv) int gain = AUTO_GAIN; /* tenths of a dB */ int dev_index = 0; int dev_given = 0; + int fd_given = 0; int ppm_error = 0; int enable_biastee = 0; pthread_cond_init(&ready, NULL); pthread_mutex_init(&ready_m, NULL); squares_precompute(); - while ((opt = getopt(argc, argv, "d:g:p:e:Q:VST")) != -1) + while ((opt = getopt(argc, argv, "d:N:g:p:e:Q:VST")) != -1) { switch (opt) { case 'd': dev_index = verbose_device_search(optarg); dev_given = 1; break; + case 'N': + dev_index = atoi(optarg); + fd_given = 1; + break; case 'g': gain = (int)(atof(optarg) * 10); break; @@ -420,7 +426,7 @@ int main(int argc, char **argv) buffer = malloc(DEFAULT_BUF_LENGTH * sizeof(uint8_t)); - if (!dev_given) { + if (!dev_given && !fd_given) { dev_index = verbose_device_search("0"); } @@ -428,7 +434,12 @@ int main(int argc, char **argv) exit(1); } - r = rtlsdr_open(&dev, (uint32_t)dev_index); + if (fd_given) { + r = rtlsdr_open_fd(&dev, dev_index); + } else { + r = rtlsdr_open(&dev, (uint32_t)dev_index); + } + if (r < 0) { fprintf(stderr, "Failed to open rtlsdr device #%d.\n", dev_index); exit(1); @@ -493,7 +504,7 @@ int main(int argc, char **argv) else { fprintf(stderr, "\nLibrary error %d, exiting...\n", r);} rtlsdr_cancel_async(dev); - pthread_cancel(demod_thread); + pthread_kill(demod_thread, 0); pthread_join(demod_thread, NULL); pthread_cond_destroy(&ready); pthread_mutex_destroy(&ready_m); diff --git a/src/rtl_biast.c b/src/rtl_biast.c index 185e838..e9c914e 100644 --- a/src/rtl_biast.c +++ b/src/rtl_biast.c @@ -41,7 +41,8 @@ void usage(void) "bias tee: rtl_biast -d 0 -b 1\n" "Any GPIO: rtl_biast -d 0 -g 1 -b 1\n\n" "Usage:\n" - "\t[-d device_index (default: 0)]\n" + "\t[-d device_index (default: 1)]\n" + "\t[-N file_desc use file descriptor instead of libusb index\n" "\t[-b bias_on (default: 0)]\n" "\t[-g GPIO select (default: 0)]\n"); exit(1); @@ -52,16 +53,21 @@ int main(int argc, char **argv) int i, r, opt; int dev_index = 0; int dev_given = 0; + int fd_given = 0; uint32_t bias_on = 0; uint32_t gpio_pin = 0; int device_count; - while ((opt = getopt(argc, argv, "d:b:g:h?")) != -1) { + while ((opt = getopt(argc, argv, "d:N:b:g:h?")) != -1) { switch (opt) { case 'd': dev_index = verbose_device_search(optarg); dev_given = 1; break; + case 'N': + dev_index = atoi(optarg); + fd_given = 1; + break; case 'b': bias_on = atoi(optarg); break; @@ -74,7 +80,7 @@ int main(int argc, char **argv) } } - if (!dev_given) { + if (!dev_given && !fd_given) { dev_index = verbose_device_search("0"); } @@ -82,7 +88,12 @@ int main(int argc, char **argv) exit(1); } - r = rtlsdr_open(&dev, dev_index); + if (fd_given) { + r = rtlsdr_open_fd(&dev, dev_index); + } else { + r = rtlsdr_open(&dev, (uint32_t)dev_index); + } + rtlsdr_set_bias_tee_gpio(dev, gpio_pin, bias_on); exit: diff --git a/src/rtl_fm.c b/src/rtl_fm.c index 037793c..c1b562c 100644 --- a/src/rtl_fm.c +++ b/src/rtl_fm.c @@ -192,7 +192,8 @@ void usage(void) "\t wbfm == -M fm -s 170k -o 4 -A fast -r 32k -l 0 -E deemp\n" "\t raw mode outputs 2x16 bit IQ pairs\n" "\t[-s sample_rate (default: 24k)]\n" - "\t[-d device_index (default: 0)]\n" + "\t[-d device_index (default: 1)]\n" + "\t[-N file_desc use file descriptor instead of libusb index\n" "\t[-T enable bias-T on GPIO PIN 0 (works for rtl-sdr.com v3 dongles)]\n" "\t[-g tuner_gain (default: automatic)]\n" "\t[-l squelch_level (default: 0/off)]\n" @@ -1057,6 +1058,7 @@ int main(int argc, char **argv) #endif int r, opt; int dev_given = 0; + int fd_given = 0; int custom_ppm = 0; int enable_biastee = 0; dongle_init(&dongle); @@ -1064,12 +1066,16 @@ int main(int argc, char **argv) output_init(&output); controller_init(&controller); - while ((opt = getopt(argc, argv, "d:f:g:s:b:l:o:t:r:p:E:F:A:M:hT")) != -1) { + while ((opt = getopt(argc, argv, "d:N:f:g:s:b:l:o:t:r:p:E:F:A:M:hT")) != -1) { switch (opt) { case 'd': dongle.dev_index = verbose_device_search(optarg); dev_given = 1; break; + case 'N': + dongle.dev_index = atoi(optarg); + fd_given = 1; + break; case 'f': if (controller.freq_len >= FREQUENCIES_LIMIT) { break;} @@ -1190,7 +1196,7 @@ int main(int argc, char **argv) ACTUAL_BUF_LENGTH = lcm_post[demod.post_downsample] * DEFAULT_BUF_LENGTH; - if (!dev_given) { + if (!dev_given && !fd_given) { dongle.dev_index = verbose_device_search("0"); } @@ -1198,7 +1204,12 @@ int main(int argc, char **argv) exit(1); } - r = rtlsdr_open(&dongle.dev, (uint32_t)dongle.dev_index); + if (fd_given) { + r = rtlsdr_open_fd(&dongle.dev, dongle.dev_index); + } else { + r = rtlsdr_open(&dongle.dev, (uint32_t)dongle.dev_index); + } + if (r < 0) { fprintf(stderr, "Failed to open rtlsdr device #%d.\n", dongle.dev_index); exit(1); diff --git a/src/rtl_power.c b/src/rtl_power.c index df3ceb7..3c750ce 100644 --- a/src/rtl_power.c +++ b/src/rtl_power.c @@ -130,7 +130,8 @@ void usage(void) "\t[-e exit_timer (default: off/0)]\n" //"\t[-s avg/iir smoothing (default: avg)]\n" //"\t[-t threads (default: 1)]\n" - "\t[-d device_index (default: 0)]\n" + "\t[-d device_index (default: 1)]\n" + "\t[-N file_desc use file descriptor instead of libusb index\n" "\t[-g tuner_gain (default: automatic)]\n" "\t[-p ppm_error (default: 0)]\n" "\t[-T enable bias-T on GPIO PIN 0 (works for rtl-sdr.com v3 dongles)]\n" @@ -774,6 +775,7 @@ int main(int argc, char **argv) int gain = AUTO_GAIN; // tenths of a dB int dev_index = 0; int dev_given = 0; + int fd_given = 0; int ppm_error = 0; int interval = 10; int fft_threads = 1; @@ -792,7 +794,7 @@ int main(int argc, char **argv) double (*window_fn)(int, int) = rectangle; freq_optarg = ""; - while ((opt = getopt(argc, argv, "f:i:s:t:d:g:p:e:w:c:F:1PDOhT")) != -1) { + while ((opt = getopt(argc, argv, "f:i:s:t:d:N:g:p:e:w:c:F:1PDOhT")) != -1) { switch (opt) { case 'f': // lower:upper:bin_size freq_optarg = strdup(optarg); @@ -802,6 +804,10 @@ int main(int argc, char **argv) dev_index = verbose_device_search(optarg); dev_given = 1; break; + case 'N': + dev_index = atoi(optarg); + fd_given = 1; + break; case 'g': gain = (int)(atof(optarg) * 10); break; @@ -896,7 +902,7 @@ int main(int argc, char **argv) fprintf(stderr, "Reporting every %i seconds\n", interval); - if (!dev_given) { + if (!dev_given && !fd_given) { dev_index = verbose_device_search("0"); } @@ -904,7 +910,12 @@ int main(int argc, char **argv) exit(1); } - r = rtlsdr_open(&dev, (uint32_t)dev_index); + if (fd_given) { + r = rtlsdr_open_fd(&dev, dev_index); + } else { + r = rtlsdr_open(&dev, (uint32_t)dev_index); + } + if (r < 0) { fprintf(stderr, "Failed to open rtlsdr device #%d.\n", dev_index); exit(1); diff --git a/src/rtl_sdr.c b/src/rtl_sdr.c index ccd6d76..60acd78 100644 --- a/src/rtl_sdr.c +++ b/src/rtl_sdr.c @@ -49,7 +49,8 @@ void usage(void) "rtl_sdr, an I/Q recorder for RTL2832 based DVB-T receivers\n\n" "Usage:\t -f frequency_to_tune_to [Hz]\n" "\t[-s samplerate (default: 2048000 Hz)]\n" - "\t[-d device_index (default: 0)]\n" + "\t[-d device_index (default: 1)]\n" + "\t[-N file_desc use file descriptor instead of libusb index\n" "\t[-g gain (default: 0 for auto)]\n" "\t[-p ppm_error (default: 0)]\n" "\t[-b output_block_size (default: 16 * 16384)]\n" @@ -120,6 +121,7 @@ int main(int argc, char **argv) uint8_t *buffer; int dev_index = 0; int dev_given = 0; + int fd_given = 0; uint32_t frequency = 100000000; uint32_t samp_rate = DEFAULT_SAMPLE_RATE; uint32_t out_block_size = DEFAULT_BUF_LENGTH; @@ -130,6 +132,10 @@ int main(int argc, char **argv) dev_index = verbose_device_search(optarg); dev_given = 1; break; + case 'N': + dev_index = atoi(optarg); + fd_given = 1; + break; case 'f': frequency = (uint32_t)atofs(optarg); break; @@ -179,7 +185,7 @@ int main(int argc, char **argv) buffer = malloc(out_block_size * sizeof(uint8_t)); - if (!dev_given) { + if (!dev_given && !fd_given) { dev_index = verbose_device_search("0"); } @@ -187,7 +193,12 @@ int main(int argc, char **argv) exit(1); } - r = rtlsdr_open(&dev, (uint32_t)dev_index); + if (fd_given) { + r = rtlsdr_open_fd(&dev, dev_index); + } else { + r = rtlsdr_open(&dev, (uint32_t)dev_index); + } + if (r < 0) { fprintf(stderr, "Failed to open rtlsdr device #%d.\n", dev_index); exit(1); diff --git a/src/rtl_tcp.c b/src/rtl_tcp.c index 78d625a..c3d5e11 100644 --- a/src/rtl_tcp.c +++ b/src/rtl_tcp.c @@ -102,7 +102,8 @@ void usage(void) printf("\t[-s samplerate in Hz (default: %d Hz)]\n", DEFAULT_SAMPLE_RATE_HZ); printf("\t[-b number of buffers (default: 15, set by library)]\n"); printf("\t[-n max number of linked list buffers to keep (default: %d)]\n", DEFAULT_MAX_NUM_BUFFERS); - printf("\t[-d device index (default: 0)]\n"); + printf("\t[-d device_index (default: 1)]\n"); + printf("\t[-N file_desc use file descriptor instead of libusb index\n"); printf("\t[-P ppm_error (default: 0)]\n"); printf("\t[-T enable bias-T on GPIO PIN 0 (works for rtl-sdr.com v3 dongles)]\n"); printf("\t[-D enable direct sampling (default: off)]\n"); @@ -395,6 +396,7 @@ int main(int argc, char **argv) uint32_t buf_num = 0; int dev_index = 0; int dev_given = 0; + int fd_given = 0; int gain = 0; int ppm_error = 0; int direct_sampling = 0; @@ -415,12 +417,16 @@ int main(int argc, char **argv) struct sigaction sigact, sigign; #endif - while ((opt = getopt(argc, argv, "a:p:f:g:s:b:n:d:P:TD")) != -1) { + while ((opt = getopt(argc, argv, "a:p:f:g:s:b:n:d:N:P:TD")) != -1) { switch (opt) { case 'd': dev_index = verbose_device_search(optarg); dev_given = 1; break; + case 'N': + dev_index = atoi(optarg); + fd_given = 1; + break; case 'f': frequency = (uint32_t)atofs(optarg); break; @@ -460,7 +466,7 @@ int main(int argc, char **argv) if (argc < optind) usage(); - if (!dev_given) { + if (!dev_given && !fd_given) { dev_index = verbose_device_search("0"); } @@ -468,7 +474,12 @@ int main(int argc, char **argv) exit(1); } - rtlsdr_open(&dev, (uint32_t)dev_index); + if (fd_given) { + r = rtlsdr_open_fd(&dev, dev_index); + } else { + r = rtlsdr_open(&dev, (uint32_t)dev_index); + } + if (NULL == dev) { fprintf(stderr, "Failed to open rtlsdr device #%d.\n", dev_index); exit(1); diff --git a/src/rtl_test.c b/src/rtl_test.c index b7f46ea..033aeb1 100644 --- a/src/rtl_test.c +++ b/src/rtl_test.c @@ -90,7 +90,8 @@ void usage(void) "rtl_test, a benchmark tool for RTL2832 based DVB-T receivers\n\n" "Usage:\n" "\t[-s samplerate (default: 2048000 Hz)]\n" - "\t[-d device_index (default: 0)]\n" + "\t[-d device_index (default: 1)]\n" + "\t[-N file_desc use file descriptor instead of libusb index\n" "\t[-t enable Elonics E4000 tuner benchmark]\n" #ifndef _WIN32 "\t[-p[seconds] enable PPM error measurement (default: 10 seconds)]\n" @@ -312,16 +313,21 @@ int main(int argc, char **argv) uint8_t *buffer; int dev_index = 0; int dev_given = 0; + int fd_given = 0; uint32_t out_block_size = DEFAULT_BUF_LENGTH; int count; int gains[100]; - while ((opt = getopt(argc, argv, "d:s:b:tp::Sh")) != -1) { + while ((opt = getopt(argc, argv, "d:N:D:s:b:tp::Sh")) != -1) { switch (opt) { case 'd': dev_index = verbose_device_search(optarg); dev_given = 1; break; + case 'N': + dev_index = atoi(optarg); + fd_given = 1; + break; case 's': samp_rate = (uint32_t)atof(optarg); break; @@ -359,7 +365,7 @@ int main(int argc, char **argv) buffer = malloc(out_block_size * sizeof(uint8_t)); - if (!dev_given) { + if (!dev_given && !fd_given) { dev_index = verbose_device_search("0"); } @@ -367,7 +373,12 @@ int main(int argc, char **argv) exit(1); } - r = rtlsdr_open(&dev, (uint32_t)dev_index); + if (fd_given) { + r = rtlsdr_open_fd(&dev, dev_index); + } else { + r = rtlsdr_open(&dev, (uint32_t)dev_index); + } + if (r < 0) { fprintf(stderr, "Failed to open rtlsdr device #%d.\n", dev_index); exit(1); -- 2.44.0

2 days, 3 hours

1
0
0 0

Release major version number change causing upgrade problems

by Carl Laufer

Hi, I just saw that the major version number was recently bumped on the osmocom rtl-sdr. Unfortunately this seems to be causing upgrade problems because if a user updates the drivers to the new major version number (eg to get Blog V4 support), the soname is now different, and this means that all previously installed software that uses librtlsdr will need to be recompiled from scratch, and software from the package manager will simply be broken. I'm not sure if the recent changes warrant a major version change and the problems that come with it? Regards, Carl

4 weeks

4
5
0 0

[PATCH] lib/xtrx: honouring/using the loglevel parameter

by Gwenhael Goavec-Merou

loglevel parameter is never used and let loglevel to DEBUG, with an annoying flood of message in terminal. This patch adds a call to xtrx_log_setlevel() at xtrx constructor level. Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou(a)trabucayre.com> --- lib/xtrx/xtrx_obj.cc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/xtrx/xtrx_obj.cc b/lib/xtrx/xtrx_obj.cc index 016b420..ab32a7f 100644 --- a/lib/xtrx/xtrx_obj.cc +++ b/lib/xtrx/xtrx_obj.cc @@ -68,6 +68,8 @@ xtrx_obj::xtrx_obj(const std::string &path, unsigned loglevel, bool lmsreset) unsigned xtrxflag = (loglevel & XTRX_O_LOGLVL_MASK) | ((lmsreset) ? XTRX_O_RESET : 0); std::cerr << "xtrx_obj::xtrx_obj = " << xtrxflag << std::endl; + xtrx_log_setlevel(loglevel, NULL); + int res = xtrx_open_string(path.c_str(), &_obj); if (res < 0) { std::stringstream message; -- 2.40.1

1 month

1
1
0 0

CRM Assignment Help at Your Fingertips

by fa318991＠gmail.com

Empower your journey in customer relationship management (CRM) with our comprehensive support services. Our team specializes in providing expert guidance and assistance tailored to your CRM assignment needs. From analyzing customer data to implementing effective strategies, our CRM Assignment Help ensures you're equipped with the knowledge and skills to excel. Trust us to be your partner in success as you navigate the complexities. Let our expertise be at your fingertips, guiding you toward academic achievement and more visit our website Now. https://reportwritinghelp.com/assignment/consumer-behavior-assignment-help

2 months, 2 weeks

1
0
0 0

Does anyone from the community want the airprobe.org domain?

by Harald Welte

Hi all, I was approached by the person currently holding the [unused] airprobe.org domain name. I guess it was at some point registered and intended to be used for the project (back in the pre-osmocom days). As far as I know it was never actually used for that. So the question is now if anyone wants to get that domain transferred in order to do something useful with it, or whether the current registrant should simply let it expire? Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 months

3
4
0 0

Cheap RTL2832U / FC0012 gives "No supported tuner found", but has I2C devices

by Nick Burch

Hi All I bought a cheap DVB-T stick that was supposed to be a RTL2832U with a FC0012 tuner with RTL-SDR support. As might have been expected given the price, it doesn't work. The various rtl_ tools all report "No supported tuner found", eg rtl_eeprom gives: > Found 1 device(s): > 0: Generic RTL2832U OEM > > Using device 0: Generic RTL2832U OEM > No supported tuner found > Enabled direct sampling mode, input 1 > > Current configuration: > __________________________________________ > Vendor ID: 0x0bda > Product ID: 0x2838 > Manufacturer: Realtek > Product: RTL2838UHIDIR > Serial number: 00000001 > Serial number enabled: yes > IR endpoint enabled: yes > Remote wakeup enabled: no > __________________________________________ The vendor did give me a full refund suspiciously quickly, so clearly the lack of advertised RTL-SDR compatibility is well known to them! I then took the cover off, and it does have a chip that's labelled RTL2832U, plus another similar sized one I can't read the label of. After a bit of searching, I found this old post with a patch to list all the I2C devices: https://www.mail-archive.com/osmocom-sdr@lists.osmocom.org/msg00454.html That reports: > I2C devices found: > 20 a0 a2 So there is something working there, but I'm not sure if it's enough... Is there any hope for this stick? And if so, what would my next steps be? Thanks Nick

4 months, 2 weeks

3
2
0 0

Binary packages: changes in supported distributions

by Oliver Smith

Hello various Osmocom mailing lists, the official Osmocom binary packages will not be built anymore for the following distributions starting at 2024-02: * Raspberry Pi OS 64-bit (use Debian_12 etc. instead) * Ubuntu 23.04 (Ubuntu 23.10 and LTS 20.04/22.04 feeds are available) * openSUSE 15.4 (openSUSE Tumbleweed feed is available) * Debian Testing (Debian Unstable and 12-10 feeds are available) For Raspberry Pi OS 64-bit users, make sure to adjust your /etc/apt/sources.list.d as described here to switch to a Debian aarch64 feed: https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds See the new linux distributions article for information on how long we plan to keep building packages for each distribution: https://osmocom.org/projects/cellular-infrastructure/wiki/Linux_distributio… Let me know if you have questions. Best regards, Oliver -- - Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

4 months, 3 weeks

1
0
0 0

Fix MSYS2 MinGW64 build

by Ruslan Migirov

can you review this patch?

5 months

1
0
0 0

gr-osmosdr: Multiple Airspy devices

by AsciiWolf

Hello, Is there any chance the following patch could be reviewed and/or merged into upstream gr-osmosdr? It allow multiple Airspy devices to be used (which is sadly not possible without the patch). The patch is already used in the downstream gr-osmosdr package in Fedora for last two years and seems to work without issues. https://osmocom.org/issues/5144#note-4 Thanks! Regards, Daniel

5 months, 3 weeks

1
0
0 0

rtl-sdr: New release

by AsciiWolf

Hello, Please, consider doing a new tag/release of rtl-sdr. The last tagged version is from 2018 and there were many changes since then including the recently added RTL-SDR V4 dongle support. Thanks! Regards, Daniel

5 months, 3 weeks

3
2
0 0

MS9120 USB VGA dongle

by Niklas Cathor

After seeing the osmo-fl2k[1] project, I've bought a USB VGA dongle, hoping it would contain a FL2000. The model I've bought looks identical (from the outside) to the black one on the picture. Unfortunately it contains a different chip: a Macrosilicon MS9120. There is not a lot of information about this chip, the manufacturer does not even publish a datasheet (I've sent them an email to ask for one, but don't have high hopes). What I've found so far is: - someone's reverse-engineering attempt of the android driver[2] - a bit of python code to read & write the chip's memory[3] The second thing is for a different chip by the same manufacturer, but it seems to work with my device as well. So, I was wondering if anyone here has already attempted to re-purpose this chip as a transmitter :) cheers, - niklas [1] https://osmocom.org/projects/osmo-fl2k/wiki [2] https://github.com/animaone/macrosilicon_reverse_engineering_journey/ [3] https://github.com/hwti/ms210x-tools

5 months, 3 weeks

2
1
0 0

gr-osmosdr: New release

by AsciiWolf

gr-osmosdr: New release Hello, Please, consider doing a new tag/release of gr-osmosdr. The last tagged version is from 2022 and there were multiple changes since then including the recently added RTL-SDR V4 dongle support. Thanks! Regards, Daniel

5 months, 3 weeks

1
0
0 0

[PATCH] RTL-SDR Blog V4 Upconverter GPIO Switch

by Carl Laufer

In future blog v4 production batches (out in several months time), it will be possible to turn off the upconverter when tuned outside of the HF bands. Please add the code to control the GPIOs to turn off the upconverter when it is not in use. diff --git a/src/tuner_r82xx.c b/src/tuner_r82xx.c index 1510fc3..38d4802 100644 --- a/src/tuner_r82xx.c +++ b/src/tuner_r82xx.c @@ -1151,6 +1151,12 @@ int r82xx_set_freq(struct r82xx_priv *priv, uint32_t freq) cable_2_in = (band == HF) ? 0x08 : 0x00; rc = r82xx_write_reg_mask(priv, 0x06, cable_2_in, 0x08); + if (rc < 0) + goto err; + + /* Control upconverter GPIO switch on newer batches */ + rc = rtlsdr_set_bias_tee_gpio(priv->rtl_dev, 5, !cable_2_in); + if (rc < 0) goto err; Regards, Carl

7 months, 1 week

1
0
0 0

[PATCH] Fix MacOS rtl_tcp bind error

by Carl Laufer

Just realized the attachment was scrubbed by the list. Pasting plain text below: diff --git a/src/rtl_tcp.c b/src/rtl_tcp.c index 8781ba9..5595729 100644 --- a/src/rtl_tcp.c +++ b/src/rtl_tcp.c @@ -562,7 +562,7 @@ int main(int argc, char **argv) setsockopt(listensocket, SOL_SOCKET, SO_REUSEADDR, (char *)&r, sizeof(int)); setsockopt(listensocket, SOL_SOCKET, SO_LINGER, (char *)&ling, sizeof(ling)); - if (bind(listensocket, (struct sockaddr *)&local, sizeof(local))) + if (bind(listensocket, (struct sockaddr *)&local, aiHead->ai_addrlen)) fprintf(stderr, "rtl_tcp bind error: %s", strerror(errno)); else break; Regards, Carl

7 months, 4 weeks

1
0
0 0

[PATCH] Adjust gr-osmosdr lower tuning limit for the RTL-SDR Blog V4

by Carl Laufer

Just realized my patch attachments are getting scrubbed by the list. Hopefully this plain text paste works. diff --git a/lib/rtl/rtl_source_c.cc b/lib/rtl/rtl_source_c.cc index 5e3306b..644bf7a 100644 --- a/lib/rtl/rtl_source_c.cc +++ b/lib/rtl/rtl_source_c.cc @@ -455,6 +455,8 @@ double rtl_source_c::get_sample_rate() osmosdr::freq_range_t rtl_source_c::get_freq_range( size_t chan ) { osmosdr::freq_range_t range; + char manufact[256]; + char product[256]; if (_dev) { if (_no_tuner) { @@ -464,6 +466,8 @@ osmosdr::freq_range_t rtl_source_c::get_freq_range( size_t chan ) return range; } + rtlsdr_get_usb_strings( _dev, manufact, product, NULL ); + enum rtlsdr_tuner tuner = rtlsdr_get_tuner_type(_dev); if ( tuner == RTLSDR_TUNER_E4000 ) { @@ -478,6 +482,8 @@ osmosdr::freq_range_t rtl_source_c::get_freq_range( size_t chan ) range += osmosdr::range_t( 438e6, 924e6 ); } else if ( tuner == RTLSDR_TUNER_R820T ) { range += osmosdr::range_t( 24e6, 1766e6 ); + } else if ( tuner == RTLSDR_TUNER_R828D && strcmp(manufact, "RTLSDRBlog") == 0 && strcmp(product, "Blog V4") == 0 ) { + range += osmosdr::range_t( 0e6, 1766e6 ); } else if ( tuner == RTLSDR_TUNER_R828D ) { range += osmosdr::range_t( 24e6, 1766e6 ); } Regards, Carl

7 months, 4 weeks

1
0
0 0

Re: osmocom-sdr Digest, Vol 92, Issue 4

by Carl Laufer

Just realized my patch attachments are getting scrubbed by the list. Hopefully this plain text paste works. diff --git a/lib/rtl/rtl_source_c.cc b/lib/rtl/rtl_source_c.cc index 5e3306b..644bf7a 100644 --- a/lib/rtl/rtl_source_c.cc +++ b/lib/rtl/rtl_source_c.cc @@ -455,6 +455,8 @@ double rtl_source_c::get_sample_rate() osmosdr::freq_range_t rtl_source_c::get_freq_range( size_t chan ) { osmosdr::freq_range_t range; + char manufact[256]; + char product[256]; if (_dev) { if (_no_tuner) { @@ -464,6 +466,8 @@ osmosdr::freq_range_t rtl_source_c::get_freq_range( size_t chan ) return range; } + rtlsdr_get_usb_strings( _dev, manufact, product, NULL ); + enum rtlsdr_tuner tuner = rtlsdr_get_tuner_type(_dev); if ( tuner == RTLSDR_TUNER_E4000 ) { @@ -478,6 +482,8 @@ osmosdr::freq_range_t rtl_source_c::get_freq_range( size_t chan ) range += osmosdr::range_t( 438e6, 924e6 ); } else if ( tuner == RTLSDR_TUNER_R820T ) { range += osmosdr::range_t( 24e6, 1766e6 ); + } else if ( tuner == RTLSDR_TUNER_R828D && strcmp(manufact, "RTLSDRBlog") == 0 && strcmp(product, "Blog V4") == 0 ) { + range += osmosdr::range_t( 0e6, 1766e6 ); } else if ( tuner == RTLSDR_TUNER_R828D ) { range += osmosdr::range_t( 24e6, 1766e6 ); } Regards, Carl On Thu, Aug 31, 2023 at 12:06 AM <osmocom-sdr-request(a)lists.osmocom.org> wrote: > > Send osmocom-sdr mailing list submissions to > osmocom-sdr(a)lists.osmocom.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > osmocom-sdr-request(a)lists.osmocom.org > > You can reach the person managing the list at > osmocom-sdr-owner(a)lists.osmocom.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of osmocom-sdr digest..." > > Today's Topics: > > 1. [PATCH] Adjust gr-osmosdr lower tuning limit for the RTL-SDR Blog V4 > (Carl Laufer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 30 Aug 2023 23:55:57 +1200 > From: Carl Laufer <admin(a)rtl-sdr.com> > Subject: [PATCH] Adjust gr-osmosdr lower tuning limit for the RTL-SDR > Blog V4 > To: osmocom-sdr(a)lists.osmocom.org > Message-ID: > <CAP8SZq0i9JGFpBgvgHLfBeoTUoec0+XGoVh3Vr=_GQYqiJeL6Q(a)mail.gmail.com> > Content-Type: multipart/mixed; boundary="00000000000077e36a0604229e75" > > Patch to detect the RTL-SDR Blog V4 in gr-osmosdr, and set the lower limit > to 0 MHz. > > Regards, > Carl >

7 months, 4 weeks

1
0
0 0

[PATCH] Adjust gr-osmosdr lower tuning limit for the RTL-SDR Blog V4

by Carl Laufer

Patch to detect the RTL-SDR Blog V4 in gr-osmosdr, and set the lower limit to 0 MHz. Regards, Carl

7 months, 4 weeks

1
0
0 0

[PATCH] Fix MacOS rtl_tcp bind error

by Carl Laufer

This should fix https://osmocom.org/issues/4758 Regards, Carl Laufer

8 months

1
0
0 0

[PATCH] Support RTL-SDR Blog V4 R828D dongles

by Carl Laufer

I've just released a new R828D based dongle and it needs some code changes to work. It would be great if the osmocom drivers could support it. The dongle is based on the R828D chip, but unlike prior R828D dongles which use 16 MHz, the V4 uses a 28.8 MHz LO. Also the three RF inputs are used, and connected via a triplexer to separate them into HF, VHF and UHF bands. Finally, the open_d pin is also used to activate some notch filters for common interference bands. I've written the code so it detects an EEPROM string in the V4, and only applies the new code if that exists. This makes sure that the older R828D based dongles still work. I'm not too familiar with the patch submission process, so please let me know if something needs to be changed. And if anyone on the team needs/wants some new V4 dongles for testing, please let me know too. Thanks, Carl diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 096abae..d624732 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -119,6 +119,8 @@ struct rtlsdr_dev { int dev_lost; int driver_active; unsigned int xfer_errors; + char manufact[256]; + char product[256]; }; void rtlsdr_set_gpio_bit(rtlsdr_dev_t *dev, uint8_t gpio, int val); @@ -1430,6 +1432,16 @@ int rtlsdr_get_index_by_serial(const char *serial) return -3; } +/* Returns true if the manufact_check and product_check strings match what is in the dongles EEPROM */ +int rtlsdr_check_dongle_model(rtlsdr_dev_t *dev, char* manufact_check, char* product_check) +{ + if ((strcmp(dev->manufact, manufact_check) == 0 && strcmp(dev->product, product_check) == 0)) + return 1; + + return 0; +} + + int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) { int r; @@ -1528,6 +1540,9 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) rtlsdr_init_baseband(dev); dev->dev_lost = 0; + /* Get device manufacturer and product id */ + r = rtlsdr_get_usb_strings(dev, dev->manufact, dev->product, NULL); + /* Probe tuners */ rtlsdr_set_i2c_repeater(dev, 1); @@ -1555,6 +1570,10 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) reg = rtlsdr_i2c_read_reg(dev, R828D_I2C_ADDR, R82XX_CHECK_ADDR); if (reg == R82XX_CHECK_VAL) { fprintf(stderr, "Found Rafael Micro R828D tuner\n"); + + if (rtlsdr_check_dongle_model(dev, "RTLSDRBlog", "Blog V4")) + fprintf(stderr, "RTL-SDR Blog V4 Detected\n"); + dev->tuner_type = RTLSDR_TUNER_R828D; goto found; } @@ -1588,7 +1607,11 @@ found: switch (dev->tuner_type) { case RTLSDR_TUNER_R828D: - dev->tun_xtal = R828D_XTAL_FREQ; + /* If NOT an RTL-SDR Blog V4, set typical R828D 16 MHz freq. Otherwise, keep at 28.8 MHz. */ + if (!(rtlsdr_check_dongle_model(dev, "RTLSDRBlog", "Blog V4"))) { + fprintf(stdout, "setting 16mhz"); + dev->tun_xtal = R828D_XTAL_FREQ; + } /* fall-through */ case RTLSDR_TUNER_R820T: /* disable Zero-IF mode */ diff --git a/src/tuner_r82xx.c b/src/tuner_r82xx.c index 997abd7..9b831f4 100644 --- a/src/tuner_r82xx.c +++ b/src/tuner_r82xx.c @@ -33,6 +33,10 @@ #define MHZ(x) ((x)*1000*1000) #define KHZ(x) ((x)*1000) +#define HF 1 +#define VHF 2 +#define UHF 3 + /* * Static constants */ @@ -1098,7 +1102,14 @@ int r82xx_set_bandwidth(struct r82xx_priv *priv, int bw, uint32_t rate) int r82xx_set_freq(struct r82xx_priv *priv, uint32_t freq) { int rc = -1; - uint32_t lo_freq = freq + priv->int_freq; + + int is_rtlsdr_blog_v4 = rtlsdr_check_dongle_model(priv->rtl_dev, "RTLSDRBlog", "Blog V4"); + + /* if it's an RTL-SDR Blog V4, automatically upconvert by 28.8 MHz if we tune to HF + * so that we don't need to manually set any upconvert offset in the SDR software */ + uint32_t upconvert_freq = is_rtlsdr_blog_v4 ? ((freq < MHZ(28.8)) ? (freq + MHZ(28.8)) : freq) : freq; + + uint32_t lo_freq = upconvert_freq + priv->int_freq; uint8_t air_cable1_in; rc = r82xx_set_mux(priv, lo_freq); @@ -1109,16 +1120,60 @@ int r82xx_set_freq(struct r82xx_priv *priv, uint32_t freq) if (rc < 0 || !priv->has_lock) goto err; - /* switch between 'Cable1' and 'Air-In' inputs on sticks with - * R828D tuner. We switch at 345 MHz, because that's where the - * noise-floor has about the same level with identical LNA - * settings. The original driver used 320 MHz. */ - air_cable1_in = (freq > MHZ(345)) ? 0x00 : 0x60; + if (is_rtlsdr_blog_v4) { + /* determine if notch filters should be on or off notches are turned OFF + * when tuned within the notch band and ON when tuned outside the notch band. + */ + uint8_t open_d = (freq <= MHZ(2.2) || (freq >= MHZ(85) && freq <= MHZ(112)) || (freq >= MHZ(172) && freq <= MHZ(242))) ? 0x00 : 0x08; + rc = r82xx_write_reg_mask(priv, 0x17, open_d, 0x08); + + if (rc < 0) + return rc; + + /* select tuner band based on frequency and only switch if there is a band change + *(to avoid excessive register writes when tuning rapidly) + */ + uint8_t band = (freq <= MHZ(28.8)) ? HF : ((freq > MHZ(28.8) && freq < MHZ(250)) ? VHF : UHF); + + /* switch between tuner inputs on the RTL-SDR Blog V4 */ + if (band != priv->input) { + priv->input = band; + + /* activate cable 2 (HF input) */ + uint8_t cable_2_in = (band == HF) ? 0x08 : 0x00; + rc = r82xx_write_reg_mask(priv, 0x06, cable_2_in, 0x08); - if ((priv->cfg->rafael_chip == CHIP_R828D) && - (air_cable1_in != priv->input)) { - priv->input = air_cable1_in; - rc = r82xx_write_reg_mask(priv, 0x05, air_cable1_in, 0x60); + if (rc < 0) + goto err; + + /* activate cable 1 (VHF input) */ + uint8_t cable_1_in = (band == VHF) ? 0x40 : 0x00; + rc = r82xx_write_reg_mask(priv, 0x05, cable_1_in, 0x40); + + if (rc < 0) + goto err; + + /* activate air_in (UHF input) */ + uint8_t air_in = (band == UHF) ? 0x00 : 0x20; + rc = r82xx_write_reg_mask(priv, 0x05, air_in, 0x20); + + if (rc < 0) + goto err; + } + } + else /* Standard R828D dongle*/ + { + /* switch between 'Cable1' and 'Air-In' inputs on sticks with + * R828D tuner. We switch at 345 MHz, because that's where the + * noise-floor has about the same level with identical LNA + * settings. The original driver used 320 MHz. */ + air_cable1_in = (freq > MHZ(345)) ? 0x00 : 0x60; + + if ((priv->cfg->rafael_chip == CHIP_R828D) && + (air_cable1_in != priv->input)) { + priv->input = air_cable1_in; + rc = r82xx_write_reg_mask(priv, 0x05, air_cable1_in, 0x60); + } } err:

8 months

3
5
0 0

Osmocom discourse as alternative to mailing lists

by Harald Welte

Dear Osmocom community, while many people with a long history in FOSS development have no issues at all with mailing lists as primary form of engaging with their community, they have undoubtedly fallen out of fashion in favor of various chat/messaging systems or web based forums. In Osmocom, we've just launched an installation of the discourse forum software available at https://discourse.osmocom.org/ providing an alternative to our traditional mailing lists at https://lists.osmocom.org/ We're looking forward to see whether this web-based approach will facilitate more and/or other people to engage with the Osmocom developer/contributor community. Feel free to join and get the discussions started. If there's a need for more categories or sub-categories, just let one of the moderators know and we can help with that. The old mailing lists will continue to remain available for those who prefer them. -- - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

9 months

1
0
0 0

[PATCH] trl_tcp: fix for macos

by Stephen More

rtl_tcp does not work on macos: https://osmocom.org/issues/4758 sizeof(local) == 128 ai->ai_addrlen == 16 patch: % git diff *diff --git a/src/rtl_tcp.c b/src/rtl_tcp.c* *index 8781ba9..b64f943 100644* *--- a/src/rtl_tcp.c* *+++ b/src/rtl_tcp.c* @@ -562,7 +562,7 @@ int main(int argc, char **argv) setsockopt(listensocket, SOL_SOCKET, SO_REUSEADDR, (char *)&r, sizeof(int)); setsockopt(listensocket, SOL_SOCKET, SO_LINGER, (char *)&ling, sizeof(ling)); - if (bind(listensocket, (struct sockaddr *)&local, sizeof(local))) + if (bind(listensocket, (struct sockaddr *)&local, ai->ai_addrlen)) fprintf(stderr, "rtl_tcp bind error: %s", strerror(errno)); else break; smore@Stephens-Mini rtl-sdr %

1 year

1
0
0 0

[PATCH] rtl_sdr: enable direct sampling support

by 0x4tlas

While using rtl_sdr i noticed that there was no direct sampling support, despite the rtl-sdr library supporting it, so i wrote a patch: diff --git a/src/rtl_sdr.c b/src/rtl_sdr.cindex 2c93b57..15a4212 100644 --- a/src/rtl_sdr.c +++ b/src/rtl_sdr.c @@ -55,6 +55,7 @@ void usage(void) "\t[-b output_block_size (default: 16 * 16384)]\n" "\t[-n number of samples to read (default: 0, infinite)]\n" "\t[-S force sync output (default: async)]\n" + "\t[-D direct sampling (default: 0, 1 for I branch, 2 for Q branch)]\n" "\tfilename (a '-' dumps samples to stdout)\n\n"); exit(1); } @@ -112,6 +113,7 @@ int main(int argc, char **argv) int n_read; int r, opt; int gain = 0; + int direct_sampling = 0; int ppm_error = 0; int sync_mode = 0; FILE *file; @@ -121,8 +123,8 @@ int main(int argc, char **argv) uint32_t frequency = 100000000; uint32_t samp_rate = DEFAULT_SAMPLE_RATE; uint32_t out_block_size = DEFAULT_BUF_LENGTH; - - while ((opt = getopt(argc, argv, "d:f:g:s:b:n:p:S")) != -1) { + + while ((opt = getopt(argc, argv, "d:f:g:s:b:n:p:S:D:")) != -1) { switch (opt) { case 'd': dev_index = verbose_device_search(optarg); @@ -149,6 +151,9 @@ int main(int argc, char **argv) case 'S': sync_mode = 1; break; + case 'D': + direct_sampling = atoi(optarg); + break; default: usage(); break; @@ -200,7 +205,8 @@ int main(int argc, char **argv) #endif /* Set the sample rate */ verbose_set_sample_rate(dev, samp_rate); - + /* Set direct sampling*/ + verbose_direct_sampling(dev, direct_sampling); /* Set the frequency */ verbose_set_frequency(dev, frequency);

1 year

1
0
0 0

Re: Play RTP packets payload obtained from the mobile phone in a call service

by Tomcsanyi, Domonkos

AFAIR Wireshark cannot play our RTP streams because it has a very limited set of codecs, mostly focusing on regular VoIP audio. Cheers, Domi > 24.02.2023 dátummal, 1:29 időpontban Neels Hofmeyr <nhofmeyr(a)sysmocom.de> írta: > > On Wed, Feb 22, 2023 at 11:58:24PM +0330, morteza ali Ahmadi wrote: >> I have aggregated all RTP packets payload. How can I convert the aggregated >> bytes to a hearable audio? > > Firstly you need to be aware that 3G audio uses IuUP -- the RTP payload > includes an IuUP header followed by the AMR audio data. To see this in > wireshark, you need to go to Preferences / Protocols / IuUP and mark > [x] Dissect IuUP Payload bits. > > osmo-mgw has implemented the IuUP to AMR conversion: if one side of an MGCP > endpoint has VND.3GPP.IUFP and the other has AMR, osmo-mgw will decapsulate the > AMR from the IuUP, i.e. forward plain AMR. > > Next I guess you will convert the AMR to something you can play back, AFAIK > https://gitea.osmocom.org/osmocom/gapk is capable of that? > > Also wireshark is supposed to be able to play back an RTP stream. See the menu > item Telephony / RTP. It hasn't worked for me yet, not sure what I'm doing > wrong, but I also never tried for more than two minutes. > > This is a rough outline, you'll have to figure out all the details... > > ~N

1 year, 2 months

2
1
0 0

OsmoDevCall on Feb 15, 2023: Long range communications in the HF band

by Harald Welte

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: February 15, 2023 at 20:00 CET where: https://osmocom.org/OsmoDevCall This time, @rafael2kwill be presenting on Long range communications in the HF band This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation as outlined above 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you soon! Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - 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)

1 year, 2 months

1
0
0 0

Re: [patch] Pass additional library arguments to ld

by Paul R. Tagliamonte

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

1 year, 3 months

1
0
0 0

gr-osmosdr bias-tx runtime switching feature request

by Paul Bongaerts

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

1 year, 3 months

1
0
0 0

Request to reactivate Miri support

by MarcHOsmo＠gmx-topmail.de

Hello everyone, Short story: I would like to ask if it is possible to bring back the Miri support that was removed in October 2020? The market for cheap SDR receivers has changed in recent years and there are now more good boards with Miri chipsets. Long story: I work as an industrial mechanic, but my secret loves since many years are electronics and amateur radio. It was GNU Radio that allowed me to learn a lot about filtering, modulation or signal mixing without the necessary technical training. I started with the RTL-SDR sticks like many others and they got me off to a good start, but the lack of ability to receive signals below 20MHz without modification makes it difficult for beginners to experiment. This is where the cheap Miri Boards come into play today. I ordered boards with Miri chipset from China for 18€ delivered to Germany. They have a good performance for beginners and signals above 10kHz can also be received well. My plan is to develop cheap open source boards for amateur radio beginners that are connected directly to the Miri boards. Based on the NE555 and the Si5351A, basics such as filters, attenuators, mixing and modulating frequencies should be explained and tested. My biggest problem is that I'm not a good programmer, so I can't manage to re-implement Miri support myself and compile gr-osmosdr to get it running on Windows (yes, I'll burn in hell for it one day). Hence my request to resume Miri support in gr-osmosdr or the question of whether someone can help me to create a fork that can be compiled with Miri Support under Windows. Offtopic: After all these years of using gr-osmosdr, I would like to take this opportunity to thank everyone involved for their time and dedication, which enables people like me to learn and develop with simple means and without expensive equipment. Thanks for your time and Merry Christmas to everyone! Marc

1 year, 3 months

3
3
0 0

[patch] Pass additional library arguments to ld

by Paul R. Tagliamonte

Hey osmocom-sdr, I've got a choose your own adventure patch set here for the adventurous reviewer. On OpenBSD (but not specific to OpenBSD) libusb-1.0 lives in /usr/local/lib. The default linker (lld 13.0.0 on 7.2) doesn't include /usr/local/lib in its out of the box search path, which triggers a build failure in rtl-sdr because the -L argument(s) aren't passed through to ld. The root cause here is that we pass ${LIBUSB_LIBRARIES} to target_link_libraries, which is only the -lfoo arguments, but not the -L/foo/bar arguments. This tends to work on most systems, since libusb is usually in a place ld will search anyway. There's two ways I could see to do this. Here comes the choose your own adventure part: 1) The first is to use the PkgConfig::LIBUSB helper, which can be passed directly to `target_link_libraries`, which allows all the arguments to be passed through. This means the existing hooks to pass in a manual path would be dropped and building without pkg-config against libusb won't be supported anymore. This is the attached git format-patch entitled "0001-Use-the-PkgConfig-imported-target-rather-than-_LIBRA.patch". 2) Punch the -L arguments through next to the LIBUSB_LIBRARIES argument to `target_link_libraries`, add a new knob to set the values ("manual libusb librarypath"), and when using pkg-config, generate the arguments with a FOREACH. This is the attached git format-patch "0001-Pass-additional-library-directory-arguments-to-ld.patch". Both patch flavors build on my Debian sid box and an OpenBSD 7.2 box. paultag -- :wq

1 year, 4 months

2
1
0 0

[PATCH] Fix signal handler from getting stuck in an endless loop

by Tobias Girstmair

The signal handler for SIGINT/TERM/QUIT and, importantly, SIGPIPE tries to write an informational message to stderr. When however stderr is redirected to a closed pipe, this will cause (another) SIGPIPE, and in turn the signal handler will get called again, and again and again. Since we intend to exit rtl_fm anyways, we can just ignore this signal from this point on. --- Here is a small test program to verify the bug. from subprocess import Popen, PIPE p = Popen("rtl_test", stderr=PIPE) # sighandler is set up after rtlsdr_open() call, so read past that while p.stderr.readline()[:8] != b"Sampling": pass p.stderr.close() p.terminate() # SIGTERM -> sighandler() -> fprintf(stderr) -> SIGPIPE! Note that the signal handler is not set up immediately, but only after rtlsdr_open() is called. Due to line buffering/flushing on stderr, we must read from the pipe or rtl_* will stall and SIGTERM/PIPE will still be handled by the SIG_DFL, not triggering the write to the broken pipe. And in case someone is wondering: Using signal(2) instead of sigaction(2) is OK, as long as it only sets to SIG_DFL or SIG_IGN. src/rtl_adsb.c | 1 + src/rtl_fm.c | 1 + src/rtl_power.c | 1 + src/rtl_sdr.c | 1 + src/rtl_tcp.c | 1 + src/rtl_test.c | 1 + 6 files changed, 6 insertions(+) diff --git a/src/rtl_adsb.c b/src/rtl_adsb.c index 7aea8dd..8119ac8 100644 --- a/src/rtl_adsb.c +++ b/src/rtl_adsb.c @@ -123,6 +123,7 @@ sighandler(int signum) #else static void sighandler(int signum) { + signal(SIGPIPE, SIG_IGN); fprintf(stderr, "Signal caught, exiting!\n"); do_exit = 1; rtlsdr_cancel_async(dev); diff --git a/src/rtl_fm.c b/src/rtl_fm.c index 7c84332..037793c 100644 --- a/src/rtl_fm.c +++ b/src/rtl_fm.c @@ -246,6 +246,7 @@ sighandler(int signum) #else static void sighandler(int signum) { + signal(SIGPIPE, SIG_IGN); fprintf(stderr, "Signal caught, exiting!\n"); do_exit = 1; rtlsdr_cancel_async(dongle.dev); diff --git a/src/rtl_power.c b/src/rtl_power.c index 6204de2..df3ceb7 100644 --- a/src/rtl_power.c +++ b/src/rtl_power.c @@ -195,6 +195,7 @@ sighandler(int signum) #else static void sighandler(int signum) { + signal(SIGPIPE, SIG_IGN); do_exit++; multi_bail(); } diff --git a/src/rtl_sdr.c b/src/rtl_sdr.c index e6537ca..2c93b57 100644 --- a/src/rtl_sdr.c +++ b/src/rtl_sdr.c @@ -74,6 +74,7 @@ sighandler(int signum) #else static void sighandler(int signum) { + signal(SIGPIPE, SIG_IGN); fprintf(stderr, "Signal caught, exiting!\n"); do_exit = 1; rtlsdr_cancel_async(dev); diff --git a/src/rtl_tcp.c b/src/rtl_tcp.c index 84f5591..8781ba9 100644 --- a/src/rtl_tcp.c +++ b/src/rtl_tcp.c @@ -144,6 +144,7 @@ sighandler(int signum) #else static void sighandler(int signum) { + signal(SIGPIPE, SIG_IGN); fprintf(stderr, "Signal caught, exiting!\n"); rtlsdr_cancel_async(dev); do_exit = 1; diff --git a/src/rtl_test.c b/src/rtl_test.c index 9b44097..b7f46ea 100644 --- a/src/rtl_test.c +++ b/src/rtl_test.c @@ -115,6 +115,7 @@ sighandler(int signum) #else static void sighandler(int signum) { + signal(SIGPIPE, SIG_IGN); fprintf(stderr, "Signal caught, exiting!\n"); do_exit = 1; rtlsdr_cancel_async(dev); -- 2.38.1

1 year, 4 months

2
3
0 0

[PATCH] Add support for RFSpace CloudSDR to gr-osmosdr

by Mike McCarrick

The new-ish RFSpace CloudSDR is mostly the same as the Cloud-IQ, but has a few differences. I’ve tested it thoroughly and it works well. One side note, the CloudSDR (and probably others) require the UDP host port to be set equal to the SDR’s port. This allows multiple CloudSDRs to work simultaneously. That is, a second CloudSDR needs a different IP address, obviously, but also needs a different port, e.g. 50001 rather than the default 50000. Regards, Mike McCarrick

1 year, 4 months

1
0
0 0

A Bit Of a Mess

by Kevin Utzy

I am trying to go back and simply install gqrx on Liux Mint v21 Vanessa (Ubuntu Jammy) using an RTL-SDR V3. It all started I believe when I tried to install SDR++ building it from source. I install osmo_sdr and gr-osmosdr. I have worked my way through and deleted some of the issues, the last one being getting rid of the osmo_sdr binary. Deleting that removed the error I was getting with the libgnuradio-osmosdr.0.2.0 (it was showing libgnuradio-osmosdr.0.2.0 (build 0.3build53 or something). I am now getting an error running gqrx is "gqrx: error while loading shared libraries: libgnuradio-blocks.so.3.10.1: cannot open shared object file: No such file or directory". Some fragment of something I uninstalled incorrectly is causing gqrx distribution to think that this is already installed. If I could figure out what that is, it would be helpful. The reason I am posting this here is because it started I believe when I installed either osmo_sdr or gr-osmosdr. Thank you. Kevin

1 year, 5 months

1
0
0 0

Osmocom binary package repository URLs have changed

by Oliver Smith

Hello various Osmocom mailing lists, as previously announced (https://osmocom.org/news/191): * The binary packages are being built on Osmocom's own OBS server now. * We will stop pushing packages to the openSUSE OBS server at the end of October (in one week). If you are using Osmocom binary packages, please make sure that you have configured the new repository URLs. See the wiki for details: https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages Best, Oliver -- - Oliver Smith <osmith(a)sysmocom.de> https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

1 year, 6 months

1
0
0 0

RFC: OsmoDevCall restart: Your input required

by Harald Welte

Dear Osmocom community, your input is required in order to tune the re-launch of the OsmoDevCall talk series. One of the complaints before the suspension in Summer this year was that the "Friday night 8pm CEST" timeslot was not exactly ideal for several people. Finding a common denominator might be difficult, given that Osmocom is a dayjob for some, a hobby for most, and we're of course not all in the same time zone or even continent. So let's try to run a couple of polls to figure out: * What is the best day of the week for OsmoDevCall? https://bitpoll.de/poll/CEQnaQKEvO/ * What is the best time of day for OsmoDevCall? https://bitpoll.de/poll/59dgmzOocT/ * What is the best frequency of OsmoDevCall https://bitpoll.de/poll/8jyuRJB6Hb/ The polls are open until October 21st, 2021. I would appreciate a high turn-out so we have a good representation across our community to make an educated decision about the schedule of futur events. Can't wait to re-start OsmoDevCall! Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 year, 6 months

1
1
0 0

RFC: Reviving OsmoDevCall

by Harald Welte

[please follow-up-to openbsc(a)lists.osmocom.org so we don't cross-post all related mails] Dear Osmocom community, OsmoDevCall used to be rather successful for quite some time in recent years, but recently has been suffering quite a bit due to insufficient people volunteering to present. Big thanks to all who did! Interestingly, there's no shortage of ideas of topics at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall - but then many of the potential speakers did not have the interest or time to follow-up. Most recently, the last few instances have not been taking place due to a lack of volunteers during my holidays. Last, but not least, while during COVID lockdown winter "friday night 8pm" was a good idea, this of course is more difficult during the summer, when people are more likely want to go out the weekend. So, to summarize, let me ask some questions: * would you be interested in OsmoDevCall continuing? * which day/time/timezone would you prefer ? * would you be able and willing to volunteer to give at talk within the next 3 or so months? Any other suggestions for or around OsmoDevCall are of course also welcome. Thanks in advance, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 year, 10 months

1
0
0 0

Re: gr-osmosdr build issue (patch included)

by Stefan Oltmanns

That compiles as well, I removed const as well for a simple reason: The AVX version above doesn't use const and doesn't modify mulme either Am 20.06.22 um 11:18 schrieb Patrick Welche: > (I would just get rid of "register" and not "const" as well) > > P > > On Mon, Jun 20, 2022 at 04:41:20AM +0200, Stefan Oltmanns wrote: >> Hello, >> >> gr-osmosdr currently doesn't build on macOS (probably not with clang in >> general), because C++17 does not allow the "register storage class >> specifier". >> >> The fix is quite trivial: >> >> --- a/lib/hackrf/hackrf_sink_c.cc >> +++ b/lib/hackrf/hackrf_sink_c.cc >> @@ -299,7 +299,7 @@ void convert_avx(const float* inbuf, int8_t* >> outbuf,const unsigned int count) >> #elif USE_SSE2 >> void convert_sse2(const float* inbuf, int8_t* outbuf,const unsigned >> int count) >> { >> - const register __m128 mulme = _mm_set_ps( 127.0f, 127.0f, 127.0f, >> 127.0f ); >> + __m128 mulme = _mm_set_ps( 127.0f, 127.0f, 127.0f, 127.0f ); >> __m128 itmp1,itmp2,itmp3,itmp4; >> __m128i otmp1,otmp2,otmp3,otmp4; >> >> Could you please apply that patch and also create a new release? >> Unfortunately gr-osmosdr was thrown out of the homebrew package earlier >> this year, because it didn't build. >> I would like to get it back in, because that would make things on mac a >> lot easier (and GNURadio tutorials for mac would be correct again and >> not cause frustration). >> >> I assume the easiest way to get it back in is to have a new official >> release that builds again correctly. >> >> Best regards >> Stefan

1 year, 10 months

1
0
0 0

gr-osmosdr build issue (patch included)

by Stefan Oltmanns

Hello, gr-osmosdr currently doesn't build on macOS (probably not with clang in general), because C++17 does not allow the "register storage class specifier". The fix is quite trivial: --- a/lib/hackrf/hackrf_sink_c.cc +++ b/lib/hackrf/hackrf_sink_c.cc @@ -299,7 +299,7 @@ void convert_avx(const float* inbuf, int8_t* outbuf,const unsigned int count) #elif USE_SSE2 void convert_sse2(const float* inbuf, int8_t* outbuf,const unsigned int count) { - const register __m128 mulme = _mm_set_ps( 127.0f, 127.0f, 127.0f, 127.0f ); + __m128 mulme = _mm_set_ps( 127.0f, 127.0f, 127.0f, 127.0f ); __m128 itmp1,itmp2,itmp3,itmp4; __m128i otmp1,otmp2,otmp3,otmp4; Could you please apply that patch and also create a new release? Unfortunately gr-osmosdr was thrown out of the homebrew package earlier this year, because it didn't build. I would like to get it back in, because that would make things on mac a lot easier (and GNURadio tutorials for mac would be correct again and not cause frustration). I assume the easiest way to get it back in is to have a new official release that builds again correctly. Best regards Stefan

1 year, 10 months

1
0
0 0

RFC: migrating git.osmocom.org to gitea?

by Harald Welte

Hi all! [please follow-up-to the openbsc(a)lists.osmocom.org mailing list, if there is any discussion, we don't want to drag it over tons of mailing lists in parallel] Some weeks ago, I created https://osmocom.org/issues/5397 but it seems nobody noticed the ticket or had any comments to it. So let me post this as RFC here on the mailing list: In the past, we had a gitolite/gitosis setup, which was fine in the early days of git, but it means that people cannot easily create new repositories, see who has permissions, and we cannot delegate ownership. Even updating SSH keys requires manual interaction of a sysadmin like me. I would therefore suggest to migrate git.osmocom.org to gitea[1] This would allow the following features: * users can self-create any number of personal repositories (like gitlab/github) * we can create 'organizations' along the line of reasonably independent osmocom member projects like op25, who can then manage their own repos/permissions/... * gitea can link to redmine wiki and redmine issue trackers (rather than using its own built-in) For those repositories hosted in gerrit (mainly CNI), we would still keep git.osmocom.org a read-only mirror, like we do it right now. For those repositories not hosted in gerrit, users/projects could then accept merge requests in gitea. Coupling this with 3rd party authentication via github/gitlab/etc should make it easier for the occasional contributor to submit changes. There is a downside, of course; A lot of repo URLs have to change. Most of our current repositories are at git.osmocom.org/project.git while gitea follows a git.osmocom.org/organization/project.git scheme. I'm not sure there is any way to help to mitigate this... Any thoughts, comments? [1] https://gitea.io/ -- - 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)

2 years

1
1
0 0

OsmoDevCall on Mar 25, 2022: "Iridium reverse engineering update"

by Harald Welte

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall on March 25, 2022 at 20:00 CET at https://meeting5.franken.de/b/har-xbc-bsx-wvs In this edition, Sec and schneider will present an "Iridium reverse engineering update". This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation as outlined above 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. NOTE: There will be no recording of this talk, so if interested, please make sure you don't miss it! More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - 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)

2 years, 1 month

1
0
0 0

OsmoDevCon 2022 ?

by Harald Welte

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)

2 years, 1 month

2
4
0 0

Snap package for RTL-SDR tools

by Alberto Donato

Hi, I made a snap [1] package for the RTL-SDR tools. The package has "strict" confinement, which allows installing it on any supported distro. I tested it on Ubuntu 21.10 (on amd64) and Ubuntu Core on a Raspberry Pi (my main use case for the packaging is to be able to run rtl_tcp on the latter). Would you consider merging this to the repo and possibly publishing snap packages on the Snap Store as part of the regular release process? Cheers, -Alberto [1] https://snapcraft.io/docs

2 years, 1 month

1
1
0 0

Using rtl-sdr libraries from scratch

by madoak92＠gmail.com

Hi everyone! I'm so interested about using the rtl-sdr libraries for creating some own applications, but am a bit lost concerning the code structure and the interaction between cmake and the libraries. I have some background in C programming, but I haven't write any code as complicated, and nor of course have I had to use tools like cmake to distribute code, only I've used some Makefiles in order to compile locally a basic code. With this background, I'm trying to manage antenna switches within an array, but I need some new functionalities in the rtl_biast.c code. For this purpose, I have to use the following functions: rtlsdr_set_bias_tee rtlsdr_set_i2c_repeater rtlsdr_i2c_write_reg rtlsdr_close_bt I have modified the code but when I execute cmake and make again, I obtain errors regarding the file dependencies, saying that these functions are undeclared. How should I change the file dependencies/include and recompile it in order to make it works? Could you help me to understand the compilation process in order to arrange my own applications using rtl-sdr libraries locally? I assume I have to study thoroughly the cmake and make advanced topics, but it's a bit overwhelming and I would like to learn about it constructing the code from the basic pieces. Thank you very much in advance.

2 years, 1 month

1
0
0 0

FOSDEM 2022 - Free Software Radio Devroom

by Andrej Rode

Hi all, I’d like to invite you all to join the Free Software Radio Devroom at the FOSDEM 2022 online event tomorrow February 6th 2022 at 1300 (CET). We have a range of very interesting presentations ranging from project updates, implementation of hardware accelerators for Software Radio up to receiving communication from the most distant artificial object from Earth. You can find the full schedule here: https://fosdem.org/2022/schedule/track/free_software_radio/ You can either join just the livestream of the event, but I really encourage you to join the Matrix chat to ask questions you might have and continue discussion about the presentation after it is finished, you can even join the video call for a more direct way of communication. You can find information about the chat system here: https://fosdem.org/2022/practical/online/. If you are already a member of the GNU Radio Matrix server, you don’t have to create a new account or anything. You can simply visit: https://matrix.to/#/#space-radio-devroom:fosdem.org to join the dedicated "Free Software Radio Devroom space". This space contains the main chatroom during the devroom but also you will find all dedicated presentation chatrooms in there after the presentation has finished to continue in-depth discussion. During the presentation you can ask questions in the chat and upvote questions of others, at the end of the presentation there will be a short live Q&A where a presentation host will address said questions directly to the presenter. If your question is not answered during this time you are welcome to join the presentation chatroom to ask yourself. I hope to “see” many of you tomorrow. And a big thanks for everyone presenting or helping to make this Devroom possible this year! Cheers Andrej

2 years, 2 months

1
0
0 0

Help on patch submission process for a fix in rtlsdr

by Gonzalo José Carracedo Carballal

Hi, Long story short: I have a fix for a crash in Windows in librtlsdr when closing the device, and I'd love to submit a patch. I went through this page: https://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards and saw that I have to follow certain steps (design, review, etc) but I am not quite sure who to contact. For some projects, this is somehow automatized by means of Gerrit, but it looks that this is not the case for librtlsdr (yet) I'd like to do it the right way, how should I proceed? Should I post the patch here directly? Do I have to document the design of my fix and have it reviewed first somewhere else? Bit of backstory: some days ago I came across a crash in librtlsdr for Windows when closing the device (initially reported as a potential libusb bug, see https://github.com/libusb/libusb/issues/1043). Although workarounds existed (https://github.com/TALUAtGitHub/librtlsdr/commit/27d79d258c0fffb73afd3fffd3…) they relied on a somewhat arbitrary (1 ms) delay to give some time for libusb event callbacks to be triggered before resource cleanup. This was not working anymore, so I decided to look into it and ended up working on a solution. This solution involved refactoring the transfer / buffer array into an array of transfer objects that enabled synchronous cancellation of pending transfers (see https://github.com/BatchDrake/rtl-sdr-blog/blob/feature/xfer-completion/src…). Since it seems to work rather well, I though it could be interesting to submit a patch to have this fixed upstream. Thanks in advance, -- >> Gonzalo José Carracedo Carballal

2 years, 2 months

2
1
0 0

[PATCH] call libsub_intertrupt_event_handler in rtlsdr_cancel_async

by Jasper

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; }

2 years, 2 months

1
0
0 0

[PATCH] count number of open transfers and ensure zero open transfers before freeing memory

by Jasper

Hi all, As per discussion with Martin Ling on this mailing list, please find below a proposed patch that simplifies the async_read, keeps track of open tranfers and checks for zero open transfers before closing to avoid unidentified behaviour at close. Thanks, Jasper commit 4b06ae321e91296f13355a0715e9a961b4f57e45 Author: jvde.github <jvde.github(a)gmail.com> Date: Mon Jan 24 20:15:34 2022 +0100 count live transfers before close diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 096abae..67e30c4 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -119,6 +119,7 @@ struct rtlsdr_dev { int dev_lost; int driver_active; unsigned int xfer_errors; + int live_transfers; }; void rtlsdr_set_gpio_bit(rtlsdr_dev_t *dev, uint8_t gpio, int val); @@ -1695,11 +1696,15 @@ static void LIBUSB_CALL _libusb_callback(struct libusb_transfer *xfer) { rtlsdr_dev_t *dev = (rtlsdr_dev_t *)xfer->user_data; + dev->live_transfers --; + if (LIBUSB_TRANSFER_COMPLETED == xfer->status) { if (dev->cb) dev->cb(xfer->buffer, xfer->actual_length, dev->cb_ctx); - libusb_submit_transfer(xfer); /* resubmit transfer */ + if(!dev->async_cancel) + if( libusb_submit_transfer(xfer) == 0) /* resubmit transfer */ + dev->live_transfers++; dev->xfer_errors = 0; } else if (LIBUSB_TRANSFER_CANCELLED != xfer->status) { #ifndef _WIN32 @@ -1847,9 +1852,9 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, { unsigned int i; int r = 0; + int ret = 0; struct timeval tv = { 1, 0 }; - struct timeval zerotv = { 0, 0 }; - enum rtlsdr_async_status next_status = RTLSDR_INACTIVE; + struct timeval canceltv = { 0, 50 }; if (!dev) return -1; @@ -1863,6 +1868,7 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, dev->cb = cb; dev->cb_ctx = ctx; + if (buf_num > 0) dev->xfer_buf_num = buf_num; else @@ -1875,6 +1881,8 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, _rtlsdr_alloc_async_buffers(dev); + dev->live_transfers = 0; + for(i = 0; i < dev->xfer_buf_num; ++i) { libusb_fill_bulk_transfer(dev->xfer[i], dev->devh, @@ -1894,64 +1902,41 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, "echo 0 > /sys/module/usbcore" "/parameters/usbfs_memory_mb\n", i); dev->async_status = RTLSDR_CANCELING; + ret = -3; break; } + else + dev->live_transfers++; } - while (RTLSDR_INACTIVE != dev->async_status) { + while (RTLSDR_RUNNING == dev->async_status) { r = libusb_handle_events_timeout_completed(dev->ctx, &tv, - &dev->async_cancel); + &dev->async_cancel); if (r < 0) { /*fprintf(stderr, "handle_events returned: %d\n", r);*/ if (r == LIBUSB_ERROR_INTERRUPTED) /* stray signal */ continue; - break; + rtlsdr_cancel_async(dev); + ret = -4; } + } - if (RTLSDR_CANCELING == dev->async_status) { - next_status = RTLSDR_INACTIVE; + if (!dev->xfer) return -5; - if (!dev->xfer) - break; + for(i = 0; i < dev->xfer_buf_num; ++i) + if (dev->xfer[i]) + libusb_cancel_transfer(dev->xfer[i]); - for(i = 0; i < dev->xfer_buf_num; ++i) { - if (!dev->xfer[i]) - continue; + for (i = 0; i < dev->xfer_buf_num && dev->live_transfers > 0; ++i) + libusb_handle_events_timeout_completed(dev->ctx, &canceltv, NULL); - if (LIBUSB_TRANSFER_CANCELLED != - dev->xfer[i]->status) { - r = libusb_cancel_transfer(dev->xfer[i]); - /* 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) - continue; - - next_status = RTLSDR_CANCELING; - } - } - - if (dev->dev_lost || RTLSDR_INACTIVE == next_status) { - /* handle any events that still need to - * be handled before exiting after we - * just cancelled all transfers */ - libusb_handle_events_timeout_completed(dev->ctx, - &zerotv, NULL); - break; - } - } - } + if(dev->live_transfers > 0) return -6; _rtlsdr_free_async_buffers(dev); - dev->async_status = next_status; + dev->async_status = RTLSDR_INACTIVE; - return r; + return ret; } int rtlsdr_cancel_async(rtlsdr_dev_t *dev)

2 years, 3 months

1
0
0 0

[PATCH] librtlsdr: force wait state after lib_cancel_transfer to avoid crash on close in windows

by Jasper van den Eshof

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)

2 years, 3 months

4
6
0 0

[PATCH] fix build issue on macOS by adding libusb shared lib directory to search path

by Jasper

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

2 years, 3 months

1
0
0 0

[PATCH] rfspace: Add PPM correction

by argilo＠gmail.com

From: Clayton Smith <argilo(a)gmail.com> This patch was originally written by Alexandru Csete and posted at https://github.com/csete/gr-osmosdr-gqrx/commit/d66df300. The only change I made was to rename the _freq_corr_ppm variable to _freq_corr, since many other devices use that name. This patch used to be included in Gqrx releases, so it should work correctly. --- lib/rfspace/rfspace_source_c.cc | 17 +++++++++++++---- lib/rfspace/rfspace_source_c.h | 2 ++ 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/lib/rfspace/rfspace_source_c.cc b/lib/rfspace/rfspace_source_c.cc index 314dfc732d..113588a5d4 100644 --- a/lib/rfspace/rfspace_source_c.cc +++ b/lib/rfspace/rfspace_source_c.cc @@ -103,6 +103,7 @@ rfspace_source_c::rfspace_source_c (const std::string &args) _nchan(1), _sample_rate(NAN), _bandwidth(0.0f), + _freq_corr(0.0), _fifo(NULL) { std::string host = ""; @@ -446,6 +447,8 @@ rfspace_source_c::rfspace_source_c (const std::string &args) _thread = gr::thread::thread( boost::bind(&rfspace_source_c::tcp_keepalive_task, this) ); } + _center_freq = get_center_freq(); + #if 0 std::cerr << "sample_rates: " << get_sample_rates().to_pp_string() << std::endl; std::cerr << "sample rate: " << (uint32_t)get_sample_rate() << std::endl; @@ -600,7 +603,7 @@ static size_t read_bytes( int fd, char *data, size_t size, bool &run ) int nread = read( fd, &data[nbytes], 1 ); if ( nread == 0 ) - continue; + continue; if ( nread < 0 ) break; @@ -1378,7 +1381,10 @@ osmosdr::freq_range_t rfspace_source_c::get_freq_range( size_t chan ) double rfspace_source_c::set_center_freq( double freq, size_t chan ) { - uint32_t u32_freq = freq; + uint32_t u32_freq; + + u32_freq = freq * (1.0 + _freq_corr * 0.000001); + _center_freq = freq; /* SDR-IQ 5.2.2 Receiver Frequency */ /* SDR-IP 4.2.2 Receiver Frequency */ @@ -1395,7 +1401,7 @@ double rfspace_source_c::set_center_freq( double freq, size_t chan ) transaction( tune, sizeof(tune) ); - return get_center_freq( chan ); + return _center_freq; } double rfspace_source_c::get_center_freq( size_t chan ) @@ -1423,12 +1429,15 @@ double rfspace_source_c::get_center_freq( size_t chan ) double rfspace_source_c::set_freq_corr( double ppm, size_t chan ) { + _freq_corr = ppm; + set_center_freq( _center_freq, chan ); + return get_freq_corr( chan ); } double rfspace_source_c::get_freq_corr( size_t chan ) { - return 0; + return _freq_corr; } std::vector<std::string> rfspace_source_c::get_gain_names( size_t chan ) diff --git a/lib/rfspace/rfspace_source_c.h b/lib/rfspace/rfspace_source_c.h index 996f47b392..42bb6de6ac 100644 --- a/lib/rfspace/rfspace_source_c.h +++ b/lib/rfspace/rfspace_source_c.h @@ -145,6 +145,8 @@ private: /* members */ size_t _nchan; double _sample_rate; double _bandwidth; + double _center_freq; + double _freq_corr; gr::thread::thread _thread; bool _run_usb_read_task; -- 2.25.1

2 years, 3 months

1
0
0 0

[PATCH] Stop applying workaround for libusb < 1.0.9

by argilo＠gmail.com

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

2 years, 3 months

2
1
0 0

[PATCH] Show readable error when hackrf start/stop fails

by Martin Ling

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

2 years, 3 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr