Last updated: 2017-12-11 - Rafael Micro announcement: R820T2 Discontinued

RTL-SDR and GNU Radio with Realtek RTL2832U [Elonics E4000/Raphael Micro R820T] software defined radio receivers.


Originally meant for television reception and streaming the discovery and exploitation of the separate raw mode used in FM reception was perhaps first noticed by Eric Fry in March of 2010 and then expanded upon by Antti Palosaari in Feb 2012 who found that these devices can output unsigned 8bit I/Q samples at high rates. Or not. Who knows? A lot of people other people have helped build it up from there.

rtlsdr as we know it today was created by the osmocom people in the form of rtl-sdr and osmoSDR,

keenerd is the author of many other rtl_* tools: rtl_fm, rtl_power (heatmap.py), rtl_adsb and code changes accepted into the mainline.

patchvonbraun is the author and maintainer of the build-gnuradio script that made it easy for me, and multitudes of others, to get started with rtlsdr under GNU Radio.

rtl-sdr.com has the latest news and tutorials. rtlsdr.org has a clear introduction too.

RF, DSP, and USB details

The dongles with an E4000 tuner can range between 54-2147 MHz (in my experience) with a gap over 1100-1250 MHz in general. The R820T and R820T2 go from 24-1760 MHz (but with reduced performance above 1500 MHz). The R820T dongles use a 3.57 MHz or 4.57 MHz intermediate frequency (IF) while the E4000s use a Zero-IF. For both kinds the tuner error is ~30 +-20 PPM, relatively stable once warmed up, and stable from day to day for a given dongle. All of the antenna inputs are 75 Ohm impedance. The RTL2832 ADC differential input impedance is ~3,300 Ohm. The dynamic range for most dongles is around 45 dB. The sensitivity is somewhere around -110 dBm typically. The highest safe sample rate is 2.56 MS/s but in some situations up to 3.2 MS/s works without USB dropping samples (RTL2832U drops them internally). Because the devices use complex sampling (I/Q) the sample rate is equal to the bandwidth instead of just half of it. For the data transfer mode USB 2 is required, 1.1 won't work. Antti Palosaari's measurements show the R820T use ~300mA of 5v USB power while the E4000 devices use only ~170mA. You can cut the leads to the LED to drop usage ~10%.

The rtlsdr RTL2832U chips use a phased locked loop based synthesizer to produce the local oscillator required by the quadrature mixer. The quadrature mixer produces a complex-baseband output where the signal spans from -bandwidth/2 to +bandwidth/2 and bandwidth is the analog bandwidth of the mixer output stages. (Datasheets, general ref: Quadrature Signals: Complex, But Not Complicated by Richard Lyons) This is complex-sampled (I and Q) by the ADC. The Sigma-Delta ADC samples at some high rate but low precision. From this a 28.8 Msps stream at 8 bits is produced. That can be resampled inside the RTL2832U to present whatever sample rate is desired to the host PC. This resampled output can be up to 3.2 MS/s but 2.56 MS/s is the max recommended to avoid losing samples. The minimum resampled output is 0.5 MS/s. Check this reddit thread for caveats and details. The actual output is interleaved; so one byte I, then one byte Q with no header or metadata (timestamps). The samples themselves are unsigned and you subtract 127 from them to get their actual {-127,+127} value. You'll almost certainly notice a stable spike around DC. It's from either the 1/f noise of the electronics or if it's a Zero-IF tuner (E4000) the LO beating with itself in the mixer.

Popular software

My favorite way to explore the spectrum is using rtl_power to do very wideband multi-day surveys. For general use SDR# is probably the best application for windows with secondary mono-based linux and Mac support. I normally use Gqrx but it requires GNU Radio dependencies. Luckily there are Linux and OS X native binaries packages with all dependencies (ie, gnuradio) these days. For doing diagnostic and low signal level work Linrad is full featured and fast. osmocom_fft comes with GNU Radio module gr-osmosdr and is the natural and best way to use gr-fosphor; a GPU accelerated display. multimode has a very full and configurable GUI (it works great with GPU accelerated displays like gr-fosphor). For command line and low power devices try keenerd's rtl_fm.

These sites maintain the best list of rtlsdr device supporting applications: https://sdr.osmocom.org/trac/wiki/rtl-sdr#KnownApps, https://sdr.osmocom.org/trac/wiki/GrOsmoSDR#KnownApps, and lately http://www.rtl-sdr.com/big-list-rtl-sdr-supported-software/

Assuming you're on linux, but applicable in general, do not use the OS DVB drivers. Those are for the DVB-T mode and not the debug mode that outputs raw samples. Linux 3.x kernel should check with "$ lsmod | grep dvb_usb_rtl28xxu" and if found at least "$ sudo modprobe -r dvb_usb_rtl28xxu" to unload it.

While the sampling bandwidth is only 2.56 MHz the frequency can be re-tuned up to ~40 times a second. With frequency hopping you can survey very large bandwidths. See tholin's annotated 24 hour rtl_power spectrogram. Below is a zoomable 37200*31008 pixel 5 day long spectrogram I made using rtl_power's FFT mode and heatmap.py. It starts very far zoomed out. It might load a bit slow too. (view full window)


This page is mostly just notes to myself on how to use rtlsdr's core applications, 3rd party stuff using librtlsdr and wrappers for it, and lots on using the gr-osmosdr source in GNU Radio and GNU Radio Companion. This isn't a "blog", don't read it sequentially, just search for terms of interest or use the topics menu. For realtime support on the same topics try Freenode IRC's ##rtlsdr and reddit's r/rtlsdr.


These days for most people doing most things you want to get an dongle with an R820T2 tuner. They'll come with MCX coaxial connectors. On sites like eBay shipping from China the average price is about ~$10 shipped. These work fine for most things. At a bit higher price of ~$20 some come with improvements like SMA or F connectors, metal cases and heatsinks on the tuner for stability above 1500 MHz, temperature controlled crystal oscillators, extra breakouts on the PCB, and the like.

I bought two E4000 based rtlsdr usb dongles for $20 each in early 2012. Then many months later I bought two more R820T tuner based dongles for ~$11 each. There's photos of the E4ks up at the top of the page and of an R820T based dongle in the "mini" format off to the left (most minis do not have eeproms for device ID). It and the Newsky E4k dongle up top are MCX. Back in 2012 some of the cheaper dongles occasionally miss protection diodes but that is no longer an issue. The antenna connector on the E4k ezcap up top is IEC-169-2, Belling-Lee. I usually replace it with an F-connector or use a PAL Male to F-Connector Female. F to MCX for the other style dongles. The default design has the tuner taking 75 Ohm so that's what they all are except SMA.

Tuners

RTL-SDR Tuner Type	Frequency Range

