Ah, so wireshark on a 802.11b card can capture packets sent by the USRP2?
I will modify my test code so that it usable by some one else. It is
sorta hacked together and difficult to understand. I'll try to send it
to the list sometime today.
On Mon, Apr 20, 2009 at 2:14 AM, Ben Yahmed
<address@hidden
<mailto:address@hidden>> wrote:
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?
Thoughts?
Colby
On Fri, Apr 17, 2009 at 10:53 AM, Colby Boyer
<address@hidden <mailto:address@hidden>
<mailto: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.
Bests,
Colby
On Fri, Apr 17, 2009 at 10:15 AM, Colby Boyer
<address@hidden <mailto:address@hidden>
<mailto: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.
Colby
2009/4/17 Ben Yahmed <address@hidden
<mailto:address@hidden>
<mailto:address@hidden
<mailto: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 <mailto:address@hidden>>
<mailto:address@hidden <mailto: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,
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 <
> address@hidden
<mailto:address@hidden>
<mailto:address@hidden
<mailto:address@hidden>>
<mailto:address@hidden
<mailto:address@hidden>
<mailto: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
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
address@hidden
<mailto:address@hidden>
<mailto:address@hidden
<mailto:address@hidden>>
<mailto:address@hidden
<mailto:address@hidden>
<mailto:address@hidden
<mailto:address@hidden>>>
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
------------------------------------------------------------------------
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
<mailto:address@hidden>
<mailto:address@hidden
<mailto:address@hidden>>
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
<mailto:address@hidden>
<mailto:address@hidden
<mailto:address@hidden>>
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio