USRP2 Sample 2.4 GHz Channel

Hello,

I’m trying to sample the 802.11b wireless channels but the USRP2. I’m
currently using revision 10689 of Gnuradio.
I’ve added code to bbn_80211b_rx.py to connect the gr_probe_signal_f()
to
the top block.
To sample the channel, I use gr.probe_signal_f().
Here’s the code to connect the block:

self.connect(self.u, self.conv_c2f, self.probe2)

Then I use the gr.probe_signal_f().level() to retrieve the signal in a
loop.

data_file = open('data.txt', 'w')
T1 = time.asctime()

while cs_samples < 1000000:
    CST = self.tb.probe_channel()
    data_file.write(str(CST) + '\n')
    cs_samples += 1

    data_file.close()
T2 = time.asctime()

def probe_channel(self):
“”"
“”"

return self.probe2.level()

I was wondering if this is the fastest way to sample the channel from
python. When I compute how long this process takes, it appears that I
can
get a sample every 8-9 microseconds, which seems a lot slower than what
the
USRP2 is built to do. Am I sampling the channel in an incorrect way?
I’m running this on a machine with a Intel Quad Q9650 @ 3GHz.

Thanks,
Miklos Christine

When you say sample the channel - are you trying to look at the I&Q
samples coming right out of the USRP2? In which case, the easiest way
to start would be to use the usrp2_rx_cfile.py script, then you can
load the file into Matlab/Octave/etc. to take a look at. If you want
to record samples coming out of one of a block in the flowgraph (e.g.
in the 802.11b scripts) - you can modify the flowgraph to connect up a
file_sink at each point you want to record data from.
Doug

On Tue, Sep 15, 2009 at 9:41 PM, Miklos Christine
[email protected] wrote:

    data_file.close()

get a sample every 8-9 microseconds, which seems a lot slower than what the


Doug G.
[email protected]

Yes, that is exactly what I’m looking for. However, when running
usrp2_rx_cfile.py with decimation = 4, I get a ‘S’ printing to stdout.
Is
anyone else able to run usrp2_rx_cfile.py and not get that overrun
message?
What could be the reason for ‘S’? Is it a limitation on how fast we can
write the samples to the hard disk?
I want to keep the maximum number of samples possible.

Thanks,
Miklos Christine

On Wed, Sep 16, 2009 at 6:52 AM, Douglas G. <

Depending on how long you want to sample (and how much system RAM
you’ve got) you can also do something like using tmpfs (i.e. a RAM
disk). I’ve often resorted to this when doing collections lasting a
minute or less. At 25MS/s * 32bit/S (I&[email protected]) * 60s = 5.58GB
according to my calculator - so that may or may not be a viable option
for you.
Doug

On Thu, Sep 17, 2009 at 1:00 AM, Matt E. [email protected] wrote:

At a decimation rate of 4 you are generating 25 MS/s. If those samples are
complex shorts, that works out to 100 MB/s. If those samples are complex
floats, that is 200 MB/s. In the former case, you really need a RAID array
of at least two fast drives to keep up. In the latter, you’re going to need
to do something more exotic.

Matt


Doug G.
[email protected]

Miklos Christine wrote:

Yes, that is exactly what I’m looking for. However, when running
usrp2_rx_cfile.py with decimation = 4, I get a ‘S’ printing to stdout.
Is anyone else able to run usrp2_rx_cfile.py and not get that overrun
message?
What could be the reason for ‘S’? Is it a limitation on how fast we can
write the samples to the hard disk?
I want to keep the maximum number of samples possible.

At a decimation rate of 4 you are generating 25 MS/s. If those samples
are complex shorts, that works out to 100 MB/s. If those samples are
complex floats, that is 200 MB/s. In the former case, you really need a
RAID array of at least two fast drives to keep up. In the latter,
you’re going to need to do something more exotic.

Matt

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs