Using USRP to transmit and receive samples

Hello,

We have used Matlab to generate *.mat file, a file around 1966240
complex
number OFDM samples.
Thinking to (I) transmit between two USRPs, (II) let the receiver side
saving data into file, and later (III) putting the file on Matlab for
demodulation.

  1. What is the best way to do it? like create GRC blocks? or UHD
    example?
  2. How can I make sure that the TX part will stop when those 1966240
    samples are sent. and RX part will stop when completely receiving those
    1966240 samples?
  3. Should the file type be the *.dat?

Sincerely,

JPL

On Thu, Oct 17, 2013 at 11:14 PM, JPL [email protected] wrote:

samples are sent. and RX part will stop when completely receiving those
1966240 samples?
3. Should the file type be the *.dat?

Sincerely,

JPL

I’ll attempt to respond to both questions since they are really the same
thing.

First, this is kind of a weird way to use GNU Radio. GNU Radio provides
you
an environment to do all of the signal processing you want to do in c++
or
(if you want) python. The flowgraph of file -> transmit antenna --> over
the air --> receive antenna -> file followed by signal processing in
Matlab
is sort of not the point of GNU Radio. There’s nothing saying you cannot
do
this, but you might look in to implementing whatever signal processing
you
are doing in GNU Radio. This will reduce the round trip time of testing
and
make the whole experience a little better. ( you’re basically doing an
even
slower version of what we call flying blind:
http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#Flying-Blind )

Re: your other email and question about GR file sink/source:
About the file sinks…
http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-is-the-file-format-of-a-gr_file_sink
Basically it’s a binary file just like you would expect if you open a
file
with ‘b’ flag in most languages I’m familiar with. If you’re dumping
complex floats in there then you’ll need to read two float values.

  1. There is a block called head. It takes a number of samples to pass
    through and then quits. But again, you might consider your approach
    here.

  2. I’ve never actually looked in to the format of a .mat file, but
    connecting that (regardless of data inside the file) to a UHD source
    would
    be spewing garbage out. The .dat extension you might see in GR
    literature
    is just a convention we use to denote it’s data; it’s not really a
    special
    format.

-Nathan

Hi JPL,

.mat is really just a complicated container format for all kind of
matlab data – GNU Radio can’t directly deal with that, although with
SciPy you could create something that will be able to parse .mat files;
but that is quite useless, as you could as well use Matlab to write
something that can be directly used with other software.

So to answer question (1.), I’d agree with Nathan: Best way to do it is
using the existing GNU Radio OFDM tools, not writing code that has
already been written several times, and start with something that
already works. Thereby dropping Matlab as your signal processing
framework, and only using it for data analysis and visualisation.

To comment on (II): GNU Radio has blocks like “file_sink”. They will
just save the samples to a file, in this case, in the format of raw
float32s (1 for real, 1 for imag part) one after another.

To answer (III): If you really want to do that, see the GNU Radio source
tree, gnuradio-core/src/utils/read_{float,complex,…}_binary.m. There
is the same with “write” instead of “read”.

Greetings,
Marcus

Hi!

Quick answer, don’t have time right now:
(A) Why did you save them as wav audio? Usually, it’s wiser to just
store them as raw data; see the scripts in
gnuradio-core/src/utils/{read,write}*
Note: you’re sending symbols from the source, not samples! Use bytes as
data format.

Answers:
(1) yes, that should do the trick.
(2) no, I think you should replace the CRC generator, unless you want to
have your symbols interleaved with checksums

Greetings,
Marcus

Hello,

I found out two *.grc files, tx_ofdm and rx_ofdm, under
gr_digital/examples/ofdm.

Don’t know if this can be realized,
first test running the steps without changing any parameters in *.grc.
(A) use *.dat generated from Matlab (I saved a set of wav audio),
(B) place it as input in the tx_ofdm.grc,
© send through antenna,
(D) the other USRP execute rx_ofdm.grc
(E) put the output *.dat into Matlab analyzing.

Question:
(1) should I just replace the “Vector Source block” into “File Source”
in
tx_ofdm.grc?
(2) the rx_ofdm.grc, again, am I right just replace “tag debug” with
“file
sink”?

Is this possible?

Sincerely,

On Fri, Oct 18, 2013 at 06:00:48PM -0500, JPL wrote:

Question:

(1) should I just replace the “Vector Source block” into “File Source” in
tx_ofdm.grc?

This won’t work, the input expects a tagged stream (see the
corresponding manual page). You will need to split the file into
packets, and tag them with their length. Currently there’s no automatic
way to do that.

(2) the rx_ofdm.grc, again, am I right just replace “tag debug” with “file
sink”?

This on the other hand should work, providing your receiver is actually
working.

MB


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

Sorry my bad, it’s typo.
I actually did save *.wav into *.dat.
and good to hear about that “it will work”

One question,
the scripts in gnuradio-core/src/utils/{read,write}
If I use those scripts in the matlab, I will not need to worry about
setting the format, like float, int, or byte…etc, right?
and default, what type of format will the script save it into the *dat?

Thanks

On Mon, Oct 21, 2013 at 09:06:24PM -0500, JPL wrote:

Hello, Martin

  1. Would you please tell me where the “manual page” is?

It’s in the manual.
You go to gnuradio.org, click ‘C++ manual’, then ‘Related Pages’, then
‘Tagged Stream Blocks’.

  1. And you are saying keep “vector source” block not replace with “file source”
    block.

How can vector source import and read my *.dat?

You will have to load the .dat into a variable and then pass that to the
vector sink. It’s not the most user-friendly method, I admit, but the
tagged stream blocks are still pretty new and we’re only just figuring
out use-cases.

MB


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

Hello, Martin

  1. Would you please tell me where the “manual page” is?
    Because I cannot understand
    How the Vector source works
    (tagged_streams.make_lengthtags((packet_len,),(0,).length_tag_name)?
    and where the "Import"block grab the value from (from
    gnuradio.digital.utils import tagged_streams), (import numpy), and
    (import
    random)?
    I just need to know how *vector source *related to those *import *block

  2. And you are saying keep “vector source” block not replace with
    file
    source
    ” block.
    How can vector source import and read my *.dat?

Thanks again.

hi, i tried connecting a file sink at the tag debug place and i found
o’s and
1’s coming. we may have to pack them back like opposite operation in
transmitter GRC. i used REPACK Bits block and tested that the actual
data (1
to 96) is not coming back… and we have to use the “check CRC” in the
stream
crc block. but in the examples, it is given generate crc … is that
right?
is there any trick to get back the data other than this… looking
forward
for reply…


View this message in context:
http://gnuradio.4.n7.nabble.com/Using-USRP-to-transmit-and-receive-samples-tp44221p44306.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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