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 signal level.
I say most packets because there is still an issue involved in the
receiver where the regenerator signal pops up before the peak detector
signal resets it and causes a problem in the packet sampler. To see what
I mean, run
“benchmark_ofdm.py --log”
And look at the output of the regen and peak detector blocks:
gr_plot_char.py ofdm_sync_pn-regen_b.dat ofdm_sync_pn-peaks_b.dat
This will plot a series of 0’s with a few 1’s, where the peaks occur.
The peak detector sends it out once, and then the regenerator takes
over. For every packet, there is one output of the peak detector. If you
look, sometimes the peak detector will hit just after a regenerated
signal. By this point, it’s too late and the ofdm_sampler has already
triggered off of the regen signal and ignores the peak.
It’s a bit of a hassle, but I’ll look into it soon. Any help is
appreciated, though 
Tom
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 output ::
ok: True pktno: 100 n_rcvd: 60 n_right: 59
ok: True pktno: 103 n_rcvd: 61 n_right: 60
ok: True pktno: 105 n_rcvd: 62 n_right: 61
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, lot of them were in
errors), so I increased tx-amplitude to ~3000.
Am I using the right version of the code ? Is the tarball release
better to use ? Can you please let me know if there are any parameters
which I need to change ?
Thanks,
Shravan
-----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 among the packets received, lot of them were in
errors), so I increased tx-amplitude to ~3000.
Am I using the right version of the code ? Is the tarball release
better to use ? Can you please let me know if there are any parameters
which I need to change ?
Tom mentioned an existing problem in the email you replied to, which you
didn’t address in your response. Could that be the problem or have you
ruled it out?
For debugging these types of errors, I really do suggest (from
experience!) that you start saving the outputs of the intermediate
stages to disk and seeing what they look like. It might require some
understanding of the receiver, but then again you probably want that
knowledge anyway…
It’s likely (as I found with older versions of the DBPSK code, for
instance) that some of the synchronization and/or timing algorithms
aren’t working in your setup. But maybe there’s lots of cochannel
interference. Maybe the RSSI is low. Maybe the frequency offset of your
daughterboards is too large to be handled by the PLLs…
The way that you can tell these things is by analyzing the output –
it’s really hard for Tom to debug it offline. And he can’t test his code
in all possible environments.
- -Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHs3iGy9GYuuMoUJ4RAtSyAJ9pyTdRSiJONyTSWtHZErCtzH8FrwCdFYNu
NMAnpoUeOInoFo1U2hRFSZs=
=Y0Jt
-----END PGP SIGNATURE-----
Dan H. wrote:
which I need to change ?
Tom mentioned an existing problem in the email you replied to, which you
didn’t address in your response. Could that be the problem or have you
ruled it out?
Yes, thanks for pointing that out, Dan. The problem I discussed in my
original email is certainly the problem; it’s exactly what I was seeing.
For debugging these types of errors, I really do suggest (from
experience!) that you start saving the outputs of the intermediate
stages to disk and seeing what they look like. It might require some
understanding of the receiver, but then again you probably want that
knowledge anyway…
Excellent point. Visualization tools are a key to understanding and
debugging this stuff.
By using the --log option, the receiver will dump output data files for
every important (and even some not-so-important) block in the chain. The
gr_plot_XXX.py scripts are useful for getting a quick look at the
output. There is a local gr_plot_ofdm.py script distributed as part of
the ofdm example directory that provides a specific way of looking at
the output of the OFDM system.
It’s likely (as I found with older versions of the DBPSK code, for
instance) that some of the synchronization and/or timing algorithms
aren’t working in your setup. But maybe there’s lots of cochannel
interference. Maybe the RSSI is low. Maybe the frequency offset of your
daughterboards is too large to be handled by the PLLs…
Always the case, really. These methods are as straight-forward as we can
make them to do the basic receivers for different modulations. Most
standard/commercial digital radios do a whole lot more to make sure the
signal is properly received. Cochannel interference will quickly kill
these implementations. And in the case of the M-PSK code, my first
version was textbook while the second version was the right way; that
helps, too 
Tom
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
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 how to see it.
Changing the parameters externally will do nothing to solve this.
Tom
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:
I mean, run
triggered off of the regen signal and ignores the peak.
Discuss-gnuradio Info Page
–
View this message in context:
http://www.nabble.com/OFDM-Updates-tp15334667p21748528.html
Sent from the GnuRadio mailing list archive at Nabble.com.
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 gnuradio-3.1.3.tar ?
The OFDM stuff is currently only in the trunk.
Eric
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 B. wrote:
The OFDM stuff is currently only in the trunk.
Eric
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
View this message in context:
http://www.nabble.com/OFDM-Updates-tp15334667p21803051.html
Sent from the GnuRadio mailing list archive at Nabble.com.
On Mon, Feb 02, 2009 at 06:53:32PM -0800, adib_sairi wrote:
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)?
$ svn co http://gnuradio.org/svn/gnuradio/trunk
Eric
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 B. wrote:
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
View this message in context:
http://www.nabble.com/OFDM-Updates-tp15334667p21803896.html
Sent from the GnuRadio mailing list archive at Nabble.com.
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 my gnu radio? can you help me for this? thank you.
adib
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
trunk using “patch”.
Eric
Eric B. 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 command… but to confirm, i
re
install it using yum reinstall boost …but also when i configure it, it
tell
me that i dosent have the boost… can any one tell me why? is it because
i
had the lower version of boost? but i think i got the latest because i
use
the yum install command…
adib sairi
–
View this message in context:
http://www.nabble.com/OFDM-Updates-tp15334667p23406445.html
Sent from the GnuRadio mailing list archive at Nabble.com.
adib_sairi wrote:
because i use the yum install command…
adib sairi
i manage to install the trunk. it is the boost package problem. if we
use
the yum install boost, it only manage to update up to boost v1.34 but
the
new trunk require boost v1.35 and higher… so the solution is we have to
manually install the boost by downloding the package from the boost
website
and follow the instruction inside this document…
http://www.gnuradio.org/trac/browser/gnuradio/trunk/README.building-boost
but unfortunately the OFDM example in trunk revision 10991 is not
working
well. there is no data receive by the receiver when i run the
benchmark_ofdm_* example… does anyone know how to solve this?is there
any
ofdm example that is working? thanks
adib
–
View this message in context:
http://www.nabble.com/OFDM-Updates-tp15334667p23443577.html
Sent from the GnuRadio mailing list archive at Nabble.com.
adib_sairi wrote:
because i use the yum install command…
manually install the boost by downloding the package from the boost website
and follow the instruction inside this document…
http://www.gnuradio.org/trac/browser/gnuradio/trunk/README.building-boost
but unfortunately the OFDM example in trunk revision 10991 is not working
well. there is no data receive by the receiver when i run the
benchmark_ofdm_* example… does anyone know how to solve this?is there any
ofdm example that is working? thanks
adib
The benchmark examples work. You have to play with the transmit power,
symbol rates, etc. depending on the distance, daughterboards, and other
setup issues.
Tom
