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> 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> 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
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> 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
