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 Sat, Oct 19, 2013 at 3:02 AM, Marcus Müller <mar...@hostalia.de> wrote:
> 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> 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
