osmocom-sdr September 2012

osmocom-sdr@lists.osmocom.org

20 participants
11 discussions

Mis-detected E4000 instead of FC0013 tuner when using NOXON DAB Stick on Raspberry Pi
by Christoph Gommel 18 Oct '12

18 Oct '12

Hello Guys, First of all: I am amazed by your project - many ideas come up in my head what can be done with this tiny cheap SDR. I have tested rtl_sdr with a linux-vm on my Mac successfully but wanted to run it on my raspberry pi. Unfortunately and thithout an explainable reason to me the tools detect an E4000 instead of the soldered FC0013 on my stick - but only on the PI. To fix this issue I have changed the detection order in librtlsdr.c: diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 3a67b53..cb34f1d 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1073,13 +1073,6 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) /* Probe tuners */ rtlsdr_set_i2c_repeater(dev, 1); - reg = rtlsdr_i2c_read_reg(dev, E4K_I2C_ADDR, E4K_CHECK_ADDR); - if (reg == E4K_CHECK_VAL) { - fprintf(stderr, "Found Elonics E4000 tuner\n"); - dev->tuner_type = RTLSDR_TUNER_E4000; - goto found; - } - reg = rtlsdr_i2c_read_reg(dev, FC0013_I2C_ADDR, FC0013_CHECK_ADDR); if (reg == FC0013_CHECK_VAL) { fprintf(stderr, "Found Fitipower FC0013 tuner\n"); @@ -1088,6 +1081,13 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index) goto found; } + reg = rtlsdr_i2c_read_reg(dev, E4K_I2C_ADDR, E4K_CHECK_ADDR); + if (reg == E4K_CHECK_VAL) { + fprintf(stderr, "Found Elonics E4000 tuner\n"); + dev->tuner_type = RTLSDR_TUNER_E4000; + goto found; + } + /* initialise GPIOs */ rtlsdr_set_gpio_output(dev, 5); After compiling the lib the FC0013 is detected and the sticks works great on my Pi. Of course this is not a perfect solution and I will figure out later in depth WHY the E4K_CHECK_VAL comes out of the FC0013. Anybody else who has or had the same problems? the Hardware used is: Bus 001 Device 004: ID 0ccd:00b3 TerraTec Electronic GmbH NOXON DAB/DAB+ Stick regards Christoph

5 4

Sweex USB dongle with rtl_sdr
by Andrew Harrison 05 Oct '12

05 Oct '12

Hi There I have been working with a Sweex USB dongle that has the RTL3282u - FC0012 chipset. Its id is "1f4d:a803 G-Tek Electronics Group" I have been able to get it working with rtl_sdr and rtl_fm. Can you add its id to the source code for others to use. Andrew Harrison.

2 1

Issues with rtl_tcp
by Scott Cutler 02 Oct '12

02 Oct '12

I've ported my app to use rtl_tcp.exe instead of the native rtlsdr libs, and while it is partly working (samples reading correctly, no dropped samples, etc.), I have run into two issues. First--when I start reading samples too quickly after setting the sample rate, I get this error: C:\Users\Scott Cutler\Projects\p4\0\projects\sdr\SeeDeR\SeeDeR\rtl-sdr-release\x32>rtl_tcp.exe -f 100000000 -s 2048000 Found 1 device(s). Found Elonics E4000 tuner Using Generic RTL2832U (e.g. hama nano) Tuned to 100000000 Hz. listening... Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR (gr-osmosdr) source to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...). client accepted! set freq 105000000 set sample rate 1920000 worker cond timeout Signal caught, exiting! comm recv socket error Signal caught, exiting! all threads dead.. listening... Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR (gr-osmosdr) source to receive samples in GRC and control rtl_tcp parameters (frequency, gain, ...). If I instead wait about two seconds after setting the sample rate, there is no problem. There is also no problem if I immediately read samples after connecting, where I set the sample rate on the command line. The other issue is that tuning is very slow--about one second per call to rtlsdr_set_center_freq. I had a similar problem with the rtlsdr.dll library, and I found that tuning was very slow if performed from the main thread, but fairly quick (maybe 10-20 hz) if done from the async proc thread that rtlsdr_read_async launches. That seemed a bit odd to me but it worked. I suspect that rtl_tcp.exe is doing the same thing; calling rtlsdr_set_center_freq from the main thread. Ideas, anyone? Thanks! -Scott PS: I'm running Win7-64, in case it matters. Also using the latest version here: http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip

