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
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
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
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
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
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)
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
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
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.
