rtl-sdr offset tuning and other questions

David Jacobowitz david.jacobowitz at gmail.com
Mon May 20 04:18:41 UTC 2013


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 at gmx.net> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130519/57ee5cba/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtl-sdr-annotated.h
Type: text/x-chdr
Size: 15349 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130519/57ee5cba/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trivial.c
Type: text/x-csrc
Size: 7613 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130519/57ee5cba/attachment-0001.bin>


More information about the osmocom-sdr mailing list