This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-sdr@lists.osmocom.org/.
David Jacobowitz david.jacobowitz at gmail.comThanks, 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.htm> -------------- 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>