July 2013 - osmocom-sdr - lists.osmocom.org

by Favati

Hi there! I'm using a dongle on a raspberry + rtl_tcp and sdrsharp on another machine (quad core.... 3gb ram...good machine!) The problem occour at 00:57 http://www.youtube.com/watch?v=4E2MPfEzEi8 and at 1:34 in this video: http://www.youtube.com/watch?v=8snz1wQSRpw If i stop and start sdrsharp, it works ok for some minutes...then the problem is up again! No errors appear on the console of raspberry/rtl_tcp I'm not able to understand if it's a problem of rtl_tcp,raspberry or whatelse... Things i've tryed: 1) Changed the samplerate 2) Changed the raspberry (tested tp1/tp2 too...getting 4.98v!!!) 3) Changed the dongle 4) Updated sdrsharp The dongles tryed work ok on a pc I've no more idea.... Anyone can help me? PS: If someone know a program that works in linux and is similar to sdrsharp AND CAN INTERFACE TO A REMOTE RTL_TCP...

10 years, 2 months

6
13
0 0

MiricsFlexiTV-MSI3101

by marzano

A quite good (AM/SW)/FM/DAB/DVB-T USB dongle. Mirics FlexiTV MSi3101 (two chips MSi001+MSi2500) http://www.mirics.com http://www.mirics.com/node/31 Data sheets available, register yourself at Mirics portal. RF Tuner: MSi001/MSi002 ( used by FUNcubrePro+ ?), seems better than R820T ADC and HiSpeed USB interface: MSi2500 . ADC 10 bit , better than 8 bit RTL2832U aDC. Windows binary software available: FMDABplayer, DVB_T decoder, Windows lib.dll and API doc. IO-DATA GV-TV100 stick sold on Japan . Stick, chips and dev board available from Mirics. Linux software at address http://cgit.osmocom.org/libmirisdr/ It seems project on stand-by . Can author Steve Markgraf comment ? Francesco

10 years, 5 months

3
2
0 0

rtl-sdr offset tuning and other questions

by David Jacobowitz

Hi guys, I'm new to this list (and to radio) so I hope you will please indulge me if I ask something that is a FAQ. Also, some of these questions are about the dongle, not the library. I am working on a personal project to use SDR techniques to decode aviation navigation signals (VOR). I've got the signal processing mostly working from recorded signals, but am now trying to integrate my SW with the radio in real time. I have a few questions: - What exactly is offset tuning? How is offset tuning different from tuning to an offset? Is this a feature that mostly benefits people who are not going to put their IF through another mixer? In my application I am already tuning to an offset, and pulling down a wide enough IF that actually holds many channels of interest. (VOR channels have 50kHz spacing). I then use a software mixer/channelizer to choose the channel I want. Am I correct in assuming that offset tuning is of no use to me? - regarding AGC, what is the difference between AGC and auto gain? That is, the library API has RTLSDR_API int rtlsdr_set_tuner_gain_mode(rtlsdr_dev_t *dev, int manual) RTLSDR_API int rtlsdr_set_agc_mode(rtlsdr_dev_t *dev, int on); I'm guessing that these affect different AGCs. One for the tuner and one for the RTL device. What are the benefits and costs of having either or both on? - regarding rtlsdr_read_async(...) and related functions. I take it that the library is setting up a ring buffer and calling me back when it has a new buffer of data for me. How long to I have to work with this buffer? Obviously, if I want to work in real-time I need to keep up with the sample rate. But my application can afford to throw away buffers since it can decode a few ms of data from one station and then revisit it much later. However, I'd like to know how long I have until the buffer gets clobbered. I'm presuming it's stable until all the n-1 other buffers have been hit. - generally how fast can the RTL devices tune? I know, this is not an rtlsdr question per se, but I'm curious. I noticed that when I tune, I get a delay. This is a great library and I'm so glad it's out there! I was not looking forward to plumbing the depths of USB drivers to understand how to pull data from the RTL dongle! I think rtl-sdr.h could use perhaps a smidge more documentation. I'd be happy to submit a comments-only patch if there's interest. :-) Regards, Dave Jacobowitz

10 years, 7 months

4
5
0 0

R820T vs. E4000

by Benedikt Heinz

