[Discuss-gnuradio] Installatio of GNUradio
Sir kindly guide me how to install GNUradio... what are the steps... IM using Linux Mint If there is any blog regarding this kindly send me the link. SOHAIB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [coproc] Domain concept for blocks and ports
Hi, This is an evolution of a concept that was mentioned at GRcon which I really liked and I thought a bit more about it. The general idea is that each block and each port within blocks would have a "domain" associated to it. For the blocks this would essentially represent where that block is running, like CPU, DSP, FPGA, GPU For the ports this would represent where the data are stored Main memory, GPU memory, page-locked memory for a coproc, shared zone with a DSP, ... Once you have those, you'd need ingress/egress blocks to cross over data domains, they could be either a memcpy on the host, or a read/write buffer queued in a CL command queue, or whatever is required. Those wouldn't even need to be really exposed to the user. GRC/GR-core could be smart enough to find an appropriate path to move the data from one data domain to the other, it just needs a list of such available block. The advantage of introducting this concept to blocks is that for all the various types of coproc you can think of, the GR core doesn't have to know anything special and can delegate to appropriate domain handlers/plugins. Even the CPU domain and Main memory domain would just be plugins, no special case or anything, they would be treated just like any other. So coproc aren't "second class citizens", they're treated just like the main CPU is. Anyway, just my 2 ct. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] recv_frame_size and send_frame_size
Hi all, I have changed recv_ frame_size and send frame by typing uhd_usrp_probe "addr0=198.168.10.2,recv_frame_size=4096, send:frame_size=4096". I have also change the MTU size on my host computer to 4096. After starting gnuradio companion the frame size was set to 1472 bytes again. What is hier the problem? How can I change the frame sizes permanently? Thanks AB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Sampling rate issue
HI everyone , ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Sampling rate issue
Hi everyone , I'm doing a small experiment i.e FM transmitter using gnuradio and usrp b100.i'm facing problem to set the output sampling rate.How exactly should be the sampling rate at each stage to transmit the audio file.Below is the grc file of my flowgraph Please can anyone help me Thanks in advance Sandhya fm_transmitter.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to read the file from "File Sink" in GRC?
very simple. this is part of my code for reading complex signal, but mind that i have separated real and imaginary values, there is a way to read in an array of complex i suppose. file = fopen(read_path, 'r'); %fseek(file, 194*8, 'bof'); data = fread(file, 'single', 'l'); fclose(file); i_data = data(1:2:length(data)); q_data = -1*data(2:2:length(data)); On Fri, Oct 18, 2013 at 6:20 AM, JPL wrote: > Hello, > > I used the File Sink block to save some data. > they are > "Byte", pink color > and > "complex", light blue color. > > How can I get something, like *.m script, to open those types of files on > Matlab? > > Thanks a lot. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 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".
Greetings,
Marcus
On 10/18/2013 06:53 AM, West, Nathan wrote:
On Thu, Oct 17, 2013 at 11:14 PM, JPL 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
https://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] zero ninput_items_required[0]
Hi list,
I am designing very simple FSK modulator. The principle of operation is
following:
based on symbol value nco generates baseband signa. The problem is
somewhere in my forecast function, but I can't figure out where, probably
because of misunderstanfing of something.
The body of my forecast function is:
ninput_items_required[0] = noutput_items * d_sym_rate / d_sampling_freq;
printf("ninput_items_required %d, noutput_items %d\n",
ninput_items_required[0], noutput_items);
when i run execution, the output is following:
ninput_items_required 8, noutput_items 4096
ninput_items_required 4, noutput_items 2048
ninput_items_required 2, noutput_items 1024
ninput_items_required 1, noutput_items 512
ninput_items_required 0, noutput_items 256
ninput: 0, produced: 0
The last line of the output comes from general_work function and prints
number of input items and number of produced output samples.
Can somebody explain me why forecast is called 5 times, till number of
input items reach 0, and after that nothing is possible in work function,
cause it won't enter the loop since ninput_items = 0;
Thanks,
--
Nemanja Savić
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] zero ninput_items_required[0]
On Fri, Oct 18, 2013 at 02:32:48PM +0200, Nemanja Savic wrote:
> The body of my forecast function is:
>
> ninput_items_required[0] = noutput_items * d_sym_rate / d_sampling_freq;
> printf("ninput_items_required %d, noutput_items %d\n", ninput_items_required
> [0], noutput_items);
If d_sym_rate and d_sampling_freq are integers, integer division will
cause ninput_items_required to be zero for small values of
noutput_items.
> when i run execution, the output is following:
>
> ninput_items_required 8, noutput_items 4096
> ninput_items_required 4, noutput_items 2048
> ninput_items_required 2, noutput_items 1024
> ninput_items_required 1, noutput_items 512
> ninput_items_required 0, noutput_items 256
> ninput: 0, produced: 0
>
> The last line of the output comes from general_work function and prints number
> of input items and number of produced output samples.
>
> Can somebody explain me why forecast is called 5 times, till number of input
> items reach 0, and after that nothing is possible in work function, cause it
> won't enter the loop since ninput_items = 0;
Depending on the state of the buffers, the scheduler calls forecast()
until it finds a value of ninput_items_required that works (it tries to
process as much as possible). In your case, there is probably some
situation where the input buffer is not full.
The way you've set up forecast(), the scheduler will eventually find out
that it doesn't need any items to produce at least 256 output items. So
it calls work() with no input data, expecting 256 output items.
But since you can't produce anything without input, nothing happens.
It seems like what you want is a sync_decimator, got a gr::block. This
means you set relative_rate in the ctor and don't need to handle all of this
yourself. Make sure you don't set relative_rate to zero, again!
In a sync_decimator, you won't need forecast() at all and your work
function is much simpler. The scheduler will also never try to call a
sycn_decimator w/o input.
MB
--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)
Dipl.-Ing. Martin Braun
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
pgpSTdMcprpVT.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC USRP source/sink block - IP address
Hello all
just looking for some help regarding the USRP N210 in GRC.
I'm having a problem with the IP address in GRC.
I have looked around but the only material I have found regarding IP address
relates to setting up the N210 on the network.
That part I have correct.
-> I can ping the device
-> uhd_find_devices returns as it should
-> utilitiy programs (txrx_loopback) work
My problem I think is in integration with GRC.
I have an existing flow that implements my OFDM system (loopback to same
device) that I was using with my USRP1.
All I have done after swapping in the N210 into the loop is populate the
fields in the USRP sink/source block with the N210's address.
I get the following error complaining about the IP address:
/
Traceback (most recent call last):
File "transmitter_gain_freq_test.py", line 226, in
tb = transmitter_gain_freq_test()
File "transmitter_gain_freq_test.py", line 111, in __init__
channels=range(1),
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py",
line 116, in constructor_interceptor
return old_constructor(*args)
File "/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py",
line 2479, in usrp_source
return _uhd_swig.usrp_source(*args)
RuntimeError: unknown key format: 192.168.10.2
/
The generated code is as follows:
self.uhd_usrp_source_0 = uhd.usrp_source(
device_addr="192.168.10.2",
stream_args=uhd.stream_args(
cpu_format="fc32",
channels=range(1),
),
)
self.uhd_usrp_source_0.set_time_now(uhd.time_spec(time.time()),
uhd.ALL_MBOARDS)
self.uhd_usrp_source_0.set_samp_rate(samp_rate)
self.uhd_usrp_source_0.set_center_freq(carrier, 0)
self.uhd_usrp_source_0.set_gain(RX_gain, 0)
self.uhd_usrp_source_0.set_antenna("RX", 0)
With the remaining fields blank or default (works with USRP1)
System:
ubuntu 12.10
GNU radio 3.6.5.1
I'm rather stumped here, any suggestions of change would be much
appreciated.
port number perhaps?
Alex B
--
View this message in context:
http://gnuradio.4.n7.nabble.com/GRC-USRP-source-sink-block-IP-address-tp44233.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] zero ninput_items_required[0]
Thank you Martin, I will try with the sync_decimator, but it is also
important for me to unterstand what's happening here.
So, I have vector source -> throttle -> fsk_modulator -> scope sink.
Vector source generates 8 symbols. From where scheduler starts, from source
or from the sink? And why it didn't stop for any value before 0? What
should I add into general block to avoid this?
Thank you
On Fri, Oct 18, 2013 at 2:59 PM, Martin Braun (CEL) wrote:
> On Fri, Oct 18, 2013 at 02:32:48PM +0200, Nemanja Savic wrote:
> > The body of my forecast function is:
> >
> > ninput_items_required[0] = noutput_items * d_sym_rate / d_sampling_freq;
> > printf("ninput_items_required %d, noutput_items %d\n",
> ninput_items_required
> > [0], noutput_items);
>
> If d_sym_rate and d_sampling_freq are integers, integer division will
> cause ninput_items_required to be zero for small values of
> noutput_items.
>
> > when i run execution, the output is following:
> >
> > ninput_items_required 8, noutput_items 4096
> > ninput_items_required 4, noutput_items 2048
> > ninput_items_required 2, noutput_items 1024
> > ninput_items_required 1, noutput_items 512
> > ninput_items_required 0, noutput_items 256
> > ninput: 0, produced: 0
> >
> > The last line of the output comes from general_work function and prints
> number
> > of input items and number of produced output samples.
> >
> > Can somebody explain me why forecast is called 5 times, till number of
> input
> > items reach 0, and after that nothing is possible in work function,
> cause it
> > won't enter the loop since ninput_items = 0;
>
> Depending on the state of the buffers, the scheduler calls forecast()
> until it finds a value of ninput_items_required that works (it tries to
> process as much as possible). In your case, there is probably some
> situation where the input buffer is not full.
> The way you've set up forecast(), the scheduler will eventually find out
> that it doesn't need any items to produce at least 256 output items. So
> it calls work() with no input data, expecting 256 output items.
> But since you can't produce anything without input, nothing happens.
>
> It seems like what you want is a sync_decimator, got a gr::block. This
> means you set relative_rate in the ctor and don't need to handle all of
> this
> yourself. Make sure you don't set relative_rate to zero, again!
> In a sync_decimator, you won't need forecast() at all and your work
> function is much simpler. The scheduler will also never try to call a
> sycn_decimator w/o input.
>
> MB
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Martin Braun
> 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
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
Nemanja Savić
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC USRP source/sink block - IP address
On Fri, Oct 18, 2013 at 06:06:16AM -0700, Alexander B wrote: > That part I have correct. > -> I can ping the device > -> uhd_find_devices returns as it should > -> utilitiy programs (txrx_loopback) work > > My problem I think is in integration with GRC. You need to specify addr="IP", not just the IP (otherwise, UHD doesn't know you want to use ethernet). > The generated code is as follows: > > self.uhd_usrp_source_0 = uhd.usrp_source( > device_addr="192.168.10.2", That's wrong ^ MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun 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 pgpYcao62tHbO.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC USRP source/sink block - IP address
Thanks for the reply Martin yeah I got it now. I had actually tried that but I put: addr="192.168.10.2" in the address field where it should be: addr=192.168.10.2 Thanks again Alex B -- View this message in context: http://gnuradio.4.n7.nabble.com/GRC-USRP-source-sink-block-IP-address-tp44233p44236.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to make modified uhd/host/examples
> Message: 4 > Date: Thu, 17 Oct 2013 12:41:54 -0700 (PDT) > From: Naceur > To: Discuss-gnuradio@gnu.org > Subject: [Discuss-gnuradio] How to make modified uhd/host/examples > Message-ID: <1382038914757-44214.p...@n7.nabble.com> > Content-Type: text/plain; charset=us-ascii > > Hello GR Forum, > > I have to add some instructions for test purpose into some files of > /uhd/host/examples Could you show me how to make the new files, or send > me the link of How to instructions. > BTW, I never used CMake before. If there is another tool for the purpose I > am ok too. > > Regards, > Naceur > I have been doing this a lot recently as I've been trying to add GPS time and location tags to a stream of data I'm recording with a USRP. It really is as simple as the instructions here: http://files.ettus.com/uhd_docs/manual/html/build.html provided you have all the dependencies satisfied and all the source files downloaded from the repository. Cmake is required as the build depends on the various configuration files scattered throughout the source directories (you get these when you check out the repository). I'm not really a programmer (pretty much a hack), but I do know that they use Cmake as a tool to enable compiling across multiple platforms. And if I can make it work, just about anyone can. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to read the file from "File Sink" in GRC?
Thanks Nemanja. Have you ever try reading Byte data in Matlab? On Fri, Oct 18, 2013 at 4:31 AM, Nemanja Savic wrote: > very simple. this is part of my code for reading complex signal, but mind > that i have separated real and imaginary values, there is a way to read in > an array of complex i suppose. > file = fopen(read_path, 'r'); > %fseek(file, 194*8, 'bof'); > data = fread(file, 'single', 'l'); > fclose(file); > i_data = data(1:2:length(data)); > q_data = -1*data(2:2:length(data)); > > > > On Fri, Oct 18, 2013 at 6:20 AM, JPL wrote: > >> Hello, >> >> I used the File Sink block to save some data. >> they are >> "Byte", pink color >> and >> "complex", light blue color. >> >> How can I get something, like *.m script, to open those types of files on >> Matlab? >> >> Thanks a lot. >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > -- > Nemanja Savić > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [volk] google hangout/meeting
I think it might be good for whoever would be interested in VOLK to get together for another meeting in a couple of weeks to discuss any progress and to include anyone who was not at the inaugural meeting at GRCon. A rough agenda: * Data collected so far from pybombs -- what can we get out of it * I'm planning an experiment for existing blocks that I'll present results from if they're interesting. * What is everybody working on? -- avoid duplicated efforts Proposed Time: Thursday, October 31st 5PM UTC. (12pm noon US Central time). This is the same time of day as GR dev calls, and 2 weeks after yesterday's call. If you are interested in attending, please RSVP on G+ (https://plus.google.com/u/0/events/celd7aonrkj0g0ivvcs5rm42b40) or reply to me here (no need to reply all). -Nathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] recv_frame_size and send_frame_size
Parameters you pass to UHD like this are not persistent between runs, the hardware is re-initialized each time so you must pass them each time. In GRC you would pass the parameters as per the example I've attached. -Ian args_example.grc Description: Binary data On Oct 18, 2013, at 2:10 AM, Baier wrote: > Hi all, > > I have changed recv_ frame_size and send frame by typing uhd_usrp_probe > "addr0=198.168.10.2,recv_frame_size=4096, send:frame_size=4096". I have also > change the MTU size on my host computer to 4096. After starting gnuradio > companion the frame size was set to 1472 bytes again. What is hier the > problem? How can I change the frame sizes permanently? > Thanks > AB > > ___ > 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
[Discuss-gnuradio] How to make an FFT block in c++
Hello, I'm trying to make an FFT block in my hierarchical block, but I cannot seem to find the correct syntax. I'm trying to make it with a BLACKMAN_HARRIS windowing function, and it's easy in a python program: fft_forward = fft.fft_vfc(window_size, True, (fft.blackmanharris(window_size)), 1) fft_backward = fft.fft_vcc(window_size, False, (fft.blackmanharris(window_size)), False, 1) But in a c++ program it gets hairy. Does anyone have any experience with this? gr::fft::fft_vfc::sptr fft_forward = gr::fft::fft_vfc::make(SIZE, true, gr::filter::firdes::WIN_BLACKMAN_HARRIS, num_threads); gr::fft::fft:vcc::sptr fft_reverse = gr::fft::fft_vcc::make(SIZE, false, gr::filter::firdes::WIN_BLACKMAN_HARRIS, false, num_threads); I believe what I have wrong is the Windowing, which is of the form: const std::vector< float > & window Sincerely, Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to make an FFT block in c++
On Fri, Oct 18, 2013 at 10:05 PM, Tommy Tracy II wrote: > Hello, > > I'm trying to make an FFT block in my hierarchical block, but I cannot seem > to find the correct syntax. > I'm trying to make it with a BLACKMAN_HARRIS windowing function, and it's > easy in a python program: > > fft_forward = fft.fft_vfc(window_size, True, > (fft.blackmanharris(window_size)), 1) > fft_backward = fft.fft_vcc(window_size, False, > (fft.blackmanharris(window_size)), False, 1) > > > But in a c++ program it gets hairy. Does anyone have any experience with > this? > > gr::fft::fft_vfc::sptr fft_forward = gr::fft::fft_vfc::make(SIZE, true, > gr::filter::firdes::WIN_BLACKMAN_HARRIS, num_threads); > gr::fft::fft:vcc::sptr fft_reverse = gr::fft::fft_vcc::make(SIZE, false, > gr::filter::firdes::WIN_BLACKMAN_HARRIS, false, num_threads); > > I believe what I have wrong is the Windowing, which is of the form: > > const std::vector< float > & window I have only used gr::fft::fft_complex in C++ but I think it uses the same window type. If that's true you can create the window using: window = gr::filter::firdes::window(gr::filter::firdes::WIN_BLACKMAN_HARRIS, SIZE, 6.76); Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using USRP to transmit and receive samples
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 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 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
