Simultaneously send data and store it in file with high sample rate

GNU Radio
1

Hi,
How to simultaneously transmit data to usrp and also store it in a
file.? I
ran two separate flow graphs.But i want to have a sample rate of
25Mhz.Is
it possible to do it.

I want the same thing in receiver side also(simultaneously detect the
packet and store the data)

I am using USRPN210 and Ubuntu 12.04

Thanks.

2

Thanks.

Hi,

you can connect a block’s output to as many inputs as you want. So take
tha last block in your chain that generates your signal and connect it
both to a uhd sink (which will make the USRP transmitt the signal) and a
file sink (which will write the same samples to a file).

Same goes for the receiver side. If you use GRC just add another
connection from a block’s out port to another ones in port and the
output
will be send to both blocks.

Yours
Martin

3

Hi Martin,
Thanks a lot. I am using gr-digital narrowband examples,with little bit
of
changes in the code.I am still not able to get full sample rate of
25MHz.At
max i am getting 2MHz sample rate.
I attached my code ,can you please let me know what might be the
reason.Is
it because of processing time or some other reason.

parameters i am passing from terminal
sudo python test.py -f 5.825e9 --rx-freq 5.825e9 --tx-gain 31.5
–rx-gain
31.5 -m dbpsk -a=“serial=ECR13W5UP” -r 1e6

if i try to change -r(bit rate) to >2e6 i am getting overflow.

Thanks.

4

How to simultaneously transmit data to usrp and also store it in a

connection from a block’s out port to another ones in port and the
output
will be send to both blocks.

Yours
Martin

Hi,

first of all please make sure that you reply to the list rather than to
the individual persons, or CC the list so that answers are also
available
for anyone who might have a similar question in the future.

The question how to do a block connect is confusing me a bit. Maybe
there
is a misunderstanding? You should already have done block connections
when
setting up your flowgraphs.

Anyway what I mean is a standard connection of two GNURadio blocks, so
in
GRC it might look like this (I know I am not an ASCII artist, sorry)

             |---->(Your signal processing block)

(UHD Source)-----|
|---->(File Sink)

This should lead to python code like this

##################################################

Blocks

##################################################
self.uhd_usrp_source_0 = uhd.usrp_source(…)
self.yourblock_0 = yourmodule.yourblock(…)
self.file_sink_0 = gr.file_sink(gr.sizeof_gr_complex*1, …)
##################################################

Connections

##################################################
self.connect((self.uhd_usrp_source_0, 0), (self.file_sink_0, 0))
self.connect((self.uhd_usrp_source_0, 0), (self.yourblock_0, 0))

Yours
Martin

5

31.5 -m dbpsk -a=“serial=ECR13W5UP” -r 1e6

Can you please show me an example… How to write connect statement?

ran two separate flow graphs.But i want to have a sample rate of

Same goes for the receiver side. If you use GRC just add another
first of all please make sure that you reply to the list rather than to
Anyway what I mean is a standard connection of two GNURadio blocks, so

Blocks

Yours
Martin

Hi,

you are passing a serial and not an IP address as argument, that makes
me
assume you have a USB based USRP like the USRP1? I don’t know the exact
number but I think the rate limit you can achieve over the USB is
somewhere around 2MSamples/sec, but definitely below 25MSamples/sec. For
that you would need a Gigabit Ethernet USRP. Even if the connection for
the USRP is fast enough for higher rates you can still run into
overflows
if your code is to slow to follow up with the signal processing. In this
case either optimize your code, get a better system (mainly RAM and CPU)
or simplify your flow graph to do less processing overall.

Martin

6

On 03/25/2013 07:27 AM, Nada ABDELKADER wrote:

GNURADIO_CORE_INCLUDE_DIRS)
– package ‘gnuradio-fcd’ not found
Gruel required to compile osmosdr

What type of system are you on?

If you run build-gnuradio with the “–verbose” option, you can get more
information about what it’s doing.

This looks to me like the gnuradio part of the build failed in some
subtle way, and gr-osmosdr failed because none of the gnuradio
components
were installed.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

7

Hi all,

I’m trying to build gnuradio using the gnuradio_build script and I’m
getting these errors:

Configuring Boost C++ Libraries…
– Could NOT find GRUEL (missing: GRUEL_INCLUDE_DIRS)
– checking for module ‘gnuradio-core’
– package ‘gnuradio-core’ not found
– Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES
GNURADIO_CORE_INCLUDE_DIRS)
– checking for module ‘gnuradio-iqbalance’
– package ‘gnuradio-iqbalance’ not found
– Could NOT find GNURADIO_IQBALANCE (missing:
GNURADIO_IQBALANCE_LIBRARIES GNURADIO_IQBALANCE_INCLUDE_DIRS)
– checking for module ‘gnuradio-uhd’
– package ‘gnuradio-uhd’ not found
– gnuradio-uhd not found.
– Could NOT find GNURADIO_UHD (missing: GNURADIO_UHD_LIBRARIES
GNURADIO_UHD_INCLUDE_DIRS)
– checking for module ‘gnuradio-fcd’
– package ‘gnuradio-fcd’ not found
– gnuradio-fcd not found.
– Could NOT find GNURADIO_FCD (missing: GNURADIO_FCD_LIBRARIES
GNURADIO_FCD_INCLUDE_DIRS)
– checking for module ‘libosmosdr’
– package ‘libosmosdr’ not found
– libosmosdr not found.
– checking for module ‘libmirisdr’
– package ‘libmirisdr’ not found
– libmirisdr not found.
CMake Error at CMakeLists.txt:121 (message):
Gruel required to compile osmosdr

