Hi Tom, Matt
replied inline:
On Wed, Feb 17, 2010 at 10:26 AM, Tom Rondeau trondeau1...@gmail.comwrote:
On Tue, Feb 16, 2010 at 5:45 PM, Srinivas psriniva...@gmail.com wrote:
Matt,
Thanks for verifying the data rate calculation!
I tried the other solutions that you suggested, namely,
Matt,
Thanks for verifying the data rate calculation!
I tried the other solutions that you suggested, namely,
*- increasing the data rate by a factor of 2 or 4
*It works.
*
- modifying the OFDM code to widen the search range* - How do I widen the
search range ?
Should I be looking in the
On 02/16/2010 02:45 PM, Srinivas wrote:
Matt,
Thanks for verifying the data rate calculation!
I tried the other solutions that you suggested, namely,
*- increasing the data rate by a factor of 2 or 4
*It works.
*
- modifying the OFDM code to widen the search range* - How do I widen
the search
On 02/12/2010 03:53 PM, Srinivas wrote:
Matt,
There was a frequency offset of ~30 KHz at the Rx w.r.t Tx so I
compensated for it and it worked!.
The settings I am using is as follows:
./benchmark_ofdm_tx.py -f 2.45G --tx-amplitude 0.9 -M 8 -s 200 -m bpsk
--fft-length=512 --occupied-tones=80
That formula will give you the number of occupied tones per second. You
need to multiply by the number of bits per tone to get bps. If you are
using BPSK, multiply by 1. If using QPSK, you'll need to multiply by 3,
8PSK by 3, etc.
I meant to say:
BPSK - multiply by 1
QPSK - mult by 2 (not 3
Matt,
There was a frequency offset of ~30 KHz at the Rx w.r.t Tx so I compensated
for it and it worked!.
The settings I am using is as follows:
./benchmark_ofdm_tx.py -f 2.45G --tx-amplitude 0.9 -M 8 -s 200 -m bpsk
--fft-length=512 --occupied-tones=80 -i 64 --tx-gain=10 --cp-length=128
On 02/11/2010 04:45 PM, Srinivas wrote:
Hi All,
I have 2 pairs of USRP2s with GNURadio-3.2 installed on their hosts. On
one pair I am able to successfully run OFDM (benchmark_ofdm_tx rx)
with almost 95+% packet success rate. However on the other pair I am not
receiving even 1 packet!
I am
Hi all
I am trying OFDM transmission and receive test.
I’m using Ubuntu 9.10, gnuradio version 3.3 and two USRP boards with basic TX
and RX and I am using GRC.
In the GRC I make simple test signal flow with usrp
Tx : File source - OFDM mod - USRP sink
Rx : USRP source- OFDM demod
, 2010 10:22 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] OFDM modulation/demodulation over USRP2
Hi,
I'm using Ubuntu 9.10, gnuradio version 3.2.2 and two USRP2
boards with XCVR2450 daughter boards. The boards are about a
meter apart from each other.
I'm trying to get OFDM
Of Veljko Pejovic
Sent: Wednesday, January 13, 2010 10:22 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] OFDM modulation/demodulation over USRP2
Hi,
I'm using Ubuntu 9.10, gnuradio version 3.2.2 and two USRP2
boards with XCVR2450 daughter boards. The boards are about a
meter
+patrik.eliardsson=foi...@gnu.org
[mailto:discuss-gnuradio-bounces+patrik.eliardsson=foi...@gnu.
org] On Behalf Of Veljko Pejovic
Sent: Wednesday, January 13, 2010 10:22 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] OFDM modulation/demodulation over USRP2
Hi,
I'm using Ubuntu 9.10
Hi,
I'm using Ubuntu 9.10, gnuradio version 3.2.2 and two USRP2 boards
with XCVR2450 daughter boards. The boards are about a meter apart from
each other.
I'm trying to get OFDM working over USRP2 boards and for that I'm
using GRC. I created a simple local loop (without USRPs):
Hi All,
I am implementing a OFDM tranceiver. I am following the benchmark.py and
tunnel.py for achieving it. I am facing the following problems while
performing receive-- transmit-- receive:
1.It receives on the startup of the code.
2.It transmits and then it does not receive at all.
I have
Hello everyone,
I was trying to implement some OFDM transmission with a
rfx2400 without using the ofdm code that comes with gnuradio but creating my
own one.
I make a 256 bean Ifft transform after the windowing, and I've tried
two different types of window the rectangular one (aka no window :)
Hi out there,
I'm trying to send an ofdm signal. I don't want to tramsit any data, I only
want to see the reslting spectrum.
Now I'm wondering how to turn off certain carriers.
I know this is possible by adjusting the transmitted data but is there a
better way to do this?
For example by
Hi,
I found the OFDM IFFT caculation is very different from what I got in
MATLAB.
In detail, my command is shown below
./benchmark_ofdm_tx.py -f 10M -i 512 --fft-length=64 --occupied-tones=32
--cp-length=4 (bpsk)
The packet size is 8 bits, after a serials of operation, it added 4 bytes
On Fri, Jul 31, 2009 at 12:52:44AM +, maher manai wrote:
i'm working on wlan system wich is 802.11a/g it use OFDM mod . in
GRC i found a ofdm mod block wich contains mod type ,ifft , cyclic
prefix but i think it doesn't support the number of subcarrier
pilots and there position wich are 4
i'm working on wlan system wich is 802.11a/g it use OFDM mod . in GRC i found a
ofdm mod block wich contains mod type ,ifft , cyclic prefix but i think it
doesn't support the number of subcarrier pilots and there position wich are 4
pilots . so i ask if smeone can explain to me if there is any
i am trying to transmit sound through OFDM system using the USRP
i was able to transmit and receive audio in OFDM system without the USRP and
also was able to transmit and receive audio using the USRP without OFDM
when i try to merge the 2 system using the scope i see that there is a signal
sorry if i keep asking a lot of questions but this time i tried google 1st and
didn't find a solution to my problem
i am trying to transmit audio through ofdm modulator then USRP
then from the Rx of the USRP (same USRP) to OFDM demod to audio sink
i am using basic Tx and basic Rx connected to
how can i get the C++ source code of the blocks in GRC
i mainly need that of the OFDM mod and demod i tried browsing browse source
tab in gnuradio.org but it is something like a tree where i dont understand any
thing
can any one plz help
try something like:
$ find [gnuradio-build-tree-path] -name gr_ofdm*
find, grep and others are friendly, you just have to talk to them... So
are the man- pages =;oP
//Mattias
how can i get the C++ source code of the blocks in GRC
i mainly need that of the OFDM mod and demod i tried browsing
Subject: Re: [Discuss-gnuradio] OFDM Mod C++ source code
To: discuss-gnuradio@gnu.org discuss-gnuradio@gnu.org
Date: Wednesday, July 8, 2009, 5:52 PM
try something like:
$ find [gnuradio-build-tree-path] -name gr_ofdm*
find, grep and others are friendly, you just have to talk to them... So
On Wed, Jul 8, 2009 at 14:02, Abdalla Sokarabdallaso...@yahoo.com wrote:
i downloaded gnuradio from the update manager not from the source
and when i searched for gr_ofdm i only found the .h files but i need the
.cpp files
Do:
$ apt-get source gnuradio
Johnathan
Katy Qian wrote:
Hi,
For the majority of my tests (ex. below), with benchmark_ofdm_*, the
receiver terminates prematurely with:
...
ok: True pktno: 7501 n_rcvd: 4537n_right: 4263
ok: True pktno: 7502 n_rcvd: 4538n_right: 4264
ok: True pktno: 7503
Hi,
For the majority of my tests (ex. below), with benchmark_ofdm_*, the
receiver terminates prematurely with:
...
ok: True pktno: 7501 n_rcvd: 4537n_right: 4263
ok: True pktno: 7502 n_rcvd: 4538n_right: 4264
ok: True pktno: 7503 n_rcvd: 4539
adib_sairi wrote:
thanks Eric.. now i am trying to install from the trunk (revision 10978).
i am using fedora 9. ./bootstrap command was success but ./configure give
me an error. it tell be that i dont have the boost package. I think i had
install the boost package using yum install
adib_sairi wrote:
adib_sairi wrote:
thanks Eric.. now i am trying to install from the trunk (revision 10978).
i am using fedora 9. ./bootstrap command was success but ./configure give
me an error. it tell be that i dont have the boost package. I think i had
install the boost package using
Eric Blossom wrote:
If you mean that you have local changes that are based on the 3.1.3
tarball, then the most straight-forward way to handle this is to
generate a diff -u between the unmodified 3.1.3 source and your
modified source, then apply that difference to a virgin copy of the
I just added the blks2.ofdm_mod/demod blocks to GRC in the gnuradio
trunk. svn up!
The generated code looks a bit odd... but so are the OFDM blocks:
- options class containing parameters to ofdm mod and demod (why not
*args and **kwargs?)
- no input stream to ofdm mod, has a send_pkts
Hi, I'm trying to implement an OFDM modulator. I've almost done but I have a
question: In the new version of the ofdm.py (the one included in the trunk
version, under the dab folder) I have to pass two inputs to the ofdm_mod
class: the first of 96 bytes (depending on the numbers of the carreers)
oh ok.. so do i need to copy the whole trunk to run the example? or do i
need to copy the whole library (rev @9989)?
Eric Blossom wrote:
On Fri, Jan 30, 2009 at 06:52:24AM -0800, adib_sairi wrote:
hi,
i would like to try the OFDM example but i cannot find the
benchmark_ofdm_tx.py and
I had download the whole trunk (Revision 10377) but i cannot run the
example in it (benchmark_ofdm_tx.py) and i think it is because i does not
merge it with my GNU Radio yet. I use GNU Radio 3.1.3. how can i merge the
trunk with my gnu radio? can you help me for this? thank you.
adib
Eric
On Mon, Feb 02, 2009 at 08:45:37PM -0800, adib_sairi wrote:
I had download the whole trunk (Revision 10377) but i cannot run the
example in it (benchmark_ofdm_tx.py) and i think it is because i does not
merge it with my GNU Radio yet. I use GNU Radio 3.1.3. how can i merge the
trunk with
hi,
i would like to try the OFDM example but i cannot find the
benchmark_ofdm_tx.py and benchmark_ofdm_rx.py file in
/gnuradio-example/python/digital. did i search it in the wrong place or did
the file being remove from the gnuradio-3.1.3.tar ?
trondeau wrote:
For anyone working with the
On Fri, Jan 30, 2009 at 06:52:24AM -0800, adib_sairi wrote:
hi,
i would like to try the OFDM example but i cannot find the
benchmark_ofdm_tx.py and benchmark_ofdm_rx.py file in
/gnuradio-example/python/digital. did i search it in the wrong place or did
the file being remove from the
I think you could change the value of -d and -i and see. This is what I
tried.
./benchmark_ofdm_tx.py -f 440M -T A --tx-amplitude 5000 -v -i 128
--fft-length 128 --occupied-tones 80 --cp-length 32
./benchmark_ofdm_rx.py -f 440M -R A -v -d 64 --fft-length 128
--occupied-tones 80 --cp-length 32
Hello everyone,
I noticed that in the OFDM benchmark implementation, the padding for
the USRP is set to false in transmit_path.py when creating the ofdm
modulator, whereas in the digital/benchmark it is set to true.
I do not see where else in the OFDM implementation the packets to be
sent
Hi,
I'm currently trying to get a hang of the OFDM-internals and I'm stuck
in gr_ofdm_mapper_bcv. I hope someone might be able to enlighten me...
First of all, how exactly does gr_ofdm_mapper_bcv decide which carriers
are used? I really, really hate having to ask this kind of question when
I
Hello,
I am testing the OFDM trunk code 9798 in openSUSE 10.3 (i586). I run
the benchmark_ofdm_tx.py script while having connected the USRP to a
spectrum analyzer and to my surprise, using the default parameters of
the script (those are: Modulation Type: bpsk, FFT length: 512,
Occupied Tones:
In your sixteen QAM and other figures I see two effects.
Notice just the slightest hint that arcs through the top four
constellation points in the 16 QAM is not straight. This curvature is
caused by nonlinearity.
Your result almost surely can NOT be clock jitter. If you had a lot of
clock
-Original Message-
From: Bob McGwier [mailto:[EMAIL PROTECTED]
Sent: den 6 juni 2008 09:23
To: Per Zetterberg
Cc: discuss-gnuradio@gnu.org; 'Per Zetterberg'
Subject: Re: [Discuss-gnuradio] OFDM results.
In your sixteen QAM and other figures I see two effects.
Notice just
Bob-
In your sixteen QAM and other figures I see two effects.
Notice just the slightest hint that arcs through the top four
constellation points in the 16 QAM is not straight. This curvature is
caused by nonlinearity.
Your result almost surely can NOT be clock jitter. If you had a lot
Jeff Brower wrote:
Bob-
In your sixteen QAM and other figures I see two effects.
Notice just the slightest hint that arcs through the top four
constellation points in the 16 QAM is not straight. This curvature is
caused by nonlinearity.
Your result almost surely can NOT be clock jitter.
PROTECTED]
Sent: den 6 juni 2008 09:23
To: Per Zetterberg
Cc: discuss-gnuradio@gnu.org; 'Per Zetterberg'
Subject: Re: [Discuss-gnuradio] OFDM results.
In your sixteen QAM and other figures I see two effects.
Notice just the slightest hint that arcs through the top four
constellation points
Jeff:
Good to hear from you again. I am distinguishing betwen clock recovery
operations in the receiver and the oscillator feeding the down
conversion mixers. Even though there is some commonality in the sources
for these two DIFFERENT things on the USRP, implementation factors of
the
Bob-
Good to hear from you again. I am distinguishing betwen clock recovery
operations in the receiver and the oscillator feeding the down
conversion mixers. Even though there is some commonality in the sources
for these two DIFFERENT things on the USRP, implementation factors of
the
Matt Ettus wrote:
Jeff Brower wrote:
Bob-
In your sixteen QAM and other figures I see two effects.
Notice just the slightest hint that arcs through the top four
constellation points in the 16 QAM is not straight. This curvature is
caused by nonlinearity.
Your result almost surely can NOT
Bob McGwier wrote:
The USRP is not in the same league with the USRP2. The on board
oscillator is much better but external oscillators will make it even
better. So the answer is a big yes, the USRP2 will be better.
Actually, I need to disagree again here :)
The master oscillator on the
Hello Per
What is the cause of the problems. Clock jitter ?, non-linearities ?
No idea what could be the problem in your case, but maybe try also
plotting the phase of all symbols in one OFDM symbol vs the offset from
the central carrier.
I'm currently working on DAB and I found some
-gnuradio] OFDM results.
Hello Per
What is the cause of the problems. Clock jitter ?, non-linearities ?
No idea what could be the problem in your case, but maybe try also
plotting the phase of all symbols in one OFDM symbol vs the offset from
the central carrier.
I'm currently working on DAB
where is the inaccuracy in sampling frequency exactly happening?
In USRP?
Yes - the sampling frequency is inaccurate, because the crystal on the
USRP is not oscillating at exactly 64 MHz.
FYI, the samples in the plot are actually not from an USRP (I didn't
record them myself) - the inaccuracy
Dear all,
I am experimenting with OFDM between two USRPs. Unfortunately, I am not yet
able to master the gnuradio framework so I have made my own implementation.
The results are given in the link below.
http://www.s3.kth.se/~perz/usrp/OFDM_results.pdf
How does this compare with the gnuradio
Hey,
I add two parameters in gnuradio-core/python/ofdm.py
expert.add_option(,--onoff,type =intx, default = 0,
help=set the number of use
multi_constellation decision [defalut=%default])
for (i = 0 ; ioccupied-tones ; i++)
Hi,
I use an array to implement supporting multi-constellation scheme for OFDM
system, but
I got a problem in modifying the code for /trunk/
gnuradio-core/src/python/gnuradio/blks2impl/ofdm.py
in which I generate a parameter multi_modulation[i][j]
while i is the ith subcarrier, and j is the
CHIN-YA HUANG wrote:
Hi,
Does anyone have clear idea about how gunradio implements serial to parallel
mapping since 802.11 has 52 channels?
I check the gr_ofdm_mapper_bcv.cc , but still have no idea about it.
In further, I want to apply an array mapping to implement that different channels
Hi,
Does anyone have clear idea about how gunradio implements serial to parallel
mapping since 802.11 has 52 channels?
I check the gr_ofdm_mapper_bcv.cc , but still have no idea about it.
In further, I want to apply an array mapping to implement that different
channels use different
10:54 am
Subject: Re: [Discuss-gnuradio] OFDM Updates
To: CHIN-YA HUANG [EMAIL PROTECTED]
Cc: discuss-gnuradio@gnu.org
I wonder if you are told several more times that it is already
released
in an svn branch if you will finally look to see how to get it?
http://gnuradio.org/trac/browser
- Original Message -
From: Tom Rondeau [EMAIL PROTECTED]
Date: Wednesday, March 26, 2008 9:50 am
Subject: Re: [Discuss-gnuradio] OFDM Updates
To: CHIN-YA HUANG [EMAIL PROTECTED]
Cc: discuss-gnuradio@gnu.org
CHIN-YA HUANG wrote:
Hello Tom,
Based on your information below I know the problem
it.
Chin-Ya
- Original Message -
From: Bob McGwier [EMAIL PROTECTED]
Date: Monday, March 31, 2008 11:54 pm
Subject: Re: [Discuss-gnuradio] OFDM Updates
To: CHIN-YA HUANG [EMAIL PROTECTED]
Cc: discuss-gnuradio@gnu.org
I wonder if you are told several more times that it is already
Hi Tom,
Would you mind release your modified code for me as reference first? Thanks
Chin-Ya
- Original Message -
From: Tom Rondeau [EMAIL PROTECTED]
Date: Wednesday, March 26, 2008 9:50 am
Subject: Re: [Discuss-gnuradio] OFDM Updates
To: CHIN-YA HUANG [EMAIL PROTECTED]
Cc: discuss
Hello Tom,
Based on your information below I know the problem will be receiver. However,
if I want to solve the receiver's problem. Where is the starting point you
suggestion? From the gnu-radio core part?
Chin-Ya
From: Tom Rondeau
Subject:[Discuss-gnuradio] OFDM Updates
Date
my current branch,
which will be in a few days, hopefully.
Tom
From: Tom Rondeau
Subject:[Discuss-gnuradio] OFDM Updates
Date: Thu, 07 Feb 2008 14:09:58 +
User-agent: Thunderbird 2.0.0.9 (Windows/20071031)
For anyone working with the OFDM code, my latest check
Sarang Mandke wrote:
I used Tom Rondeau's changeset 7848 and applied it to my current
updated code.
Currently I am getting a runtime error from ofdm sampler saying that
there are insufficient output ports.
Has anyone faced a similar issue? Esp. for OFDM over air, this is a
major prob.
Scrive Eric Blossom [EMAIL PROTECTED]:
On Thu, Feb 28, 2008 at 12:51:18PM +0100, Crespi Floriana wrote:
Hi,
I have a problem with OFDM system.
I transmit OFDM signal at 2.4 GHz, but I receive half of the total packets.
Moreover, only half of the packets received are correct.
CRC
Crespi Floriana wrote:
Scrive Eric Blossom [EMAIL PROTECTED]:
On Thu, Feb 28, 2008 at 12:51:18PM +0100, Crespi Floriana wrote:
Hi,
I have a problem with OFDM system.
I transmit OFDM signal at 2.4 GHz, but I receive half of the total packets.
Moreover, only half of the packets received
Hi,
I have a problem with OFDM system.
I transmit OFDM signal at 2.4 GHz, but I receive half of the total packets.
Moreover, only half of the packets received are correct.
CRC controller is perfect but i want a ber estimate, so I change the
payload (binary file) and I receive check bit by bit.
On Thu, Feb 28, 2008 at 12:51:18PM +0100, Crespi Floriana wrote:
Hi,
I have a problem with OFDM system.
I transmit OFDM signal at 2.4 GHz, but I receive half of the total packets.
Moreover, only half of the packets received are correct.
CRC controller is perfect but i want a ber estimate, so
Eric Blossom wrote:
On Thu, Feb 28, 2008 at 12:51:18PM +0100, Crespi Floriana wrote:
Hi,
I have a problem with OFDM system.
I transmit OFDM signal at 2.4 GHz, but I receive half of the total packets.
Moreover, only half of the packets received are correct.
CRC controller is perfect but i want
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
George Nychis wrote:
it seems to me like you're using antennas, you can try coax to isolate
the problem maybe you're getting interference at 2.4GHz. But answer
Eric's questions too.
With suitable attenuation of course -- I think Matt says at
Shravan Rayanchu wrote:
Hi Dan and Tom,
Thanks for your comments. I'll trying changing the parameters and look
at the log files to see what might be wrong.
Shravan
As you will see in my original email, the problem is inside of the OFDM
receiver, and I pointed out what that issue is and
Hi Tom,
I checked out the latest version of gnuradio from the trunk (svn co
http://gnuradio.org/svn/gnuradio/trunk gnuradio). I am running the
OFDM code on 2 USRP nodes over the air. The nodes are placed pretty
close to each other (a separation of ~1-1.5 meters) but this is what I
get as the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shravan Rayanchu wrote:
Basically, I seem to completely lose some of the packets in the air.
Of the packets I receive, almost all the packets are received
correctly. Initially, the error rate was too high (The packets were
getting lost and also
Dan Halperin wrote:
Shravan Rayanchu wrote:
Basically, I seem to completely lose some of the packets in the air.
Of the packets I receive, almost all the packets are received
correctly. Initially, the error rate was too high (The packets were
getting lost and also among the packets received,
Hi Dan and Tom,
Thanks for your comments. I'll trying changing the parameters and look
at the log files to see what might be wrong.
Shravan
On Feb 13, 2008 6:15 PM, Tom Rondeau [EMAIL PROTECTED] wrote:
Dan Halperin wrote:
Shravan Rayanchu wrote:
Basically, I seem to completely lose some
For anyone working with the OFDM code, my latest check-in to the trunk
fixes some of the main issues of transmitting over the air. Using
benchmark_ofdm_rx and benchmark_ofdm_tx on different machines, I am now
able to successfully capture most packets with any modulation at the
appropriate
On Sun, Feb 03, 2008 at 05:59:06PM +0100, Jacopo wrote:
Thanks a lot
Another question: It's possible to have adaptive modulation, that is the
possibility to use different modulation for any subcarrier?
Bye
Jacopo
It's definitely possible. The main question is how to design an
Jacopo wrote:
Thanks! But where can i check this parameter?
Is it possible that fft_length= occupated carrier (--occupied-tones in
blksimpl/ofdm.py) + un_used carrier ? Where can i set the position of
the occupated_bins?
bye
To modify the bandwidth, you have to set the interpolation and
Thanks a lot
Another question: It's possible to have adaptive modulation, that is the
possibility to use different modulation for any subcarrier?
Bye
Jacopo
2008/2/3, Thomas Rondeau [EMAIL PROTECTED]:
Jacopo wrote:
Thanks! But where can i check this parameter?
Is it possible that
Jacopo wrote:
Thanks a lot
Another question: It's possible to have adaptive modulation, that is
the possibility to use different modulation for any subcarrier?
Bye
Jacopo
No, not in the current implementation. You'll have to create a new
ofdm_modulator block to handle this behavior.
Jacopo wrote:
Hello I'm studing an OFDM implementation on gnuradio. I want to modify
benchmark_ofdm_tx.py.
I have just read ofdm.py and trasmit_path.py but I can't find how
change some parameters.
I'd want a bandwith of 20Mhz, where I can set this option? Where can I
set the carriers
Thanks! But where can i check this parameter?
Is it possible that fft_length= occupated carrier (--occupied-tones in
blksimpl/ofdm.py) + un_used carrier ? Where can i set the position of the
occupated_bins?
bye
2008/2/2, Matt Ettus [EMAIL PROTECTED]:
Jacopo wrote:
Hello I'm studing an OFDM
Hello I'm studing an OFDM implementation on gnuradio. I want to modify
benchmark_ofdm_tx.py.
I have just read ofdm.py and trasmit_path.py but I can't find how change
some parameters.
I'd want a bandwith of 20Mhz, where I can set this option? Where can I set
the carriers number? And the pilot
Hello all,
For an experiment I'm working on I need to transmit an OFDM signal from
one USRP and 'respond' from another USRP with an OFDM message with
(hopefully) millisecond timing. I've used elements of
benchmark_ofdm_tx/rx and the tunnel examples to construct the following:
USRP A
Hello to all the experts!
I am doing a mini project on GNU Radio using OFDM. Somehow I am getting
runtime errors when i try to run the benchmark scripts .
The message i get when trying to run benchmark_ofdm_tx.py is
[EMAIL PROTECTED]:~/gnuradio/gnuradio-examples/python/ofdm$
On Mon, Oct 01, 2007 at 10:33:25PM +0200, Sarang Mandke wrote:
Hello to all the experts!
I am doing a mini project on GNU Radio using OFDM. Somehow I am getting
runtime errors when i try to run the benchmark scripts .
The message i get when trying to run benchmark_ofdm_tx.py is
[EMAIL
Josh Blum wrote:
I reimplemented the packet modulator/demodulator in GRC, and updated the
packet_mod_demod.grc.xml example. The packet modulator can be used
interchangeably with the gmsk, psk, and qam modulators (same for demod).
See PacketModHelper and PacketDemodHelper in
I'm still not entirely sure what the difference between the hier and
hier2 versions are? Is there anywhere that discusses this? I've checked
the wiki and the mailing list with no results.
The hier blocks were a way to hide a linear chain of blocks inside a
macro block, and all blocks
Josh Blum wrote:
Its not quite that. I should explain. The packet modulator block in
blks is weird for another reason, it takes another gnuradio block (a
modulator) as an argument in the constructor. The problem being that
this does not fit into GRC too well.
OFDM is itself a modulation
Hello all,
I'm trying to write an OFDM mod/demod for the gnuradio companion and
I'm running into a problem. I'm following the (now deprecated?) packet
modulator code that was in GRC very closely. I have an OFDMDemod block
which creates the following class when its used:
---
class
On Sat, Aug 04, 2007 at 01:01:21PM -0400, Robert McGwier wrote:
All resolvable with in-band signaling and RSSI with feedback to agc
hardware and software.
I know, I know, I am a broken record.
Bob
Hi Bob!
Good to hear that you're still out there ;)
Eric
Tom Rondeau wrote:
Matt and I
Matt and I have had a bit of a chance to work out some kinks in the OFDM
world. My latest merge should allow people to operate over the air ok.
The problem turns out to be false correlations when using the BasicRX
boards because with the low gain, the noise only toggles the last 1 or 2
LSBs, which
All resolvable with in-band signaling and RSSI with feedback to agc
hardware and software.
I know, I know, I am a broken record.
Bob
Tom Rondeau wrote:
Matt and I have had a bit of a chance to work out some kinks in the OFDM
world. My latest merge should allow people to operate over the
I just checked in a fix for the regenerate block. It's possible this was
the cause of some of the assertions people were seeing when running the
receiver. Could someone who was seeing that problem would check out the
latest revision and see if it's still a problem?
Thanks,
Tom
Brett Trotter wrote:
Tom Rondeau wrote:
Just the status report from the work done the past couple of weeks on
OFDM. With Matt Ettus, Bob McGwier, and Eric Blossom, we successfully
transmitted and received OFDM over the air with BPSK, QPSK, and 16QAM. I
have merged the code into the trunk
Martin Dvh wrote:
Tom Rondeau wrote:
Just the status report from the work done the past couple of weeks on
OFDM. With Matt Ettus, Bob McGwier, and Eric Blossom, we successfully
transmitted and received OFDM over the air with BPSK, QPSK, and 16QAM.
I have merged the code into the trunk so
Tom Rondeau wrote:
Just the status report from the work done the past couple of weeks on
OFDM. With Matt Ettus, Bob McGwier, and Eric Blossom, we successfully
transmitted and received OFDM over the air with BPSK, QPSK, and 16QAM. I
have merged the code into the trunk so others can use
Just the status report from the work done the past couple of weeks on
OFDM. With Matt Ettus, Bob McGwier, and Eric Blossom, we successfully
transmitted and received OFDM over the air with BPSK, QPSK, and 16QAM. I
have merged the code into the trunk so others can use it, though I
currently
Tom Rondeau wrote:
Just the status report from the work done the past couple of weeks on
OFDM. With Matt Ettus, Bob McGwier, and Eric Blossom, we successfully
transmitted and received OFDM over the air with BPSK, QPSK, and 16QAM.
I have merged the code into the trunk so others can use it,
I've checked out the latest version (5772) and tried running the
benchmark_ofdm files. The benchmark_ofdm.py and ofdm_benchmark_tx.py seem
to be working. But when I use the benchmark_ofdm_rx.py I get the following
error:
python: gr_ofdm_correlator.cc:105: gr_complex
401 - 500 of 554 matches
Mail list logo
