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"?
Is this possible?
Sincerely,
On Fri, Oct 18, 2013 at 5:43 AM, Marcus Müller <mar...@hostalia.de
<mailto:mar...@hostalia.de>> wrote:
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
On 10/18/2013 06:53 AM, West, Nathan wrote:
On Thu, Oct 17, 2013 at 11:14 PM, JPL <jplscan...@gmail.com
<mailto:jplscan...@gmail.com>> wrote:
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
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.
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.
-Nathan
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
