Hi All, So I ran a sanity test on the TX and RX functions.
In the tx.py file, I added a file sink to record the data being sent to the USRP2. In the rx.py file I added a file source to read that data, rather than reading samples from the USRP2. When I did this, it was able to successfully demodulate the packets from reading the sample data from a file. So TX is working(?) unless something is going wrong with initializing/sending stuff to the hardware. So perhaps the rx is not correctly reading samples in from the USRP2? Thoughts? Colby On Fri, Apr 17, 2009 at 10:53 AM, Colby Boyer <csbo...@berkeley.edu> wrote: > Hi Ben, > > I uploaded my files to the usrp2_version in the CGRAN server. It uses the > same files I used to run my USRP2 tests, so it should interface with the > hardware correctly. Let me know if it does not. > > Bests, > Colby > > > On Fri, Apr 17, 2009 at 10:15 AM, Colby Boyer <colby.bo...@gmail.com>wrote: > >> Hi Ben, >> >> Perhaps I haven't updated the CGRAN repo yet. I'll take a look and try to >> get back to you within an hour. >> >> Colby >> >> 2009/4/17 Ben Yahmed <maher.ben_yah...@sophia.inria.fr> >> >> I'm trying to modify the bbn_80211b_rx.py code inorder to receive packets >>> but in every step I'm facing an AttributeError like: >>> >>> AttributeError: 'usrp2_source_32fc_sptr' object has no attribute >>> 'make_format' >>> >>> AttributeError: 'usrp2_source_32fc_sptr' object has no attribute >>> 'set_format' >>> >>> AttributeError: 'module' object has no attribute 'set_gain' >>> >>> AttributeError: 'gr_hier_block2_sptr' object has no attribute 'subdev' >>> >>> It seems that the code has not been switched correctly to work with usrp2 >>> and still make reference to usrp classes. >>> >>> Did you try to run the bbn_80211b_rx.py with the usrp2 that you have? >>> >>> >>> >>> >>> Tiago Rogério Mück wrote: >>> >>>> That's good news. >>>> >>>> The code I sent seemed to be working but i realy didn't tested it. We >>>> have only one USRP2 here and we were trying to receive pkts using a 802.11b >>>> PCI card (Realtek RTL8180L chipset), but without success (some problems >>>> with >>>> the card configuration). >>>> >>>> 2009/4/17 Valerio, Danilo <vale...@ftw.at <mailto:vale...@ftw.at>> >>>> >>>> >>>> Hi Colby! >>>> >>>> >>>> We have also tried without success. >>>> We have used the TX path from Tiago and a modified version of the >>>> RX path (firmware and FPGA at their latest update). >>>> I also felt confident that the the TX path works, and consequently >>>> that the RX path had some problem. >>>> >>>> >>>> So we have tried to transmit with the USRP2 and receive with a >>>> real IEEE802.11 chipset (Ralink chipset RT2500). >>>> This chipset has no firmware and we modified the linux driver so >>>> as to: >>>> - avoid mac CRC (Everything received on the MAC layer is passed to >>>> the higher layers); >>>> - set fixed modulation schemes (i.e. DBPSK 1Mbps); >>>> - set PLCP long preamble. >>>> - set complete monitor/passive mode. >>>> >>>> >>>> The chipset detects some transmitted frames. This could be an >>>> indication that the PLCP preamble/header is correct (?). >>>> However the PLCP payload is just rubbish. >>>> We have also tried to submit stupid payloads (like ffffffff) and I >>>> have the impression that what we receive is just random. :-( >>>> >>>> >>>> If we obtain some successful result in the next few days, I'll let >>>> you know! >>>> >>>> >>>> Best Regards, >>>> Danilo >>>> >>>> >>>> >>>> On Friday 17 April 2009 09:17:38 Colby Boyer wrote: >>>> > Hi All, >>>> > >>>> > I've been trying to run some hardware tests between two USRP2s, >>>> but I have >>>> > had no success in receiving packets. I am using the modified TX >>>> from Tiago. >>>> > I feel sorta confident that the TX code works, because when I >>>> run the >>>> > usrp2_fft.py, I see a wave form being transmitted over the channel. >>>> > >>>> > Has anyone have any success on receiving packets between two >>>> USRP2s? When >>>> > RX/TX there is a usrp2::ctor reset db failed error. Could this >>>> cause >>>> > problems for the RX/TX? I am using the firmware that was shipped >>>> with the >>>> > USRP2. >>>> > >>>> > Thanks, >>>> > Colby Boyer >>>> > >>>> > On Wed, Apr 15, 2009 at 10:40 AM, Ben Yahmed < >>>> > maher.ben_yah...@sophia.inria.fr >>>> <mailto:maher.ben_yah...@sophia.inria.fr>> wrote: >>>> > >>>> > > Hi all, >>>> > > >>>> > > Since I have tested the tx code (bbn_80211b_tx_port2.py), I >>>> wanted to run >>>> > > the bbn_80211b_rx.py inorder to capture the packets sent but I >>>> encountred >>>> > > this error: >>>> > > >>>> > > >>>> > > # ./bbn_80211b_rx.py Traceback (most recent call last): >>>> > > File "./bbn_80211b_rx.py", line 179, in <module> >>>> > > main () >>>> > > File "./bbn_80211b_rx.py", line 174, in main >>>> > > app = app_flow_graph() >>>> > > >>>> > > File "./bbn_80211b_rx.py", line 159, in __init__ >>>> > > self.u = usrp_rx(0, options.decim, options.rx_subdev_spec, >>>> > > options.width_16, options.verbose, options.gain, options.freq) >>>> > > File "./bbn_80211b_rx.py", line 97, in __init__ >>>> > > >>>> > > self.u.set_decim(decim_rate=(decim * 1.5)) >>>> > > File >>>> "/usr/local/lib/python2.5/site-packages/gnuradio/usrp2.py", line 499, >>>> > > in set_decim >>>> > > return _usrp2.usrp2_source_32fc_sptr_set_decim(self, *args, >>>> **kwargs) >>>> > > >>>> > > TypeError: usrp2_source_32fc_sptr_set_decim() takes exactly 2 >>>> arguments (1 >>>> > > given) >>>> > > >>>> > > do you have any idea about the origin of this problem? Thank >>>> you in >>>> > > advance. >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > On Mon, Apr 06, 2009 at 04:29:20PM -0300, Tiago Rogério Mück >>>> wrote: >>>> > > >>>> > >> / Updated from the trunk and I'm not getting that msg anymore./ >>>> > >> / / >>>> > >> / Everything seems to be ok now./ >>>> > >> >>>> > > >>>> > > Glad to hear it! Thanks for letting us know. >>>> > > >>>> > > Eric >>>> > > >>>> > > >>>> > >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