Elonics E4000 (E4K)	54 - 2200 MHz (1100 MHz-1250 MHz gap)
Rafael Micro R820T	24 - 1766 MHz (>1500 MHz is bad w/o tuner cooling)
Rafael Micro R820T2	24 - 1766 MHz (>1500 MHz is bad w/o tuner cooling)
Rafael Micro R820T2 	13 - 1864 MHz (mutability's driver)
Fitipower FC0013	22 - 1100 MHz (FC0013B/C, FC0013G has seperate L band input)
Fitipower FC0012	22 - 948 MHz
FCI FC2580		146 - 308 MHz and 438 - 924 MHz

Only three tuners are very desirable at this time. The Elonics E4000 and the Raphael Micro R820T/R820T2. In general they are of equal performance but the sticks with R820T2 chips are easy to find, cheaper (~$10 USD), and they have a smaller DC spike due to the use of a non-zero intermediate frequency but must have cooling for the tuner to PLL lock above ~1500 MHz or so. The E4K is better for high end (>1.7GHz) while the R820T can tune down to 13 MHz without any hardware mods (mutability's driver). The tuners themselves are set up and retuned with I2C commands. E4000 tuners used to re-tune twice as fast as R820T tuners, but this was fixed in keenerd's experimental branch where R820T actually tune a tiny bit faster than the E4Ks. These changes were later adopted by the main rtlsdr.

Re-tune speed

But that was the old days when rtlsdr sticks re-tuned relatively slowly. As time passed re-tuning speed has been increased by clean-ups in code and specifically keenerd's changes so the tuner doesn't wait nearly as long for the pll to settle. More recently tejeez's mod made the re-tuning even faster by updating all the changed registers for a re-tune in one r82xx_write I2C call. With this done you can re-tune at rates of up to 41(!) hops per second; a ~2x improvement over then-existing drivers. Since then all of these re-tuning changes have been incorporated into the main rtlsdr.

Further massive speed-ups can be had at the cost of pretty much all reliability. By not waiting for PLL lock at all and always leaving the i2c repeater register enabled tejeez reports retuning speeds of up to 300 jumps per second are possible.

Tuning range

As of Aug. 2014 a handful of people have found ways to extend the r820t frequency range as well. Initially thought to top out at 1700 MHZ the R820T driver has has re-written to tune from 22 to 1870(!) MHz. While efforts have been made to extend the lower range as well, with the PLL seeming to lock down to 8 MHz in some cases, this range turns out to be full of images and repeats of the higher frequency range. A later effort with the addition of driver tweaks to the RTL2832 downconverter pushed the low end down to ~15 MHz. The code is at https://github.com/mutability/rtl-sdr/.

After tejeez worked out the no-mod HF reception a couple people have noted that the tuners with fc0013 receive HF even better than the R820T board designs. So if you have one of those laying around you might want to try HF with it.

Gain settings

The E4K has settings for LNA (-5..+25dB), mixer (4 or 12dB) and total of 6 IF gain stages with various gains allowing for 1dB steps between 3 and 57dB. The software only deals with LNA and mixer gain and not independently. IF gain can be set through the API.

R820T also has LNA, mixer and IF gain settings - the exact steps are not known. The numbers in the library code are through measuring the gain at a fixed frequency. That gave 0..33dB for the LNA, 0..16dB for the mixer and -4.7..40.8dB for the IF gain. The current library does not expose these settings through an API, only LNA and mixer are set through some algorithm. IF gain is set to a fixed value.

bofh__ gives more detail about the R820T step size,

The mixer gain step is 1dB (matches the empirical data passably, but not great) and the IF/VGA gain step is 3.5dB (matches mine basically dead-on). LNA gain step is not mentioned, all it says is "1111 - max, 0000 - min"

Frequency error

All of the dongles have significant frequency offsets from reality that can be measured and corrected at runtime. My ezcap with E4000 tuner has a frequency offset of about ~44 Khz or ~57 PPM from reality as determined by checking against a local 751 Mhz LTE cell using LTE Cell Scanner. Here's a plot of frequency offsets in PPM over a week. The major component of variation in time is ambient temperature. With the R820T tuner dongle after correctly for I have has a ~ -17 Khz offset at GSM frequencies or -35 ppm absolute after applying a 50 ppm initial error correction. When using kalibrate for this the initial frequency error is often too large and the FCCH peak might be outside the sampled 200 KHz bandwidth. This requires passing an initial ppm error parameter (from LTE scanner) -e . Another tool for checking frequency corrections is keenerd's version of rtl_test which uses (I think) ntp and system clock to estimate it rather than cell phone basestation broadcasts.

Also very cool is the MIT Haystack people switching to rtlsdr dongles (pdf) for their SRT and VSRT telescope designs, Use of DVB-T RTL2832U dongle with Rafael R820T tuner (pdf). The first of these characterizes the drift of the R820T clock and gain over time as well as a calibration routine.

As of 2015 there are a number of SDR-enthusiast targeting dongles produced with temperature controlled oscillators (TXCO) that run at less than 1 PPM with no start-up drift.

R820T2 variant

I recently (06-15-2014) found out from prog (of SDR# and airspy) that there are actually two different versions of the R820T tuner. The normal one and the R820T2. The T2 has different intermediate frequency filters allowing for wider IF bandwidths and apparently slightly better sensitivity (a few dB lower noise floor?). For rtlsdr dongles this difference in IF filter bandwidth usually doesn't matter much since all of them are larger than the RTL2832U's debug/SDR mode bandwidth of ~3 MHz. But there are certain situations where a larger tuner bandwidth is advantageous: such as when using Jowett's HF tuning mod. As of Sept. 2014 some of the new R820T2 have been showing up in Terratec "E4000 upgrade" model sticks. But don't count on it. I bought one from ebay seller "smallpartsbigdifference" which had a photo showing an R820T2 and it was just an R820T. Since ~2015 R820T2 have become far more available. Here's a pdf with the R820T2 Register Descriptions.

As of 2017-12-11 Rafael Micro has been sending out emails saying the R820T2 has been discontinued. Alternate versions of the series, not pin compatible, are the R836, R840, or R828D. I've already seen SDR-targeted dongles using the R828D.

R820T/2 IF Filter Settings

In Feburary 2015 Leif sm5bsz (of linrad) relased a modified librtlsdr with changes to the rtlsdr R820T tuner code to allow for finer grained control over IF filter settings.

The IF filter which actually is a low pass filter and a high pass filter can be set for a bandwidth of 300 kHz. Dynamic range increases by something like 30 dB for the second next channel 400 kHz away. It is also possible to get some more improvement by changing the gain distribution.

Following this gat3way's patched gr-osmosdr and Vasili_ru's SDR# driver were released. gat3way made the IF filter width variable from within gqrx by presenting it as a gain value. Vasili's rtlsdr SDR# driver also moves the SDR# decimation normally applied during demodulation to the front of the IQ stream. This gives better dynamic range for the visual FFT but demodulated quality is not changed. So far this is all experimental but expect it to be brought mainline on both sides soon.

keenerd's experimental branch automatically set IF filter width based on sample rate but had not exposed them as manually set values.

R828D variant

In late 2013 Astrometra DVB-T2 dongles with the R828D tuner (pic) paired RTL2832U have begun to appear (2). The DVB-T2 stuff is done by a separate Panasonic chip on the same I2C bus. merbanan wrote a set of patches, rtl-astrometa, for librtlsdr has better support these tuners. The performance hasn't been characterized but it at least works for broadcast wide FM via SDR. steve|m's preliminary testing suggests bad performance in the form of the crystal for the DVB-T2 demodulator leaking fixed spurs 25 dB above noise floor in the IF at approximately 196 and -820 KHz. He was able to mitigate these with the hardware mod of removing the crystal for the DVB-T2 chip (ref). Official support was added to the rtl-sdr on Nov 5th while testing support was added on Nov 4th. In April 2017 u/strangerwithadvice on reddit made a quality post on the r/rtlsdr subreddit where he characterized the noise floor of an R828D dongle stock and with a number of modifications to reduce noise.

Double FC0013 tuner PCI DVB card

randomsdr reported on Freenode ##rtlsdr IRC on 2015-09-03 that the Leadtek Winfast DTV2000DS PLUS pci card has 2x FC0013 tuners and 2x rtl2832u chips like 2 normal rtlsdr dongles. Performance is not good but tools like rtl_fm work if the VID/PID is added to the rtlsdr driver table and udev rules set. It isn't recommended except as a novelty.

E4000 datasheet

2012-08-22: The E4000 tuner datasheet has been released into the wild. Elonics-E4000-Low-Power-CMOS-Multi-Band-Tunner-Datasheet.pdf, but...

"All the ones that are documented in the DS are 'explained'in the driver header file ... And the rest, the datasheet call them "Ctrl2: Write 0x20 there" and no more details"

R820T original, support, etc

2012-09-07: Experimental support for dongles with the Rafael Micro R820T tuner that started appearing in May has been added to rtl-sdr source base by stevem. These tuners cover 24 MHz to 1766 MHz. They also don't have the DC spike caused by the I/Q imbalance since they use a different, non-zero, IF. On the other hand, they might have image aliasing due to being superheterodine receivers. See stevem's tuner comparisons. On 2012-09-20 the R820T datasheet was leaked to the ultra-cheap-sdr mailing list. The R820T2 Register Description pdf was provided by luigi tarenga to the ultra cheap sdr mailing list after he received it from RafaelMicro. The official range is 42-1002 Mhz with a 3.5 dB noise figure. On 2012-10-04 my order arrived. I'm liking this tuner very much since it actually works well, locking down to 24 Mhz or so *without* direct sampling mode. Here's a rough gnuplot spectral map of 24 to 1700 Mhz over 3 days I made with some custom perl and python scripts. Don't judge the r820t on the quality of that graph, it is just to show the range. You can see what I think is either front-end mixer filters not attenuating enough or actual intermodulation as RFI. I do almost no processing of the signal (ie, no IQ correction), don't clear the buffer between samples (LSB probably bad), and use a hacky way to display timeseries data in gluplot. Real SDR software like SDR# shows them to be equal or better in quality to E4ks.

stevem did gain measurement tests with a few dongles using some equipment he had to transmit a GSM FCCH peak, "which is a pure tone." This includes the E4000 and R820T tuners. In addition he measured the mixer, IF and LNA for the R820T.

High Frequency (0-30Mhz) Direct Sampling Mod

Steve Markgraf of Osmocom has created an experimental software and hardware modification to receive 0~30Mhz(*) by using the 28.8 MHz RTL2832U ADCs for RF sampling and aliasing to do the conversion. In practice you only get DC-14.4MHz in the first Nyquist zone but the upper could be had by using a 14.4 MHz to 28.8 MHz bandpass filter. In the stereotypical ezcap boards you can test this by connecting an appropriately long wire antenna to the right side of capacitor 17 (on EzTV668 1.1, at least) that goes to pin 1 of the RTL2832U. That's the one by the dot on the chip surface. Apparently even pressing a wet finger onto the capacitor can pick up strong AM stations. This bypasses static protection among other things so there's a chance of destroying your dongle. For gr-osmosdr the parameter direct_samp=1 or direct_samp=2 gives you the two I or two Q inputs.

No hardware change, software mod direct sampling

It has recently become possible to use direct sampling with no hardware modifications at all. It is still very experimental and performance is bad. In Oct 2012 Anonofish on the r/rtlsdr subreddit had discovered the PLL would lock for a small ~ 3686.6 MHz - 3730 MHz range far outside the normal tuning range and there seemed to be signals there. In January 2014 ##rtlsdr IRC channel user tejeez figured out this bypassed the tuner (mixer leakage) and implemented a set of register settings (R820T IF frequency, IF filter bandwidths, r82xx_write_reg_mask(priv, 0x12, val, 0x08) replaced with r82xx_write_reg_mask(priv, 0x12, val|0x10, 0x18)) that would exploit this to enable HF reception. Shortly thereafter keenerd assembled everything into a relatively easy to use patch-set.

If you want to give HF listening a try with no risk keenerd has added these changes rtl_fm and rtl_power in his experimental rtlsdr repository. To use the no mode mode with rtl_ tools append the argument, "-E no-mod". To use the no-mod direct sampling in something that uses gr-osmosdr, like gqrx or GRC flowgraphs, add the following to the the "device string" parameters: ie "direct_samp=3". Plug your HF antenna into the normal connector, no hardware mods needed.


Differential input

I've been told my pin numbering doesn't correspond to the datasheets, so take that with salt. The relative positions are correct regardless of the numbering. The RTL2832 ADC differential input impedance is ~3,300 Ohm.

A number of people have tried to match the ADC's input impedance and both differential inputs by using baluns of various sorts. The datasheet seemed to say 200 Ohm so a lot of people (myself included) tried 4:1 baluns which did improve performance. But better matches can be found using the 1800 Ohm (36:1) Mini-circuits T36-1-KK81 with a 3900 Ohm resistor in parallel with the secondary to bring the RTL impedance down to 1800 Ohm (ref: G8JNJ).

Dekar has a page showing how to use an ADSL transformer to generate signal for the ADCs differential input using pin 1 (+I) and 2(-I) on the RTL2832. mikig has a useful pdf schematic with part numbers for using wide band transformers or toroids for winding your own. Here's a series of posts from bh5ea20tb showing how to use a FT37-43 ferrite core. And another example from IW6OVD Fernando. PY4ZBZ as well. The ADC has a differential/balanced input so this is done mainly for the unbalanced->balanced conversion. But the ADC input pins also have a DC offset so you can't just connect one to GND for that.

Tom Berger (K1TRB) used multiple core materials with trifilar wire and performed tests using his N2PK virtual network analyzer on May 19th (2013).

Hams love type 43 ferrite, but for almost every application, there is a better choice. For broadband HF transformers Steward 35T is generally a better choice. Therefore, I wound a couple transformers and did the comparison. Type 43 and 35T Transformer Material Compared

For my tests with direct sampling mode I ordered a couple wideband transformers from coilcraft. The PWB-2-ALB and PWB-4-ALB to be specific. I sampled the PWB-4-ALB for free and ordered 4 of the PWB-2-ALB for ~$10 shipped. Both seem to work fine though I have no means of comparative testing.

If you're particularly interested in HF work then an upconverter would be better than the HF mod. With the mod there will be aliases(*) for any frequency over 14.4 Mhz (1/2 the 28.8 clock rate). So you'd want a 14 MHz lowpass for the low end or a 14-28 MHz bandpass for the high end. And probably other little idiosyncracies. A lot of people chose to just use an upconverter instead. KF7LE wrote up short summaries comparing 16 popular upconverters.

Another alternative is to make a diplexer so that you get both HF via direct sampling and VHF+/etc without any switches. G8JNJ has a detailed guide with annotated photos on how to build the appropriate circuit and modify the latest R820T2 type dongles with it. He reports being able to receive from 15 KHz to 1.8 GHz with this mod.

Noise, shielding, cables, and why is that FM signal there?!

When you see something weird, like commercial FM broadcasts at 27 MHz, what you are seeing incomplete filtering of mixing products. It's the harmonics of the square wave driving the mixers combined with insufficient rf filtering to suppress the response. You can tell if it is a local oscillator mixer harmonic leakage by sweeping the frequency and seeing how fast the ghost signal moves relative to this; look for linear relationships (ie, 2x the speed, 1/4 the speed). Sometimes local signals can be powerful (ie, pagers) or close enough to make the preamplifier behave non-linearly resulting in intermodulation. For this kind of RFI turning down the gain helps.

The tuners all have a certain amount of intrinsic noise too. keenerd had done tests with an R820T rtlsdr terminated to a resistor inside of a metal box. For these tests rtl_power gain was set to max (49.6dB) and a frequency sweep was done through the entire tuner range, r820t Background Noise. The 28.8 MHz spikes from the clock frequency can be seen among other abberations.

But not everything is a ghost from hardware design problems. Depending on your computer setup and local electronics there could be a lot of "real noise"; LCD monitors are a common culprit for VHF noise spikes distributed across wide ranges. It is best to shield and put ferrites on everything if you can.

To solve the commercial FM mixing problems an FM trap can be used. Commercial ones work fine typically. But for non-commercial FM RFI like emergency services and pagers custom filters must be made or ordered. Adam-9A4QV has a detailed write-up on making FM trap with a very high upper passband (all the way to 1.7 GHz) with links to design for other low VHF bands. tejeez shared his VHF bandstop design on IRC. Like Adam's it has the unique feature of not also wiping out harmonics of the FM band: fm-notch.jpg fm-notch_schematic.png. This means you can use it and still do wideband frequency hopping (unlike, say, a 1/4th wave coaxial stub). For more information on this general type of coaxial cable notch filter check out Ed Loranger's write up on VHF Notch filters (photo). For my powerful 461 MHz RFI that can be received without an antenna I use a custom 3 cavity notch filter from Par Electronics.

Acinonyx describes one way to doing this using a single strip of aluminum tape combined with a spring to connect it to the dongle ground. Akos Czermann at the sdrformariners blog made a somewhat confusing but definitely empirical comparison of noise levels compared to different hardware mods like disconnecting the USB ground from the rtlsdr ground. Quite a few people have had success with that and scotch tape around the USB connector works to test it.

Some others bond the enclosure to both the antenna and the USB shield and this works reliably and well.

Martin from g8jnj.net finds the most effective mod to reduce USB and DC-converter noise is shielding the antenna input area with metal soldered to the pcb ground, "The noise seems to be coupled directly between components on the topside of the PCB." You can find it if you scroll about halfway down the page linked.

Additional noise comes from the switching power supply in the RTL2832U that runs at 1.024MHz. This drops the supplied 3.3v down to the 1.2v needed for internal use. ttrftech has successfully disconnected this switching supply replaced it with 3 diodes to drop the 5v line down to ~1.2v. In the example linked above ttrftech uses power form the far side of the board but the eeprom's power rail would also work. This decreases spurs in HF significantly. It will increase power usage though; something to watch out for when R820T dongles start out at ~300mA a piece.

Laidukas's "Mods and performance of R820T2 based RTL SDR receiver covers replacing all the power rails with external linear regulators, increasing the amount of bypass capacitance on power lines, adding extra chip filtering for the USB 5v line, cutting off the IR receiver part of the PCB, wiring in a TCXO 28.8MHz oscillator, creating a shield with kapton tape and copper foil soldered extensively to the PCB ground, and a new heavy metal case and connectors.

To reduce signal loss over long distances and get away from computer RFI I like to run long USB *active* extension cable with hubs at the end and ferrites added instead of coaxial cable. Around this USB cable I clip on 5 or 6 ferrites at each end. Active extension/repeater USB2 cables of up to 25m in length can be used.

Using External Clocks and coherent sampling in general...

Multiple coherent dongles

The most exciting development in rtlsdr that has happened recently are Juha Vierinen's discuss-gnuradio mailing list and blog posts about a simple and inexpensive method to distribute the clock signal from one dongle to multiple others for coherent operation.

"I recently came up with a trivial hack to build a receiver with multiple coherent channels using the RTL dongles. I do this basically by unsoldering the quartz clock on the slave units and cable the clock from the master RTL dongle to the input of the buffer amplifier (Xtal_in) in the slave units (I've attached some pictures)."

Since I've seen a lot of people asking, the dongles he used were Newsky TV28T v2 w/R820T tuners.

Ben Silverwood later replicated this technique with his " Low cost RTL-SDR passive multistatic DAB radar." implementation in matlab. The youtube video description has links to photos of the setup.

Also, there's a Japanese seller with high precision SMD 28.8 MHz crystals. And an ebay seller with high precision 28.8 MHz oscillators for around ~$30 shipped.

Things again became exciting in June of 2014. Going beyond simple clock sharing and it's max of 3 dongles, YO3IIU put up a great post his build of a 4+ dongle RTL2832u based coherent multichannel receiver using a CDCLVC1310-EVM dev board from TI for clock distribution. His post shows the results of a gnuradio block he coded that does all the correlation math to align the samples from each receiver (which are out of step due to the way USB works). Unfortunately the software was never released.

steve|m's experiments were the first I heard about back in 2011. He used his 13MHz cell-phone clock as a reference for a PLL to generate 28.8MHz. He said he used 1v peak to peak. He also related it was possible to not even use the PLL and just the 13 MHz clock if w/E4000 tuners if you don't care about sample rate offset.

<steve|m> not really, just a picture and a short clip: http://steve-m.de/projects/rtl-sdr/osmocom_clocksource.webm http://steve-m.de/pictures/rtlsdr_external_clock.jpg
<steve|m> a motorola C139

The Green Bay Public Packet Radio guys have written up an interesting article on using 14.4 MHz temperature controlled crystal oscillators sent through a passive (two diode) frequency doubler followed by crystal filters made out of the old rtlsdr clock crystals to provide a low PPM error clock for rtlsdr devices. Since their mirror was missing images I cut them out of the Zine pdf and made a mirror here.

I first heard about the GBPPR article from patchvonbraun who implemented one and performed tests which he posted about on the Society for Amateur Radio Astronomy list. It turns out that even with a good distributed clock the 2x R820t rtlsdr dongles still have large phase error for some reason, see: Phase-coherence experiments with RTLSDR dongles and the photo post: Progress towards using RTLSDR dongles for interferometry.

Alex Paha has also done clock distribution but unlike the others he used E4000 tuner based receivers for his dual coherent receiver. He also seems to be using only half the I/Q pairs. This post is in Russian.

Actually maintaining coherence over re-tunes and USB2 latency
rtl_coherent

In October 2015 teejez uploaded his rtl_coherent code for maintaining multi-dongle coherence using external antenna switches to disconnect the antennas and connect all to a common noise source for correlation calibration. Here's a video of him using it to make a 3 dongle direction finder.

Each dither-disabled rtl-sdr is fed from the same reference clock. They still have unknown phase shifts and sampling time differences relative to each other. This is calibrated by disconnecting them from antennas and connecting every receiver to the same noise source. Cross correlation of the noise gives their time and phase differences so that it can be corrected. Currently the signal is received and processed in short blocks with each block starting with a burst of calibration noise.

As I understand it the switch chips are sa630 that "look" for dongle i2c traffic. There are controlled by two RC delay circuits so that every time you change frequency (causing i2c traffic) it disconnects antennas, waits for some time, feeds a pulse (just one edge from the logic chip) into all dongles, waits a bit more and connects the antennas back. You can see the evolution of his setup from this earlier prototype to this later prototype and finally the version used in his direction finder.

Every time you tune any two (or more) dongles to a new frequency there will be a tiny difference in the frequency each actually tuned to. The offset must corrected before trying to correlate them. If you don't it'll look like there's a constantly varying phase shift. Also don't forget to let the dongles warm up to equilibrium otherwise this additional temperature related frequency shift will cause changes even larger than relative tuning offset and you'll get the "random" phase shift again.

Multi-RTL

As of 2016 Piotr Krysik's "Multi-RTL" (github) has made maintaining coherence of multiple dongles accessible even to the amateur. His GNU Radio block handles all the complex details of keeping multiple rtlsdr coherent even when they're tuned to different frequencies and over re-tunes. It requires no external circuitry. You just have to distribute the clock signal with cable.

PLL Dithering and you.

On the clock coherencey side Michele Bavaro's has explored, tweaked, and replaced, librtlsdr's pll setting code, intermediate frequency, and PLL dithering settings, such that the math, and results, work out cleaner. Using this modified driver he was able to minimize frequency setting errors and improve his GPS carrier following code. This is written up with code examples at his blog in, GNSS carrier phase, RTLSDR, and fractional PLLs (the necessary evil). Without dithering you can only tune to increments of 439.45 Hz. With dithering, you can tune to aproximately anything.

tejeez from the ##rtlsdr IRC relates that this can be done in r82xx_set_pll by changing r82xx_write_reg_mask(priv, 0x12, val, 0x08) to r82xx_write_reg_mask(priv, 0x12, val|0x10, 0x18). This has been implemented as an option in rtl_sdr, '-N', in keenerd's experimental branch.

Misc

In the absence of any useful information about the RTL2832U clock here's some information about the R820T's clock system.

Crystal parallel capacitors are recommended when a default crystal frequency of 16 MHz is implemented. Please contact Rafael Micro application engineering for crystal parallel capacitors using other crystal frequencies. For cost sensitive project, the R820T can share crystal with backend demodulators or baseband ICs to reduce component count. The recommended reference design for crystal loading capacitors and share crystal is shown as below.

Antenna, but particularly broadband antenna

I've also written up a seperate, longer, page on the challenges and solutions when implementing broadband antenna.

When I want to do some scanning that takes advantage of the tuner's very wide ranges I use five types of antenna: discone, spiral, dual planar disks, vivaldi (tapered slot), and horns (TEM and pyramidal). Discone, dual planar disk, and archimedian spiral antenna can omnidirectionally cover almost the full range of the E4000 tuner but things get a bit too large to go all the way to the 24 Mhz of the R820T. You can refer to the seperate spiral antenna page for construction and technical details. To build my discone I followed Roklobsta's D.I.Y. Discone for RTLSDR. With just a discone and rtl_power it's possible to see lots of LEO satellite carrier frequencies doppler across the spectrum.

To get an idea of how much you can see with a discone here's a directory where I produce ~2 to 4 day long ~70 to 1000 MHz range 25KHz resolution 45k*10k pixel spectrograms. They each have a javascript zoomable interface to load small tiles progressively. An example. With just a discone and rtl_power it's possible to see lots of LEO satellite carrier frequencies doppler across the spectrum.

But with a band specific helix in a cone reflector (helicone) many more satellites can be picked up. The previous is a link to a zoomable spectrogram of ~2 days of the 1616-1626 MHz satellite band that Iridium satellites use. No LNA was used. There's plenty of RFI/EMI even through a 1 GHz high pass but the satellite doppler passes are clearly there in numbers if you zoom in far enough.

When using such broadband antenna, or even a band specific helix, it is possible to pick up powerful out of band signals due to overloading or incomplete mixer filtering. It's important to identify any extraordinarily powerful transmitters nearbye and filter them out. In my case I have a 50w transmitter at 461 MHz across the street always going full power. I bought a custom tuned 3 cavity notch filter from PAR Electronics. This limits the upper frequency range to 1GHz but does at least solve the RFI problem.

Usually the spectra are much cleaner when using directional and resonant antenna instead of wideband omnidirectionals. But many directional antenna like helix and log periodic dipoles have very large out of band sidebands on low frequencies not in the designed range.


Chipset docs, GNU Radio, DSP, and Antenna Links

Page Sections

RTL-SDR Links



Warning: I'm learning as I go along. There are errors. Refer to the proper documentation and original sources first.


GNU Radio *and* RTL-SDR Setup

You don't need GNU Radio to use the rtlsdr dongles in sdr mode, but there are many useful apps that depend on it. patchvonbraun has made setting up and compiling GNU Radio and RTLSDR with all the right options very simple on Ubuntu and Fedora. It automates grabbing the latest of everything from git and compiling. It will also uninstall any packages providing GNU Radio already installed first. Simply run, http://www.sbrac.org/files/build-gnuradio, and it'll automate downloading and compiling of prequisites, libraries, correct git branches, udev settings, and more. I had no problems using Ubuntu 10.04, 12.04, or 14.04. These days (2015) pybombs is slowly taking over for build-gnuradio but for now this works best.

If you're thinking about trying this in a virtual machine: don't. If you do get it partially working it'll still suck.

As an aside: If you're an OSX user then you can use the MacPorts version of GNU Radio (including gqrx, etc) maintained by Michael Dickens.

mkdir gnuradio
cd gnuradio
wget http://www.sbrac.org/files/build-gnuradio
chmod a+x build-gnuradio
./build-gnuradio --verbose          # default is latest 3.7
*or*
./build-gnuradio -o --verbose       # install old 3.6.5.1

Install 3.7. Most gnu radio projects have been ported to it as default. Only a few old things will require 3.6.

An (re)install looks like this. It might be useful to save the log output for future reference. Then test it. The test output below is from a very old version of rtl_test with an E4K dongle. Newer versions, and R820T tuners will output slightly different text.

rtl_test -t
Found 1 device(s):
  0:  ezcap USB 2.0 DVB-T/DAB/FM dongle

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Elonics E4000 tuner
Benchmarking E4000 PLL...
[E4K] PLL not locked!
[E4K] PLL not locked!
[E4K] PLL not locked!
[E4K] PLL not locked!
E4K range: 52 to 2210 MHz
E4K L-band gap: 1106 to 1247 MHz

Once GNU Radio is installed the "Known Apps" list at the rtl-sdr wiki is a good place to start. Try running a third party receiver, a python file or start up GNU Radio Companion (gnuradio-companion) and load the GRC flowcharts. If you're having "Failed to open rtlsdr device #0" errors make sure something like /etc/udev/rules.d/15-rtl-sdr.rules exists and you've rebooted.

Updating

When updating you can just repeat the install instructions which is simple but long. The advantage to repeating the full process is mainly if there are major changes in the gr-osmosdr as well as rtl-sdr. It'll do things like ldconfig for you.

./build-gnuradio -e gnuradio_build
Just compile/installing rtl-sdr

If you don't have the patience for a full recompile and there haven't been major gnu radio or gr-osmosdr changes it's much faster just to recompile rtl-sdr by itself. The instructions to do so are at the osmosdr page. It'll only take a few minutes even on slow machines. Once you have the latest git clone it is like most cmake projects:

git clone git://git.osmocom.org/rtl-sdr.git
cd rtl-sdr; mkdir build; cd build; cmake ../ ; make; sudo make install; sudo ldconfig

rtl-sdr supporting receivers, associated tools

Pager stuff


DongleLogger: my pyrtlsdr lib based spectrogram and signal strength log and plotter

Purpose:

Obsolete. Use rtl_power instead. Automatic generation of and html gallery creation of wideband spectrograms using multiple rtlsdr dongles to divide up the spectrum. It also produces narrow band total charts, and other visualizations.

(not live): http://erewhon.superkuh.com/gnuradio/live/ - click the spectrograms for time series plot

These scripts cause the rtlsdr dongle to jump from frequency to frequency as fast as they can and take very rough total power measurement. This data is stored in human readable logs and later turned into wideband spectrograms by calling gnuplot. In order to further increase coverage of any given spectrum range multiple instances of the script can be run at once in the same directory adding to the same logs. Their combined output will be represented in the spectrogram.

Details:

I don't know much python but the python wrapper for librtlsdr pyrtlsdr was a bit easier to work with than gnu radio when I wanted to do simple things without a need for precision or accuracy. Actualy receivers with processing could be made with it too, but not by me. This is the gist of what it does,

power = 10 * math.log10(scan[freq]) = scan = self.scan(sdr, freq) = capture = sdr.read_samples(self.samples) = iq = self.packed_bytes_to_iq(raw_data) = raw_data = self.read_bytes(num_bytes)

The pyrtlsdr library can be downloaded by,

git clone https://github.com/roger-/pyrtlsdr.git

I have used the "test.py" matplotlib graphical spectrogram generator that came with pyrtlsdr as a seed from which to conglomerate my own program for spectrum observation and logging. Since I am not very good with python I had to pull a lot of the logic out into a perl script. So everything is modular. As of now the python script generates the spectrogram pngs and records signal strength (and metadata) in frequency named logs. It is passed lots of arguments.

These arguments can be made however you want, but I wrote a perl script to automate it along with a few other useful things. It can generate a simple html gallery of the most recent full spectral map and spectrograms with each linked to the log of past signal levels. Or it can additionally generate gnuplot time series pngs (example) and link those intead of the raw logs. It also calls LTE Cell Scanner and parses out the frequency offset for passing to graphfreq.py for correction. I no longer have it running because of the processor usage spikes which interrupt daily tasks. In the past I'd have rsync updating the public mirror with a big pipe every ~40 minutes.

Modifying pyrltsdr

As it is pyrtlsdr does not have the get/set functions for frequency correction even if I sent the PPM correct from the perl script. Since the hooks (?) were already in librtlsdr.py (line 60-66) but just not pythonized in rtlsdr.py they were easy to add to the library. These changes are required to use frequency correction and make the int variable "err_ppm" available. I have probably shown that I don't know anything about python with this description.

I forked roger-'s pyrtlsdr on github and added them there for review or use, https://github.com/superkuh/pyrtlsdr/commit/ffba3611cf0071dee7e1efec5c1a582e1e344c61. I apologize for cluttering up the pyrtlsdr namespace with such trivial changes but I'm new to this and github doesn't allow for private repositories.

What you should be using instead.

Download

fast version: see below

slow version:

The faster version

Speed ups, Inline C usb reset, and avoiding dongle reinitialization... (less options)
cli switches/options
-dev 1			:: rtlsdr device ID (use to pick dongle)
-g 30			:: gain
-s 			:: interval between center frequencies
-r 2400000		:: sample rate
-d2 /path/here		:: path to the directory to put logs, plots, gallery
-c 751			:: LTC Cell scanner frequency offset correction, takes freq in Mhz of base cell
-w			:: turn on web gallery generation
-p			:: turn on gnuplot time series charts for every freq (don't use to maximize speed)
-m			:: generate full range spectrogram using all.log (this is the most useful thing)
-mr "52-1108,1248-1400,1900-2200"	:: set of frequency ranges to plot as a another spectrogram

These two scripts do fast scans within python from x to y frequency. Enabled it with -fast and make sure to set start and stop frequency with -f1 and -f2. Do not use -flist with this option.

$ while true; do perl radioscan_faster.pl -d2 /tmp/faster -f1 25 -f2 1700 -fast -g 30 -r 2400000 -s 1.2 -m -p; sleep 1; done;
Running graphfreq in non-batch fast mode 25 to 1700 Mhz at 1.2 Mhz spacings.
 Spectrograms and text output disabled.
Using LTE Cell Scanner to find frequency offset from 751 Mhz station...Found Rafael Micro R820T tuner
-44k frequency offset. Correcting -58 PPM.
Generating spectral map.

python ./graphfreqs_faster.py 40000000 2400000 30 -58 /tmp/faster 1700000000
Found Rafael Micro R820T tuner
... (repeat many, many times)

This is an example output "spectral map" (a spectrogram with a silly name).

This example output above shows the overloading effects of using a wideband discone that picks up off-band noise. Each column is made up of small squares colored by intensity of the signal. Since the scripts start at the low frequency and sweep to high there is a small time delay between the bottom and top (see it more clearly zoomed in). And this is represented as the slant of the row. Sometimes strong signals will swamp out others resulting in discontinuities displaying as small dark vertical bands.

Or fast (-fast) scan a smaller range with smaller range (-f1,-f2: 24-80Mhz), with smaller samplerate (-r: 250 Khz) at smaller intervals (-s: 400Khz steps) with a gain of ~30. Only output a large spectrogram of all frequencies to the directory specified with -d2 as spectral-map.png. This example does not use frequency offset correct (-c) for even faster speeds.

while true; do perl radioscan_faster.pl -d2 /home/superkuh/radio/2012-02-02_R820T_Discone_lowfreq -f1 24 -f2 80 -fast -g 30 -r 250000 -s 0.4 -m -p; sleep 1; done;
Running graphfreq in non-batch fast mode 24 to 80 Mhz at 0.4 Mhz spacings.
 Spectrograms and text output disabled.
Generating spectral map.

python ./graphfreqs_faster5.py 24000000 250000 30 0 /home/superkuh/radio/2012-02-02_R820T_Discone_lowfreq 80000000 400000
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz

Combining multiple rtlsdr devices for greater speed

Full

Zoom

By splitting up the spectrum into multiple smaller slices and giving them to multiple dongles the time required for one scan pass can be greatly improved. The above spectrogram is made with 2 dongles, one for the lower half and one for the upper. It is from ryannathans who also contributed the code for for specifying device ID. This is as simple as running the script twice but giving each instance a different "-dev" argument to specify device ID. You can run as many rtlsdr devices with my scripts as you wish (up to the USB and CPU limits). If they are using the same directory (-d2) their log data will be combined automagically for better coverage.

while true; do perl radioscan_faster.pl -d2 /home/superkuh/radio/2013-06-09_multidongle -f1 25 -f2 525 -fast -g 40 -r 2400000 -s 1.2 -m -dev 0; sleep 1; done;
...
Found Rafael Micro R820T tuner
while true; do perl radioscan_faster.pl -d2 /home/superkuh/radio/2013-06-09_multidongle -f1 525 -f2 1025 1100 -fast -g 29 -r 2400000 -s 1.2 -m -dev 1; sleep 1; done;
...
Found Elonics E4000 tuner
Outlier signals skewing your color map scale?

Sometimes I get corrupt samples that show a signal level of +60dB. These skew the scale of the output spectrograms. If I notice that they have occurred during a long run I'll use grep to find them and remove them manually. I replace the signal level with the level of the previous non-corrupt sample. In the future I'll build this kind of outlier removal in to the scripts, or sanity check before writing them.

grep -rinP " (3|4|5|6)\d+\.\d+" *.log

All the incremental improvements in speed I've made above are okay but not very easy to maintain with multiple script types (bash/perl/python). I'm slowly putting together an Inline C based perl wrapper for exposing librtlsdr's functions within a perl script to write this as a standalone in perl. This is slow work because I've never done anything like it before.

rtlsdrperl - what if there were a perl wrapper for librtlsdr?

Well, there never will be. But here's some example code anyway.

#!/usr/bin/perl
use Inline C => DATA => LIBS => '-L/usr/local/lib/ -lrtlsdr -lusb';
use warnings;
use strict;

my $fuckingtest = get_device_name(0);
print "Device name: $fuckingtest\n";
my $fuckingtest2 = get_device_count();
print "# Devices: $fuckingtest2\n";

__END__
__C__
const char* rtlsdr_get_device_name(uint32_t index);
char * get_device_name(int count) {
	char* res = rtlsdr_get_device_name(count);
	return res;
}

uint32_t rtlsdr_get_device_count(void);
int get_device_count() {
	int hem = rtlsdr_get_device_count();
	return hem;
}

Older version

graphfreqs.py

You have to have the modified pyrtlsdr with the get/set functions for frequency correction. LTE Cell Scanner should also be installed so the "CellSearch" binary is available. Then download the two scripts above and put them in the same directory. For large bandwidths sampled this feature, ppm error correction, has an unnoticably small effect but I wanted to add it anyway.

To call the spectrogram/log generator by itself for 431.2 Mhz at 2.4MS/s with a gain of 30 and frequency correction of 58 PPM use it like,

python graphfreqs.py 431200000 2400000 30 58

I've disabled the matplotlib (python) per frequency spectrogram plots for frequencies over 1 Ghz because there's not much going on up there. Also, the x-axis ticks and labels become inaccurate for some reason.

Logs and format

The signal strength logs, named by frequency (e.g. 53200000.log), use unix time and are comma seperated with newlines after each entry. In order of columns it is: unix time , relative signal level , gain in dB, PPM correction.

1345667680.28 , -34.65 , 29 , 57
1345667955.59 , -34.67 , 29 , 57
1345668004.37 , -34.55 , 29 , 57
1345668110.06 , -33.88 , 29 , 57

It also generates a log file with all frequencies for use with gnuplot, all.log. This file has unixtime first, then frequency, then gain and ppm error.

1347532002.5 52000000 -14.84 29.0 58
1347532004.88 53200000 -17.84 29.0 58
1347532007.04 54400000 -17.98 29.0 58
1347532009.04 55600000 -19.78 29.0 58
1347532011.02 56800000 -24.04 29.0 58
1347532012.98 58000000 -26.21 29.0 58
1347532014.92 59200000 -25.10 29.0 58
radioscan.pl

The radioscan.pl script is used to automate calling graphfreqs in arbitrary steps. To generate plots and signal strength for 52 Mhz to 1108 Mhz with a gain of 30, sample rate of 2.4MS/s, and an interval between center frequencies of 1.2 Mhz, call it like,

$ perl radioscan.pl -flist "52-1108,1248-2200" -g 30 -r 2400000 -s 1.2
cli switches/options
-flist "52-1108,1248-2200"  :: sets of frequency ranges to scan.
-g 30			:: gain
-s 			:: interval between center frequencies
-r 2400000		:: sample rate
-d1 /path/here 		:: path to where the scripts are if now pwd
-d2 /path/here		:: path to the directory to put logs, plots, gallery
-c 751			:: LTC Cell scanner frequency offset correction, takes freq in Mhz of base cell
-w			:: turn on web gallery generation
-p			:: turn on gnuplot time series charts for every freq
-m			:: generate full range spectral map using all.log
-mr "52-1108,1248-1400,1900-2200"	:: set of frequency ranges to plot as a another spectral map

Because I can use the default directories I keep it running like the below, but anyone else should make sure to set -d2.

$ while true; do perl radioscan.pl -flist "52-1108,1248-2200" -g 30 -r 2400000 -s 1.2 -w -c 751 -p -m -mr "52-1108"; sleep 1; done;

Running pyrtl graphfreq batch job 52 to 1108 Mhz at 1.2 Mhz spacings.
Using LTE Cell Scanner to find frequency offset from 751 Mhz station...Found Elonics E4000 tuner
42.6k frequency offset. Correcting 56 PPM.
Generating spectral map.
Generating another spectral map over only 52-1108.

python ./graphfreqs_offset.py 52000000 2400000 30 56
Found Elonics E4000 tuner
python ./graphfreqs_offset.py 53200000 2400000 30 56
Found Elonics E4000 tuner
python ./graphfreqs_offset.py 54400000 2400000 30 56
Found Elonics E4000 tuner
...
python ./graphfreqs_gnuplot.py 316000000 2400000 30 56
Found Elonics E4000 tuner
Dongle froze, reseting it's USB device...
Resetting USB device /dev/bus/usb/001/017
Reset successful
python ./graphfreqs_gnuplot.py 317200000 2400000 30 56
Found Elonics E4000 tuner
..
Generating page, moving images.

starting rsync...
Tuner/USB freeze solution with unplugging
edit: as of Jan 5th 2013, librtlsdr has added soft reset functionality

Since graphfreqs.py's initializing and calling of rtl-sdr happens so frequently there are sometimes freezes. To fix these the USB device has to be reset. In the past I would accomplish this by un and re-plugging the cord manually. But that meant lots of downtime when I was away or sleeping. So, I've added in a small C program to the perl script using Inline::C that exposes a function, resetusb(). It is used if the eval loop around the graphfreqs call takes more than 10 seconds. This means you need Inline::C to run this script. To look at the original C version with a good explanation of how to use it click here.

sub donglefrozen {
	my $usbreset;
	my @devices = split("\n",`lsusb`);
	foreach my $line (@devices) {
		if ($line =~ /\w+\s(\d+)\s\w+\s(\d+):.+Realtek Semiconductor Corp\./) {
			$usbreset = "/dev/bus/usb/$1/$2";
			resetusb($usbreset);
}}}
__END__
__C__
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/ioctl.h>
#include <linux/usbdevice_fs.h>

int resetusb(char *dongleaddress)
{
	const char *filename;
	int fd;
	int rc;
	filename = dongleaddress;
	fd = open(filename, O_WRONLY);
	if (fd < 0) {
		perror("Error opening output file");
		return 1;
	}
	printf("Resetting USB device %s\n", filename);
	rc = ioctl(fd, USBDEVFS_RESET, 0);
	if (rc < 0) {
		perror("Error in ioctl");
		return 1;
	}
	printf("Reset successful\n");
	close(fd);
	return 0;
}

Page Sections

My rtlsdr receiver + w/gnuradio implementation of the 11 GHz VSRT solar interferometer

As far as I understand it, the VSRT design is a subset of intensity interferometer that uses the frequency error between multiple 11 GHz satellite TV "low noise downconverter block" (LNBF) clocks to create a beat frequency in the total power integrated. I am basically copying the MIT Haystack Very Small Radio Telescope (VSRT) but replacing the discrete component integrator and USB video input device with an rtlsdr dongle. The idea is to spend as little on hardware as possible.

With modern LNBF the error between same model parts is about 30 ppm which results in beat frequencies of ~100 KHz at the 10 GHz of the mixers. With this kind of front-end there are no nulls but the fringe modulation can still be read out as variations in count of histogram bins that contain the beat frequency (in the total power fft). This intensity measurement proxy traces out the the envelope of the fringes and varies as a sinc function of distance between antenna. Knowing this and the distance can give you high angular diameter and position measurements of very bright radio sources.

$75 2x 18" satellite dishes w/mounts shipped
$10 2x Ku LNFB (PLL321 S-2, ~30ppm error, RDA3560 w/27Mhz xtal.)
$10 rtlsdr receiver (r820t or e4k, ~30ppm error)
$10 power combiner (cheaper ones work too)
$5 coaxial power injector (LPI 2200)
$20 coaxial power supply (LPI 188PS) + diodes
$20 100ft RG6 quadshield + F connectors
$130 Two Dish Position Motors (HH90)
$60 DVB-S PCI card (Skystar 2, DiSEqC 1.2)
$10 DiSEqC 1.2 switch
$80 PVC, metal stock, drill bits
Historical and other context.

For a detailed mathematical explanation of VSRT see MIT Haystack's VSRT Introduction. There is also a thread on the Society for Amateur Radio Astronomers list discussing the VSRT design. The more general concept of intensity interferometry, where you correlate total power instead of frequency, was originally developed by Hanbury-Brown & Twiss. Roger Jennison was around too. "The Early Years of Radio Astronomy: Reflections Fifty Years after Janskys Discovery" by W T Sullivan (2005) is an excellent source about Hanbury Brown and Twiss's side of it. The chapter "The Invention and Early Devlopment of The Intensity Interferometer" (pdf) is fascinating. Also see "The Development of Michelson and Intensity Long Baseline Interferometry" (pdf). It covers not only the technical concepts but also historical context, detailed hands-on implementations, and other personal anectdotes. And check out Jennison's book "Radio Astronomy" (1966)) as he invented the process of phase closure which uses a third antenna signal combined mathematically to recover some of the missing phase information. Arranged in a triangle of projected baselines the phase errors cause equal but opposite phase shifts in ajoining baselines, canceling out in the "closure phase". The MIT Haystack groups managed to resolve individual sunspots groups moving across the solar disk using with the technique with the VSRTs.



"An interferometer is an instrument that combines two signals (normally from two detectors) in a manner that the signals interfere to produce a resultant signal. The resultant signal is usually the vector sum of the two signals, but in some cases it is the product or some other mix. The traditional interferometer, usually studied and analyzed in physics courses, combines the two signals in a way that both amplitude and phase information are used. By varying the positions of the two detectors, it is possible to synthesize an effective aperture that is equivalent to the separation of the detectors and to reconstruct the impinging wavefront, thus providing significant information about the extent and structure of the signal source. The traditional phase-sensitive interferometer requires retention of the signal phase at each detector – the phase-sensitive interferometry technique will not be discussed in detail here."

"A special case of the interferometer is the intensity interferometer, which performs an intensity correlation of signals from the two detectors. Although in the intensity interferometer the phase information from the two antennas is discarded, the correlation of the two signals remains useful. Aperture synthesis is not practical, but some important source characteristics may be determined."



I think the VSRT is a special case of intensity interferometer where you don't try to align samples by time after recording. Instead you just look for the baseline distance sinc pattern in total power at the beat frequency of the unsynchronized clocks.

Implementation so far.

So far I've only done it with manual pointing screwed to a board. The interferometry correlation is done with a satellite tv market stripline power combiner at the intermediate frequency (IF, ~950-1950 MHz) and then an rtlsdr dongle is used to measure the total power of a 2.4 MHz bandwidth of the intermediate frequency range. I use a gnuradio-companion flowgraph to take the total power and then do a fourier transform of the total power. In this fourier transform the fringes show up as a modulation of the count in the FFT bins which correspond to the difference in frequency between the two downconverters. In my case this is about ~100 KHz.

In the Haystack VSRT memos a line drop amplifier, or two, are sometimes put behind the respective LNBF IF coax outputs or the power combiner. With the rtlsdr dongle and relative short (<10m) baselines of RG6 this isn't required.

The GUI allows for setting the exact 2.4 MHz bandwidth of the IF range to sample and the total power FFT bin bandpass to where and what the LNBF beat frequency is. The file name is autogenerated to the format,

prefix + datetime.now().strftime("%Y.%m.%d.%H.%M.%S") + ".log"

The time embedded in the filename is later used by a perl script, vsrt_log_timeplot.pl, which converts and metadata tags the binary records to gnuplot useable text csv format for making PNG plots.

Download

Who else helped

I consulted with patchvonbraun a lot for the software/gnuradio side. He gave me an example of how to use the WX GUI Stripchart and I would not have guessed I needed to square the values from the beat frequency bins after the first squaring for taking total power. He made a generic simulator for dual free running clocks LNBF intensity interferometers. You don't even need to have an rtlsdr device to run it; only an up to date install of gnuradio. It is an easy way to understand how to do interferometry without a distributed clock signal.

patchvonbraun's: simulated-intensity-interferometer.grc


Physical

With this setup on a 1 meter baseline and a intermediate tuning frequency of 1.6 GHz IF (10700 MHz+(1600 MHz−950 MHz)= 11350 MHz) the main beamwidth would be about 70*(c/11GHz)/1m), or 1.9 degrees. This does not resolve the solar disk (~0.5 deg) during drift scans. I have been told that the magnitude goes down in a SINC pattern as you widen the baseline and approach resolving the source but I will not resolve the sun initially. In the VSRT Memos "Development of a solar imaging array of Very Small Radio Telescopes" a computationally complex way to resolve individual action regions is done with a 3rd dish providing "phase closure" in the array on a slanted north-south baseline in addition to the existing east-west baseline. I try to point my dishes so that the Earth is passing the sun through the beam at ~12:09pm (noon) each day. To aid in pointing a cross of reflective aluminum tape is applied center of the dish. This creates a cross of light on the LNBF feed when it is in the dish focal plane and the dish is pointed at the sun. The picture below is from later in the day, the one of the left shows the sun drifting out of the beam as it sets. I made my LNBF holders out of small pieces of wood compression fit in the dish arm. There are grooves for the RG6 coax to fit ground out with a rotary tool. The PVC collars have slots cut in the back with screws going into the wood to set the angle.


The screenshot shows a short run near sunset on an otherwise cloudy day. The discontinuities are me running outside and manually re-pointing the dishes. But it does highlight how the beat frequency of the 2 LNBF varies as they warm up when turned on. It starts down at ~90 KHz but within 10 minutes it rises to ~115 KHz. After it reaches equilibrium the variation is ~ -+1 KHz. I could change the existing 80-120 KHz bandpass to a 110-120 KHz bandpass and have better sensitivity. But that bandwidth is something that has to be found empirically with each LNBF pair and set manually within the GUI for now.

patchvonbraun said it was feasible to identify the frequency bins with the most counts and that there was an example within the simpla_ra code,

"You could even have a little helper function, based on a vector probe, that finds your bin range, and tunes the filter appropriately."

The below close up of indoor testing showing how everything is connected on the rtlsdr side showing the power injector, e4k based rtlsdr (wrapped in aluminum tape), and the stripline based satellite power combiner for correlation. The two rg6 quadshield coaxial lines going from the power combiner to the ku band LNBF are as close to the same length as I could trim them. I use a 1 amp 18v power supply and coaxial power injector to supply power to the LNB and any amplifiers. This voltage controls linear polarization (horiztonal/vertical) and it can be changed by putting a few 1 amp 1N4007 in series with the power line to drop the voltage.

Accessory scripts.

tp-modes.grc produces binary logs that are pretty simple. The count of the LNBF beat frequency bins in the bandpass are saved as floats represented as 4 pairs of hexadecimal. When the integration time is set to the default 1 second then one 4 byte data point is written to the log every 0.5 seconds. I highly recommend not changing this for now. There is no metadata or padding. Here's a screenshot of a run using the utility "bless",

In order to convert the binary logs of 4 byte records into something gnuplot can parse I use a simple perl script,

#!/usr/bin/perl
use warnings;
use strict;

my $data = '/home/superkuh/vsrt_2013.06.13.12.26.47.log';
my $bytelength = 4; 
my $format = "f"; # floats (little endian)
my $num_records;

if ($ARGV[0]) {
	$data = $ARGV[0];
} else {
	print "you need to pass the log file path as an argument.";
	exit;
}

open(LOG,"$data") or die "Can't open log.\n$!";
binmode(LOG);

my $i = 0;
until ( eof(LOG) ) {
	my $record;
	my $decimal;
	read(LOG, $record, $bytelength) == $bytelength
		or die "short read\n";
	$decimal = unpack($format, $record);
	printf("$i,\t$decimal\n", $decimal);
	$i++;
}

Now I have the filename which gives the time the gnuradio-companion grc file started running. This is not the time I hit the record button and started logging. The offset is a second or two. Ignoring that, it is possible to use the start time encoded in the log file name to figure out when a particular measurement was taken. To do that I have to know the interval between entries saved to the binary log.

$ date && ls -l /home/superkuh/vsrt_2013.06.14.12.03.00.log && sleep 60 && date && ls -l /home/superkuh/vsrt_2013.06.14.12.03.00.log
Fri Jun 14 13:05:24 CDT 2013
-rw-r--r-- 1 superkuh superkuh 29644 2013-06-14 13:05 /home/superkuh/vsrt_2013.06.14.12.03.00.log
Fri Jun 14 13:06:24 CDT 2013
-rw-r--r-- 1 superkuh superkuh 30124 2013-06-14 13:06 /home/superkuh/vsrt_2013.06.14.12.03.00.log

((30124−29644)/4)/60 = 2

$ date && ls -l /home/superkuh/vsrt_null.log && sleep 60 && date && ls -l /home/superkuh/vsrt_null.logFri Jun 14 13:44:36 CDT 2013
-rw-r--r-- 1 superkuh superkuh 8 2013-06-14 13:44 /home/superkuh/vsrt_null.log
Fri Jun 14 13:45:36 CDT 2013
-rw-r--r-- 1 superkuh superkuh 488 2013-06-14 13:45 /home/superkuh/vsrt_null.log

((488−8)/4)/60 = 2

To know what time a log record corresponds to, take the time from the filename and then add 0.5 seconds * the index of the 4 byte entry in the binary log. This should be possible to write into the until loop so it outputs time instead of just index $i. The below example is a hacky version of my log parser that does just this. Here's an example output.

# UTC Epoch	# Beat Freq Bins
1371229380.0,	1.38292284646013e-06
1371229380.5,	1.37606230055098e-06
1371229381.0,	1.374015937472e-06
1371229381.5,	1.366425294691e-06
1371229382.0,	1.35845414206415e-06
1371229382.5,	1.36476899115223e-06
1371229383.0,	1.36480070977996e-06
1371229383.5,	1.36444589315943e-06
1371229384.0,	1.35775212584122e-06
1371229384.5,	1.36395499339415e-06
1371229385.0,	1.35322613914468e-06
1371229385.5,	1.36412847950851e-06
1371229386.0,	1.36531491534697e-06
1371229386.5,	1.3664910056832e-06
1371229387.0,	1.36144888074341e-06
1371229387.5,	1.35596496875223e-06
1371229388.0,	1.35830066483322e-06
1371229388.5,	1.3654090480486e-06
1371229389.0,	1.358990175504e-06
1371229389.5,	1.37098015784431e-06
1371229390.0,	1.387945303577e-06
1371229390.5,	1.38286770834384e-06
1371229391.0,	1.36734763600543e-06
1371229391.5,	1.36036248932214e-06
...
#!/usr/bin/perl
use DateTime;
use warnings;
use strict;

# The simplest possible gnuplot plot using this program's output.
# ./vsrt_log_timeplot.pl /home/superkuh/vsrt_2013.06.14.12.03.00.log > whee2.log
# gnuplot> plot "./whee2.log" using 1:2 title "VSRT Test" with lines

my $data = '/home/superkuh/vsrt_2013.06.13.12.26.47.log';
my $bytelength = 4; 
#my $format = "V"; # oops, not this unsigned 32 bit (little endian)
my $format = "f"; # float
my $num_records;

if ($ARGV[0]) {
	$data = $ARGV[0];
} else {
	print "you need to pass the log file path as an argument.";
	exit;
}

my $dt; # declare datetime variable globally
extracttime($data); # $dt now has date object.

open(LOG,"$data") or die "Can't open log.\n$!";
binmode(LOG);

my $i = 0;
until ( eof(LOG) ) {
	my $record;
	my $decimal;
	read(LOG, $record, $bytelength) == $bytelength
		or die "short read\n";

	$decimal = unpack($format, $record);

	# This is a stupid/fragile way to deal with datetime
	# not having enough precision. It only works if the
	# record to record interval is always 0.5 seconds.
	my $recordtime = $dt->epoch();
	if (0 == $i % 2) {
		printf("$recordtime.0,\t$decimal\n", $decimal);
	} else {
		printf("$recordtime.5,\t$decimal\n", $decimal);
	}

	$dt->add( nanoseconds => 500000000 );
	$i++;
}

sub extracttime {
	my $timestring = shift;
	# /home/superkuh/vsrt_2013.06.13.12.26.47.log
	$timestring =~ /(\d{4}\.\d{2}\.\d{2})\.(\d\d\.\d\d\.\d\d)/;
	my $year_month_day = $1;
	my $time = $2;

	my ($year,$month,$day) = split(/\./, $year_month_day);
	$time =~ s/\./:/g;
	my ($hour,$minute,$second) = split(/:/, $time);

	$dt = DateTime->new(
		year       => $year,
		month      => $month,
		day        => $day,
		hour       => $hour,
		minute     => $minute,
		second     => $second,
		time_zone  => 'America/Chicago',
	);

	$dt->set_time_zone('UTC');
	return 1;	
}

Now I just have to make up a good gnuplot format and integrate the calls into the perl script.