Sorry I skipped the link.
I read the svn+lineseparator issue on the page
http://gnuradio.org/trac/wiki/WindowsTips
On 10/9/08, Umair Nasir [EMAIL PROTECTED] wrote:
I am using the cygwin environment.
As my college doesn't allow the svn command to download the latest gnuradio
trunk, giving
sorry if i keep coming up with more problems, i'm just trying to make
gnuradio better...
building from source from the trunk
(http://gnuradio.org/svn/gnuradio/trunk), after ./bootstrap, when
running ./configure, i get the following warning:
chmod: cannot access `gr-msdd6000/src/run_tests': No
I am using the cygwin environment.
As my college doesn't allow the svn command to download the latest
gnuradio
trunk, giving the error 'cannot resolve hostname', so I used the windows
based software 'TortoiseSVN' and downloaded everything in the folder
'gnuradio'.
Does the svn within cygwin
Hello,
my name is Alvaro Palomo. For the last few months I've been working
with the GNU Radio architecture and now I'm having some troubles
understanding a part of it. I hope somebody can give me a hand.
My problem is related to the Reed-solomon and Viterbi components. In
the trunk they are
Hi,
I am using USRP+RFX1400+SUSI
I am using following flow graph to receive data
usrp_source_c - gr.fir_filter_ccf - gr.quadrature_demod_cf -
gr.simple_correlator - gr.vector_sink_b
Some time I receive following error:
*** glibc detected *** python: free(): invalid next size (fast):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 9, 2008, at 8:39 AM, Dan wrote:
Hi, I am working on an OOK receiver but am having some problems with
the squelch.
I wrote a script with the following flow graph:
USRP.source_c - complex_to_mag - add_const_ff( -const ) -
Dear All,
I am working on an application where I have a sender S and a receiver
R. The procesure runs as follows:
(1) S transmits the channel estimation sequence. R estimates channel.
(2) S switches to receiving mode. R switches to the transmiting mode.
R sends the channel estimation back to S.
On Thu, Oct 09, 2008 at 11:39:29AM -0400, Dan wrote:
Hi, I am working on an OOK receiver but am having some problems with the
squelch.
I wrote a script with the following flow graph:
USRP.source_c - complex_to_mag - add_const_ff( -const ) -
binary_slicer_fb - file_sink
This works fine,
On Wed, Oct 8, 2008 at 12:20 PM, Kyle Pearson
[EMAIL PROTECTED] wrote:
On Tue, Oct 7, 2008 at 6:36 PM, Karthik Vijayraghavan
[EMAIL PROTECTED] wrote:
On Tue, Oct 7, 2008 at 3:01 PM, Kyle Pearson
[EMAIL PROTECTED] wrote:
I downloaded rev. 9728 from the svn today and after installing it when
I
Hello Everyone,
We purchased a USRP some time ago, and have been using it fairly frequently to
troubleshoot some wireless transmission products and protocols as we develop
them.
It works great. Fantastic, Actually.
What we want to do is build some test boxes that have an embedded
On Thursday 09 October 2008 19:47:10 Bill Stevenson wrote:
Hello, everyone!
I am just running a demo program to realize communication between two usrps
using benchmark_rx and benchmark_py under the Python/digital dir. But when
I am trying to use dqpsk modulation scheme, the packets received
Hello All,
How can I add support for the XCVR2450 daughterboard to the latest stable
release? I am in the process of updating some code to work with the trunk,
but in the meantime I would like to be able to use the old code in
conjunction with the XCVR2450.
Thanks,
Dustin
--
Dustin Maas
On Thu, Oct 09, 2008 at 07:29:51AM -0700, kaleem ahmad wrote:
Hi,
I am using USRP+RFX1400+SUSI
I am using following flow graph to receive data
usrp_source_c - gr.fir_filter_ccf - gr.quadrature_demod_cf -
gr.simple_correlator - gr.vector_sink_b
Some time I receive following error:
Hi,
I ran some performance analysis of the inband code, and found the pmt based
message passing as highly inefficient.
As a first step, I changed the pmt_list[1-6] implementations from using an
imbalanced tree with refcounted pairs against a much more simple pmt_vector
based one, resulting in
On Thu, Oct 09, 2008 at 12:24:26PM -0500, Zenny Zhang wrote:
Dear All,
I am working on an application where I have a sender S and a receiver
R. The procesure runs as follows:
(1) S transmits the channel estimation sequence. R estimates channel.
(2) S switches to receiving mode. R switches
On Thu, Oct 09, 2008 at 09:26:47PM +0200, Stefan Brüns wrote:
Hi,
I ran some performance analysis of the inband code, and found the pmt based
message passing as highly inefficient.
As a first step, I changed the pmt_list[1-6] implementations from using an
imbalanced tree with refcounted
complex_to_mag_squared is many many times faster than complex_to_mag.
Using it would reduce your CPU consumption.
Okay, I changed the block from complex_to_mag to mag_squared and it seems to
work well, thanks.
However, I am still looking for a way to prevent writing to file when a
signal is
Eric Blossom wrote:
The pmt type probably needs to be reimplemented. The current version
was coded in about 1 day. It was the simplest thing that could have
possibly worked. I'm disinclined to go with statically typed messages
for a number of reasons that I don't have time to go into now.
Dear Eric,
On Thu, Oct 9, 2008 at 2:19 PM, Eric Blossom [EMAIL PROTECTED] wrote:
Use Auto Transmit/Receive switching (ATR) and see tunnel.py for an
example that uses it. (It's a terrible example of a MAC, but does show
how to set up something similar to what you want.) No need to stop
the
On Thu, Oct 9, 2008 at 5:20 AM, Alvaro Palomo [EMAIL PROTECTED] wrote:
My problem is related to the Reed-solomon and Viterbi components. In
the trunk they are placed in the folder /gnuradio-core/src/lib/viterbi
and /gnuradio-core/src/lib/reed-solomon respectively, well, I suppose
you already
On Thu, Oct 9, 2008 at 11:59 AM, Dustin Maas [EMAIL PROTECTED] wrote:
How can I add support for the XCVR2450 daughterboard to the latest stable
release? I am in the process of updating some code to work with the trunk,
but in the meantime I would like to be able to use the old code in
On Thu, Oct 9, 2008 at 1:41 PM, George Nychis [EMAIL PROTECTED] wrote:
Just a little bit from just about the only person who has *actually* used
the PMT type other than Eric ;) I definitely agree with Eric against
statically typed messages. It will severely impact a major goal of the PMT,
Hello, everyone!
I think there is a bug in benchmark_rx.py and benchmark_tx.py files!!!
Seriously!
I am just running a demo program to realize communication between two
usrps using benchmark_rx and benchmark_py under the Python/digital dir.
But it appears that that program does not support
Thanks. That did the trick.
-Dustin
On Thu, Oct 9, 2008 at 5:10 PM, Johnathan Corgan
[EMAIL PROTECTED] wrote:
On Thu, Oct 9, 2008 at 11:59 AM, Dustin Maas [EMAIL PROTECTED] wrote:
How can I add support for the XCVR2450 daughterboard to the latest stable
release? I am in the process of
Hi there
I would like to know a thing or two about the HBF at the end of the
rx_chain. From what it looks, it's a 31-tap lowpass FIR filter with
every second tap being a zero to make it a halfband filter? Also,
because we're at least decimating by 4 in the CIC and 2 in the HBF, we
have 8 clocks
25 matches
Mail list logo
