discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Test cases for validation of AM/FM receiver


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Test cases for validation of AM/FM receiver
Date: Sat, 9 Feb 2002 18:00:48 -0800
User-agent: Mutt/1.2.5i

On Sat, Feb 09, 2002 at 05:04:15PM -0800, Seth David Schoen wrote:
> Eric Blossom writes:
> 
> > Yes, I've got a couple of 5 second segments of I data collected off
> > the air.  Note that it's taken at 20M samples / second, 16-bit, so 5
> > seconds is 200MB.  Compressed with bzip2, it's about 38MB.  If you want
> > it, let me know where you'd like me to push it.
> 
> A theoretical question: why does compressing with bzip2 help with that
> kind of data?  Clearly, there are patterns in RF signals, but from what
> I understood, I wouldn't have imagined that these were patterns which
> bzip2 could compress.  Doesn't bzip2 compression rely on finding
> redundancy in the form of repeated strings of bytes?  Why would those
> occur so often in RF sample data?

I don't know the details of bzip's insides, but on the data in
question it does almost twice as good a job as gzip.  A couple of
other observations: although formattted into 16 bits, the data has
only 12 significant bits, so roughly 1/4 of the nibbles are either 0xf
or 0x0, which definitely helps.  Also, if you look at the FM data,
adjacent samples are highly correlated, so it may be winning there.  I
also compressed some raw ATSC data, but the 200MB compressed only to
about 100MB, instead of the the 38MB or so with the FM data.  This
doesn't surprise me because ATSC signal is carrying much more
information than the FM stuff.  Its spectrum is relatively flat,
whereas each FM station in the FM data set is pretty much a single
spike in the frequency domain.

Eric



reply via email to

[Prev in Thread] Current Thread [Next in Thread]