- osmocom-sdr - lists.osmocom.org

PATCH: Fixed arbitrary resampling in rtl_fm
by f.meyer-hermann＠gsg-elektronik.de 25 Jul '16

25 Jul '16

As already on github, I fixed rtl_fm's arbitrary resampling by fixing the output buffer length and allowing upsampling by copying the audio data since the algorithm cannot work in-place. I have attached a patch, if you are interested to integrate it into the official branch. Regards, Ferdinand Meyer-Hermann

1 0

post a new release
by Joseph Poirier 22 Jul '16

22 Jul '16

If would be nice to have a newer official release available; installation using the package manager on many Linux distros gets a two year old librtlsdr that's missing the rtlsdr_set_tuner_bandwidth function (added about nine months ago), as well as, other nice updates and fixes. cheers, joe

6 12

Fwd: Patch for osmocom-sdr
by Mike Davis 24 Jun '16

24 Jun '16

Hi I can't sensibly use git-send-email as it wants to do the actual emailing on my behalf, and I use Gmail for this account. I tried sending via git-send-email directly to the list MX and SORBS blocked me, so I've attached the three patches as formatted by 'git format-patch' here. Regards Mike On Fri, Jun 24, 2016 at 9:46 AM, Sylvain Munaut <246tnt(a)gmail.com> wrote: > Hi, > > > Initially I tried to do a Pull Request on the Github repository, > > Yeah we don't use github. > > tbh I'm not even sure who's doing the mirror there ... > > > but was > > told I should send a patch to this mailing list. What format should I > use to > > send the patch? > > See the doc for git-send-email > > You create a git commit with your patch then use that to send it by > mail to the list and it will handle the formatting for you and making > sure the patch isn't mangled by your mail client. > > Cheers, > > Sylvain >

1 0

Patch for osmocom-sdr
by Mike Davis 24 Jun '16

24 Jun '16

Hi I have a patch for the gr-osmosdr project that I am hoping you will be able to merge into the repo. The patch makes it possible to choose which hackrf is opened by the sink component. It also moves the hackrf_open code into a separate, shared source file that is used by both the sink and the source components. Initially I tried to do a Pull Request on the Github repository, but was told I should send a patch to this mailing list. What format should I use to send the patch? Regards Mike

2 1

merge request - update to soapy_support
by Josh Blum 24 Jun '16

24 Jun '16

Hey list, I've pushed some minor fixes to the soapy_support branch. With these fixes I was able to use the siggen gui app with the LimeSDR. More details in the commits. http://git.osmocom.org/gr-osmosdr/log/?h=soapy_support I would appreciate if this can be merged into master. Thanks! -josh

1 0

Patch for gr-osmosdr
by Mike Davis 23 Jun '16

23 Jun '16

Hi I have a patch for the gr-osmosdr project that I am hoping you will be able to merge into the repo. The patch makes it possible to choose which hackrf is opened by the sink component. It also moves the hackrf_open code into a separate, shared source file that is used by both the sink and the source components. Initially I tried to do a Pull Request on the Github repository, but was told I should send a patch to this mailing list. What format should I use to send the patch? Regards Mike Davis

1 0

Re: [PATCH] librtlsdr.pc: use "Require: libusb-1.0" instead of "Libs: -lusb-1.0"
by Bjørn Forsman 07 Jun '16

07 Jun '16

