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