Hi everyone, although there are some comparisons between the R820T and the E4000 already [1, 2], I also did some tests with another use-case in mind. I'm working on a thing similar to RTLSDR-Scanner [3]. I want to monitor a large part of the spectrum continuously. So I compared the R820T with the E4000 using RTLSDR-Scanner w/ and w/o an antenna. My results are here: https://docs.google.com/folder/d/0ByDAKwyEiyx_XzZ5ZnpRV1VZWDQ/edit?usp=shar… There's much more spurs with the E4000 than w/ the R820T. According to [1, 2] one also would expect a better overall sensivity compared to the E4000. However, the GSM900 signals for example seem to be way better with the E4000 according to the RTLSDR-Scanner. Tuning to a certain channel w/ OsmoSDR Source in GNUradio gives about the same SNR - contrary to the RTLSDR-Scanner output. Can anyone explain this? Also, the DVB-T channel at 502MHz is quite weak in the R820T RTLSDR-Scanner output when compared to the E4000. I had a closer look at the lower limit of the channel in gnuradio. This can be seen in the 502MHz_*.png pictures. The E4000 produces a nice +20dB step while one can hardly see the channel in the R820T spectrum. I don't understand this as well. Is this AGC-related? Manually setting a fixed gain didn't really help though... Any explanations? Thank you! Best regards, Hunz [1] http://steve-m.de/projects/rtl-sdr/tuner_comparison/ [2] http://www.hamradioscience.com/rtl2832u-r820t-vs-rtl2832u-e4000/#more-1852 [3] https://github.com/EarToEarOak/RTLSDR-Scanner

10 years, 7 months

5
5
0 0

OpenBSD: crashing

by Alan Corey

This is with a version of rtl-sdr I got by git last night and OpenBSD 5.2 (current release). 5.2 has some pthreads fixing so I waited until I bought another computer and loaded it. Are the crashes related to threads? I don't know, but possibly. It didn't work with OpenBSD 5.0 either. rtl_fm crashes and uses threads rtl_adsb crashes and uses threads rtl_tcp doesn't crash, uses threads, actually stops on ctrl-c rtl_test doesn't crash, doesn't use threads, won't stop rtl_eeprom doesn't crash, doesn't use threads, ends normally I'm not real practiced using gdb but I tried looking at a couple of core files, here's a run of rtl_fm: rtl_fm -f 162550000 -N - | play -t raw -r 24k -e signed-integer -b 16 -c 1 -V1 - -: (raw) Encoding: Signed PCM Channels: 1 @ 16-bit Samplerate: 24000Hz Replaygain: off Duration: unknown In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0 Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000013 Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Rafael Micro R820T tuner Oversampling input by: 42x. Oversampling output by: 1x. Buffer size: 8.13ms Tuned to 162802000 Hz. Sampling at 1008000 Hz. Output at 24000 Hz. Exact sample rate is: 1008000.009613 Hz Tuner gain set to automatic. In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0 Done. Abort (core dumped) d530# gdb -c rtl_fm.core /usr/local/bin/rtl_fm GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd5.2"... Core was generated by `rtl_fm'. Program terminated with signal 6, Aborted. Reading symbols from /usr/lib/libpthread.so.16.0...done. Loaded symbols for /usr/lib/libpthread.so.16.0 Reading symbols from /usr/lib/libm.so.7.0...done. Loaded symbols for /usr/lib/libm.so.7.0 Reading symbols from /usr/local/lib/librtlsdr.so.0.0...done. Loaded symbols for /usr/local/lib/librtlsdr.so.0.0 Reading symbols from /usr/local/lib/libusb-1.0.so.1.0...done. Loaded symbols for /usr/local/lib/libusb-1.0.so.1.0 Symbols already loaded for /usr/lib/libpthread.so.16.0 Reading symbols from /usr/lib/libc.so.65.0...done. Loaded symbols for /usr/lib/libc.so.65.0 Loaded symbols for /usr/libexec/ld.so #0 0x0abbd98d in kill () from /usr/lib/libc.so.65.0 (gdb) bt #0 0x0abbd98d in kill () from /usr/lib/libc.so.65.0 #1 0x0ac29545 in abort () at /usr/src/lib/libc/stdlib/abort.c:68 #2 0x005e9298 in pthread_mutex_unlock (mutexp=0x3c003d8c) at /usr/src/lib/librthread/rthread_sync.c:218 #3 0x1c00266e in full_demod (fm=0xcfa2de5c) at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:583 #4 0x1c0028ff in demod_thread_fn (arg=0xcfa2de5c) at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:641 #5 0x005ebc2e in _rthread_start (v=0x84da4c00) at /usr/src/lib/librthread/rthread.c:111 #6 0x0aba62e9 in __tfork_thread () from /usr/lib/libc.so.65.0 The backtrace (bt) shows that it dies trying to do a mutex_unlock (I think). rtl_tcp also does a mutex_unlock and it doesn't crash. I'm probably reading it wrong for all I know. I don't know what's causing the signal 6 either. I'd also like to get the -lrt of of the cmake files. OpenBSD doesn't use or have lrt, it works without. I can edit it out and compile, but every time I run cmake again, I have to edit the files again. Alan ----- Radio Astronomy - the ultimate DX

10 years, 8 months

5
10
0 0

ACARS decoder using rtl-sdr

by Skip Tavakkolian

Hi, Thank you Thierry and Andreas for your work. I've been experimenting with rtl-sdr library with different RTL2832U devices -- initially for receiving/decoding ADS-B data, and now for ACARS data -- and have been very impressed by the device and the code. For ACARS I was on the same path -- i.e. merging Thierry's code with rtl_fm (AM mode) -- and I'm very happy to see Andreas has already done it! Incidentally, my plan for writing an ADS-B decoder was also (fortunately) shortened when I discovered Dump1090 (Salvatore Sanfilippo) and a nice fork of it (MalcolmRobb). To compile rtl_acars.c, I added it to my local rtl_sdr source directory and made a few mods to the CMakeLists.txt files, etc to build/install it. The diffs can be found here (includes my mods to CMakeLists.txt to compile on Mac OS X): http://pastebin.com/nwjtUDqC -Skip Thierry Leconte wrote: > Le 15/07/2013 09:54, Andreas Reinhardt a écrit : > > Hi everyone, > > > > I have combined "rtl_fm" with Thierry Leconte's (GPL'ed) acarsdec > library code and created "rtl_acars" which can directly decode ACARS flight > info messages to the console. > Hey that's great news! > I just bought a rtl card for fun recently and subscribe to this list . > Very happy to see someone use my very old acars decoder code :-) > will try it very soon !

10 years, 9 months

2
1
0 0

RTL_FM raw mode squelch

by Sdr Guru

Hi Please enable raw mode squelch. It does wonders when debuging remote loctions (ppm_error!). And significantly reduces data volumes. rtl_fm -R -f 1**M -s 12k -l 220 | sox -r 12k -t raw -e signed-integer -b 16 -c 2 -V1 - -C 0 out.flac sox out.flac out_s.wav silence -l 1 0.2 1% -1 2.0 1% SG

10 years, 9 months

2
1
0 0

Re: osmocom-sdr Digest, Vol 20, Issue 12

by Peter Stuge

Peter Dohm wrote: > I can show you screen shots of zadig if you'd like to see them, Even if they look good that's actually not good enough.

10 years, 9 months

1
0
0 0

Terratec T-Stick+ oddity in Windows 8

by Peter Dohm

Hi. As it appears, the Terratec T-Stick+ is supported properly in the latest releases of osmocom's libraries. I have a T-Stick+ working properly in SDRSharp using the latest version of the standard zadig drivers as everyone on Windows uses. When i downloaded the latest osmocom Windows binaries from here: http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip, i get the following result when i run rtl_test.exe on a fully-patched Windows 8 64-bit OS: C:\Users\user\Downloads\RelWithDebInfo\rtl-sdr-release\x64>rtl_test.exe -t Found 2 device(s): 0: Terratec T Stick PLUS 1: Terratec T Stick PLUS Using device 0: Terratec T Stick PLUS usb_open error -12 Failed to open rtlsdr device #0. I've tried this both as administrator and as a normal user, btw. Curiously enough, HDSDR also can not locate the device for some reason no matter what I do, and i've installed the zadig drivers on BOTH tuner instances just to be sure... Somewhat perplexed... Can anyone offer any advice? Cheers Peter Dohm

10 years, 9 months

2
1
0 0

ACARS decoder using rtl-sdr

by Andreas Reinhardt

Hi everyone, I have combined "rtl_fm" with Thierry Leconte's (GPL'ed) acarsdec library code and created "rtl_acars" which can directly decode ACARS flight info messages to the console. Confirmed to compile on OSX 10.6 (not possible for me to check if it also compiles under Windows and *nix). Feel free to add it as another proof of concept to your distro unless you consider it too much of a quick&dirty hack. Grab the code from: http://pastebin.com/kLJHyQWt Best regards, Andreas

10 years, 9 months

4
4
0 0

Re: ACARS decoder using rtl-sdr

by Pawel Janowski

Hello its great idea ! I think the next step (small for man big form mankind) should be decoding (based on rtl_fm) APRS messages and putting into APRS-IS Servers ! with regards Pawel, SQ7MRU http://sq7mru.blogspot.com/

10 years, 9 months

2
1
0 0

Re: ACARS decoder using rtl-sdr

by Adam Nielsen

> Hi, > > The grab connection doesn't work :( > > 73, Murat TA1DB If you're running a recent version of Linux, it will load DVB drivers so you can watch TV with the device. You'll have to unload these to make the device available for use: sudo rmmod dvb_usb_rtl28xxu rtl2832 e4000 (assuming an e4000 device, not sure what module to unload for other tuners, lsmod will tell you.) Cheers, Adam.

10 years, 9 months

2
2
0 0

Possible bug in device removal detection code in librtlsdr.c

by Alexey Kruglov

Hi. Device removal detection code in _libusb_callback in librtlsdr.c may be buggy. Every time we get any status other than LIBUSB_TRANSFER_COMPLETED (including LIBUSB_TRANSFER_ERROR) the code doesn't resubmit current buffer, and we get the real number of working buffers decreased by one. If that number goes down to 0, rtlsdr_read_async() will hang. Linux version tries to control it by counting the number of LIBUSB_TRANSFER_ERROR buffers that came in row in dev->xfer_errors. But if we already have _one_ failed buffer during the whole transfer up to the moment, that counter will never reach dev->xfer_buf_num. So it seems more straightforward to 1. count the failed buffers and rtlsdr_cancel_async() when it reaches 0 or some sensible threshold, and 2. maybe resubmit some kinds of the failed buffers other than LIBUSB_TRANSFER_COMPLETED, if it makes sense. I am not a libusb guru and it's not well documented in this part, so I am not sure about my second point. Hoping some librtlsdr developers will appear on this list. -- GPG fp: 6DFA 1186 7576 DE60 6CCB EB39 AD81 1733 EEBB 970A

10 years, 9 months

2
1
0 0

Delay after rtlsdr_cancel_async

by Alexey Kruglov

Hi. I noticed there is a 1 second delay in librtlsdr between calling rtlsdr_cancel_async and releasing from rtlsdr_read_async. I'm writing a radio scanner and this delay limits scanning speed considerably. I tracked the delay down to this piece of code in librtlsdr.c: while (RTLSDR_INACTIVE != dev->async_status) { r = libusb_handle_events_timeout(dev->ctx, &tv); [...] if (RTLSDR_CANCELING == dev->async_status) { next_status = RTLSDR_INACTIVE; [...] if (dev->dev_lost || RTLSDR_INACTIVE == next_status) { >>>> libusb_handle_events_timeout(dev->ctx, &tv); break; } The marked line is almost always(?) invoked when all the events are already processed, hence it blocks for tv = 1 second. In fact I don't understand what this `if' is supposed to do at all. I tried to modify this line by changing the delay to 0 making it a non-blocking call (leaving the timeout of 1 sec for the former libusb_handle_events_timeout call). This worked with my project and the 1 second delay disappeared. So, I suppose, it's better to either a) remove the whole `if' or b) make the latter libusb_handle_events_timeout non-blocking as I did. I checked that b) works for me, and didn't test a) yet. The question is: what that `if (dev->dev_lost ...' is supposed to do? And the two possible fixes for 1 second delay bug depending on the answer are (diffs): === 1630a1631 > struct timeval tv_nb = { 0, 0 }; 1696c1697 < libusb_handle_events_timeout(dev->ctx, &tv); --- > libusb_handle_events_timeout(dev->ctx, &tv_nb); === === 1694,1698d1693 < < if (dev->dev_lost || RTLSDR_INACTIVE == next_status) { < libusb_handle_events_timeout(dev->ctx, &tv); < break; < } === -- GPG fp: 6DFA 1186 7576 DE60 6CCB EB39 AD81 1733 EEBB 970A

10 years, 9 months

1
1
0 0

Anybody running gr-osmosdr or gr-baz under Windows?

by Murat Toloğlu

Hi All, After more than 2 weeks of endless trials to build, install and run gr-osmosdr and/or gr-baz in Windows 7 to have an RTL2832 source in GNU Radio - GRC without success I really wander if anybody exists and running these programs under Windows? Do you know anybody who succeeded to build and install gr-osmosdr and/or gr-baz in Windows? Regards, Mu

10 years, 9 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr July 2013