Greeting,
After building up some strong Matlab's prototype of my 802.11 receiver, I
have to make really big and complicated GUI with lot of button's, plots,
different tabs etc.
And my question is simple:
Any way to output complex data collected by USRP from grc to any other
enviroment (c++ or
Hi Ernest,
Or it would be better practice to build receiver in grc and then
plotting results out with UDP sink (already tried that, seems to be
working)?
that's a good question, and it depends on what you want to do, how much
stuff you'd have to port etc.
Any way to output complex data collected
Hi list,
I have a custom block trying to connect with other blocks in gnuradio like:
for i in xrange(len(self.sources)):
self.connect(self.src[i], self.filt[i], self.resampler[i],
(self.finder, i))
number of connections should be equal to number of sources.
All goes well, but it is executing
A pipe would probably be a better choice here, but yeah.
Or you build your own custom blocks to interface with your other code.
M
On 10/16/2014 09:37 AM, Ernest Szczepaniak wrote:
So i can just constantly write data to file (with file sink) and open it in a
loop in any C++ enviroment right?
Is it possible to do 11ac on SDR?
On Wed, Oct 15, 2014 at 10:07 PM, Bastian Bloessl bloe...@ccs-labs.org wrote:
Hi,
On 10/10/2014 06:20 PM, Zhang, Jiayi wrote:
Dear Marcus and Bloessl,
Thanks for the reply. I also notice the fully functional gr-ieee802-11
package provide by Bloessl.
Hi gsmandvoip,
On 16.10.2014 09:52, gsmandvoip wrote:
Hi list,
I have a custom block trying to connect with other blocks in gnuradio like:
for i in xrange(len(self.sources)):
self.connect(self.src[i], self.filt[i], self.resampler[i],
(self.finder, i))
shouldn't that read for i in
On 10/16/2014 12:41 PM, David Halls wrote:
Is there any way to get a pointer to a UHD sink block from another
block in a flow graph, such that I can read from the time registers of
a USRP?
Depends how you're building your flow-graph: In Python, simply pass a
reference to your UHD block object
Hi All,
I need to scale down the OFDM transmission signal in time domain, after IFFT
is done, so that, all the values are within the range -1 to 1. But, I cant
simply add one more scaling block after cp_adder in
self.connect(self.preambles, self.ifft, self.cp_adder, self.scale, self)
(file:
Hi Marcus,
I tested again my problem with connecting a data file (file source) to the
fir filter and read the output with the one resulted from Matlab. The error
which appears due to the data precision is in acceptable order.
However, when I directly connect my tx to the fir filter, it did
Hi you!
Any pointer on where should I make the change?
Yes. Do it before preambling!
The inverse dft is a linear operation; it doesn't really matter whether
you scale before or after. Note though that the IFFT as we use it adds a
sqrt(length_of_fft) factor, so account for that by dividing your
I'm a bit confused. Your diagram
TX-FIR-...
-Filesink
Indicates that TX is a source, whereas TX usually is an information sink
in DSP. Maybe you want to fill us in about the type of block TX is?
Greetings,
Marcus
On 16.10.2014 13:47, Mostafa Alizadeh wrote:
Hi Marcus,
I tested again my
On Thu, Oct 16, 2014 at 8:54 AM, Marcus Müller mar...@hostalia.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
... and in C++ you can just use the sptr that you normally use when
using the uhd sink.
But: since Martin added the message ports to the UHD blocks, things
have gotten
On Wed, Oct 15, 2014 at 2:55 PM, Achilleas Anastasopoulos anas...@umich.edu
wrote:
Is forecast() need to be protected in such a case as well?
just searching on the web i realized that no operation can be assumed
atomic, so
I guess every single set_ method (even if it assigns a
Gisle,
Please open this as a ticket in our Issue tracker so that it doesn't get
lost in the email archives.
Thanks,
Tom
On Wed, Oct 15, 2014 at 1:27 PM, Gisle Vanem gva...@yahoo.no wrote:
I just got this error from MSVC v16 while trying to compile
atsc_sync_impl.cc:
I just tried doing a complete PyBombs reinstall and that didn't seem the help.
I checked and simple GRC files run fine. I can also see the signal where I
expect it to be in GQRX, so I think my tuning parameters are correct.
Are there some other things I should try?
Sent from my iPhone
On
Thanks Sebastian,
My solution in the end was to use a UHD source, which generates rx_time, I then
created a block which reads in this rx_time tag and sends it as a message to a
block just before my UHD sink which converts this to a tx_time based on the
number of bursts sent, and the burst
John thanks for all your help, this works, although it is necessary to add
‘tx_sob’ and ‘tx_eob’ tags (or certainly it is for those not using the latest
gr-uhd).
If you are using MIMO it is more complicated, as you have to add a ‘tx_time’
tag as well. This is not obvious how to generate in a
Dear All,
How can I create a block like 'Random PDU Generator', but that outputs items
rather than PDUs over a message port?
Hopefully its easy but I am not clear if I need a work function or not, and if
I don't have one then how do I pass the items out, as one does in a normal
block?
Is it not the case that a given instance of a block is only ever
executed by a single thread, so instance variables
are completely safe to modify in-flight?
There are exceptions, of course, like in FFTW, only a single thread can
be planning at a time, due to the
way FFTW does its thing.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Marcus,
On 16.10.2014 16:54, mle...@ripnet.com wrote:
Is it not the case that a given instance of a block is only ever
executed by a single thread, so instance variables
are completely safe to modify in-flight?
No; assume the following
On 10/16/2014 07:54 AM, mle...@ripnet.com wrote:
Is it not the case that a given instance of a block is only ever
executed by a single thread, so instance variables are completely
safe to modify in-flight?
There is one thread that alternates calling the async message handlers,
the forecast
Hi David,
items is a output/input buffer stream term in GNU Radio.
You can just put whatever data type you'd want (ok, a lot of data types)
into PMTs, and send them around; for sample vectors, PMT uniform vectors
are the way to go.
If you just use message passing, you don't need to implement a
I'm happy this is working for you, David. So do I understand correctly,
that the adding tx_time finally made the MIMO case work?
I'd never done burst transmission with multiple USRP outputs. I'm not
totally surprised but I wasn't sure what would happen.
Maybe someone from Ettus can comment on
On Mon, Oct 13, 2014 at 4:30 PM, Jason Noble jason.noble...@gmail.com
wrote:
The purpose of my current experiments is to create a 16QAM transmitter and
receiver, with UDP sources/sinks, and using bladeRFx40's to
transmit/receive.
I'm using Number sinks to check values at various points of
Yeah, so, a little cerebral flatulence on my part.
I think the problems come in with variables that can change shape
during a setting operation, which could lead
to horrific badness if the shape change happens while the work
function is using the variable. Imagine a
private buffer whose
The vector sink is for debugging only. Don't use it in production code,
because there's no convenient way to
vacuum it out, so it grows without bound.
When I've had this problem, I use a vector-probe block, and have a
function probe running at a couple of Hz,
and then leverage the
A very simple way would just be to write your block downstream of the
FFT in Python. You can then operate on the vectors in the work function.
M
On 10/16/2014 07:44 PM, mle...@ripnet.com wrote:
The vector sink is for debugging only. Don't use it in production code,
because there's no
You should probably look at the new OFDM codes. If you see the
ofdm_tx.grc example, I think there's already a scaler in there.
M
On 10/16/2014 01:35 PM, zealdeal wrote:
Hi All,
I need to scale down the OFDM transmission signal in time domain, after IFFT
is done, so that, all the values are
Hello Everyone,
I have a custom PCB to power an SDR, and I'm going to need to provide
a gnuradio driver for it.
We are using:
* Xilinx Zynq 7020 SoC
* Analog Devices AD9364 ADC
* AvNet ZedBoard for prototyping
I can only imagine that we will ultimately use a tweaked version of
the Ettus
Hi Harrison,
Here's a good tutorial on writing a custom block:
http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
You can create a source block with *gr_modtool add -t source ...*
You may also try to add your receiver to the source block in gr-osmosdr
Hi Harrison,
There's no driver architecture in GNU Radio; you just write
sink/source blocks.
If you have a few minutes to spare, start with the GNU Radio tutorials
[1] from start to hardware; that should give you a solid primer on how
things work with GNU Radio. If you then know how you get your
Tx is an abbreviation of tx blocks! :)
I finally found the problem! I used heap memory but I never release it in
different blocks! So during the runtime, the memory allocation get the
error: std::bad_alloc after somewhile. Now this is fine.
Thank you too much,
Best,
Mostafa
On Thu, Oct 16,
Hi all,
A little while back I submitted an issue
(http://gnuradio.org/redmine/issues/693) regarding the inability to instantiate
the delay block with a negative int (to consume samples) despite the code
comments and documentation.
Tom submitted a commit and clarified that you have to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16.10.2014 22:02, Mostafa Alizadeh wrote:
Tx is an abbreviation of tx blocks! :)
That still doesn't make sense! :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBAgAGBQJUQCmHAAoJEAFxB7BbsDrLQs0H/R4afmR6XubcaN1qJAleVqiJ
That's right John, the tx_time tag was required.
This is actually relatively involved to create in a tx flow graph. I added a
UHD source to acquire rx_time which I then pass as a message to a block just
before the twin UHD sink, where I calculate a desired tx_time.
perhaps someone can chime in
On Thu, Oct 16, 2014 at 8:40 AM, John Malsbury jmalsbury.perso...@gmail.com
wrote:
I'm happy this is working for you, David. So do I understand correctly,
that the adding tx_time finally made the MIMO case work?
I'd never done burst transmission with multiple USRP outputs. I'm not
totally
Original message
From: Matt Ettus
Date:2014/10/16 22:42 (GMT+00:00)
To: John Malsbury
Cc: David Halls ,GNURadio
Subject: Re: [Discuss-gnuradio] Source Block - Flow Control
On Thu, Oct 16, 2014 at 8:40 AM, John Malsbury
On TX, if you need your first sample to be valid and everything settled in
the radio, you should zero pad ahead of it. If you need your last sample
to go out clean, you should zero pad after it. In both cases, a few
microseconds worth is usually fine. This flushes buffers and filters, but
also
Thanks Matt. is this likely to be the cause of the Us at the beginning? How can
I pad simply in GNU radio? can i add padding to every burst? if so that seems
straightforward. I can just mux some zeros in.
Also should the padding be included in the burst length?
Original message
Is there any way to access the fft bins from python without writing a custom
block?
- Original Message -
From: Martin Braun martin.br...@ettus.com
To: discuss-gnuradio@gnu.org
Sent: Thursday, October 16, 2014 2:02:03 PM
Subject: Re: [Discuss-gnuradio] help accessing fft bins in
40 matches
Mail list logo
