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.comSome 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 at 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 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/20130522/923e458e/attachment.htm> -------------- next part -------------- A non-text attachment was scrubbed... Name: trivial.c Type: text/x-csrc Size: 8315 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20130522/923e458e/attachment.bin>