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/.
keenerd keenerd at gmail.comNew feature! If your eeprom serial looks like "ABC 115p" it'll automatically apply a ppm correction of 115. (The start of the string can be anything you want, it checks the end for a ppm value.) The important part is that the ppm value starts with a space and ends with "p". Works in rtl_fm, rtl_power and rtl_tcp. The automatic value can be overridden with the command line switch. Once again, this is in my experimental github repo: https://github.com/keenerd/rtl-sdr On 12/18/13, Deron <deron at pagestream.org> wrote: > > - After 20-30 forced quits, the device will go completely bonkers. Ok, > not very technical and hopefully related to the inability to stop it in > general. You are the only person to have this problem. More people (myself included) have found the new code to exit much more gracefully and consistently. Given that you were getting a bunch of xhci errors it really sounds like the fault is in libusb or your hardware. What libc and version of libusb are you using? To be safe I've added some explicit clean up code that I was letting the OS handle on exit. > - I have no idea how to make scanning work. Is there something I am > missing to force it to continue scanning at the next frequency? As it says in the --help: "use multiple -f for scanning (requires squelch), ranges supported, -f 118M:137M:25k" If you'd like something other than rtfm, please provide the exact command you are using. > Also, when it finds something that breaks squelch ... This is a little more complicated to be useful, but I'm working on it. > - I'm using an R820T based device. As I understand it, the offset tuning > is unnecessary. Looking at the code, "-E offset" should do just what I > want. It disables the offset/90deg shift in rtl_fm, and the library > recognizes that is unnecessary and returns -2 or some such. The (very > minor) bug is that it reports it as an error that it is unable to set > the offset. You've got some things confused. "-E offset" should only be used with E4000 chips. The 90 degree shift (in software) is different from dongle offset tuning. But I understand what you want to accomplish and will add support for that. -Kyle http://kmkeen.com