Hi again,
I am working on my own SDR project for Stereo FM radio support, but i
would like to also improve quality for rtl_fm application, i made
unoficial patch to add:
Complex FIR - to filter strong signals close to wanted signal
Real FIR - to filter pilot from FM
Stereo FIR
Stereo Deemphasis
AGC support - it can give better resolution of IQ data
Some other improvments in FM radio code.
All FIR filters has 3 possible variants, simple, LUT, SSE2 instricts, of
course SSE is the fastest one and it should works on Intel Atoms, but
not on ARM.
Feel free to use any part of code in any of you programs, I know that
this code is little to much to add it into rtl_fm, but maybe it could
somebody help to recieve HW stereo FM radio.
Speed of SSE code is much better than anything you can get around here,
on Core i7 it consume only 5% of one CPU, so i could demodulate at least
80 channels at the same time in stereo quality of course.
I tried this code only on AMD64 and GCC Linux, so i am not sure if it
can be compiled under windows.
--
Miroslav Slugeň
+420 724 825 885
Teramos Multimedia s.r.o.
Hi there!
I'm using a dongle on a raspberry + rtl_tcp and sdrsharp on another
machine (quad core.... 3gb ram...good machine!)
The problem occour at 00:57
http://www.youtube.com/watch?v=4E2MPfEzEi8
and at 1:34 in this video:
http://www.youtube.com/watch?v=8snz1wQSRpw
If i stop and start sdrsharp, it works ok for some minutes...then the
problem is up again!
No errors appear on the console of raspberry/rtl_tcp
I'm not able to understand if it's a problem of rtl_tcp,raspberry or
whatelse...
Things i've tryed:
1) Changed the samplerate
2) Changed the raspberry (tested tp1/tp2 too...getting 4.98v!!!)
3) Changed the dongle
4) Updated sdrsharp
The dongles tryed work ok on a pc
I've no more idea....
Anyone can help me?
PS: If someone know a program that works in linux and is similar to
sdrsharp AND CAN INTERFACE TO A REMOTE RTL_TCP...
Hi,
I've been working on a project the involves tuning VOR signals. They are
narrow band signals. > 25 kHz. For that, the wide bandwidth of the RTL
dongles isn't that helpful to me. (and actually a hindrance when two
signals are inside the sample range but widely different strengths)
Anyway, the lowest I can get my dongles (R820T) to go is 250ksps, which is
fine. I've been working at that frequency for awhile, but getting some
strange results. For example, if I tune in to 116.8 MHz, which should be
the OAK VOR, it works fine. But if I tune to 115.8 MHz, which should be the
SFO VOR I get ... the OAK VOR. That is, there is a perfect copy of the OAK
signal 1 MHz shifted down.
If I switch the sample rate to 1.024Msps or 900ksps, I don't get this
problem.
I don't understand what is happening here. 1 MHz is an even multiple of
250kHz, so maybe I'm getting an image of OAK overpowering the relatively
weaker SFO signal. But should there not be filters that manage this?
I guess I was expecting that if the device is set to 250ksps, then it would
"close down" filters appropriately to reject signals out of that band. But
maybe the filters don't work properly below a certain sample rate? Like the
rtl2832 can sample down to 250ksps, but the 820T tuner was not designed for
it?
Or perhaps I'm doing something wrong? Can I control the filters directly?
I'm glad I find this issue because I was going nuts thinking my software
had some mysterious bug. But I can reproduce this issue just with SDR# or
whatever. :-)
Regards.
Dave J
Hi,
I want to use multiple rtl-sdr dongles to do some multi-antenna experiments.
Is it possible to read IQ samples from multiple rtl-sdr dongles in a
synchronized manner?
I already have a glance at dump1090 codes, which is a project using rtl-sdr
to decode aircraft broadcasting ADS-B messages in 1090MHz.
Seems that I should use rtlsdr_read_async() instead of rtlsdr_read_sync(),
because that if rtlsdr_read_sync() is used, I have to call it multiple
times sequentially. That looks not synchronized.
But rtlsdr_read_async() function only accept one rtl-sdr device as input
parameter, and it will be blocked after it is called. So seems that it also
can't be used for my purpose directly.
Also welcome any opinion on how to improve rtl-sdr lib/driver to support
this feature.
Thank you.
BR
Jiao Xianjun
Hi all,
time is moving fast, and I want to start some initial discussion and
planning for OsmoDevCon 2014.
There are basically four questions which I'm raising below. Please
provide your feedback to the osmocom-event-orga mailing list only, to
avoid cross-posting over all the project lists.
= Who? =
My intention is to keep it an 'active developer/contributer only' event,
like we had it before. I would also want to keep the group relatively
small, to keep the 'Osmocom family' atmosphere.
If desired, we could have one half or full day of public prsentations in
a larger auditorium, but the developer meeting should be a close group,
as known so far.
= Where? =
If we keep the number of attendees within the same range as this year,
then I'm sure we could again hold it at the same venue. I know it is
not perfect, but it is a place that we have access to, 24 hours per day,
and free of cost for community projects like osmocom.org.
If the community wants a larger event, then this is something that would
require more funds and much more time organizing. And that is something
that I personally could not offer to take care of, sorry. I'm happy to
attend and support any larger events, but I'm unable to take care of
fundraising and venue research.
= When? =
Q1/2014. In January, I'm not aware of any 'blocker' events. February,
there is Fosdem (Feb 1 + Feb 2), and MWC from Feb 24 through Feb 27. In
March there is CeBIT (March 10-14) and Easter holidays (with EasterHegg
March 17-21). Did I miss any other FOSS / mobile event that might clash
in Q1?
So my preference woudl be to do it either late January (23-26) or in
February (6-9 or 13-16). Any preferences regarding preferred schedule?
Once we have some concencus here on the list [and we want to do it in
the same size / venue], I'll talk to IN-Berlin.
= What? =
I think that question is easy to answer, if we have the above three
figured out... There's no shortage of topics, I suppose.
You can start adding your suggestions to
http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2014
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
During implementation of signal strength calculations I came across some
problems with E4000 tuners.
The RTLSRD library uses these E4000 gains:
const int e4k_gains[] = { -10, 15, 40, 65, 90, 115, 140, 165, 190,
215, 240, 290, 340, 420 };
These are the gains from Table 6 of the data sheet plus the mixer gain
of 12 db for the last value and 4 db for all others. But the last gain
of 30 db from Table 6 is only valid when LNA gain enhancement is enabled.
Cite from datasheet section 1.16 LNA Gain enhancement:
"The LNA gain numbers quoted throughout this document assume that this
register is programmed to the recommended value."
The RTLSDR libary actually does not change the LNA gain enhancement
register AGC11 with manual gain mode and clears it with automatic gain
mode. So the last two values of the e4k_gains array must be:
290 = 250 + 40 (max. LNA gain + low mixer gain)
370 = 250 + 120 (max. LNA gain + high mixer gain)
With enabled LNA enhancement, the last value would be
420 = 250 + 120 + 50 (max. LNA gain + high mixer gain + enhancement)
However, enabling LNA gain enhancement did not work (like the larger LNA
gain step size of 5 db).
I have verified the above by measuring pure carrier signals of different
strength using FFT and subtracting the total gain. Using the corrected
values, the changings in the measured signals correspond to the
changings of the transmitted signal. With automatic control, the values
has been also compared with the input power calculated from
the RSSI indicator and LNA gain.
The second to last value of Table 6 is also 25 db. I assume that this is
a misprinting and the correct value is 22.5 db. Then the corresponding
e4k_gains array entry must be changed from 290 to 265.
Mixer Gain (automatic mode)
In automatic mode, the mixer control register AGC7 is set to 0x01. This
will enable autonomous control with a threshold value of zero resulting
in always using the high mixer gain of 12 db.
When the received signal is inside the automatic gain range (> -50 dbm),
the output voltage of the LNA is so high that applying any amplifying
afterwards usually results in overdrive samples. Therefore, the
automatic mixer gain should be disabled or set to switch to high mixer
gain at max. LNA gain by setting control register AGC7 to 0x1D.
For the same reason, the total IF gain should be set to less than 10 db.
Applications using automatic gain control can then increase the IF gain
when the input signal is below -50 dbm to extend the sensitivity range.
NOTE: Section 1.15.2 of the datasheet states that writing 0x15 to AGC7
corresponds to a LNA gain threshold of 7.5 db. This is obviously wrong
(verified by reading the mixer Gain2 register with different signals).
I hope this is helpful
Jochen Arndt
A quite good (AM/SW)/FM/DAB/DVB-T USB dongle.
Mirics FlexiTV MSi3101 (two chips MSi001+MSi2500)
http://www.mirics.comhttp://www.mirics.com/node/31
Data sheets available, register yourself at Mirics portal.
RF Tuner: MSi001/MSi002 ( used by FUNcubrePro+ ?), seems better than R820T
ADC and HiSpeed USB interface: MSi2500 . ADC 10 bit , better than
8 bit RTL2832U aDC.
Windows binary software available: FMDABplayer, DVB_T decoder,
Windows lib.dll and API doc.
IO-DATA GV-TV100 stick sold on Japan .
Stick, chips and dev board available from Mirics.
Linux software at address
http://cgit.osmocom.org/libmirisdr/
It seems project on stand-by .
Can author Steve Markgraf comment ?
Francesco
I've been thought-experimenting with capturing data from two devices and
measuring their correlation. For example, if two rtl-sdr processes are
launched to read one sample block from two devices, how closely do the two
devices' samples line up with each other in time?
I'm expecting that there will be no reliable correlation. My working
theory is that each process calls into libusb_handle_events_timeout
according to its own process schedule and that there is no way to
coordinate these two calls to happen closely enough in time for the
transfers to happen in a more synchronized fashion. Threads do not appear
to be any better solution to the problem. I'm not an expert in usb
transfers, or libusb, or rtlsdr for that matter, so I'm going only on what
I can glean from reading the source code of librtlsdr.c and libusb
documentation.
libusb does say however that it can specifically handle multiple devices in
one async loop. Multiple bulk transfers can be set up to multiple devices
in one process, and one call to libusb_handle_events_* can be used to
handle those transfers. My thinking is that because the triggering event
for both samples is now the same function call in the same process, the
samples will be more synchronized, ideally down to some reliably offset of
say a few microseconds. Juha Vierinen's hard-hack to make two devices use a
coherent sample clock makes this idea even more interesting to me.
But, it doesn't look like librtlsdr can handle multiple devices. I'm game
to take a stab at a patch that can extend its functionality. But I wanted
to run this idea by the community first before spending code time on
figuring this out. Do the experts here think that there is any potential
benefit to be gained by taking this approach?
-Michel
*>>>Please humor me. How are you determining that the gain is not being
set?*
See my previous message with Baudline captures:
~$ rtl_fm -f 89000000 -R -s 1000000 -g 0 - | baudline -stdin -samplerate
1000000 -quadrature -flipcomplex -channels 2 -format le16
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000013
Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Oversampling input by: 2x.
Oversampling output by: 1x.
Buffer size: 4.10ms
Tuned to 89500000 Hz.
Sampling at 2000000 Hz.
Output at 1000000 Hz.
Exact sample rate is: 2000000.052982 Hz
Tuner gain set to 0.00 dB.
Result: https://dl.dropboxusercontent.com/u/102802145/baudline0dB.jpg
~$ rtl_fm -f 89000000 -R -s 1000000 -g 30 - | baudline -stdin -samplerate
1000000 -quadrature -flipcomplex -channels 2 -format le16
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000013
Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Oversampling input by: 2x.
Oversampling output by: 1x.
Buffer size: 4.10ms
Tuned to 89500000 Hz.
Sampling at 2000000 Hz.
Output at 1000000 Hz.
Exact sample rate is: 2000000.052982 Hz
Tuner gain set to 29.70 dB.
Result: https://dl.dropboxusercontent.com/u/102802145/baudline30dB.jpg
GQRX, LNA gain = 0dB
Result: https://dl.dropboxusercontent.com/u/102802145/gqrx0dB.jpg
GQRX, LNA gain=30dB
Result: https://dl.dropboxusercontent.com/u/102802145/gqrx30dB.jpg
I know its very strange but I lost two days trying to make work a project
here before I realized rtl_fm was outputting only noise.
Hi again.
I noticed a strange behaivour from RTL-SDR source in GNU-Radio 3.7.1
When sample rate is set to 900ksps, actual output sample rate is only 300
ksps.
You can check this easily connecting a RTL_SDR Source to a WX Gui FFT Sink
and a RF signal generator.
For example, on RTL-SDR Source set sample rate to 900000 and frequency to
144000000 Hz.
On the WX GUI FFT Sink, set sample rate to 900000 and base frequency to
144000000 Hz.
Now apply a signal on 144.1 MHz. The FFT Display will show it at 144.3 MHz.
Apply a signal on 144.05 MHz. The FFT Display will show it at 144.15 MHz.
Now on the WX GUI FFT Sink, set sample rate to 300000 and repeat the above
steps. The signal will be displayed at its right places.
Interestingly, setting sample rate to 1Msps works fine.
Tested with both E4000 and R820T dongles.
Any advice?
Thank you!
Hello!
I noticed a problem with rtl_fm and r820t tuners. In few words, it doesn't
matter what value of gain you set with the -g parameter. The r820t tuner
will be always at its lower gain, this is deaf as a doorknob.
Otherwise, the same dongles works fine with GNU Radio or GQRX for example,
and gain can be set without problems.
rtl_fm gain works nicely on e4k tuners.
Someone else have noticed this?
Hello,
Make ouputs the following error messages when building the latest commit
of gr-osmocomsdr [rev:0d10f5e9bc950d6d2b3c39ae574e2d325a0fbeb6]
$ make
Scanning dependencies of target gnuradio-osmosdr
[ 2%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/source_impl.cc.o
[ 5%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/sink_impl.cc.o
[ 8%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/ranges.cc.o
[ 11%] Building CXX object lib/CMakeFiles/gnuradio-osmosdr.dir/device.cc.o
[ 13%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/fcd/fcd_source_c.cc.o
[ 16%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/file/file_source_c.cc.o
[ 19%] Building CXX object
lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o
/home/joel/src/gr-osmosdr/lib/rtl/rtl_source_c.cc: In member function
‘virtual osmosdr::freq_range_t rtl_source_c::get_freq_range(size_t)’:
/home/joel/src/gr-osmosdr/lib/rtl/rtl_source_c.cc:467:26: error:
‘RTLSDR_TUNER_R828D’ was not declared in this scope
} else if ( tuner == RTLSDR_TUNER_R828D ) {
^
make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/rtl/rtl_source_c.cc.o]
Error 1
make[1]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2
make: *** [all] Error 2
OS: Fedora 19 x64
I am currently using the previous commit:
b8441496288aa319f4aeaabd9df63c58be53e916 which builds fine on my
workstation. I haven't tested the commits made between this and the
latest revisions.
Regards,
Joel
Woops, the mistake I am making is that the dongles are independent USB
devices, there is no way to synchronize each Dongle's Acquisition. This is
another reason to interface these Dongles with a BusPirate and 24bit Audio
Board.
From: osmocom-sdr-bounces(a)lists.osmocom.org
[mailto:osmocom-sdr-bounces@lists.osmocom.org] On Behalf Of Jay Salsburg
Sent: Tuesday, November 12, 2013 3:58 PM
To: osmocom-sdr(a)lists.osmocom.org
Subject: RE: multiple devices in one process?
USB 2.0 has a built-in hardware latency. If you are unwilling to go through
the trouble of special coding, be sure to use the USB Dongles alone on their
own PCI USB Card, this will minimize latency.
Hardware may be forced to respond at will if Assembly Code is used to
exercise the interfaces, utilizing acquisition calls controlled by processor
interrupts. A Real Time Clock (RTC) in internal Hardware or an external RTC
can be used to trigger Processor Interrupts initiating any function in the
(Assembly) code and attached hardware.
Using a patch will not work with any reasonable accuracy, depending on the
Hardware, (an educated guess) of a many microseconds. Patching indicates
high level control (high level language like C++, Python, etc), only low
level control will call the hardware anywhere near the timing desired. If
you are to access two different devices, their data should be both buffered
together in parallel through a first-in-first-out buffer, perhaps even with
the RTC time stamp to quantize the packets therefore allowing subsequent
coherence in post processing. In high speed audio and video interfaces, very
high speed is used, like Firewire and Thunderbolt to stream the data into
memory, eliminating most of the hardware latency you are experiencing. The
maximum acquisition rate for USB 2.0 is about 48,000 samples per second,
times 24 bit depth, times 8, and that is for a fast computer doing nothing
else but recording the data stream.
From: osmocom-sdr-bounces(a)lists.osmocom.org
[mailto:osmocom-sdr-bounces@lists.osmocom.org] On Behalf Of Michel Pelletier
Sent: Sunday, November 10, 2013 11:14 PM
To: osmocom-sdr(a)lists.osmocom.org
Subject: multiple devices in one process?
I've been thought-experimenting with capturing data from two devices and
measuring their correlation. For example, if two rtl-sdr processes are
launched to read one sample block from two devices, how closely do the two
devices' samples line up with each other in time?
I'm expecting that there will be no reliable correlation. My working theory
is that each process calls into libusb_handle_events_timeout according to
its own process schedule and that there is no way to coordinate these two
calls to happen closely enough in time for the transfers to happen in a more
synchronized fashion. Threads do not appear to be any better solution to
the problem. I'm not an expert in usb transfers, or libusb, or rtlsdr for
that matter, so I'm going only on what I can glean from reading the source
code of librtlsdr.c and libusb documentation.
libusb does say however that it can specifically handle multiple devices in
one async loop. Multiple bulk transfers can be set up to multiple devices
in one process, and one call to libusb_handle_events_* can be used to handle
those transfers. My thinking is that because the triggering event for both
samples is now the same function call in the same process, the samples will
be more synchronized, ideally down to some reliably offset of say a few
microseconds. Juha Vierinen's hard-hack to make two devices use a coherent
sample clock makes this idea even more interesting to me.
But, it doesn't look like librtlsdr can handle multiple devices. I'm game
to take a stab at a patch that can extend its functionality. But I wanted
to run this idea by the community first before spending code time on
figuring this out. Do the experts here think that there is any potential
benefit to be gained by taking this approach?
-Michel
_____
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3426 / Virus Database: 3222/6830 - Release Date: 11/12/13
_____
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3426 / Virus Database: 3222/6830 - Release Date: 11/12/13
David Jacobowitz wrote:
> So, is there any way to line up samples post-hoc?
Of course you can develop an elaborate hardware+software system to
inject, recover, and sync onto an in-band clock.
Or you could just buy hardware which already does what you need.
//Peter