Hi All,
Has anyone looked into implementing the higher bit rates (5.5Mbit and
11Mbit) of 802.11b using complementary code keying (CCK)? If CCK does
have
to be implemented from scratch, would it be more beneficial to implement
G,
which would provides a large number of speeds with one scheme (OFDM)?
Also, does anyone know if the BBN code on the USRP could communicate
with
hardware 80211b (ASIC) equipment? I’ve heard that there are issues with
ack
latency. If there is a problem, did the BBN people bother to implement
the
acks in their code?
Regards,
Colby B.
Hi Colby,
Hi All,
Has anyone looked into implementing the higher bit rates (5.5Mbit and
11Mbit) of 802.11b using complementary code keying (CCK)? If CCK does have
to be implemented from scratch, would it be more beneficial to implement G,
which would provides a large number of speeds with one scheme (OFDM)?
A student from us is working on implementing IEEE802.11p (yes, “p” - it
is not a typo) with GnuRadio and USRP2.
In order to do this he will first look into 802.11g and 802.11a.
He started his master-thesis some weeks ago. Therefore, results are not
yet expected very soon.
Also, does anyone know if the BBN code on the USRP could communicate with
hardware 80211b (ASIC) equipment? I’ve heard that there are issues with ack
latency. If there is a problem, did the BBN people bother to implement the
acks in their code?
We have tried in these days to transmit broadcast frames from a
wifi-card to the USRP2 and viceversa.
Broadcast does not require ACKs, but still no success… 
Regards,
Colby B.
Best Regards,
Danilo
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Colby B. wrote:
Also, does anyone know if the BBN code on the USRP could communicate
with hardware 80211b (ASIC) equipment? I’ve heard that there are issues
with ack latency. If there is a problem, did the BBN people bother to
implement the acks in their code?
As I recall, the transmit functionality of the original BBN code was
not standards compliant: due to the limited bandwidth of the USRP1 it
did not actually do DSSS (or CCK, etc.) - it created the frame, and used
DBSK (and possibly DQPSK) - but I don’t think it did any sort of
spreading.
Doug
Doug G.
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
[email protected]
[email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD4DBQFJ24i+gfOzzR5bXIgRAlujAJYoTn0j6X04U9RK70O/4riBjIEyAKCTSTyC
s1nrGmITgBy6yJ12pj4evw==
=B03s
-----END PGP SIGNATURE-----
Hi Douglas,
Douglas G. wrote:
As I recall, the transmit functionality of the original BBN code was
not standards compliant: due to the limited bandwidth of the USRP1 it
did not actually do DSSS (or CCK, etc.) - it created the frame, and used
DBSK (and possibly DQPSK) - but I don’t think it did any sort of spreading.
Doug
Actually I think that spreading IS implemented (see barker sequence).
As far as I remember, the legacy IEEE802.11 at 1 Mbps uses DBPSK and
barker sequence.
Any 802.11b/g card should be able to receive that.
If this is correct,
I believe that, by putting a wifi-card in monitor/passive mode, a frame
correctly transmitted from the USRP will be decoded by the card.
If your card allows you to disable CRC check at MAC layer, then you
should see the frame also on wireshark (as a malformed packet)…
I’ll let you know if it works out!
In the meanwhile, if you find errors in my thoughts, well tell me and I
save time for something more useful! 
bye,
Dan 