osmocom-sdr

osmocom-sdr@lists.osmocom.org

1 participants
912 discussions

[PATCH] output calculated ppm to stderr
by Андрей Родионов 23 Sep '17

23 Sep '17

Good day, I found an issue, when i call rtl_test from external program with "-p” argument. PPM is written into stdout, which means it will be automatically flushed on interactive shell or when fflush called manually. Neither of this was used. All other output was written to stderr, hence simple patch: diff --git a/src/rtl_test.c b/src/rtl_test.c index 9a6cfda..c7e60c5 100644 --- a/src/rtl_test.c +++ b/src/rtl_test.c @@ -202,7 +202,7 @@ interval += (int64_t)(ppm_now.tv_nsec - ppm_recent.tv_nsec); nsamples_total += nsamples; interval_total += interval; - printf("real sample rate: %i current PPM: %i cumulative PPM: %i\n", + fprintf(stderr, "real sample rate: %i current PPM: %i cumulative PPM: %i\n", (int)((1000000000UL * nsamples) / interval), ppm_report(nsamples, interval), ppm_report(nsamples_total, interval_total)); Best Regards, Andrey

1 0

No supported tuner found
by Gabor Mikes 19 Sep '17

19 Sep '17

Hi All, I recently purchased a couple of DVB-sticks on Amazon, titled: "RTL-SDR, FM+DAB, DVB-T USB Stick Set with RTL2832U & R820T. Great SDR for SDR#, HDSD" I got "No supported tuner found" when running the rtl_test command. I see others have had the same issue, so when I finally figured it out, I thought some of you might be interested. First of all, this stick has a FC0012 tuner despite the title. Secondly this stick is obliviously wired differently than other sticks with FC0012 because it needs different gpio settings. I added a few lines to the rtlsdr_open() function in librtlsdr.c, just before probing for FCxxx: /* initialise GPIOs */ rtlsdr_set_gpio_output(dev, 0); rtlsdr_set_gpio_output(dev, 3); rtlsdr_set_gpio_output(dev, 4); rtlsdr_set_gpio_output(dev, 5); rtlsdr_set_gpio_output(dev, 6); rtlsdr_set_gpio_bit(dev, 3, 1); rtlsdr_set_gpio_bit(dev, 4, 0); rtlsdr_set_gpio_bit(dev, 6, 0); /* reset tuner before probing */ rtlsdr_set_gpio_bit(dev, 5, 1); rtlsdr_set_gpio_bit(dev, 5, 0); With this modification the tuner comes a live and everything works. Kindest regards, Gabor Mikes

1 0

[PATCH] Add ipv6 support to rtl_tcp
by A. Maitland Bottoms 04 Sep '17

04 Sep '17

I've prepared this patch in response to Debian bug #870804 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870804 It passes the text from the -a and -p options through getaddrinfo() and uses the first result that has a valid socket with a successful bind. While not a complete bind to all possible valid names, it does appear to address the use case of the bug submitter without completely changing the program flow. I submit this for inclusion in the osmocom rtl-sdr repo as it may be of use to others. Thanks for your consideration, -Maitland

1 0

redmine e-mails broken from 08/26 through 08/31
by Harald Welte 31 Aug '17

31 Aug '17

Dear Osmocom community, from August 26th 06:54 UTC through August 31st 06:22 UTC our Osmocom.org redmine could not send any e-mails. This was due to a configuration file syntax error introduced by me, my apologies. If you rely on redmine e-mail notifications to the issues you have subscribed to, please double-check as related notifications during that interval were unfortunately lost. Best regards, Harald p.s.: The reason for the config change was to enable e-mail notifications from jenkins.osmocom.org (which it now has, if you want to configure e.g. post-build notification actions). -- - 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 0

vdl mode2 decoder for RTL SDR
by Thierry Leconte 31 Jul '17

31 Jul '17

Hi I just put on github my new project : vdl mode2 decoder for RTL dongle https://github.com/TLeconte/vdlm2dec

1 0

SDRSharp/Airspy on Debian
by Oscar Llerena 21 Jul '17

21 Jul '17

Hi guys I am attempting to install Airspy (before known as SDRSharp) on my Debian 9.0 and I am following this link: https://rtlsdr.org/softwarelinux When it gets to the line of Airspay Installation it quotes "Don't forget to blacklist the kernel driver as mentioned here <https://github.com/airspy/host/wiki/Troubleshooting%5Dhere%5D.%20%20*%20Dow…> ." which links you to this wiki site https://github.com/airspy/airspyone_host/wiki/Troubleshooting#linux- debianubuntu I was able to install airspy-git, gr-osmosdr, and gqrx but I get lost on the part of blacklist the kernel >= 3.17 What can I do to blacklist the kernell driver? Thanks

1 0

GPIO pin integration to osmosdr in gnuradio via argument
by samuel verdon 17 Jul '17

17 Jul '17

Hello, I’m trying to switch the state of the pin J2_3 of my xb100 through the argument line of the osmosdr block in gnuradio. To do this, I added this code to the file bladerf_common.cc 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 /* Support of the XB100 to control pin J2_3 through the argument line*/ if ( dict.count("xb100") ) { if (bladerf_expansion_attach(_dev.get(), BLADERF_XB_100)) { std::cout << "Could not attach XB-100" << std::endl; } else { _xb_100_attached = true; std::cout << "Expension XB-100 attached" << std::endl; if ( bladerf_expansion_gpio_dir_masked_write(_dev.get(),BLADERF_XB100_PIN_J2_3, 1)) { std::cout<< "Could not set TRX pin direction" << std::endl; } std::cout << "J2_3 output direction selected" << std::endl; if ( dict["xb100"] == "TX" ) { if(bladerf_expansion_gpio_masked_write (_dev.get(),BLADERF_XB100_PIN_J2_3, BLADERF_XB100_PIN_J2_3)){ std::cout<< "sorry, but I cannot set pin to 1" << std::endl;} } else if(dict["xb100"] == "RX" ) { if(bladerf_expansion_gpio_masked_write (_dev.get(),BLADERF_XB100_PIN_J2_3, 0)){ std::cout<< "sorry, but I cannot set pin to 1" << std::endl;} } else { std::cout<< "Wrong parameter specified, should be TX or RX" << std::endl;} } } In my osmosdr bloc, I added this argument “ xb100=tx” but I don’t have my 5V on my pin :( I don’t understand why the pin is not setted when I start my flowgraph… Could you help me please? Thank you Samuel Verdon

1 0

Fwd: Re: Problem with latest version (master) of gr-osmosdr
by John Ackermann N8UR 25 Jun '17

25 Jun '17

After a successful build of the Gnuradio plus extras by modifying the build-gnuradio script to point to the osmocom git repository for rtlsdr, I get an error and backtrace/memory map similar to the attached osmosdr-error-output.txt when I exit from, e.g., osmo_fft (the program seems to run fine until exit). Fabian suggested that I post this to the list. I also installed op25 on this system, and it fails at runtime with a bunch of errors that I'm attaching as "op25-error-output.txt"; the end of the sring is: wx._core.PyAssertionError: C++ assertion "!m_frameStatusBar" failed at ../src/common/framecmn.cpp(381) in CreateStatusBar(): recreating status bar in wxFrame I wonder if this error is related, as op25 on a several-month-old gnuradio installation works fine. Thanks for any pointers on how to resolve this issue (or these issues). John -------- Forwarded Message -------- Subject: Re: Problem with latest version (master) of gr-osmosdr Date: Sat, 24 Jun 2017 14:35:45 -0400 From: John Ackermann N8UR <jra(a)febo.com> To: kerel <kerel-fs(a)gmx.de> Here you go, Fabian. Thanks much for looking into this! I have noticed this problem each time I've managed to get a successful build-gnuradio completion on this system (e.g., after I commented out the changes that made the build fail). I have another machine that was updated using build-gnuradio perhaps three months ago, and it does not exhibit this behavior. One difference is that the other machine is running Linux Mint 18.0, while the current one is on 18.1 (both "apt-get dist-upgraded" to current levels at the time of the build). John ---- On 06/24/2017 02:23 PM, kerel wrote: > Hi John, > this seems like an unrelated issue in gr-osmosdr, but I can't tackle it > with the partial? backtrace you provided and can't reproduce it myself. > Could you provide the full backtrace? > > Sincerely, > Fabian

1 2

Problem with latest version(s)
by John Ackermann N8UR 25 Jun '17

25 Jun '17

Hi -- I've recently been trying to install the Gnu Radio system on a new machine using the build-gnuradio script. The script is failing with an error in the gr-osmocom build phase, and I've been able to verify this with a separate attempt to build. In rtl_source_c.cc, line 224, the build fails with: error: 'rtlsdr_set_bias_tee' was not declared in this scope ret = rtlsdr_set_bias_tee(_dev, bias_tee); It appears that changes were merged into the tree on about June 11 to add bias tee support, and that this error results from that change set. I'm able to get a successful build if I comment out those few lines of code, but when I try to run an application (e.g., osmocom_fft), upon exit there is a bunch of traceback output and a lengthy memory map printed. I'm no debugging expert, but I can tell that the exact error and address change on different runs, but always appear to be related to a memory map or corrupted list. I don't know if anyone else has seen either the build issue, or the traceback issue, so thought I should report it here. FWIW, I'm building on a fresh install of Linux Mint 18.1 using the latest version of the build-gnuradio script on a Lenovo M900 i7-6700T system. I've used the build-gnuradio script on several other systems in the past without encountering this issue. If you need any further info, I'm happy to provide it. Thanks, John N8UR

2 2

gr-fosphor CL_INVALID_VALUE in clEnqueueFillBuffer call
by Raj Bhattacharjea 21 Jun '17

21 Jun '17

I'm using the latest fosphor from git (7b6b9961bc2d9b84daeb42a5c8f8aeba293d207c) and am seeing two weird (and I believe related) issues. Firstly, I see the following error: [+] Selected device: TITAN X (Pascal) [!] CL Error (-30, /home/user/gr-fosphor/lib/fosphor/cl.c:409): Unable to queue clear of spectrum buffer This is CL_INVALID_VALUE returning from clEnqueueFillBuffer, so I added some debug fprints to cl.c to see what parameters were being passed into clEnqueueFillBuffer: Edits: fprintf(stderr, "size = %d\n", 2 * 2 * sizeof(cl_float) * FOSPHOR_FFT_LEN); fprintf(stderr, "pattern_size = %d\n", sizeof(float)); fprintf(stderr, "pattern = %p\n", &noise_floor); fprintf(stderr, "offset = %d\n", 0); Output: size = 16384 pattern_size = 4 pattern = 0x7fb66b7fdd2c offset = 0 These parameters look like they shouldn't cause CL_INVALID_VALUE: https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/clEnqueueFil… But there is this one condition that might be met, which is that somehow size (16384) is larger than the underlying buffer (cl->mem_spectrum). The underlying OpenGL buffer being too small brings me to my next (I believe related) issue. The spectrum plot in fosphor is weirdly pixelated, please see the attachment, which shows a screencap from "osmocom_fft -F -f 100e6 -g 20 -s 10e6". Where is the cl->mem_spectrum buffer ultimately declared / initialized? My OpenCL / OpenGL sharing knowledge is nonexistent, any pointers for how I can help debug this issue? Output of clinfo is attached as well, and I'm on Ubuntu 16.04 on x86_64. -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622

2 7

← Newer
1
...
32
33
34
35
36
37
38
...
92
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr