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
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.
Hello all,
when trying to build with autotools, I get an compile error stating that
there is a:
----
undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
----
This seems to be due to "-lpthreads" is missing when using autotools1
--
Dipl.-Ing. Joschi Brauchle, M.Sc.
Institute for Communications Engineering (LNT)
Technische Universitaet Muenchen (TUM)
80290 Munich, Germany
Tel (work): +49 89 289-23474
Fax (work): +49 89 289-23490
E-mail: joschi.brauchle(a)tum.de
Web: http://www.lnt.ei.tum.de/
I wrote for myself an octave wrapper for all functions in the header
file of the rtl-sdr library. Even the async routine generates a
callback to octave functions. The whole is a 1-to-1 mapping of the
functions, I tried to stay as close as possible to the C-library.
I do not know if it just me using octave, but if there is any interest
in this code, I could place it somewhere.
sample code:
pkg load rtlsdr
if rtlsdr_get_device_count()>0
dev = rtlsdr_open(0);
samprate=2048e3;
nsamples=2048;
rtlsdr_set_sample_rate(dev, samprate);
rtlsdr_set_center_freq(dev, 100e6);
rtlsdr_set_tuner_gain_mode(dev, 0);
rtlsdr_reset_buffer(dev);
buf = rtlsdr_read_sync(dev, nsamples * 2);
d = (double(buf) - 128) / 128.0;
d = d(1:2:end) + 1i * d(2:2:end);
f = (-.5:1/nsamples:.5-1/nsamples) * samprate;
plot(f, 20*log10(abs(fftshift(fft(d .* blackman(nsamples)') / nsamples))));
rtlsdr_close(dev);
end
There's only one warning for me when compiling rtl-sdr, which is
about the signedness of the third (size) argument in accept().
On linux it's socklen_t* and I *think* (google...) that windows
does not have socklen_t at all. In accept it uses int.
ftp://ftp.microsoft.com/bussys/winsock/winsock2/winsock2.h
WINSOCK_API_LINKAGE
SOCKET
WSAAPI
accept(
IN SOCKET s,
OUT struct sockaddr FAR * addr,
IN OUT int FAR * addrlen
);
Can someone please check if it compiles on windows with the attached
patch?
Hello group
I need help getting an EZCAP USB deviceusing rtl_sdr running under Windoz7.
This is probably the same bug reported on ticket 9 at
http://sdr.osmocom.org/trac/query
My EZCAP USB device self installs the drivers in Win7 and is recognized by
the DVBDream program. Leads me to believe my system and hardware is OK.
Below is a screen shot of what happens I try to load RTL-SDR..
I am an RF guy and a serious newby to software so can't contribute much.
Help!
Eric