- osmocom-sdr - lists.osmocom.org

Re: Beginner question about rtlsdr (Jared Clements)

by James Peroulas

> There is another way, and that's find a known RF signal that we can use for > synchronization. GPS would be ideal, because there's explicit solutions for > time offsets/drift that's referenced to atomic clocks. We could record 5 > minutes or so on the L1 band before an observation, then mid-capture tune > to our frequency of interest...assuming we can shift the e4k chip without > interupting the RTL2832 in it's capture sequence. > I'm not very familiar with your application, but you may also have to do sub-sample time offset estimation and compensation. Even though all of the dongles are running at exactly the same sampling *rate*, their sampling * instants* will likely be different. This is despite the fact that you used the same length of cable to feed the clock to all the dongles. For example, if you want a 2.88MHz sampling rate, this will involve dividing the 28.8MHz input by a factor of 10. One dongle might use edge numbers 0, 10, 20, 30, ... of the source clock to produce the 2.88 MHz clock and another might used edge numbers 3, 13, 23, 33, .... Their sampling frequencies will be exactly the same, but the sampling instant will be different. > Does anyone here know if this is possible? Shift the tuner without > interupting the capture? > I can confirm that you can do this since this is what I did in my LTE cell scanner to improve search speed. I configured the A/D rate once, and then I just kept changing the LO frequency. The thing is that once you change the LO frequency, the phase rotation of the received signal will change randomly for all the dongles. So, during the calibration phase, you might find that dongle 1 needs a time correction of t1 and phase correction of p1 to get its signal to align with the signal from dongle 2. After you change the LO, dongle 1 will still need the same time correction (t1), but you wont know what phase to use. Perhaps phase alignment isn't necessary for your application? BR, James -- *Integrity is a binary state - **either you have it or you don’t.* - John Doerr

11 years, 6 months

1
0
0 0

Beginner question about rtlsdr

by Michel Pelletier

Hello everyone, I hope this is an appropriate forum for a beginner question about using an E4000 dongle. I'm an amateur astronomer, and lately I've been wanting to get into amateur radio astronomy. The rtlsdr seems like a really cheap way to get involved. It can tune many interesting frequencies, in particular channel 37 around 608-614 Mhz. I am a Python programmer by trade so I am using roger-'s amazing pyrtlsdr library which is great, I can read samples from the device and they get returned as numpy arrays. The scipy.signal package allows me to correctly decimate the signal and I am working on a simple graphing program to graph signal levels in realtime, by hour, by day, and by week. I hope to basically reproduce the Jansky experiment that started the entire science of radio astronomy: http://en.wikipedia.org/wiki/Karl_Guthe_Jansky I have a question though about how to use the dongle that I can't quite figure out. roger-'s demo_waterfall program, for example, sets the default sample_rate to 1.4e6, but then on each scan only calls read_samples(2**16). The demo displays the entire megahertz of bandwidth, so I'm a bit confused as to how the 64K samples map onto the 1M samples of the device. It doesn't seem to make sense taht the device only returns the first 64K samples. Can anyone clue in a total beginner on the sample rate and reading samples from the device correlate? Thank you! -Michel

11 years, 6 months

4
12
0 0

RTL-SDR with MSI DIGIVOX Micro HD suppot

by Höss Lajos

Hi, I have USB DVB-T stick. Possibly add suport for rtl-sdr? Name: MSI DIGIVOX Micro HD (Dexatek clone?, i see black diamond design, same as Dexatek, and i found 1d19 = Dexatek) USB ID (from linux and windows): 1d19:1104 Working (very old) driver for linux rtl2832u, my linux very old, i cannot complile the current rtl-sdr because libusb, etc. too old. I will ugrade to new linux, but requies long time. I not know how to identify the tuner, but from dmesg i think this device use rtl2832 chipset + FC2580 tuner I try with nightly build sdl-sharp, and the latest http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip on windows, no succes. mngc

11 years, 6 months

2
1
0 0

Mis-detected E4000 instead of FC0013 tuner when using NOXON DAB Stick on Raspberry Pi

by Christoph Gommel

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

11 years, 7 months

5
4
0 0

bug and parameters for rtl_fm

by Alain Prignet