On 31 October 2014 at 08:54, Bjørn Forsman <bjorn.forsman(a)gmail.com> wrote: > Using "Libs: -lusb-1.0" assumes the linker knows where libusb is > located. Using "Require: libusb-1.0" is more correct as it uses > pkg-config to locate the required package and provides correct flags > (both -l and -L). > > This fix is needed to build programs that depend on librtlsdr on > NixOS[1]. (Because there is no "default" linker serach path on NixOS.) > > [1]: http://nixos.org/ > --- > librtlsdr.pc.in | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/librtlsdr.pc.in b/librtlsdr.pc.in > index 5e55049..76b4190 100644 > --- a/librtlsdr.pc.in > +++ b/librtlsdr.pc.in > @@ -7,5 +7,6 @@ Name: RTL-SDR Library > Description: C Utility Library > Version: @VERSION@ > Cflags: -I${includedir}/ @RTLSDR_PC_CFLAGS@ > -Libs: -L${libdir} -lrtlsdr -lusb-1.0 > +Libs: -L${libdir} -lrtlsdr > Libs.private: @RTLSDR_PC_LIBS@ > +Requires: libusb-1.0 > -- Ping. (Oh, and please fixup my commit message typo (s/serach/search/) if/when you apply it.) Best regards, Bjørn Forsman

1 0

librtlsdr API documentation
by Neoklis Kyriazis 02 Jun '16

02 Jun '16

Hi I have purchased an RTL2832/R820Tsdr unit from NooElec and I would like to start writing code for an application to decode weather images from satellite APT transmissions on 137 MHz. I already have written an application to decode such images, received by an old analogue FM receiver, but I feel it can be used with the RTL/SDR dongle as well. To do this I need some documentation on the librtlsdr API but I have not found any with my searches. Is there any documentation for librtlsdr API or any other documentation on how to use available funtions in the lib? My thanks in advance. -- Best Regards Neoklis - Ham Radio Call:5B4AZ http://www.5b4az.org/

2 2

rtl_tcp device index, udev and symlink
by Tim Forrester 30 May '16

30 May '16

Hi guys, new member here, but been playing with rtl dongles and sdr generally for a while now. I run four rtl dongles covering 50, 70, 144 and 432MHz with websdr running on Ubuntu Mate Works quite well but I have trouble with the device indexing changing for rtl_tcp. ie sometimes a dongle gets allocated to a different band. To try and fix the issue I've given each dongle a unique serial number and created some udev rules which create symlinks for each dongle. That all works nicely. Problem is that rtl_tcp uses device indexing starting at D0 and expects D1, D2 D3 etc. whereas my symlinks are called 6mtrs, 4mtrs, 2mtrs and 70cms Not sure how to make rtl_tcp work with symlink's rather than device index. Any ideas ? Regards Tim G4WIM

1 0

RTL-SDR discontinuous samples at low rates
by Raj Bhattacharjea 30 May '16

30 May '16

I have these RTL dongles: http://www.amazon.com/dp/B00SXZDUAQ I've always noticed that when I start up osmocom_fft at 250kSamp/s with those RTL dongles plugged in, the spectrum looks like a bunch of samples are FFT'd, and then the application waits for another batch of samples and the FFT GUI doesn't update, then some more samples come in and get FFT'd, and this process goes on. I up the rate to something like 1M or higher and go about my business. I've been working with an application that can use lower sample rates, and in my investigations, sample rates below 901kSamp/s exhibit this "burst of samples, then nothing" repeating pattern. It seems to me that samples are being dropped, i.e., the sampling is not continuous. With osmocom_fft -F (fosphor) running, if I set the sampling rate to 901k vs. 900k, I see a marked difference in the spectrum, and how often it is updated in the drawing. My suspicions about the samples not arriving / being dropped comes from doing a simple FM radio demod, which sounds great at 901kSamp/s, but plays continuous, stops and underflows, and repeats that again and again when things are run at 900kSamp/s (GNURadio flowgraph attached). I've also seen other really weird stuff, like if you ask for 215k sampling rate. Has anyone else seen these issues? Can anyone replicate? Anyone have solutions or information about what sample rates are properly supported by the hardware? Any documentation to the RTL2832u that might explain this behavior? Here is my setup: gr-osmosdr v0.1.4-48-g86ad5842 (0.1.5git) gnuradio 3.7.8.1 Ubuntu 14.04, gnuradio built from tagged release, osmosdr / fosphor built from git master some day in the past -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622

1 0