6 12

Pricing and Availability
by Alan Campbell 29 Sep '12

29 Sep '12

There's been a couple of messages now, asking when you intend to release actual product. I suspect that, provided you warn people about the "rough around the edges" code, the actual HARDWARE is good enough to sell. The repair of code, relating to debugging, will improve when more people have the hardware - and can send fault reports. You may want your code to be as perfect as the Sistine Chapel - but even Michaelangelo had to let the chapel be used while he painted. -- Alan

2 1

OsmoSDR
by Simon G4ELI/HB9DRV 28 Sep '12

28 Sep '12

Hi All, I stumbled across the OsmoSDR on http://sdr.osmocom.org/trac/ - does this supply 16-bit or maybe even higher samples? It looks great J , I'm sure a high quality SDR with this frequency range will be very popular. Simon G4ELI/HB9DRV http://dit-dit-dit.com

2 1

Licensing issues
by Scott Cutler 26 Sep '12

26 Sep '12

Greetings, all! I've recently been bitten by the rtlsdr bug and have since developed some software around it. It's Windows-based and currently decodes (mono) WFM, NFM, POCSAG, FLEX 1600/6400, and (very limited) AX.25 frames. I would like to make a semi-limited release but have some concerns about the licensing of the rtlsdr library after what SDR# went through (or seemed to go through--I'm not sure what the whole story was). I do plan on open-sourcing the whole thing eventually, but in the short term I'll probably have a limited read-only license. Simply put, am I in the clear if I: - only access rtlsdr.dll through my own reimplementation of rtl-sdr.h and rtl-sdr_export.h - do not distribute the binary rtlsdr.dll, but instead link to the Osmocom binaries Thanks for the help! - Scott

6 13

R820T tuner support in librtlsdr
by Steve Markgraf 10 Sep '12

10 Sep '12

Hi list, yesterday I committed code for the Rafael Micro R820T tuner to librtlsdr. Sticks with this combination (RTL2832 + R820T) are relatively new on the market. The main difference to all the other supported tuners so far is that it uses a Low-IF (3.57 MHz) architecture instead of Zero-IF. That means the tuner is only connected to the In-Phase ADC input, and the internal downconverter of the RTL2832 is generating the complex samples. This has the benefit of having no DC offset spike in the middle of the spectrum. So far the tuner driver comes straight from the kernel driver that Realtek supplies, and setting gain manually is not supported yet, although functions for that seem to exist. There is still is a lot that needs to be done, the best thing most likely would be to completely rewrite the driver, or at least clean it up dramatically. Initializing the tuner takes way too long at the moment, since the driver produces a lot of I2C traffic, most of it being redundant as it seems. The driver originally had a frequency limitation of 40 MHz to 900 MHz, but tests showed that the PLL of my stick can achieve lock up to 1766 MHz, and indeed both ADS-B at 1090 MHz and L-Band DAB at 1463 MHz, as well as GMR at 1556 MHz can be received just fine with the R820T. Also, the PLL could lock again at 1850 MHz to 1860 MHz, and the reception of a GSM 1800 BTS at 1854 MHz worked as well. Some initial comparisons [1] between the E4000 and R820T seem to hint at the R820T being a bit more sensitive, especially visible in the Tetra screenshots. Given that the supply of E4000-based sticks is dwindling, I'm pleased to see a new tuner that has the potential of becoming a good replacement, and staying for a while on the market. Regards, Steve [1] http://steve-m.de/projects/rtl-sdr/tuner_comparison

5 4

Re: ISDB-T USB TV RTL-SDR FM+DAB Radio Tuner Receiver Stick Realtek RTL2832U E4000
by Bharath Bhushan Lohray 07 Sep '12

07 Sep '12

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=271041428220 I am new to SDR and such hardware. The ebay listing states that the hardware does not work in the US. I am wondering if this hardware is going to work for the purpose of playing around as a SDR? Thank you, Bharath

2 1

"Best" sampling rate?
by James Peroulas 07 Sep '12

07 Sep '12

Message: 1 > Date: Thu, 6 Sep 2012 05:22:25 +1000 > From: Ben Ryan <benryanau(a)hotmail.com> > To: <osmocom-sdr(a)lists.osmocom.org> > Subject: "Best" sampling rate? > Message-ID: <SNT139-W176A4A72E42D16D41CA612B6A90(a)phx.gbl> > Content-Type: text/plain; charset="iso-8859-1" > > > > > > Come to think of it, I've also found some samplerates to be better than > others. No further info to share beyond the fact that I've noticed it too. > > Drops at higher samplerates are probably due to your CPU, IO latency, etc > (esp if virtualised). You should be able to run 2.048Msps with AF rate of > 44.1khz with next to no drops and smooth carrier audio. If not, and your > CPU isn't maxed out, likely you have a latency or bandwidth issue. > What's the rig you're running on? > > There appears to be an interaction between AF samplerate and IQ > samplerate.. under HDSDR/Win32 anyways. > It might well reduce skips and cpu load if the two rates were cleanly > divisible but I haven't tried to work the theoreticals out.. > > I just set 3.2Msps for spectrum scoping, then narrow to around 1.2Msps for > FM/AM work. The audio rate is usually 44.1khz although sometimes whendoing > an "audio print" of a signal using DRM mode I'll up it to 48khz. On the > Core2Duo I get quite a few dropped samples at 3.2Msps/48khz though - it's > hitting the limits for this system as-is (it's running VMWare MS plus it's > got layers of drivers on it). > > Another thing to consider if under Win32: differing versions of libusb, > ExtIO_RTL, ExtIO_USRP, rtl2832u++.dll files all behave differently wrt cpu, > samplerates and drops. > I haven't documented my findings yet but there's a complex relationship > between the above elements and tuner range.. some RTL libs will permit > 50mhz-~2000mhz, others puke at various spots on the dial etc. > Thanks for the inspiration. I actually re-wrote my code to use async mode and now I'm getting reliable captures up to 1.92MSPS (my desired sampling rate). I was using sync mode but apparently that's not fast enough to capture all samples! BR, James

1 0

"Best" sampling rate?
by Ben Ryan 06 Sep '12

06 Sep '12

Come to think of it, I've also found some samplerates to be better than others. No further info to share beyond the fact that I've noticed it too. Drops at higher samplerates are probably due to your CPU, IO latency, etc (esp if virtualised). You should be able to run 2.048Msps with AF rate of 44.1khz with next to no drops and smooth carrier audio. If not, and your CPU isn't maxed out, likely you have a latency or bandwidth issue. What's the rig you're running on? There appears to be an interaction between AF samplerate and IQ samplerate.. under HDSDR/Win32 anyways. It might well reduce skips and cpu load if the two rates were cleanly divisible but I haven't tried to work the theoreticals out.. I just set 3.2Msps for spectrum scoping, then narrow to around 1.2Msps for FM/AM work. The audio rate is usually 44.1khz although sometimes whendoing an "audio print" of a signal using DRM mode I'll up it to 48khz. On the Core2Duo I get quite a few dropped samples at 3.2Msps/48khz though - it's hitting the limits for this system as-is (it's running VMWare MS plus it's got layers of drivers on it). Another thing to consider if under Win32: differing versions of libusb, ExtIO_RTL, ExtIO_USRP, rtl2832u++.dll files all behave differently wrt cpu, samplerates and drops. I haven't documented my findings yet but there's a complex relationship between the above elements and tuner range.. some RTL libs will permit 50mhz-~2000mhz, others puke at various spots on the dial etc. > I was wondering if certain sampling rates were better than others for > the RTL2832 dongles? I'm finding that if the sampling rate is below > 1.1MSPS, I get few samples being dropped (but they still get dropped). > Above this rate, randomly, I get a multiple of 94 samples being > dropped. > > Are there certain sampling frequencies that are sweet-spots for the > RTL2832 that produce very stable performance? Perhaps frequencies that > are a fraction of DVB sampling frequencies? > > JP > > -- > Integrity is a binary state - either you have it or you don?t. - John Doerr

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr September 2012