Hey all.
I've been shouting it all over /r/rtlsdr and ##rtlsdr, but just for you fine folks that are only on the ML, here[1] is what I've been up to the past week:
Overhauled scanning in rtl_fm. This fixed a number of issues, where either scanning did not work at all and some brokenness on OpenBSD. It also meant giving up on the async API entirely.
Released a whole new application, rtl_power. This is something I'd had bouncing around on my hard drive for many months, half-unwritten due to over-complexity. It'll generate CSV files of arbitrarily slow/wide/detailed FFTs. Also a little visualization script[2] that won't choke when you give it 50,000 columns of data.
In the process of testing rtl_power, two more things came up. First was windows builds. I've got a half-finished mingw32 build script[3] that'll let me produce windows binaries[4] on a linux host. These have been confirmed to actually run and probably work. Only W32 for now, but just because I was too lazy to build the W64 toolchain.
Second was the discovery[5] that scanning had gotten a whole lot slower since my original experiments with rtl_fm. 85mS to retune is unacceptably slow. Since the r820t driver is the slowest, I started looking into figuring out what is going on. Still figuring that out but I have done basic cleanups to the code (removing redundancy, particularly around register writes) and the driver is 15% shorter with no modifications to code behavior.
I would not mind talking to Steve or one of the other devs on IRC about some of the more ambiguous aspects of the driver. (Like, why some reg writes are backed up to R828_Arry[] and others aren't. And is that array thread safe at all? If not I'll have to do some very large changes to support multiple dongles in rtl_power.)
I would really like to get these changes merged, particularly the rtl_fm stuff because the version in the official repo is rather bit-rotten.
-Kyle http://kmkeen.com
[1] https://github.com/keenerd/rtl-sdr [2] http://www.reddit.com/r/RTLSDR/comments/1ktzwi/ [3] http://kmkeen.com/tmp/mingw32.sh.txt [4] http://kmkeen.com/tmp/rtl-sdr-mingw32-2013-08-28.zip [5] http://www.reddit.com/r/RTLSDR/comments/1l2vlx/
Great work and thanks for posting this here!
I am looking forward to trying the new code. I have been unable to get scanning to work and existing problems you indicate may be the reason why.
John
Hi,
sorry for the delay, I was on vacation.
On 28.08.2013 13:55, keenerd wrote:
Overhauled scanning in rtl_fm. This fixed a number of issues, where either scanning did not work at all and some brokenness on OpenBSD. It also meant giving up on the async API entirely.
Merged the patch, thanks.
Released a whole new application, rtl_power. This is something I'd had bouncing around on my hard drive for many months, half-unwritten due to over-complexity. It'll generate CSV files of arbitrarily slow/wide/detailed FFTs. Also a little visualization script[2] that won't choke when you give it 50,000 columns of data.
I'll take a look at it, although I'm not sure if we should pick up yet another application in the rtl-sdr repository, or if it's better if you just maintain it outside of the tree (like dump1090 for example). Any opinions?
Second was the discovery[5] that scanning had gotten a whole lot slower since my original experiments with rtl_fm. 85mS to retune is unacceptably slow. Since the r820t driver is the slowest, I started looking into figuring out what is going on. Still figuring that out but I have done basic cleanups to the code (removing redundancy, particularly around register writes) and the driver is 15% shorter with no modifications to code behavior.
Yeah, the r820t driver is really a mess. I've seen that the v4l-guys have rewritten the driver [1], my goal for the next months is to use that for rtl-sdr, merge back our gain code and make it thread-safe.
I would not mind talking to Steve or one of the other devs on IRC about some of the more ambiguous aspects of the driver. (Like, why some reg writes are backed up to R828_Arry[] and others aren't. And is that array thread safe at all? If not I'll have to do some very large changes to support multiple dongles in rtl_power.)
According some recent tests by patchvonbraun the array isn't thread-safe.
Regards, Steve
[1] http://git.linuxtv.org/linux-2.6.git/blob/HEAD:/drivers/media/tuners/r820t.c
-
John -
keenerd -
Steve Markgraf