Re: Using USRP to transmit and receive samples

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

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 )

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.

2. 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.

3. 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.

Re: Using USRP to transmit and receive samples

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".

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

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
)

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.

2. 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.

3. 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.

.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".

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

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
)

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.

2. 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.

3. 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.

Re: Using USRP to transmit and receive samples

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

On 10/19/2013 01:00 AM, JPL wrote:

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,

(C) 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"?

.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".

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

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
)

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.

2. 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.

3. 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.

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

On 10/19/2013 01:00 AM, JPL wrote:

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,

(C) 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"?

.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".

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

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
)

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.

2. 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.

3. 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.

Re: Using USRP to transmit and receive samples

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.

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.

Re: Using USRP to transmit and receive samples

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

> 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?

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.

Re: Using USRP to transmit and receive samples

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..