Hi everybody,
Now i have a USRP board and a XCVR2450 daughterboard, i have installed
gnuradio-3.1.3 on FC9 sucessfully.
But i can not find XCVR2450 in the usrp_dbid.dat. I wonder if i add
"XCVR2450 Tx"0x0060
"XCVR2450 Rx"0x0061 in the usrp_dbid.dat and run gen_usrp_dbid.py to
gener
Johnathan Corgan wrote:
> On Thu, Dec 11, 2008 at 1:46 PM, Marcus D. Leech wrote:
>
> Yes. The "thread-per-block" design by Eric allows, in many cases, for
> the flowgraph throughput to rise until an individual block consumes
> 100% of a single core. This is a great improvement over the
> single
On Fri, Dec 12, 2008 at 2:42 PM, Glenn Richardson wrote:
> Our transmit chain indeed follows this exact pattern. The RRC was/is used
> to shape the data stream, and then we resampled in a second block.
>
> I would be interested to measure the performance gain by eliminating the
> extra block(s).
Johnathan Corgan wrote:
On Fri, Dec 12, 2008 at 1:47 PM, Josh Blum wrote:
However, I would like to make these convenience blocks for some of the
combinations. Would RRC FIR be useful? Any other suggestions for some
practical combinations?
A rational resampler that used RRC taps would
On Fri, Dec 12, 2008 at 1:47 PM, Josh Blum wrote:
> However, I would like to make these convenience blocks for some of the
> combinations. Would RRC FIR be useful? Any other suggestions for some
> practical combinations?
A rational resampler that used RRC taps would be useful as a transmit
side
See http://gnuradio.org/trac/wiki/GNURadioCompanion#FilterDesign
you have access to all the firdes function from inside grc. Just pick
out an FIR filter block, and enter firdes.root_raised_cosine(...) for
the taps parameter.
I made a few wrappers around the FIR filters for the pass band taps:
Thanks Bob!
That would be appreciated, especially here.
73,
Rob
Robert McGwier wrote:
Agreed, Tom and I don't have Qt3 on our systems as we have moved on.
I think we need to change the tests to look SPECIFICALLY for qt4 since
that is what we support.
Bob
On Fri, Dec 12, 2008 at 1:27 PM, Ro
Where did the root_raised_cosine filter go?
I recently began exploring GRC in the svn trunk, and quickly realized
that the root_raised_cosine filter has gone missing.
Missing is perhaps too strong of word... the filter exists in the
gr_firdes general library, but isn't brought out to a GRC bl
Agreed, Tom and I don't have Qt3 on our systems as we have moved on.
I think we need to change the tests to look SPECIFICALLY for qt4 since
that is what we support.
Bob
On Fri, Dec 12, 2008 at 1:27 PM, Rob Frohne wrote:
> Hi Everyone,
>
> After removing qt3-mt-dev, gnuradio builds just fine on
Hi Everyone,
After removing qt3-mt-dev, gnuradio builds just fine on Ubuntu 8.04. I
don't think this is the real solution, but a work around because I at
least still have some qt3 legacy code I haven't rewritten in QT4.
73,
Rob, KL7NA
Rob Frohne wrote:
Hi All,
I'm having difficulty comp
There IS a Gnu-Radio ready made block for Manchester encoding decoding.
Once you realize that this encoding is nothing but a finite automaton
(finte state machine) followed by memoryless modulation, all components
for encoding/decoding are there.
See gr-trellis.
Achilleas
-
On Fri, Dec 12, 2008 at 8:19 AM, Bob McGwier wrote:
> To be completely honest, I have never understood the gain to us provided by
> the COST the single threaded scheduler imposed. I cannot find the service
> the single thread scheduler provides that cannot be done more easily and
> with much gr
On Fri, Dec 12, 2008 at 6:39 AM, w w wrote:
> I'm new to GNU Radio and would like encode and decode manchester...I looked
> through the documentation for manchester or L encoding but did not see any
> thing. I was wondering if someone could point me in the right direction?
There isn't a ready
On Fri, Dec 12, 2008 at 8:23 AM, Bob McGwier wrote:
> This is in the trunk now right?
Yes.
-Johnathan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
This is in the trunk now right?
Bob
ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
"And yes I said, yes I will Yes", Molly Bloom
-Original Message-
From: discuss-gnuradio-bounces+rwmcgwier=gmail@gnu.org
[mailto:discuss-gnurad
To be completely honest, I have never understood the gain to us provided by
the COST the single threaded scheduler imposed. I cannot find the service
the single thread scheduler provides that cannot be done more easily and
with much greater efficiency in the TPB or even before in a simpler worker
On Thu, Dec 11, 2008 at 1:46 PM, Marcus D. Leech wrote:
> Also, I looked into the process details of the process running
> usrp_ra_receiver.py, and found that it had
> 25 threads. That must mean that each block runs in its own thread
> now?
Yes. The "thread-per-block" design by Eric allows, i
On Dec 12, 2008, at 3:29 AM, mutsa gahadza wrote:
Dear all
I have two debian host PCs and two USRPs. I have been trying to
measure Channel Impulse Response using usrpsounder.py.
My command lines are as follows:
# ./usrp_sounder.py -f 2.4G -r -v -D -F output.dat
# ./usrp_sounder.py -f 2.4G
I'm new to GNU Radio and would like encode and decode manchester...I looked
through the documentation for manchester or L encoding but did not see any
thing. I was wondering if someone could point me in the right direction?
TIA
___
Discuss-gnuradio mai
Dear all
I have two debian host PCs and two USRPs. I have been trying to measure Channel
Impulse Response using usrpsounder.py.
My command lines are as follows:
# ./usrp_sounder.py -f 2.4G -r -v -D -F output.dat
# ./usrp_sounder.py -f 2.4G -R A -t -v -D
I then used
a=read_complex_binary.m
plo
20 matches
Mail list logo
