[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USR

From: Ben Yahmed
Subject: Re: [Discuss-gnuradio] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems
Date: Mon, 20 Apr 2009 11:14:42 +0200
User-agent: Thunderbird (X11/20090105)

Hi all,
Thank you Colby for the update. I just run the code and it seems to work, but when I send packets from another USRP2 with the same frequency (bbn_80211b_tx_port2.py) I don't see anything happening. when I run wireshark, a huge number of packets was arriving, something like 11000 packets /s with the protocol 0xbeef I don't know how it should work exactly, but I think that the USRP2 is capturing the signal without beeing able to differentiate the packtes sent by the other USRP2.

Can you share with us the code that works with the file to see the output of bbn_80211b_rx.py ?

Ben Yahmed

Colby Boyer wrote:
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?



On Fri, Apr 17, 2009 at 10:53 AM, Colby Boyer <address@hidden <mailto:address@hidden>> 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.


    On Fri, Apr 17, 2009 at 10:15 AM, Colby Boyer
    <address@hidden <mailto:address@hidden>> 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.


        2009/4/17 Ben Yahmed <address@hidden

            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 <address@hidden
                <mailto:address@hidden> <mailto:address@hidden

                   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,

                   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 <
                   > address@hidden
                <mailto:address@hidden>>> 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
                   > > 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.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
                line 499,
                   > > in set_decim
                   > > return
                _usrp2.usrp2_source_32fc_sptr_set_decim(self, *args,
                   > >
                   > > 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
                   > >
                   > >> / 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 mailing list
                address@hidden <mailto:address@hidden>

            Discuss-gnuradio mailing list
            address@hidden <mailto:address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]