Hello, I have found what I think is a bug in rtl_fm.c : on line 171 there is if (fm->prev_index < (fm->downsample)) { but fm->prev_index start at -1 so to get an undersampling of factor fm->downsample, one should have if (fm->prev_index < (fm->downsample-1)) { Without this correction, I get underruns, with this one, there is no underrun. Moreover, I have tried the idea of http://www.embedded.com/design/embedded/4212086/DSP-Tricks--Frequency-demod… to avoid atan : +int polar_discriminant2(int ar, int aj, int br, int bj) +{ + int cr, cj; + double angle; + angle = (double)(ar * (aj - bj) - aj * (ar - br)) / (double)(ar*ar + aj*aj); + return (int)(angle*(1<<12)); +} Finally, to get good results, I use these parameters : DEFAULT_BUF_LENGTH (32 * 16384) capture_rate = 2304000 fm->downsample = 12 fm->post_downsample=8 sample_rate = 24000 Best regards, Alain Prignet

11 years, 7 months

1
0
0 0

Sweex USB dongle with rtl_sdr

by Andrew Harrison

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.

11 years, 7 months

2
1
0 0

Issues with rtl_tcp

by Scott Cutler

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

11 years, 7 months

6
12
0 0

Pricing and Availability

by Alan Campbell

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

11 years, 7 months

2
1
0 0

OsmoSDR

by Simon G4ELI/HB9DRV

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

11 years, 7 months

2
1
0 0

Licensing issues

by Scott Cutler

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

11 years, 7 months

6
13
0 0

R820T tuner support in librtlsdr

by Steve Markgraf

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

11 years, 8 months

5
4
0 0

Re: ISDB-T USB TV RTL-SDR FM+DAB Radio Tuner Receiver Stick Realtek RTL2832U E4000

by Bharath Bhushan Lohray

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

11 years, 8 months

2
1
0 0

"Best" sampling rate?

by James Peroulas

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

11 years, 8 months

1
0
0 0

"Best" sampling rate?

by Ben Ryan

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

11 years, 8 months

1
0
0 0

"Best" sampling rate?

by James Peroulas

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

11 years, 8 months

1
0
0 0

Fixed a division by zero bug in rtl_fm that appears on OS X

by Christoph Gommel

Hallo guys, I tried to isolate the Floating point exception that prevents rtl_fm from running on my OS X Machine. XCode's code analysis mechanism showed pointed out a location of some code that not only might bring up a division by zero but brought this on my machine. After adding some basic handling rtl_fm runs now on my Mac but does not deliver appropiate sound. It's chopped and not understandable. Despite the fact that gnuradio performs great on the same machine there seem to be more bugs present I do not understand at the moment. But first of all this small patch should be added to the main code base. Sorry for not knowing more about git than executing "git diff" ;( I am a daily svn user who does not understand the non-linear anarchistic version management behind git by now... diff --git a/src/rtl_fm.c b/src/rtl_fm.c index 0350d8b..d00ef2d 100644 --- a/src/rtl_fm.c +++ b/src/rtl_fm.c @@ -313,13 +313,17 @@ int mad(int *samples, int len, int step) int i=0, sum=0, ave=0; for (i=0; i<len; i+=step) { sum += samples[i]; - } - ave = sum / (len * step); + } + if (len * step) //Avoid Division by zero errors + ave = sum / (len * step); sum = 0; for (i=0; i<len; i+=step) { sum += abs(samples[i] - ave); - } - return sum / (len * step); + } + if (len * step) //Avoid Division by zero errors + return sum / (len * step); + else + return (0); } int post_squelch(struct fm_state *fm)

11 years, 8 months

1
0
0 0

Re: LTE Cell Scanner

by James Peroulas

> Date: Mon, 27 Aug 2012 12:27:21 +0200 > From: Christian Buchner <christian.buchner(a)gmail.com> > > For some reason, your CellSearch software worked the second time I ran > it. Here's the result for a scan in Munich. The two frequencies found > correspond to the operators O2 and Vodafone. Deutsche Telekom is > either not using the 800 MHz band here, or I happen to be out of the > reception range for this dongle. > > Detected the following cells: > C: CP type ; P: PHICH duration ; PR: PHICH resource type > CID fc foff RXPWR C nRB P PR CrystalCorrectionFactor > 449 796M -13.2k -47.7 N 50 N one 0.99998344473785039099 > 372 806M -13.2k -43.7 N 50 N one 0.99998362964129883235 I see that the received signal power is very low at -44dB, so it kind of makes sense that these cells would not be detected every time you run the program. I suspect that if you moved outdoors or used a tuned LTE antenna, these cells would be detectable more reliably. > This software project is way cool! I am surprised how precise my crystal is. > > Now who's willing to extend the code to combine several dongles to > scan the full 10 MHz band and to analyze the allocated resources > signalled on the PDCCH so we can generate statistics on cell load and > number of UEs served? Wow, I think that would be a major undertaking for these dongles! I think that's a task best suited for the USRP and the OpenLTE project :) JP

11 years, 8 months

1
0
0 0

LTE Cell Scanner

by James Peroulas

I just released an LTE cell scanner based on the rtlsdr library. If you're interested, the code is available on github: https://github.com/Evrytania/LTE-Cell-Scanner This code will search for all the LTE cells in your area and will also report the frequency error of your dongle. BR, James P.S. Many thanks for the rtlsdr library! -- Integrity is a binary state - either you have it or you don’t. - John Doerr

11 years, 8 months

5
9
0 0

Re: osmocom-sdr Digest, Vol 9, Issue 16

by James Peroulas

> Message: 1 > Date: Fri, 24 Aug 2012 18:11:59 +0200 > From: Christian Buchner <christian.buchner(a)gmail.com> > To: osmocom-sdr(a)lists.osmocom.org > Subject: Re: LTE Cell Scanner > Message-ID: > <CALm6U+pZd8Ufmu1UCOQ_+0ebMc_joDOh9_dFW0g=1QW=M2p02A(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I was able to build it on Ubuntu 9.04 (Jaunty Jackalope) with a little > upgrading of some dependencies. > > CellSearch is now crashing in the static initializer for the > ROM_TABLES object. *sigh* > > Would anyone have an idea what may be is causing it? > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb773b910 (LWP 21087)] > 0x00f743fe in itpp::Vec<std::complex<double> >::set_size () from > /usr/local/lib/libitpp.so.7 > Current language: auto; currently asm > (gdb) where > #0 0x00f743fe in itpp::Vec<std::complex<double> >::set_size () from > /usr/local/lib/libitpp.so.7 > #1 0x00f74ada in itpp::Vec<std::complex<double> >::operator= () from > /usr/local/lib/libitpp.so.7 > #2 0x0808b0cd in PSS_fd::PSS_fd () > #3 0x08094444 in global constructors keyed to ROM_TABLES () > > Christian Are you still having problems with this? Can you try upgrading to the latest github code? I changed the initialization sequence for the ROM_TABLES and it might fix your problem too. BR, James

11 years, 8 months

1
0
0 0

RTL_FM fails on OS X

by Christoph Gommel

Hello, I was completely happy that rtl-sdr builds without any problems in my iMac (with OSX 10.8.1 and latest Macports). Using a RLT2832-Dongle that is plugged into my mac on other machines via rtl_tcp works well, also recording data is working. What fails is running rtl_fm: iGommel:build chg$ rtl_fm -f 97300000 -s 44100 test.raw Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000291 Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Elonics E4000 tuner Oversampling input by: 23x. Oversampling output by: 1x. Buffer size: 8.08ms Tuned to 97553575 Hz. Sampling at 1014300 Hz. Exact sample rate is: 1014300.020041 Hz Tuner gain set to -1.00 dB. Floating point exception: 8 Unfortunately i don't have the debugging skills to find the position of the Floating point exception without a high-level GUI ;) Any idea what can be done by me to help chasing the bug? Christoph

11 years, 8 months

1
0
0 0

BONANZA - The e4000 *complete* reference document :)

by Ben Ryan

Hey all, Got some gold for ya's. Registers, the works. Even a reference design schematic. Grab it while it's hot, before the lawyers catch on.. and thanks guys for all your hard work with RTLSDR! https://skydrive.live.com/redir?resid=E55F3F5F75B5A7BB!1160

11 years, 8 months

1
0
0 0

[benzandstra@caiway.nl: Small comment about the rtl-sdr wiki]

by Harald Welte

FYI, -- - 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)

11 years, 9 months

1
0
0 0

[jarribas@cttc.es: GNSS-SDR now supports the RTLSDR signal source]

by Harald Welte

Hi all! I'm forwarding this announcement from the GNSS-SDR developers. I will also put it on the sdr.osmocom.org site. Congratulations to steve-m, horizon, hoernchen and the team! 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)

11 years, 9 months

1
0
0 0

Say Enter "RTL readlen=524288" in the 'ExtIO : Device hint' edit field, when that is what you mean

