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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio