17 May
2013
17 May
'13
8:56 p.m.
Hi guys,
I'm new to this list (and to radio) so I hope you will please indulge me
if I ask something that is a FAQ. Also, some of these questions are
about the dongle, not the library.
I am working on a personal project to use SDR techniques to decode
aviation navigation signals (VOR). I've got the signal processing mostly
working from recorded signals, but am now trying to integrate my SW with
the radio in real time.
I have a few questions:
- What exactly is offset tuning? How is offset tuning different from
tuning to an offset?
Is this a feature that mostly benefits people who are not going to put
their IF through another mixer? In my application I am already tuning to
an offset, and pulling down a wide enough IF that actually holds many
channels of interest. (VOR channels have 50kHz spacing). I then use a
software mixer/channelizer to choose the channel I want. Am I correct in
assuming that offset tuning is of no use to me?
- regarding AGC, what is the difference between AGC and auto gain?
That is, the library API has
RTLSDR_API int rtlsdr_set_tuner_gain_mode(rtlsdr_dev_t *dev, int manual)
RTLSDR_API int rtlsdr_set_agc_mode(rtlsdr_dev_t *dev, int on);
I'm guessing that these affect different AGCs. One for the tuner and one
for the RTL device.
What are the benefits and costs of having either or both on?
- regarding rtlsdr_read_async(...) and related functions.
I take it that the library is setting up a ring buffer and calling me
back when it has a new buffer of data for me.
How long to I have to work with this buffer? Obviously, if I want to
work in real-time I need to keep up with the sample rate. But my
application can afford to throw away buffers since it can decode a few
ms of data from one station and then revisit it much later. However, I'd
like to know how long I have until the buffer gets clobbered. I'm
presuming it's stable until all the n-1 other buffers have been hit.
- generally how fast can the RTL devices tune? I know, this is not an
rtlsdr question per se, but I'm curious. I noticed that when I tune, I
get a delay.
This is a great library and I'm so glad it's out there! I was not
looking forward to plumbing the depths of USB drivers to understand how
to pull data from the RTL dongle! I think rtl-sdr.h could use perhaps a
smidge more documentation. I'd be happy to submit a comments-only patch
if there's interest. :-)
Regards,
Dave Jacobowitz
19 May
19 May
3:28 p.m.
Hi David,
I am working on a personal project to use SDR
techniques to decode
aviation navigation signals (VOR). I've got the signal processing mostly
working from recorded signals, but am now trying to integrate my SW with
the radio in real time.
- What exactly is offset tuning? How is offset
tuning different from
tuning to an offset?
For E4000 tuners only this will shift thei 0-IF point outside of RTL
sampling bandwidth which may help if you have a wideband (DECT or such)
signal you want to sample but don't want it to be distorted by the usual
LO-leakage peak in the middle. The drawback is that you might get hit by a
image signal.
Is this a feature that mostly benefits people who are
not going to put
their IF through another mixer? In my application I am already tuning to
an offset, and pulling down a wide enough IF that actually holds many
channels of interest. (VOR channels have 50kHz spacing). I then use a
software mixer/channelizer to choose the channel I want. Am I correct in
assuming that offset tuning is of no use to me?
For narrowband signals you are good to do offset tuning yourself.
- regarding AGC, what is the difference between AGC
and auto gain?
AGC is for RTL chip, auto gain is for the tuner (if implemented).
RTLSDR_API int rtlsdr_set_tuner_gain_mode(rtlsdr_dev_t
*dev, int manual)
Works for E4000 tuners only AFAIR.
Steve: do other tuners provide AGC functions as well?
RTLSDR_API int rtlsdr_set_agc_mode(rtlsdr_dev_t *dev,
int on);
I'm guessing that these affect different AGCs. One for the tuner and one
for the RTL device.
Yes.
What are the benefits and costs of having either or
both on?
It depends on the application. While in presence of strong interference
the tuner auto gain seems to perform well on E4000 devices, the RTL gain
from my understanding only scales the signal to optimally use the dynamic
range of 8 bits. Within controlled environment (narrowband
antenna/LNA/filters) i usually let them off entirely and set the gains for
best SNR manually.
Historically we have implemented them with some time in between so now
both gains have their own setters.
- regarding rtlsdr_read_async(...) and related functions.
I take it that the library is setting up a ring buffer and calling me
back when it has a new buffer of data for me.
Yes.
How long to I have to work with this buffer?
Obviously, if I want to
work in real-time I need to keep up with the sample rate. But my
application can afford to throw away buffers since it can decode a few
ms of data from one station and then revisit it much later. However, I'd
like to know how long I have until the buffer gets clobbered. I'm
presuming it's stable until all the n-1 other buffers have been hit.
You should spend as little time as possible inside a callback, this is a
libusb requirement. You might copy some buffers to be passed to a worker
thread later on and keep skipping buffers inside the callback until your
worker thread is ready for the next shot.
- generally how fast can the RTL devices tune? I know,
this is not an
rtlsdr question per se, but I'm curious. I noticed that when I tune, I
get a delay.
Can't tell, never evaluated that myself. But again, this largely depends
on the tuner interactions involved.
smidge more documentation. I'd be happy to submit
a comments-only patch
if there's interest. :-)
This would be appreciated.
Best regards,
Dimitri
20 May
20 May
6:18 a.m.
Thanks, Dimitri. This helps a lot.
I tried to make some suggested additional comments to the header file,
which I have attached. You can take them or leave them. I think perhaps for
a sophisticated c programmer the API is obvious, but for me I needed a bit
more help.
I have also written a small program that uses the async API to serve as a
minimalist working example on how to use the library which folks might find
helpful. Based on your answers below, I just copy the buffer in the
callback into my own ring of buffers, then work on the buffers in a
separate thread.
The program just writes captured data directly to disk. It works on my
computer, but I haven't tested it extensively.
Both files are attached.
Regards,
Dave J
On Sun, May 19, 2013 at 6:28 AM, Dimitri Stolnikov <horiz0n(a)gmx.net> wrote:
Hi David,
I am working on a personal project to use SDR techniques to decode
AGC is for RTL chip, auto gain is for the tuner (if implemented).
RTLSDR_API int rtlsdr_set_tuner_gain_mode(**rtlsdr_dev_t *dev, int
> manual)
Works for E4000 tuners only AFAIR.
Steve: do other tuners provide AGC functions as well?
RTLSDR_API int rtlsdr_set_agc_mode(rtlsdr_**dev_t *dev, int on);
> I'm guessing that these affect
different AGCs. One for the tuner and one
> for the RTL device.
Yes.
What are the benefits and costs of having either or both on?
It depends on the application. While in presence of strong interference
the tuner auto gain seems to perform well on E4000 devices, the RTL gain
from my understanding only scales the signal to optimally use the dynamic
range of 8 bits. Within controlled environment (narrowband
antenna/LNA/filters) i usually let them off entirely and set the gains for
best SNR manually.
Historically we have implemented them with some time in between so now
both gains have their own setters.
> - regarding rtlsdr_read_async(...) and related functions.
> I take it that the library is setting
up a ring buffer and calling me
> back when it has a new buffer of data for me.
Yes.
How long to I have to work with this buffer? Obviously, if I want to work
> in real-time I need to keep up with the sample rate. But my application can
> afford to throw away buffers since it can decode a few ms of data from one
> station and then revisit it much later. However, I'd like to know how long
> I have until the buffer gets clobbered. I'm presuming it's stable until all
> the n-1 other buffers have been hit.
You should spend as little time as possible inside a callback, this is a
libusb requirement. You might copy some buffers to be passed to a worker
thread later on and keep skipping buffers inside the callback until your
worker thread is ready for the next shot.
- generally how fast can the RTL devices tune? I know, this is not an
> rtlsdr question per se, but I'm curious. I noticed that when I tune, I get
> a delay.
Can't tell, never evaluated that myself. But again, this largely depends
on the tuner interactions involved.
smidge more documentation. I'd be happy to submit a comments-only patch
> if there's interest. :-)
This would be appreciated.
Best regards,
Dimitri
aviation navigation signals (VOR). I've got
the signal processing mostly
working from recorded signals, but am now trying to integrate my SW with
the radio in real time.
- What exactly is offset tuning? How is offset tuning different from
tuning to an offset?
For E4000 tuners only this will shift thei 0-IF point outside of RTL
sampling bandwidth which may help if you have a wideband (DECT or such)
signal you want to sample but don't want it to be distorted by the usual
LO-leakage peak in the middle. The drawback is that you might get hit by a
image signal.
Is this a feature that mostly benefits people who are not going to put
their IF through another mixer? In my application
I am already tuning to an
offset, and pulling down a wide enough IF that actually holds many channels
of interest. (VOR channels have 50kHz spacing). I then use a software
mixer/channelizer to choose the channel I want. Am I correct in assuming
that offset tuning is of no use to me?
For narrowband signals you are good to do offset tuning yourself.
- regarding AGC, what is the difference between AGC and auto gain?
22 May
22 May
6:53 p.m.
Some slight cleanup of the trivial example and fix for correctly letting
threads return / join.
On Sun, May 19, 2013 at 9:18 PM, David Jacobowitz <
david.jacobowitz(a)gmail.com> wrote:
Thanks, Dimitri. This helps a lot.
I tried to make some suggested additional comments to the header file,
which I have attached. You can take them or leave them. I think perhaps for
a sophisticated c programmer the API is obvious, but for me I needed a bit
more help.
I have also written a small program that uses the async API to serve as a
minimalist working example on how to use the library which folks might find
helpful. Based on your answers below, I just copy the buffer in the
callback into my own ring of buffers, then work on the buffers in a
separate thread.
The program just writes captured data directly to disk. It works on my
computer, but I haven't tested it extensively.
Both files are attached.
Regards,
Dave J
On Sun, May 19, 2013 at 6:28 AM, Dimitri Stolnikov <horiz0n(a)gmx.net>wrote;wrote:
Hi David,
I am working on a personal project to use SDR techniques to decode
AGC is for RTL chip, auto gain is for the tuner (if implemented).
RTLSDR_API int rtlsdr_set_tuner_gain_mode(**rtlsdr_dev_t *dev, int
> manual)
Works for E4000 tuners only AFAIR.
Steve: do other tuners provide AGC functions as well?
RTLSDR_API int rtlsdr_set_agc_mode(rtlsdr_**dev_t *dev, int on);
> I'm guessing that these affect
different AGCs. One for the tuner and one
> for the RTL device.
Yes.
What are the benefits and costs of having either or both on?
It depends on the application. While in presence of strong interference
the tuner auto gain seems to perform well on E4000 devices, the RTL gain
from my understanding only scales the signal to optimally use the dynamic
range of 8 bits. Within controlled environment (narrowband
antenna/LNA/filters) i usually let them off entirely and set the gains for
best SNR manually.
Historically we have implemented them with some time in between so now
both gains have their own setters.
> - regarding rtlsdr_read_async(...) and related functions.
> I take it that the library is setting
up a ring buffer and calling me
> back when it has a new buffer of data for me.
Yes.
How long to I have to work with this buffer? Obviously, if I want to
> work in real-time I need to keep up with the sample rate. But my
> application can afford to throw away buffers since it can decode a few ms
> of data from one station and then revisit it much later. However, I'd like
> to know how long I have until the buffer gets clobbered. I'm presuming it's
> stable until all the n-1 other buffers have been hit.
You should spend as little time as possible inside a callback, this is a
libusb requirement. You might copy some buffers to be passed to a worker
thread later on and keep skipping buffers inside the callback until your
worker thread is ready for the next shot.
- generally how fast can the RTL devices tune? I know, this is not an
> rtlsdr question per se, but I'm curious. I noticed that when I tune, I get
> a delay.
Can't tell, never evaluated that myself. But again, this largely depends
on the tuner interactions involved.
smidge more documentation. I'd be happy to submit a comments-only patch
> if there's interest. :-)
This would be appreciated.
Best regards,
Dimitri
aviation navigation signals (VOR). I've got
the signal processing mostly
working from recorded signals, but am now trying to integrate my SW with
the radio in real time.
- What exactly is offset tuning? How is offset tuning different from
tuning to an offset?
For E4000 tuners only this will shift thei 0-IF point outside of RTL
sampling bandwidth which may help if you have a wideband (DECT or such)
signal you want to sample but don't want it to be distorted by the usual
LO-leakage peak in the middle. The drawback is that you might get hit by a
image signal.
Is this a feature that mostly benefits people who are not going to put
their IF through another mixer? In my application
I am already tuning to an
offset, and pulling down a wide enough IF that actually holds many channels
of interest. (VOR channels have 50kHz spacing). I then use a software
mixer/channelizer to choose the channel I want. Am I correct in assuming
that offset tuning is of no use to me?
For narrowband signals you are good to do offset tuning yourself.
- regarding AGC, what is the difference between AGC and auto gain?
19 Sep
19 Sep
8:38 a.m.
--
Hello to all, I am interested to decode the VOR signals. If anyone has a
trick I will be pleased to exchange emails.
thanks and best regards
Jean Marie POLARD
F5VLB
1, Boutil
22540 Louargat (France)
IN88IN
3:10 p.m.
Jean-Marie, group (and french readers)
Please find attached to this email a report from a student explaining how
to decode the VOR signals
regards
sylvain F4GKR
2013/9/19 Jean Marie POLARD <jm.polard(a)kermaz.com>
--
Hello to all, I am interested to decode the VOR signals. If anyone has a
trick I will be pleased to exchange emails.
thanks and best regards
Jean Marie POLARD
F5VLB
1, Boutil
22540 Louargat (France)
IN88IN
4407
days inactive
4532
days old
5 comments
4 participants
participants (4)
-
David Jacobowitz -
Dimitri Stolnikov -
Jean Marie POLARD -
Sylvain AZARIAN