On Wed, Feb 5, 2014 at 2:25 AM, Tom McDermott tom.mcdermo...@yahoo.com wrote:
A flow graph that used to work in Gnuradio 3.7 now fails in 3.7.2.1
I've isolated it to the QT GUI Sink component, which causes the flowgraph to
immediately
aborts with a segmentation fault.
Core was generated by
On Wed, Feb 5, 2014 at 9:35 AM, Tom Rondeau t...@trondeau.com wrote:
On Wed, Feb 5, 2014 at 2:25 AM, Tom McDermott tom.mcdermo...@yahoo.com
wrote:
A flow graph that used to work in Gnuradio 3.7 now fails in 3.7.2.1
I've isolated it to the QT GUI Sink component, which causes the flowgraph to
Hi,
There is no throttle block in my flow graph. The USRP source is directly
connected to the custom block.
In the custom block, I form a 4x8 matrix with 4 being number of USRP's and
8 is the number of samples from each of them.
Then I do cross co-variance of the matrix(4x8) with its
On Tue, Feb 4, 2014 at 7:51 PM, Achilleas Anastasopoulos
anas...@umich.edu wrote:
To add to the question:
And what about the documentation on the C++ header files?
Achilleas,
We definitely want to support this. Possibly we just don't have the
hooks that take the doc xml output and insert
Hi,
A couple of digests ago I read about getting data from a running
flowgraph using probes.
I have a flowgraph that gets samples from an hardware source, filters
and decimates, and then sends samples to graphical sink.
The thing is, I want to be able to grab samples from the running
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, I think don't know why it overflows, but I get a better feeling
for your system :) thanks.
So: You have four UHD sources in parallel, feeding your block's four
input streams simultaneously, is that right? So, in that case, you
have a total sample
I've created a branch for folks to try out with changes to the gr-audio-osx
code, the sink only for now. Hopefully this branch addresses GR issue #623
http://gnuradio.org/redmine/issues/623 for the sink (I'm working on the
source separately; it's more involved not just for this bug but
Dear All,
I'm trying to perform a simple way of equalization in OFDM transmission. I
extracted the coefficients provided by the OFDM channel estimation block,
and sent them back to the transmitter using a TCP socket.
Are these coefficients valid to use in equalization, i.e., can I divide the
Hello All,
I have a Segmentation fault (core dumped), when i run digital_bert_rx.py and
digital_bert_tx.py.
./digital_bert_rx.py -f 2460M --rx-gain=30 --args=addr=192.168.10.2
./digital_bert_tx.py -f 2460M --tx-gain=30 --args=addr=192.168.10.3
--amplitude=0.2
When I run for a sevral times
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Mohammed,
I forgot to reply to the list in my previous mail, so I do this now.
On 05.02.2014 16:14, Mohammed Karmoose wrote:
Hi Johannes
Thank you for your prompt reply. I'm just trying to get my hands
as dirty as possible with Gnuradio. I'm
Tom,
thanks,for the reply.
Just want to confirm that in the current way gr_modtool generates a new OOT
module,
no matter what content we put on the docs directory, this will not result
in an invocation of doxygen, and thus it will not generate ANY kind of
manual
(not necessarily from header
On Wed, Feb 5, 2014 at 8:36 AM, raf raf raf...@hotmail.fr wrote:
Hello All,
I have a Segmentation fault (core dumped), when i run digital_bert_rx.py
and digital_bert_tx.py.
./digital_bert_rx.py -f 2460M --rx-gain=30 --args=addr=192.168.10.2
./digital_bert_tx.py -f 2460M --tx-gain=30
On 05.02.2014 06:51, Mohammed Karmoose wrote:
Dear All,
I'm trying to perform a simple way of equalization in OFDM transmission.
I extracted the coefficients provided by the OFDM channel estimation
block, and sent them back to the transmitter using a TCP socket.
Are these coefficients valid to
I was doing some work with this kernel and came across an odd result
that I think is caused by a non-saturating add in the generic
proto-kernel, that should also be relevant to the 16i_max_star_16i.
I haven't looked too much in to the SSE versions, but the generic
versions are doing a comparison
It's all well and good to send in an audio device name to the gr-audio
sink/source, and then see if that device name matches anything / works / is
found. In my fixes to gr-audio-osx, if the audio device was specified but not
found, the code will print out a list of available device names and
So here's an interesting one. I need to pipe some samples from a JACK
application to my graph. Using ALSA won't work (even with pcm.jack), and I
cannot install Pulseaudio in Arch for whatever reason. That was the
previous solution, but now it must be JACK.
Googling brings up old threads and not
Hi everybody,
I am also facing this problem. I am running a GMSK modulation and sometimes
I get the error:
Exception in thread Thread-915:
Traceback (most recent call last):
File /usr/lib/python2.7/threading.py, line 808, in __bootstrap_inner
self.run()
File
Hi Guys,
Is it possible to write a c++ block that takes 2 input streams,
produces 1 output streams, but to generate 1000 outputs it needs 1000
inputs of the first kind and 1 input of the second kind? How do I set
the set_output_rate? Does it apply to both input streams? How can I
ensure that the
Hi folks,
I want to accomplish the following with my usrp:
Receive from 1400 Mhz till 1500 Mhz and detect if there is activity (=signal,
no matter what) on 1430, 1430 and 1490 Mhz
So i have to split the spectrum in 3 parts (= channels) and do a peak detection
on each.
But how do i split
Dear All,
I suspect there is a bug in cfo_model_impl.h, where calling set_std_dev to
set the std_dev back to 0 causes undesirable effects.
How to reproduce the bug:
a) Standard OFDM TX-RX example in GRC. Connect the TX block to the RX block
through this channel model block.
b) Use a variable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Guy,
100MHz bandwidth is not easy to process. In fact, you can only capture
it at once if you have one of the brand new USRP X3*0.
But let's assume you have that :) and let's assume you have the
processing power to handle that amount of data.
You
Let me be more clear of what is my goal here:
We receive the 13cm ham band (2300Mhz - 2400 Mhz)
This is converted down (-900Mhz) to 1400 - 1500 Mhz) (L band)
This way normal satelite receivers can rx amateur television stations in 13cm
band.
We have 3 input frequencies in use: 2330 Mhz, 2360 Mhz
On 05.02.2014 13:13, on4...@telenet.be wrote:
Let me be more clear of what is my goal here:
We receive the 13cm ham band (2300Mhz - 2400 Mhz)
This is converted down (-900Mhz) to 1400 - 1500 Mhz) (L band)
This way normal satelite receivers can rx amateur television stations in 13cm
band.
We
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As Martin said, I think with these specifications your problem becomes
manageable :)
Get the detection running for a single channel, meaning that you tune
your USRP to the channel (you might even do that on the actual 13cm
band, daughterboards like
There may a problem with alsa and linux.
You can find all available cards in the file /proc/asound/cards.
But in some cases you can't use a card directly.
For instance the Delta M44 offers 10 channels, but in many use cases you
only work with 2 channels. So you have to use plugins.
Of course,
25 matches
Mail list logo
