Hi all,
Yes, a couple USRP2 802.11 BBN code threads ;) Trying to separate the
discussions a bit.
Did anyone get the TX code to properly interoperate with an 802.11 card? I
have the usrp2_version branch running, with my modification to fix the
transmission filter, and I am using a probe response
Hi,
I was trying out some experiments using USRP1 and the files benchmark_tx.py
and benchmark_rx.py in the digital folder. I wanted to know few things.
(i) I saw the option of digital amplitude in benchmark_tx.py. Could someone
tell me the gain of which component on the USRP board is controlled
I don't have the exact details of the time synchronization bug right now, but
it had to do with when the timing estimate moved across the symbol boundary.
If I recall correctly, the raw incoming samples are sent through a Barker
filter, and the time synchronization code attempts to sample the f
Hi Daniel,
Any help would be greatly appreciated :) Maybe I can poke at the time
synchronization code also.
It seems as though the decoder's inability to detect some of the short
preambles might be due to the scrambler. If I make my own "preamble" that
uses 7 bytes of scrambled 1s instead of 7
I remember I had the same problem with the crc error on the short preamble when
I wrote the code, but I never figured out what the problem was. However, I did
receive an email from someone who claimed to have fixed the problem (I think) a
couple of years ago. If you want I can email him. Also
One more thing, it only catches 44 out of 50 short preambles.
- George
On Mon, Nov 30, 2009 at 4:14 PM, George Nychis wrote:
> Hi all,
>
> I'm in the progress of implementing the 802.11 short preamble on the TX
> side. There is code on the RX side (based on yesterday's discussion) to
> handle
Hi all,
I'm in the progress of implementing the 802.11 short preamble on the TX
side. There is code on the RX side (based on yesterday's discussion) to
handle a short preamble, but I am positive there is no code on the TX side
to transmit using a short preamble. Of course, I'd like to implement
> George,
> That is a little bit odd for beacon frames, although my reading of the spec
> doesn't disallow that (at least not in 802.11-2007): 19.3.2.2 Short preamble
> PPDU format says only that the short preamble is appropriate for use with 2,
> 5.5, and 11Mb/s modes. By the way, the short preamb
George Nychis wrote:
The other thing that is odd, is that the beacon's in my trace use a
short preamble (based on flags) but the transmission is at 1Mbps.
From looking at the 802.11 spec, short preambles can only be followed
by 2, 5.5, or 11Mbps PSDUs. Here is a pcap of a beacon frame:
http:/
The other thing that is odd, is that the beacon's in my trace use a short
preamble (based on flags) but the transmission is at 1Mbps. From looking at
the 802.11 spec, short preambles can only be followed by 2, 5.5, or 11Mbps
PSDUs. Here is a pcap of a beacon frame:
http://cyprus.cmcl.cs.cmu.edu/
Really a python question:
...the gnuradio.gr package lists many functions and some variables. The
package contents items are reflected as individual files in the
/usr/lib/python2.6/dist-package/gnuradio/gr, but where are the individual files
and variables defined?
RH
Hi Doug,
Thanks for the clarifications. I missed the order that the bits are
transmitted in, so that makes sense now.
I took a 1 second capture of 802.11 traffic, that I know has 1Mbps beacons
in it and probe responses. The machine was able to decode them with its
Atheros card, and if I look at
George Nychis wrote:
I also think that the decoder is improperly looking for synchronization...
According to the 802.11 spec, the long preamble uses an SFD that is
0xF3A0, and the short is 0x05CF (verified by a quick google
(http://www.google.com/search?hl=en&safe=off&client=firefox-a&rls=org.
13 matches
Mail list logo
