Hi, Paul Thanks for your description. I finally figure out the problem that the Gigabyte Ethernet Card in my computer does not support Gigabyte. Either it is because of driver problem or itself. After using another good Ethernet card, it works smoothly. :)
I have another question for FTW OFDM, in which I wanna implement the transmit-wait-transmit scenario. Specifically, I tried to transmit some data stream first, sleep for a few second and then transmit another one. $ sudo python ftw_ofdm_tx.py -e eth1 -f 2.462G -i 5 --regime=3 -g 30 -r 1 However, from the spectrum I have observe, it seems USRP2 keeps generating the same signal, without any sleeping or waiting time. By looking into the codes, I found msgq() seems to be fine. Also, when there is no payload, EOF set to true, telling the msgq() no more messenge. Then, what is the possible reason for my problem? Any suggestions are appreciated! Thanks, Guanbo On Tue, Feb 22, 2011 at 7:40 AM, Paul Fuxjäger <fuxjae...@ftw.at> wrote: > 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 > > -- Regards, Brian
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