by Jay Salsburg

OK I get it. I wish those who write this stuff were not so Cryptic and Acronymous. On this page ... http://wiki.spench.net/wiki/USRP_Interfaces the author has an entry that looks like this "RTL readlen=524288" yet nowhere in the immediate text is there any language stating to enter this text in the 'ExtIO : Device hint' edit field, you have to sort of guess the author thoughts. No one is ever thinking like the one who is doing the original thinking so to reproduce original thinking adequate references to what the author is thinking is required to reproduce the original thoughts in the reader's mind. Literate illustration makes everything so much easier (and a liberal sprinkling screen shots). Thanks Jay Salsburg

11 years, 9 months

4
6
0 0

The real problem with this thing

by Jay Salsburg

I have been hacking into one of those $20 DVB-T TV Tuner Dongles. To get it to tune to the Freq I want I use the usual method with the ExtIO Drivers. The real problem with this thing, as far as making good use of the valuable E4000, is the RTL2832, even though controlling the Tuner through the USB requires the RTL2832. This clumsy Analog to Digital Converter / USB interface Chip, does not have the Audio dynamic range needed for my purposes. The infuriating predilection it has to crash every time you want to shift frequency is another disadvantage. Since the Owners of the E4000 have gone into Bankruptcy, I am taking the initiative to hack the Tuner. First, I attached a high gain audio amplifier's input directly to the Tuner's output then to a 96K Sample per Second, 24 Bit Audio card to observe a high quality spectral image from the tuner. Next is to hack into and record the I2C sent to the Tuner, so it may be controlled independent of that infuriating RTL2832. If anyone has done this, please share your code and understanding. Thanks Jay Salsburg

11 years, 9 months

3
6
0 0

Re: [Discuss-gnuradio] FCD/Alsa bug (Re: Bug hunting)

by don.lewis＠dses.org

Sent via the HTC V..b.livid™, anbURL: http://maps.google.com/maps?q=40.031769,-105.2;Kn)na?bks3213, 3128 Bell Dr, Boulder, CO 80301, USA AT&T 4G -3$/-)44+$LTE( (::,2mk: ----- Reply message ----- From: "Christian Gagneraud" <chris(a)techworks.ie> To: "Dimitri Stolnikov" <horiz0n(a)gmx.net> Cc: <discuss-gnuradio(a)gnu.org>, <osmocom-sdr(a)lists.osmocom.org> Subject: [Discuss-gnuradio] FCD/Alsa bug (Re: Bug hunting) Date: Wed, Aug 8, 2012 9:02 am Cross posting to discuss-gnuradio. The bug in question is that if you instanciate an alsa source on a busy device (opened by another app), then the program crashed. On 08/08/12 00:23, Dimitri Stolnikov wrote: > Hi Christian, [...] > > The other problem (segfault on trow in ctor) still has to be addressed. Yes, I started to investigate, and it seems to me that this is not a gr-osmosdr bug, but it's a gnuradio one, caused by gr-fcd. This simple test program have the same problem, yet it only uses gr-fcd. #include <iostream> #include <fcd_source_c.h> int main(int argc, char **argv) { fcd_source_c_sptr fsrc; try { fsrc = fcd_make_source_c("hw:2"); // KO, from gr-fcd } catch (std::runtime_error &e) { std::cerr << "Error!\n"; } exit(0); } g++ test.cc -o test -I/usr/local/include/gnuradio -lgnuradio-fcd Here is the log: audio_alsa_source[hw:2]: Device or resource busy Error! *** glibc detected *** /home/cgagneraud/sdr/gr-osmosdr/test: free(): invalid pointer: 0x08052e3c *** [...] And here is a cleaned up backtrace: operator delete gruel::msg_accepter::~msg_accepter checked_delete<gr_hier_block2> boost::detail::sp_counted_impl_p<gr_hier_block2>::dispose [...] const, boost::shared_ptr<gr_basic_block> > > >::~map __cxa_finalize __do_global_dtors_aux [...] main The problem is related to gnuradio-core/src/lib/runtime/gr_sptr_magic.{h,cc} and the static std::map in there. gr_hier_block2 ctor insert "this" in this map, but then in fcd_source ctor, audio_alsa_source ctor throws an exception, so "this" (gr_hier_block2/fcd_source) is not a valid pointer anymore. When the program exits, the map get cleanup up and free is called on this pointer. It's not possible to cleanup the map in fcd_source, because the dtor is not called when exception occurs in the ctor (which, btw, leads to some memory leaks in alsa_source: namely d_hw_params and d_sw_params). It's a bad idea to call fetch_initial_sptr(this) before throwing in the ctor, because it seems the object get deleted.

11 years, 9 months

1
0
0 0

just learning to fly with sdr ... and hit a 64-bit snag

by Gary Lawrence Murphy

First off, this is my first post to the group and I want to thank everyone who has worked to get this kit as far as it is; I was deathly worried that I might be stuck with unusable hardware, and it is still unusuable, but there seems to be light at the end of the SDR tunnel and I'm hoping this is the right forum for asking newbie questions :) Here's where I am so far: I have the Hama Nano DVB-T+DAB+FM with the Elonics E4000 tuner and my goal is really very modest (I hope) in that I only want to tune in one ordinary analog FM station, the FM transmitter in the next room that supplies our house with music from our MP3 collection. Rather than pay $40 at walmart for a radio for my lab, I thought I'd spend $20 on the USB device and have some fun in the process. And it's been fun: I found the recipe for the rtl_fm using the alsa aplay, and I assume the examples were concerned with some other sort of radio (shortwave?) because the recommended 48k sampling sounded like a taxi radio! Not really Easy Listening sort of audio. with some experimenting I found a formula that is still heavily distorted, but recognizable as music: rtl_fm -f 96.3e6 -s 192000 -l 5 -| aplay -t raw -f s16_le -r 192k -c 1 the trouble was that it wouldn't play continuously on my 3300-bogomips netbook, so I moved the code over to my 64-bit dual-core laptop and that's where a strange thing happened: when run as a regular user, the code aborts giving strange (unicode?) gibberish as the device name, but when run as root, the name is correctly reported although the program aborts. ~/Work/dev$ rtl_fm -f 96.3k -s 192000 - | aplay -t raw -r 192k -f s16_le Found 1 device(s): 0: , mX��, SN: ��z� Using device 0: Generic RTL2832U (e.g. hama nano) usb_open error -3 Failed to open rtlsdr device #0. ~/Work/dev$ sudo rtl_fm -f 96.3k -s 192000 - | aplay -t raw -r 192k -f s16_le Found 1 device(s): 0: Generic, RTL2832U, SN: 77771111153705700 Using device 0: Generic RTL2832U (e.g. hama nano) usb_claim_interface error -6 Failed to open rtlsdr device #0. on the 32-bit platform, the *Using device* line is followed by Found Elonics E4000 tuner Oversampling input by: 6x Oversampling output by: 1x is there perhaps some simple config setting that I've overlooked in the 64-bit box? Both are running Ubuntu 12.04 here are the kernel messages on loading the device on 64bit Aug 9 13:47:58 strata kernel: [200306.632008] usb 3-1: new high-speed USB device number 3 using xhci_hcd Aug 9 13:47:58 strata kernel: [200306.663830] usb 3-1: ep 0x81 - rounding interval to 32768 microframes, ep desc says 0 microframes Aug 9 13:47:58 strata kernel: [200306.669822] dvb-usb: found a 'RTL2832U DVB-T USB DEVICE' in warm state. Aug 9 13:47:58 strata kernel: [200306.669840] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Aug 9 13:47:58 strata kernel: [200306.671500] DVB: registering new adapter (RTL2832U DVB-T USB DEVICE) Aug 9 13:47:58 strata kernel: [200306.689815] RTL2832U usb_init_bulk_setting : USB2.0 HIGH SPEED (480Mb/s) Aug 9 13:47:58 strata mtp-probe: checking bus 3, device 3: "/sys/devices/pci0000:00/0000:00:1c.3/0000:09:00.0/usb3/3-1" Aug 9 13:47:59 strata kernel: [200306.972506] RTL2832U check_tuner_type : E4000 tuner on board... Aug 9 13:47:59 strata mtp-probe: bus: 3, device: 3 was not an MTP device Aug 9 13:47:59 strata kernel: [200307.552737] DVB: registering adapter 0 frontend 0 (Realtek DVB-T RTL2832)... Aug 9 13:47:59 strata kernel: [200307.553116] input: IR-receiver inside an USB DVB receiver as /devices/pci0000:00/0000:00:1c.3/0000:09:00.0/usb3/3-1/input/input15 Aug 9 13:47:59 strata kernel: [200307.553243] dvb-usb: schedule remote query interval to 287 msecs. Aug 9 13:47:59 strata kernel: [200307.553251] dvb-usb: RTL2832U DVB-T USB DEVICE successfully initialized and connected. I notice that it DOESN'T say "*will pass the complete MPEG2 transport stream to the software demuxer"* as it does on the 32bit side. Also, what is the syntax for the -g switch? I have tried integers, decimals and the string -3dB and in all cases I get the message *Warning: Failed to set tuner gain* -- could the gain control simply be unsupported by my device? Lastly, I'd like to ask the hard question: are my goals here feasible? Is this an appropriate device for listening to FM broadcasts at the computer or is this more a hobbyist's SDR playground and, like a dancing bear, the bear doesn't dance amazingling, it is only amazing that the bear dances at all ;) -- *Have Blog, Will Travel: blog.teledyn.com* *A Serviceable Substitute: post.teledyn.com*

11 years, 9 months

2
2
0 0

Bug hunting

by Christian Gagneraud

Hi, Is there any bug tracker for the gr-osmosdr somewhere? It would be nice if the "audio_alsa_source[hw:X]: Device or resource busy" could be fixed. The problem with that bug is you can't even interogate the device driver for supported gain, etc... If the device is used by another application. For example, I have permanently 2 devices plugged in, I use an FCD to send AIS data to aishub.com, and a RTL to experiment with. The problem with this bug is that if you use python you can't even catch the exception, it simply crash the script. I think that the behaviour is different when using C++. Another "bug" I discovered is that if you just do a device scan to print available device and exit the python script, it will generate plenty of error messages like "libusb:warning [cancel_bulk_transfer] unrecognised discard errno 9", the workaround is to simply wait a bit before exiting. It seems that some USB packets are still pending after calling osmosdr.source_c(). Chris -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/

11 years, 9 months

4
11
0 0

[PATCH] [rtl-sdr] Relaxed async state machine

by chris＠techworks.ie

From: Christian Gagneraud <chris(a)techworks.ie> gr-osmosdr uses the driver in a multi-thread context, as a side effect the cancel_async() can be called before read_async(), in such a case the cancel is "forgotten". This patch fixed that by being a bit more relaxed with state machine transitions. This patch doesn't fix any race conditions, it just make an anoying one less likely to happen. This patch goes along this one [1] [1] http://lists.osmocom.org/pipermail/osmocom-sdr/2012-August/000201.html Signed-off-by: Christian Gagneraud <chris(a)techworks.ie> --- src/librtlsdr.c | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/src/librtlsdr.c b/src/librtlsdr.c index 4e54d8e..d83010d 100644 --- a/src/librtlsdr.c +++ b/src/librtlsdr.c @@ -1256,6 +1256,12 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, if (!dev) return -1; + /* It can happen if cancel_async is called before read_async */ + if (dev->async_status != RTLSDR_INACTIVE) + return -1; + + dev->async_status = RTLSDR_RUNNING; + dev->cb = cb; dev->cb_ctx = ctx; @@ -1284,8 +1290,6 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx, libusb_submit_transfer(dev->xfer[i]); } - dev->async_status = RTLSDR_RUNNING; - while (RTLSDR_INACTIVE != dev->async_status) { r = libusb_handle_events_timeout(dev->ctx, &tv); if (r < 0) { @@ -1326,7 +1330,7 @@ int rtlsdr_cancel_async(rtlsdr_dev_t *dev) if (!dev) return -1; - if (RTLSDR_RUNNING == dev->async_status) { + if (RTLSDR_CANCELING != dev->async_status) { dev->async_status = RTLSDR_CANCELING; return 0; } -- 1.7.7

11 years, 9 months

1
0
0 0

[PATCH] Wait in the destructor for all I/O to finish without a timeout

by Peter Stuge

Signed-off-by: Peter Stuge <peter(a)stuge.se> --- lib/rtl/rtl_source_c.cc | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/rtl/rtl_source_c.cc b/lib/rtl/rtl_source_c.cc index 8839a2f..c8cc772 100644 --- a/lib/rtl/rtl_source_c.cc +++ b/lib/rtl/rtl_source_c.cc @@ -180,7 +180,7 @@ rtl_source_c::~rtl_source_c () if (_dev) { _running = false; rtlsdr_cancel_async( _dev ); - _thread.timed_join( boost::posix_time::milliseconds(200) ); + _thread.join(); rtlsdr_close( _dev ); _dev = NULL; } -- 1.7.4.1.343.ga91df.dirty --YZ5djTAD1cGYuMQK--