– Configuring incomplete, errors occurred!
make: *** No rule to make target `clean’. Stop.
make: *** No targets specified and no makefile found. Stop.

Can anyone help me plz to find out what’s wrong?

Nada

8

I’m on Ubuntu 11.10 and I’m using the “–verbose” option with which I
get these messages.
Yes Marcus, you’re right, apparently gnuradio components were not
installed. I tried to rebuild manually gnuradio and I got this:

######################################################
– # Gnuradio disabled components
– ######################################################
– * sphinx
– * gruel
– * gnuradio-core
– * gnuradio-companion
– * gr-blocks
– * gr-fft
– * gr-filter
– * gr-atsc
– * gr-audio
– * gr-comedi
– * gr-analog
– * gr-digital
– * gr-noaa
…

and for each component I got sth like:

Configuring gr-audio support…
– Dependency Boost_FOUND = FALSE
– Dependency ENABLE_GR_CORE =
– Disabling gr-audio support.
– Override with -DENABLE_GR_AUDIO=ON/OFF
– WARNING: Found a known bad version of Boost (v104601). Disabling.
– checking for module ‘comedilib’
– package ‘comedilib’ not found

Is that related to boost? Did I miss sth?

Nada

Quoting “Marcus D. Leech” [email protected]:

9

Thks Nicholas, now most blocks are installed
but I got always the same errors!!!

Configuring Boost C++ Libraries…
– Could NOT find GRUEL (missing: GRUEL_INCLUDE_DIRS)
– checking for module ‘gnuradio-core’
– package ‘gnuradio-core’ not found
– Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES
GNURADIO_CORE_INCLUDE_DIRS)
checking for module ‘gnuradio-iqbalance’
– package ‘gnuradio-iqbalance’ not found

Nada

Quoting Nicholas C. [email protected]:

10

On Sun, Mar 24, 2013 at 9:54 PM, john jade [email protected]
wrote:

if i try to change -r(bit rate) to >2e6 i am getting overflow.

Thanks.

John,

The ability to process data in a software radio application is
directly proportional to the sampling rate used. The higher the
sampling rate, the more computational power required. As you increase
the computational load on your application, each block takes longer to
process data, and at some point, your application can take too much
time, which means that the data flowing from the USRP to the host is
coming too fast to be processed, so it gets dropped.

A digital receiver is a complex set of algorithms used to properly
synchronize (in time, frequency, and phase not to mention any
multipath distortions) the incoming signal. This is much more complex
than just drawing the signal in a GUI.

So in other words, you shouldn’t expect to be able to handle those
kinds of bandwidth with the digital receiver. Now, there’s a lot more
optimization that can be done to make those algorithms more
computationally efficient in order to continue increasing the
potential symbol rate.

Tom

11

When running CMake, the -DENABLE_BAD_BOOST=ON option will disable that
warning and allow you to compile most blocks.

On Mon, Mar 25, 2013 at 5:38 AM, Nada ABDELKADER <

12

To expand on this further.

The number of MFLOPS required is
proportional to the sample-rate X inherent-flowgraph-complexity.

If,
on average, there’s a deficit in available MFLOPS vs required MFLOPs,
you’ll get overflows. Buffering within the flow-graph, and the driver
stacks, allows you to have short-term shortfalls, but if on average you
don’t have enough MFLOPs, you’ll fall behind, and get overruns. Think of
it as a kind of “physics of computing” thing.

The more “stuff” you do
in a flowgraph, the higher the inherent-flowgraph-complexity. A digital
receiver DSP chain is quite complex, and requires a lot of operations
to be performed on every sample. The architecture of Gnu Radio
exacerbates this somewhat, because the data-flow model tends to produce
redundant data motion that would not occur in a signal-processing chain
that was “hand coded” and “hand optimized”. It’s the price you pay for
the flexibility of the “plug a bunch of modules together” architecture.

That being said, I have flow-graphs that run at 16.67Msps, doing
“stuff” and they keep up fairly well–but on a 6-core 3.2GHz machine
with 4G of fast memory.

On 25 Mar 2013 10:36, Tom R. wrote:

John,

The ability to process data in a software radio application
is
directly proportional to the sampling rate used. The higher the

sampling rate, the more computational power required. As you increase

the computational load on your application, each block takes longer to

process data, and at some point, your application can take too much

time, which means that the data flowing from the USRP to the host is

coming too fast to be processed, so it gets dropped.

A digital
receiver is a complex set of algorithms used to properly
synchronize
(in time, frequency, and phase not to mention any
multipath
distortions) the incoming signal. This is much more complex
than just
drawing the signal in a GUI.

So in other words, you shouldn’t
expect to be able to handle those
kinds of bandwidth with the digital
receiver. Now, there’s a lot more
optimization that can be done to
make those algorithms more
computationally efficient in order to
continue increasing the