Problem with 8-bit option and dropped samples

GNU Radio
1

I’m testing the -8 option in various example programs, and haven’t been
successful in receiving valid data. The following test resulted in a
very
brief, flat line being displayed, then absolutely no data showed on the
graph, but the program continued to run.

./usrp_fft.py -f 100M -d 4 -8
format = 0x288
set_format = True

I decided to try decimating by 4 without specifying the 8-bit option,
and I
received the ‘uO’ indicating that samples were dropped from the USRP to
host, but data was displayed on the graph, and it was 16MHz wide.
What’s
going on?

./usrp_fft.py -f 92.7M -d 4
uOuOuOuOuOuOuOuOuOu

I’ve also written a data capture script that simply writes data from the
USRP to a file, and when I use the usrp.source_s () function (after
using
make_format, set_format) I get a few initial non-zero bytes, but the
rest of
the data file is zeroed out.

Any idea what is happening here? I’m wondering if my signal is so weak,
that
the 8-bit option is truncating all the data off. When running
usrp_wfm_rcv.py I can only get one strong FM radio station.

Other questions are:

Is the ‘uO’ the only indication that samples have been dropped?
Does the number of 'uO’s correspond to the number of samples dropped?
What are the buffer sizes?

Thanks!

2

Lisa Creer wrote:

I decided to try decimating by 4 without specifying the 8-bit option,
and I received the ‘uO’ indicating that samples were dropped from the
USRP to host, but data was displayed on the graph, and it was 16MHz
wide. What’s going on?

Lisa,

I’m not sure from what angle you’re wondering “what’s going on” but let
me say

  1. No surprise that samples are being lost while you run usrp_fft.py.
    This is normal for me, especially while I am resizing the window.
    Presumably resources are devoted to running GUI tasks and the USRP bits
    get dropped.

  2. No suprise that even though you are losing data, the FFT is still
    displayed. A valid FFT can be calculated even with missing samples.

Chris

3

On Mon, Aug 20, 2007 at 11:15:36PM -0400, Lisa Creer wrote:

I’m testing the -8 option in various example programs, and haven’t been
successful in receiving valid data. The following test resulted in a very
brief, flat line being displayed, then absolutely no data showed on the
graph, but the program continued to run.

./usrp_fft.py -f 100M -d 4 -8
format = 0x288
set_format = True

Have you tried increasing the gain?
What daughterboard are you using?
Do you have an antenna connected? If so, what kind?

I decided to try decimating by 4 without specifying the 8-bit option, and I
received the ‘uO’ indicating that samples were dropped from the USRP to
host, but data was displayed on the graph, and it was 16MHz wide. What’s
going on?

./usrp_fft.py -f 92.7M -d 4
uOuOuOuOuOuOuOuOuOu

64 MS/s / 4 * 4 bytes/S = 64MB/s. This won’t fit across the USB,
hence the continuous overruns.

I’ve also written a data capture script that simply writes data from the
USRP to a file, and when I use the usrp.source_s () function (after using
make_format, set_format) I get a few initial non-zero bytes, but the rest of
the data file is zeroed out.

Have you tried using the existing usrp_rx_cfile.py program? It’s
known to work.

Any idea what is happening here? I’m wondering if my signal is so weak, that
the 8-bit option is truncating all the data off.

Could be. It currently takes the high 8 bits of the 16-bit value.

[I thought that somebody had implemented the barrel shifter, but checking rx_buffer.v, I don’t see it.]

When running usrp_wfm_rcv.py I can only get one strong FM radio station.

Seems unlikely, unless you’re living in the middle of nowhere…

Have you tried:

$ usrp_fft.py -f 95M -d 8

Should show lots of stations…

Other questions are:

Is the ‘uO’ the only indication that samples have been dropped?

Yes.

Does the number of 'uO’s correspond to the number of samples dropped?

No. Overrun detection is currently implemented by polling at
approximately 10Hz. If you’re trying to receive constantly streaming
data, you shouldn’t see any uO’s.

What are the buffer sizes?

They’re configurable in the constructor to usrp.source_c.
The default is generally reasonable.

What OS and distribution are you running on?

Eric

4

On 8/20/07, Eric B. [email protected] wrote:

set_format = True

Have you tried increasing the gain?

Yes, to no avail.

What daughterboard are you using?

Basic Rx.

Do you have an antenna connected? If so, what kind?

Yes. My antenna ignorance will become apparent here, it’s what I’d call
a
basic antenna (non-telescoping), vertical antenna 14 inches tall with a
strong magnet on the bottom.

64 MS/s / 4 * 4 bytes/S = 64MB/s. This won’t fit across the USB,
hence the continuous overruns.

Wait, I thought the -8 option provided 8-bit I and 8-bit Q across the
USB.
It sounds like you’re saying the samples are still 4 bytes total (2 byte
each I and Q). So the samples are converted to shorts AFTER they get to
the
host? Then how can we decimate by 4 when using the -8 option? How can we
cram more data through the USB if it can only handle 32 MB/s?

Have you tried using the existing usrp_rx_cfile.py program? It’s
known to work.

Yes. Nothing but zeroes in data file. However, when a gain of 30 db is
applied some data appears in the file. But when a gain of 30 db is used
in
usrp_fft.py, there is no change. Hrmph.

$ ./usrp_rx_cfile.py -d 4 -8 -s out -f 92.7e6
Using RX d’board A: Basic Rx
USB sample rate 16M
[lmcreer@localhost usrp]$ hexdump out
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
11020000

Seems unlikely, unless you’re living in the middle of nowhere…

No. My traditional FM radio sitting next to the USRP (with a bigger
antenna)
gets many FM stations.

Have you tried:

$ usrp_fft.py -f 95M -d 8

Should show lots of stations…

I wouldn’t say lots…(see usrp_fft_95M_d8.png)

What OS and distribution are you running on?

Red Hat Enterprise Linux 4.3

Lisa

5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lisa Creer wrote:

set_format = True
Do you have an antenna connected? If so, what kind?

Yes. My antenna ignorance will become apparent here, it’s what I’d call a
basic antenna (non-telescoping), vertical antenna 14 inches tall with a
strong magnet on the bottom.

This sounds like it’s the wrong length to pick up FM stations.

hence the continuous overruns.

Wait, I thought the -8 option provided 8-bit I and 8-bit Q across the USB.
It sounds like you’re saying the samples are still 4 bytes total (2 byte
each I and Q). So the samples are converted to shorts AFTER they get to the
host? Then how can we decimate by 4 when using the -8 option? How can we
cram more data through the USB if it can only handle 32 MB/s?

This calculation is in reference to your immediately preceding run
without -8. With -8, the samples are indeed 2 bytes total, not 4.

  • -Dan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGy4/cy9GYuuMoUJ4RAkTCAKCGmZ841O0bj9nsY8mUm6gDVsFJvQCfeWrM
sNFi25ix/mZKSmUrhrGX4Mc=
=D3MK
-----END PGP SIGNATURE-----

6

Lisa Creer schrieb:

Any idea what is happening here? I’m wondering if my signal is so weak,
that the 8-bit option is truncating all the data off. When running
usrp_wfm_rcv.py I can only get one strong FM radio station.

Are you using a decent antenna? I used a stretched paper clip[0], which
worked which just worked to get some strong stations. Using a proper and
cheap FM Antenna with an adapter cable lets me receive more station than
most Radios.

Patrick

Engineers motto: cheap, good, fast: choose any two
Patrick S.
Student of Telematik, Techn. University Graz, Austria