11 years, 9 months

1
0
0 0

gr-ais with osmosdr

by Christian Gagneraud

Hi there, I saw a message in the July archive (I wasn't subscribed yet at that date) about updating gr-ais with osmosdr support. I was working on the same thing recently, so i decided to publish my fixes on top of Antoine's one. The result can be found here: https://github.com/chgans/gr-ais I got it working with both an FCD and an RTL: ais_rx.py --rate 96e3 --gain 30 --error -17 -d -D fcd=0 ais_rx.py --rate 1024e3 --gain 30 --error -110 -d -D rtl=0 Strangely passing freq_err=XX parameter to the source (using -D), doesn't work, the use of --error is thus needed (which will do a set_freq_corr()). Antoine, if you want sample file, just let me know. Nick, are you willing to integrate these changing back in gr-ais, Apart from the added automatic decimation filter, the changes are not intrusive at all. The default settings for UHD are 256Khz sampling with decimation filter 4, with this change, the decimation is one when using FCD (96KHz fixed frequency) and 16 for RTL when used at 1.024MHz (this was the minimum working frequency for me). Or maybe would you prefer to allow the user to set it manually, and use this technique as a fall back only. Please let me know what you guys think. Thx, Chris -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/

11 years, 9 months

4
10
0 0

Wiki page

by Christian Gagneraud

Hi, I started do add documentation to the wiki page of gr-osmosdr [1]. For now i've just added documentation about the "constructor" parameters. Any feedback welcome. [1] http://sdr.osmocom.org/trac/wiki/GrOsmoSDR PS: Could anyone tell me what the mcr is? (used for osmosdr source) -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/

11 years, 9 months

2
2
0 0

[PATCH] Add swig hint for devices_t objects

by chris＠techworks.ie

From: Christian Gagneraud <chris(a)techworks.ie> Signed-off-by: Christian Gagneraud <chris(a)techworks.ie> --- swig/osmosdr_swig.i | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/swig/osmosdr_swig.i b/swig/osmosdr_swig.i index afdbb0e..4205fd6 100644 --- a/swig/osmosdr_swig.i +++ b/swig/osmosdr_swig.i @@ -25,6 +25,7 @@ %ignore osmosdr::device_t::operator[]; //ignore warnings about %extend %template(string_string_dict_t) std::map<std::string, std::string>; //define before device +%template(devices_t)std::vector<osmosdr::device_t>; %include <osmosdr_device.h> %template(range_vector_t) std::vector<osmosdr::range_t>; //define before range -- 1.7.7

11 years, 9 months

1
0
0 0

Iterating over gain ranges with python

by Christian Gagneraud

Hi there, In a python script, I would like to iterate over things like get_gain_names, get_gain_ranges, ... The problem is that these functions return a std::vector<std::string> *. The error i get is: TypeError: 'SwigPyObject' object is not iterable It would be very nice to be able to do something like: for src.get_sample_rates(): # do something for name in get_gain_names(): # do smth I found this: http://reference-man.com/files/generators.i But i haven't been able to use it so far. :( Any help or comments appreciated. Chris -- Christian Gagneraud, Embedded systems engineer. Techworks Marine 1 Harbour road Dun Laoghaire Co. Dublin Ireland Tel: + 353 (0) 1 236 5990 Web: http://www.techworks.ie/

11 years, 9 months

2
2
0 0

gr-ais for rtl-sdr

by Antoine Sirinelli

Hi, I have tried to modify the AIS decoding implementation from Nick Foster (https://cgran.org/wiki/AIS) in order to be able to use an rtl dongle as a source. Unfortunately I am not living by the sea and I cannot test it before a couple of week. Is there anybody able to receive AIS messages willing to test my changes? You can find it on github: https://github.com/asirinelli/gr-ais The 2 main assumptions I made are: - Nick first implementation is working - rtl-sdr is able to have a sample rate of 256 kHz. Many thanks, Antoine

11 years, 9 months

2
1
0 0

RTL2832U FIR filter

by Michael Karcher

Hello people, in some experiments with my RTL2832 stick, I managed to find out how the FIR filter works. The FIR filter is running at the XTAL frequency (typically 28.8MHz). In the SDR mode, the filter is a symmetric FIR filter with 32 real-number-valued taps. Using the symmetry, only 16 coefficients need to be specified. The coefficients are stored in the 20 bytes written to the FIR register. The first coefficient describes the outermost tap, the last one the tap 0.5 taps away from the symmetry axis. The first 8 values are 8-bit numbers, the second 8 values are 12 bit numbers, resulting in 64 + 96 = 160 bits (20 bytes). The first 8 bytes written to the chip are the first 8 coefficients. The 12-bit coefficients are stored like this pairwise in three bytes: In the byte sequence "12 34 56", the first coefficient is 0x123 and the second coefficient is 0x456. Both the 8-bit and the 12-bit numbers are to be interpreted as two's complement signed numbers (thus the 8-bit coefficients range from -128 to +127, while the 12-bit coefficients range from -2048 to +2047). The resolution of all 16 coefficients is the same. I furthermore found out that this is not the only filtering going on in the RTL2832 chip in SDR mode. There seems to be a second anti-aliasing filter before the DAC, making signals disappear that are at frequencies above 0.7 times the sample rate (in the baseband), even if the programmable FIR filter lets them pass. As an example, I provide the decoded default coefficients: -54 -36 -41 -40 -32 -14 14 53 101 156 215 273 327 372 404 421 421 404 372 327 273 215 156 101 53 14 -14 -32 -40 -41 -36 -54 This filter has a quite flat passband in the interesting range for DAB (-768kHz..+768kHz) but by far not enough attenuation at 1280kHz (which will alias to 768kHz at a sampling rate of 2048kHz) to get satisfactory adjacent channel rejection. The experimentally observed alias rejection is good enough, which lead to the conclusion that there is another low-pass filter, which might be part of the resampling unit. Regards, Michael Karcher

11 years, 10 months

4
7
0 0

RTL2832U FIR filter

by Michael Karcher

Hello people, in some experiments with my RTL2832 stick, I managed to find out how the FIR filter works. The FIR filter is running at the XTAL frequency (typically 28.8MHz). In the SDR mode, the filter is a symmetric FIR filter with 32 real-number-valued taps. Using the symmetry, only 16 coefficients need to be specified. The coefficients are stored in the 20 bytes written to the FIR register. The first coefficient describes the outermost tap, the last one the tap 0.5 taps away from the symmetry axis. The first 8 values are 8-bit numbers, the second 8 values are 12 bit numbers, resulting in 64 + 96 = 160 bits (20 bytes). The first 8 bytes written to the chip are the first 8 coefficients. The 12-bit coefficients are stored like this pairwise in three bytes: In the byte sequence "12 34 56", the first coefficient is 0x123 and the second coefficient is 0x456. Both the 8-bit and the 12-bit numbers are to be interpreted as two's complement signed numbers (thus the 8-bit coefficients range from -128 to +127, while the 12-bit coefficients range from -2048 to +2047). The resolution of all 16 coefficients is the same. I furthermore found out that this is not the only filtering going on in the RTL2832 chip in SDR mode. There seems to be a second anti-aliasing filter before the DAC, making signals disappear that are at frequencies above 0.7 times the sample rate (in the baseband), even if the programmable FIR filter lets them pass. As an example, I provide the decoded default coefficients: -54 -36 -41 -40 -32 -14 14 53 101 156 215 273 327 372 404 421 421 404 372 327 273 215 156 101 53 14 -14 -32 -40 -41 -36 -54 This filter has a quite flat passband in the interesting range for DAB (-768kHz..+768kHz) but by far not enough attenuation at 1280kHz (which will alias to 768kHz at a sampling rate of 2048kHz) to get satisfactory adjacent channel rejection. The experimentally observed alias rejection is good enough, which lead to the conclusion that there is another low-pass filter, which might be part of the resampling unit. BTW: the 900kHz low sample rate limit seems to be valid for a 36MHz XTAL, not the common 28.8MHz XTAL. Regards, Michael Karcher

11 years, 10 months

2
1
0 0

OsmoSDR Hardware Design Questions

by Sandor Szilvasi

Hi OsmoCom, I was going to start a home project *very similar* to yours, when I bumped into the OsmoSDR. So, I'd like to ask a few questions regarding the OsmoSDR hardware. 1. Based on the photo<http://sdr.osmocom.org/trac/chrome/common/download.png>your fab could handle BGA packages. Why didn't you use the BGA packaged Atmel SAM3U MCU instead of the LQFP one? 2. The Lattice LatticeXP2 FPGA is available in the same package but in larger size at almost identical price. Why did you pick the smallest available FPGA, the LFXP-5E ($16) instead of the LFXP-8E ($20)? 3. You are using the SAM3U SSC to transfer data from the FPGA. Before seeing your design I had the idea to use the EBI to interface with the FPGA. After all, the EBI is on the AHB and I assume you have a bunch of FPGA I/Os left. What do you think the drawbacks of using the EBI would be? 4. The differential clock output oscillator was connected in a weird way, but I can see that it has been corrected in Rev 2. 5. My understanding is that you configure the FPGA using the JTAG lines in bit-bang mode through SAM3U GPIOs. Why don't you use the sysConfig port of the Lattice FPGA? It's faster, easier to implement with the SAM3U SPI peripheral (and it's also a feature I haven't seen with other FPGAs). See Lattice TN1141 <http://www.latticesemi.com/documents/TN1141.pdf>. 6. The board seems to be powered from the USB only, but the oscillator already draws ~100mA and it's always enabled. Adding the consumption of the MCU and the FPGA you are already above 100mA. If it's really powered only from the USB, how is it ensured that you stay below the 100mA limit specified by the USB standard until you ask for a higher current, say 500mA? I hope you didn't mind my questions above, I didn't mean to be nosy. I just got a little excited about this project. Cheers, Sandor

11 years, 10 months

3
3
0 0

RTLSDR Philosophy.

by Leif Asbrink

Hi All, A device with limited dynamic range like the RTL2832/E4000 dongle needs a carefully designed gain control to allow the user to move the dynamic range up or down to fit the current RF environment. The latest version has the required gain controls, but to write an application that optimizes the performance one has to know the dongle. I would like to use the standard library for Linrad. The purpose would be to get support for other tuners than the E4000 that are available today or that that may become available in the future. There is rtlsdr_get_tuner_gains that returns the lna gain in the case of e4000. The gain values it returns for the other tuners has a small range which means that somehow (AGC or manual) one can set a much wider gain range. In the case of E4000 there is IF gain and mixer gain. I can not find those in the other tuners even though they have to be present in the hardware - but maybe only in the form of AGC. The application program needs to have: get_mixer_gains() get_no_of_if_gain_controls() get_if_gains(no) Or something equivalent to run the E4000. To me this does not look right. Having each gain block as a separate object for the application program to figure out how to handle means that the application programmer needs to know the details of each tuner that might become available. I think a much better approach would be to see the entire tuner chip as an object. That would imply that the "set tuner gain" would use all the gain controls inside the tuner chip in the proper order. In the case of the E4000 tuner it would be like this: Max gain: lna gain set to max. IF and mixer gain set to levels that produce 6 to 10 dB above minimum noise at the RTL2832 input. Reduced gain 1 to 10 dB: The lna should be left at max gain while mixer and/or IF gain is reduced. Further reduced gain: Reduce lna gain. The contribution from IF and mixer is already negligible. Even lower gain: When lna is at minimum we can still reduce IF gain. The strategy would allow the application program to ask for the gain range. Whether the gain setting would accept any value and set the closest possible or whether it would require the user to query what gain levels the system allows is a matter of convenience. The fundamental problem is whether the application program needs to know the internals of every supported chip. A peace of hardware like the RTL2832/E4000 dongle needs a gain control that spans at least 40 dB. The other tuners need the same but in case itis only available as AGC they are not suitable for SDR. At the moment Linrad works well with the E4000, but I do not think it would work with other tuners. I will wait for progress on the librtlsdr library. Hopefully it will be clear how an application program can set the system gain over a range of at least 40 dB without knowledge of the internaldś of the tuners. 73 Leif / SM5BSZ

11 years, 10 months

2
1
0 0

stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ?

by friedtj

I am trying to implement equivalent time sampling using an EZCAP dongle configured using gnuradio-companion. Since I am not completely clear about the tasks of the E4000 wrt RTL2832, it could be that I am missing a significant information, so here is my experimental setup aimed at developing a monostatic pulse mode RADAR : * I am using a radiofrequency acoustic delay line to generate 4 echos delayed 1 to 2 microseconds after an incoming excitation pulse is generated by a frequency synthesizer. The excitation pulse is 125 ns long, and repetition rate is 4 microseconds. The carrier frequency at 860 MHz is chopped by a fast duplexer, one side being connected to the frequency synthesizer and the other sizer to the EZCAP dongle * the EZCAP is configured with an LO at 860 MHz, 2 MS/s output, and I plot |I+jQ| after keeping only 1 every 8 sample (2 MS/s=500 ns delay between samples, and 1 every 8 samples means a spacing of 4 us, close to the emitted pulse repetition rate) * equivalent time sampling is obtained by slightly tuning the emitted pule repetition rate off the 4 us: I have checked that I can indeed obtain time stretching by tuning the pulse repetition rate +/- 50 ns away from the 4 us dela, with time stretching factors of up to 10^5 (ie the 4 us pulses are recorded as 400 ms traces (thus including 10^5 points or an equivalent sampling rate of 25 GS/s). Now of course a stretching factor of 10^5 is overkill and the RF front end definitely does not have such a huge bandwidth, this is just to demonstrate the concept. With a more reasonable stretching factor of 10 (ie sampling every 4.4 us with a 4 us emission pulse repetition rate), I can expect to convert a 2 MS/s sampling rate to an equivalent time sampling of 20 MS/s, which would already improve my monostatic RADAR resolution by a factor 10, and more or less fit my targetted resolution. So now the questions: * the 125 ns pulse I generate would span 8 MHz. From my reading of the E4k description, this is within the IF bandwidth available. However, although I can observe the emitted pulse (0 dBm), I cannot see the echos (-35 to -40 dBm), whatever LNA gain I use (from 0 to 40 dB). Is the default configuration of the E4k an IF of 8 MHz, or lower. What parameter should I give the rtlsdr gnuradio source block to make sure I have the right bandwidth ? * since I am not clear about task distribution between the E4k and the RTL2832, is there another limitation that will prevent a 8 MHz wide (bandwidth) signal to be recorded through the 2 MS/s I/Q output recorded ? Thank you, Jean-Michel -- JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 32 av. observatoire, 25044 Besancon, France

11 years, 10 months

6
11
0 0

Disabling RTL2832 AGC

by Francesco Gugliuzza

A couple of days ago I posted on Reddit a small modification to librtlsdr.c to disable the RTL2832 AGC and internal amplifiers (link to post: http://www.reddit.com/r/RTLSDR/comments/vunuy/experiments_with_agc/c57sbpx the correct part is after the EDIT). Add the following lines of code: /* disable RF and IF AGC */ uint16_t tmp; tmp = rtlsdr_demod_read_reg(dev, 1, 0x04, 1); tmp &= ~0xc0; rtlsdr_demod_write_reg(dev, 1, 0x04, tmp, 1); /* disable AGC PGA */ rtlsdr_demod_write_reg(dev, 1, 0xd7, 0x00, 1); /* disable GI PGA */ rtlsdr_demod_write_reg(dev, 1, 0xe5, 0x00, 1); just after: /* disable AGC (en_dagc, bit 0) */ rtlsdr_demod_write_reg(dev, 1, 0x11, 0x00, 1); Since I don't have adequate tools to test the results, could you please test it, and if it does work, add the patch to your repository? Thank you! -- Francesco Gugliuzza HackLabProject.org Administrator Linux user #374630 Tel (VoIP geographic number): +39 0921440446 Tel (Libera il VoIP number): 5125320 E-mail: f.gugliuzza(a)hacklabproject.org

11 years, 10 months

4
7
0 0

cleanup patch

by Stefan Sydow

Here are two patches. First one just removes old code and adds some comments. It also adds a FLO check from gr-baz [1] The second patch adds return value checks to i2c read/write operations. I haven't done it yet for the whole e4k driver, but will fix that if you think, this is a good idea. By now many i2c reads/writes aren't checked - I don't like that so I started catching it with assert. Thats not optimal but a least you notice when it fails. A device reset would be the best solution, but I'm not sure if we can do that form userspace. [1] https://github.com/balint256/gr-baz/blob/master/lib/rtl2832-tuner_e4k.cc (l. 1036)

11 years, 10 months

1
0
0 0

rtl-sdr web git interface not updating

by Francesco Gugliuzza

The git web interface at http://cgit.osmocom.org/cgit/rtl-sdr/ is not reporting new changes after commit e5afd9894d730dd012ad6b73e6e56cf99e6266a2 (2012-06-08), and it's reporting wrong commit ages. Could it be fixed? Thanks. -- Francesco Gugliuzza HackLabProject.org Administrator Linux user #374630 Tel (VoIP geographic number): +39 0921440446 Tel (Libera il VoIP number): 5125320 E-mail: f.gugliuzza(a)hacklabproject.org

11 years, 10 months

2
2
0 0

Linrad with rtlsdr with and the e4000 tuner.

by Leif Asbrink

Hello, This mail is sent to all the E-mail addresses I have found in the source code of tuner_e4k.c and librtlsdr.c I have made a couple of modifications to the software and I now want to ask whether you can make changes to the standard package that you supply so Linrad users will not have to download modified files from my site to get proper operation of Linrad in the future. The most important modification is the gain setting. The tuner code requires knowledge of the gain table or searcing for legal gain values by use of the returned error code. I think that this is impractical and I changed it so the routine will now always set the nearest possible gain value and return it to the caller. The routine e4k_set_enh_gain(...) does not affect the gain of my hardware so I allow the gain setting function to use it with always the same value because I have no idea what this function is intended to do.... The default IF gain is too high. I reduced it by 6dB for a 6 dB better dynamic range. With the tuner_e4k.c currently incorporated in Linrad there is an AGC action that degrades the dynamic range by about 10 dB. I do not know anything about the e4000 internals but in case this remaining AGC can be disabled and the gain set 10 dB lower in the particular gain step controlled by the AGC, the dynamic range would improve from 66 dB to 76 dB with respect to the usual MDS (noise in 500 Hz bandwidth.) That means going from outside the scale in the QST "Key Measurements Summary" in their product testing to a mediocre result 6 dB above the limit of the range they have for SSB radios. The rtlsdr would be superior to hand held units like TH-D72A or VX-8GR in adjacent channel rejection (QST July 2011 and September 2011) if the AGC could be disabled. The details are here: http://www.sm5bsz.com/linuxdsp/hware/rtlsdr/rtlsdr.htm The Extio_RTLSDR.dll file provides 6 dB worse dynamic range because of the high IF gain setting. It also has a poor noise figure. -------------------------------------------------------------- To be able to use the callback in Linrad I have had to include various structures in the Linrad c code. I need to have this code in Linrad: i = libusb_handle_events_timeout(dev_rtlsdr->ctx, &tv1); Therefore I need the structure rtlsdr_dev which is not included in rtl-sdr.h. That structure requires other structures and it would be a good thing if those things as well as something like this: #define MAX_RTL2832_SAMP_RATE 3200000 #define MIN_RTL2832_SAMP_RATE 900001 were included in rtl-sdr.h I attach the Linrad interface routine to rtlsdr in case any of you are interested to see how I use the library. I realize the chip is far more clever and that I do not use it well. There is a substantial DC offset that seems to be possible to auto-remove. The AGC I want to get rid of might be something related to: /* disable auto mixer gain */ e4k_reg_set_mask(e4k, E4K_REG_AGC7, E4K_AGC7_MIX_GAIN_AUTO, 0); Hard to know without any documentation on the chip.... 73 Leif / SM5BSZ

11 years, 10 months

6
12
0 0

Super Efficient SMD Schottky Barrier from Comchip Technology Corporation

by Jay Salsburg

http://beta.globalspec.com/featuredProducts/detail?id=372 <http://beta.globalspec.com/featuredProducts/detail?id=372&campid=736&exhibi tId=209851&uid=%2D249525238&uh=e8a921&md=120628&mh=221961> &campid=736&exhibitId=209851&uid=%2D249525238&uh=e8a921&md=120628&mh=221961

11 years, 10 months

1
0
0 0

RTL direct sampling

by Adam Nielsen

Hi all, I've been watching with interest Steve's commits to the direct_sampling branch of the rtl-sdr repository. I haven't seen much mentioned about it though, so I'm just wondering whether anyone knows how it's progressing, and whether it's at the point yet where I should crack open one of these devices and try it out? Thanks, Adam.

11 years, 10 months

1
0
0 0

Caputed RTL-SDR file for playing around?

by Johannes Bauer

Hi list, I've stumbled upon the rtl-sdr and am quite excited. Have already ordered a dongle, but it is going to take a while until it arrives. Since I'd like to play around with it already, is there a capture file available somewhere for download to test out the functionality (working with GnuRadio etc)? I.e. someone with a dongle doing ./rtl_sdr /tmp/capture.bin -s 1.8e6 -f 392e6 (or whatever frequency there is something audible on, preferrably something that can easily be identified like FM radio) and publishing the capture.bin file? This might also be of interest to people who consider to play around with SDR, but do not know if they should buy a dongle. Would be very cool if there was something available or somebody on the list could provide one. Best regards, Joe

11 years, 11 months

2
2
0 0

v2 Prototype issues and fixes

by Sylvain Munaut

Hi, The v2 prototype I still had a couple of issues so I'll describe them here and the corresponding fixes: - Bad TVS Diode: There is a diode that's supposed to protect against ESD near the antenna connector. Turns out that the component supplier swapped reels IIRC and so that's not a TVS diode that was mounted. My board had the rework to fix this already done. I don't know if any board shipped with the wrong part. It's the small ~ 0603 sized component near the antenna connector and it's supposed to be greenish. The result of this is a ~ 10-15 dB attenuation of the input signal. - Missing LNA bias inductor: The v2 has a LNA at the input but it's missing it's bias inductor which means it's powered off. So instead of boosting the signal by 18 dB, it actually attenuates it quite a lot. Solution is simple: Solder a 0603 bias inductor. Schematics call for a 470nH inductor and make sure to choose a good RF rated one and not random junk. - FPGA 1.2V LDO Oscillation: The output capacitor of the LP3965 regulator generating the 1.2V for the FPGA core has too low an ESR (a ceramic cap is mounted). This regulator needs a capacitor with an ESR greater than 0.5 ohm and lower than 5 ohm for it to be stable. Without this, the LDO is unstable and has high spectral content at 55 kHz and harmonics. This noise is present at the output but also leaks to the input voltage of the LDO which is the 3.3V rail that powers the LNA ... This is causing unwanted images of the signal at f +- 55kHz f+- 110 kHz ... The solution is simple: replace the cap by a tantalum one within the right ESR range. ( I used a TR3A106K016C1700 from Farnell ). This is before the fix: http://i.imgur.com/rRDDQ.png and this is after : http://i.imgur.com/VlOW7.png - Impedance mismatch between E4K output and ADC input: Ideally we'd like to imagine that the E4K IQ output have very low impedance and that the ADC input have very high impedance. Turns out that neither is true: The E4K has a ~ 500 ohm output impedance and the ADC is a track and hold type and the capacitance of the input changes when you start sampling, causing a small current flow. The combination of the 2 creates a noise at the sampling frequency on the IQ lines ... The effect of this is currently unknown and is being investigated ... it might be possible to lower the noise floor a bit and get less DC offset with this. But it certainly doesn't have as much impact as the 3 erratas above for sure. See for components location. http://i.imgur.com/M4Lvt.jpg Cheers, Sylvain

11 years, 11 months

1
0
0 0

Tuning gap between 325 and 350 MHz

by Kire Pudsje

Also posted on reddit: I measured another stick and this time I also noticed the gap between 325 and 350 MHz, as was reported earlier by Roger on reddit. http://www.reddit.com/r/RTLSDR/comments/tftz4/some_frequency_response_measu… I could trace it back to the fact that the E4K_REG_SYNTH is not set properly. I do not know why yet, but first setting a different value from the desired one seems to fix the problem. It might be the wrong solution for the wrong problem, but it seems to work for me. change this line in tuner_e4k.c:448 rc = e4k_reg_set_mask(e4k, E4K_REG_SYNTH1, 0x06, band << 1); to: uint8_t tmp = e4k_reg_read(e4k, E4K_REG_SYNTH1) & ~0x06; tmp |= (band << 1) & 0x06; e4k_reg_write(e4k, E4K_REG_SYNTH1, tmp ^ 0x06); rc = e4k_reg_write(e4k, E4K_REG_SYNTH1, tmp); Kire.

11 years, 11 months

1
0
0 0

Building with autotools - missing -lpthreads

by Joschi Brauchle

Hello all, when trying to build with autotools, I get an compile error stating that there is a: ---- undefined reference to symbol 'pthread_create@@GLIBC_2.2.5' ---- This seems to be due to "-lpthreads" is missing when using autotools1 -- Dipl.-Ing. Joschi Brauchle, M.Sc. Institute for Communications Engineering (LNT) Technische Universitaet Muenchen (TUM) 80290 Munich, Germany Tel (work): +49 89 289-23474 Fax (work): +49 89 289-23490 E-mail: joschi.brauchle(a)tum.de Web: http://www.lnt.ei.tum.de/

11 years, 11 months

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr