- osmocom-sdr - lists.osmocom.org

stroboscopic (aka equivalent time sampling) using EZCAP DVB dongle ?
by friedtj 09 Jul '12

09 Jul '12

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

6 11

Disabling RTL2832 AGC
by Francesco Gugliuzza 08 Jul '12

08 Jul '12

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

4 7

cleanup patch
by Stefan Sydow 07 Jul '12

07 Jul '12

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)

1 0

rtl-sdr web git interface not updating
by Francesco Gugliuzza 07 Jul '12

07 Jul '12

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

2 2

Linrad with rtlsdr with and the e4000 tuner.
by Leif Asbrink 05 Jul '12

05 Jul '12

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

6 12

Super Efficient SMD Schottky Barrier from Comchip Technology Corporation
by Jay Salsburg 30 Jun '12

30 Jun '12

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

1 0

RTL direct sampling
by Adam Nielsen 24 Jun '12

24 Jun '12

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.

1 0

Caputed RTL-SDR file for playing around?
by Johannes Bauer 22 Jun '12

22 Jun '12

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

2 2

v2 Prototype issues and fixes
by Sylvain Munaut 21 Jun '12

21 Jun '12

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

1 0

Tuning gap between 325 and 350 MHz
by Kire Pudsje 27 May '12

27 May '12

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.

1 0