Re: [Discuss-gnuradio] FTW IEEE802.11a/g/p OFDM Frame Encoder

[Paul Fuxjäger]

Guanbo ZHENG wrote on 22.02.11 00:36:

> The frequency band is correct. Just now, I re-install the repository from
> the CGRAN, and tried again using:
> sudo python ftw_ofdm_tx.py -f 2.462G -i 5 --regime=8 --payload="Here are
> some test messages from WiSeR"  -r 10000
> So the only question is, I have NOT updated my firmware. I will try that as
> well.

We used the XCVR2450 only so far. In our experience, the most common reasons
why it fails are:

1) channel on the RX side is not set to the one you use at TX
2) TX gain is too high or too low (depending on what kind of antennas and
"channel environment" you are using)
3) old USRP2 firmware bug (try also with -s option and see if it changes the
behavior) see documentation https://www.cgran.org/wiki/ftw80211ofdmtx
4) try also with -r 1 and -r 0 (the repetition method we used in the code is
very dirty)

> By the way, what does the USRP2 generated packet look like in Wireshark at
> another laptop?

Ideally, you would tick the "capture using promiscuous mode" and "capture
using monitor mode" in the Wireshark GUI. Then you should see *every
PHY-valid frame whatsoever* the card is able to decode on the channel that
it is currently listening on. Make sure it does work like that. E.g. do you
see beacons of the access-points nearby?

The link-layer header-type should be "802.11 plus radiotap header" and you
should see the radiotap headers appended to every frame.

If you have it available you can also use cmd-line tool called athstats to
debug. You can get access to some atheros-specific counters with it, like
how many frame-detected events per seconds are registered by the NIC.



If all of this doesnt help there is this method to find out if the problem
is in HW/GNUradio subsystem or on the encoder/decoder side:

Try to generate frames using the Atheros NIC and record the signal (a block
of baseband to disk) using the USRP2 with rx_cfile.py. Then put the Atheros
in monitor mode again and transmit this very baseband block using
transmit.py we included in the ftwofdm release (in src/matlab).

You have to use the same USRP2 for recording/transmission, and you should
not wait too long between RX/TX because of potential frequency offsets.

If this "record-playback" does not work there is still something wrong in
your current XCVR2450/USRP2/GNUradio subsystem. If it does work our encoder
is the source of the problem :(


cheers
paul




-- 
Dipl.-Ing. Paul Fuxjaeger
FTW - Telecommunications Research Center Vienna
http://www.ftw.at callto://:paul.fuxjaeger.at.work
PSTN:+43-1-505283057 | 3GPP:+43-676-4787088