-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello everybody,
since we found out that the Atmel SAM3U SSC interface is only capable
of transporting 500ksps worth of I/Q data, we heard a lot of
complaining because of the too narrow bandwith. Especially compared to
the rtl-sdr with about 2msps, our 500ksps was bit contrained. The
fact, that the OsmoSDR is much more sensitive to very small signals
and brings a 14bit ADC instead of 8bits did not really compensate for
the bandwidth loss.
Also the mismatch between E4000 output resistance and ADC input
brought some unwanted spectral effects.
Instead of just releasing stuff, we decided to fix both issues: I now
have a prototype with simple stack-on-board, that adds two op-amps to
decouple the E4000 from the ADC and lower the impedance and also this
board connecteds the available FPGA pins to the MCI (SD-Card)
interface of the Atmel SAM3U.
For this to get working, we had to rewrite major parts of the ARM
firmware and the FPGA VHDL code. Today this work is completed and I
can report success: The OsmoSDR now delivers up to 4msps at 14bits.
Also the strange peaks around Niquist/zero frequency are gone.
Find a screenshot of SDRangelove recording a DAB signal at 2msps
(SDRangelove needs some more love until it can cope with 4msps in
realtime - but we have verified that 4msps works without dropped
samples using the builtin FPGA test mode).
http://www.cdaniel.de/download/osmosdr-dab-2mhz.png
We will now integrate the changes into the OsmoSDR mainboard and
reroute the now free SSC pins to the pin headers instead of the MCI
interface. Also we will add the opamps.
For the already produced OsmoSDR boards, we will have more of the
prototype stack-on-top-boards.
We will keep you in the loop!
Best regards,
Christian
PS: Regarding the DAB screenshot:
- - The horizontal lines are correct - DAB uses a so called "pilot
symbol", which only has energy on a few carriers. That's why it looks
like a pause in the signal.
- - The vertical line is also correct - DAB does not use the middle
carrier to avoid I/Q offset problems on the transmitter side.
- --
- ---------------------------------------------------
| maintech # Dipl. Inf (FH) Christian Daniel |
| GmbH ### Otto-Hahn-Str. 15 · D-97204 Höchberg |
- ---------------------------------------------------
| AG Würzburg, HRB 8790 Tax-ID DE242279645 |
- ---------------------------------------------------
| http://www.maintech.de cd(a)maintech.de |
- ---------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQfuMIAAoJEHkgzUIsAWriHA0IAI2Agg0vnjLFa5dDpxu9AAkq
6crr1Q/XAgrlmN8TY86yoYTMjJc7IZmjsAAGpidczZtSbwbmLFuTdQEo12dOvaZZ
GvkvNttoDE2zsnbU50MzWDK5BUcbfOJoQahX26P+8hbiaIsFKT8Gl8Ao9c2vz79u
e04Cl2SodmDDKnV84VL9i39+KZdkGcsbCWnFizqGzTbWyDkoSVviZORp20a3lCEZ
g8Af73jwDgVAU4lfrK9gO10G5jibHkQeULNIXFH8NbDiUPSF2557fGsu/9yC1UUC
msT0g41x8twb5nesT4ZtWDfQ3tUBgvLHn/ebv9xBxCX1Wg1W2FAFlcajbXx4zRQ=
=Taca
-----END PGP SIGNATURE-----
I'm running Ubuntu 12.04 and after installing all the latest security and
recommended updates, I'm having problems with the rtlsdr library relating
to rtlsdr_cancel_async. For example:
rtl_sdr -f 739000000 -n 1000000 cap.dat
The above will successfully capture exactly 1M samples into cap.dat, but it
will not exit after the capture is finished. I have to break out with
ctrl-c.
Anybody having similar problems? Hoping I don't have to re-install
Ubuntu... :(
James
--
*Integrity is a binary state - **either you have it or you don’t.* - John
Doerr
Hi list, hi Michel,
I'm new here, but have been working on the same solution as you are, but
for an Amsat all sky tracking receiver.
First, let me point you to the signal processing textbook I've been working
my way through: dspguide.com. It can be a bit verbose for a textbook, but
that's been to my advantage several times.
I've run into two clear obstacles trying to build an interferometric
array. Both have to do with clock synchronization. First is clock drift.
No matter how expensive the crystal, or precise the temperature control,
two clocks are going to drift with respect to each other. I'm planning on
solving this one by pulling the crystal off the dongles and replacing it
with a clock input that I'll pipe from one single clock/crystal out to each
dongle. I'm assuming that I'll have to use equal length cables to keep my
timing correct.
The second problem is synchronizing the separate data streams so I know
which samples were taken at the exact same time. This one is a bit
trickier, and I don't think there's a hardware solution for it. Most
multichannel data acquisition systems have a trigger system to solve this,
where all the channels get initialized but don't start to capture until the
trigger is received. Unfortunately I don't think there's a trigger input
pin anywhere in our dongles.
There is another way, and that's find a known RF signal that we can use for
synchronization. GPS would be ideal, because there's explicit solutions for
time offsets/drift that's referenced to atomic clocks. We could record 5
minutes or so on the L1 band before an observation, then mid-capture tune
to our frequency of interest...assuming we can shift the e4k chip without
interupting the RTL2832 in it's capture sequence.
Does anyone here know if this is possible? Shift the tuner without
interupting the capture?
This does require a wide band antenna, best options seem to be spiral and
conical spiral. There's probably other options, like an active gps patch
antenna that's duplexed in with a frequency specific duplexer, but I'm not
much of an rf guy and I like the simplicity of the single wide band antenna.
I've also been looking at options for building out an array, I've seen
reports that a good LNA can get 20dB in SNR, but a wideband preamp runs $70
on minicircuits website. Plus the cost of a bias T and a clean power
supply. And I'm not sure that I understand all the built-in options for
amplification and filtering yet. That design trade is still pretty fuzzy.
It might be more cost effective to just buy more dongles and get better SNR
through summing their outputs. More research required!
> There is another way, and that's find a known RF signal that we can use for
> synchronization. GPS would be ideal, because there's explicit solutions for
> time offsets/drift that's referenced to atomic clocks. We could record 5
> minutes or so on the L1 band before an observation, then mid-capture tune
> to our frequency of interest...assuming we can shift the e4k chip without
> interupting the RTL2832 in it's capture sequence.
>
I'm not very familiar with your application, but you may also have to do
sub-sample time offset estimation and compensation. Even though all of the
dongles are running at exactly the same sampling *rate*, their sampling *
instants* will likely be different. This is despite the fact that you used
the same length of cable to feed the clock to all the dongles. For example,
if you want a 2.88MHz sampling rate, this will involve dividing the 28.8MHz
input by a factor of 10. One dongle might use edge numbers 0, 10, 20, 30,
... of the source clock to produce the 2.88 MHz clock and another might
used edge numbers 3, 13, 23, 33, .... Their sampling frequencies will be
exactly the same, but the sampling instant will be different.
> Does anyone here know if this is possible? Shift the tuner without
> interupting the capture?
>
I can confirm that you can do this since this is what I did in my LTE cell
scanner to improve search speed. I configured the A/D rate once, and then I
just kept changing the LO frequency.
The thing is that once you change the LO frequency, the phase rotation of
the received signal will change randomly for all the dongles. So, during
the calibration phase, you might find that dongle 1 needs a time correction
of t1 and phase correction of p1 to get its signal to align with the signal
from dongle 2. After you change the LO, dongle 1 will still need the same
time correction (t1), but you wont know what phase to use. Perhaps phase
alignment isn't necessary for your application?
BR,
James
--
*Integrity is a binary state - **either you have it or you don’t.* - John
Doerr
Hello everyone, I hope this is an appropriate forum for a beginner
question about using an E4000 dongle.
I'm an amateur astronomer, and lately I've been wanting to get into
amateur radio astronomy. The rtlsdr seems like a really cheap way to
get involved. It can tune many interesting frequencies, in particular
channel 37 around 608-614 Mhz.
I am a Python programmer by trade so I am using roger-'s amazing
pyrtlsdr library which is great, I can read samples from the device
and they get returned as numpy arrays. The scipy.signal package
allows me to correctly decimate the signal and I am working on a
simple graphing program to graph signal levels in realtime, by hour,
by day, and by week. I hope to basically reproduce the Jansky
experiment that started the entire science of radio astronomy:
http://en.wikipedia.org/wiki/Karl_Guthe_Jansky
I have a question though about how to use the dongle that I can't
quite figure out. roger-'s demo_waterfall program, for example, sets
the default sample_rate to 1.4e6, but then on each scan only calls
read_samples(2**16). The demo displays the entire megahertz of
bandwidth, so I'm a bit confused as to how the 64K samples map onto
the 1M samples of the device. It doesn't seem to make sense taht the
device only returns the first 64K samples. Can anyone clue in a total
beginner on the sample rate and reading samples from the device
correlate?
Thank you!
-Michel
Hi,
I have USB DVB-T stick. Possibly add suport for rtl-sdr?
Name: MSI DIGIVOX Micro HD (Dexatek clone?, i see black diamond design, same as Dexatek, and i found 1d19 = Dexatek)
USB ID (from linux and windows): 1d19:1104
Working (very old) driver for linux rtl2832u, my linux very old, i cannot complile the current rtl-sdr because libusb, etc. too old.
I will ugrade to new linux, but requies long time. I not know how to identify the tuner, but from dmesg i think this device use rtl2832 chipset + FC2580 tuner
I try with nightly build sdl-sharp, and the latest http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip on windows, no succes.
mngc
Hello Guys,
First of all: I am amazed by your project - many ideas come up in my
head what can be done with this tiny cheap SDR.
I have tested rtl_sdr with a linux-vm on my Mac successfully but
wanted to run it on my raspberry pi.
Unfortunately and thithout an explainable reason to me the tools
detect an E4000 instead of the soldered FC0013 on my stick - but only
on the PI.
To fix this issue I have changed the detection order in librtlsdr.c:
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 3a67b53..cb34f1d 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1073,13 +1073,6 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index)
/* Probe tuners */
rtlsdr_set_i2c_repeater(dev, 1);
- reg = rtlsdr_i2c_read_reg(dev, E4K_I2C_ADDR, E4K_CHECK_ADDR);
- if (reg == E4K_CHECK_VAL) {
- fprintf(stderr, "Found Elonics E4000 tuner\n");
- dev->tuner_type = RTLSDR_TUNER_E4000;
- goto found;
- }
-
reg = rtlsdr_i2c_read_reg(dev, FC0013_I2C_ADDR, FC0013_CHECK_ADDR);
if (reg == FC0013_CHECK_VAL) {
fprintf(stderr, "Found Fitipower FC0013 tuner\n");
@@ -1088,6 +1081,13 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index)
goto found;
}
+ reg = rtlsdr_i2c_read_reg(dev, E4K_I2C_ADDR, E4K_CHECK_ADDR);
+ if (reg == E4K_CHECK_VAL) {
+ fprintf(stderr, "Found Elonics E4000 tuner\n");
+ dev->tuner_type = RTLSDR_TUNER_E4000;
+ goto found;
+ }
+
/* initialise GPIOs */
rtlsdr_set_gpio_output(dev, 5);
After compiling the lib the FC0013 is detected and the sticks works
great on my Pi.
Of course this is not a perfect solution and I will figure out later
in depth WHY the E4K_CHECK_VAL comes out of the FC0013.
Anybody else who has or had the same problems?
the Hardware used is:
Bus 001 Device 004: ID 0ccd:00b3 TerraTec Electronic GmbH NOXON DAB/DAB+ Stick
regards
Christoph
Hello,
I have found what I think is a bug in rtl_fm.c : on line 171 there is
if (fm->prev_index < (fm->downsample)) {
but fm->prev_index start at -1 so to get an undersampling of factor
fm->downsample, one should have
if (fm->prev_index < (fm->downsample-1)) {
Without this correction, I get underruns, with this one, there is no
underrun.
Moreover, I have tried the idea of
http://www.embedded.com/design/embedded/4212086/DSP-Tricks--Frequency-demod…
to avoid atan :
+int polar_discriminant2(int ar, int aj, int br, int bj)
+{
+ int cr, cj;
+ double angle;
+ angle = (double)(ar * (aj - bj) - aj * (ar - br)) / (double)(ar*ar + aj*aj);
+ return (int)(angle*(1<<12));
+}
Finally, to get good results, I use these parameters :
DEFAULT_BUF_LENGTH (32 * 16384)
capture_rate = 2304000
fm->downsample = 12
fm->post_downsample=8
sample_rate = 24000
Best regards,
Alain Prignet
Hi There
I have been working with a Sweex USB dongle that has the RTL3282u -
FC0012 chipset.
Its id is "1f4d:a803 G-Tek Electronics Group"
I have been able to get it working with rtl_sdr and rtl_fm.
Can you add its id to the source code for others to use.
Andrew Harrison.
I've ported my app to use rtl_tcp.exe instead of the native rtlsdr libs,
and while it is partly working (samples reading correctly, no dropped
samples, etc.), I have run into two issues.
First--when I start reading samples too quickly after setting the sample
rate, I get this error:
C:\Users\Scott
Cutler\Projects\p4\0\projects\sdr\SeeDeR\SeeDeR\rtl-sdr-release\x32>rtl_tcp.exe
-f 100000000 -s 2048000
Found 1 device(s).
Found Elonics E4000 tuner
Using Generic RTL2832U (e.g. hama nano)
Tuned to 100000000 Hz.
listening...
Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR (gr-osmosdr)
source
to receive samples in GRC and control rtl_tcp parameters (frequency,
gain, ...).
client accepted!
set freq 105000000
set sample rate 1920000
worker cond timeout
Signal caught, exiting!
comm recv socket error
Signal caught, exiting!
all threads dead..
listening...
Use the device argument 'rtl_tcp=127.0.0.1:1234' in OsmoSDR (gr-osmosdr)
source
to receive samples in GRC and control rtl_tcp parameters (frequency,
gain, ...).
If I instead wait about two seconds after setting the sample rate, there
is no problem. There is also no problem if I immediately read samples
after connecting, where I set the sample rate on the command line.
The other issue is that tuning is very slow--about one second per call
to rtlsdr_set_center_freq. I had a similar problem with the rtlsdr.dll
library, and I found that tuning was very slow if performed from the
main thread, but fairly quick (maybe 10-20 hz) if done from the async
proc thread that rtlsdr_read_async launches.
That seemed a bit odd to me but it worked. I suspect that rtl_tcp.exe
is doing the same thing; calling rtlsdr_set_center_freq from the main
thread.
Ideas, anyone? Thanks!
-Scott
PS: I'm running Win7-64, in case it matters. Also using the latest
version here:
http://sdr.osmocom.org/trac/attachment/wiki/rtl-sdr/RelWithDebInfo.zip