discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] Bluetooth implementation frequency hopping restrictio


From: Kresimir Dabcevic
Subject: [Discuss-gnuradio] Bluetooth implementation frequency hopping restrictions
Date: Thu, 24 Feb 2011 14:06:41 +0100



Hello all!

My name is Kresimir Dabcevic and am currently a masters student at Mälardalen University in Sweden, starting my masters thesis on Software defined radio.

We are looking to do a research on power consumption of technologies that operate in the 2.4 GHz ISM band, primarily Bluetooth and ZigBee.

We are looking to purchase Ettus' USRP N200 with RFX2400 daughterboard for our research, and therefore use GNU Radio as our software.

My understanding is that implementing ZigBee should be possible via the UCLA ZigBee PHY project, however implementation of Bluetooth presents a problem because of the frequency-hopping characteristic of this technology - there are some threads in the mailing lists' archives which state that implementation of BT is not possible since USRP does not have enough bandwidth possibility to encompass the whole 79 MHz band BT uses for FH. However, if I understood correctly, this applies to USRP1 platform (these threads date a few years back), which only had 8 MHz instantenous bandwidth, whereas USRP N200 should have 50 MHz (8-bit mode), and I presume that it also supports working in a 4-bit mode, which should allow for a 100 MHz bandwidth, which should be sufficient?

Also, the following article by Dominic Spill and Andrea Bittau:
http://darkircop.org/bt/gnuradio/Bluesniff.pdf
states that
"Bluetooth devices retune their radios 1,600 times per second in order to communicate with each other, but unfortunately tuning at such a rate is not an easy task with the USRP. The 2.48GHz daughterboard is able to retune within 200?s, which is not fast enough to follow a Bluetooth hopping pattern since each time slot is 600?s. Hopping with a tuning delay of 200?s would cause up to one third of each packet to be lost."
which would imply that the hardware restrictions are not only tied to the platform itself, but also to the daughterboard?

On the other hand, I have come upon the implementation GR-Bluetooth,
http://darkircop.org/bt/gnuradio/
which states
"An implementation of the Bluetooth baseband layer for GNU Radio for experimentation and teaching students about Software Defined Radio, it should not be used for Bluetooth communications as it is not a complete software stack."

Could this implementation suffice for the research and/or are there other implementations of BT's PHY layer available for GNU Radio?

We are just starting to look into the GNU Software (and SDR in general) problematics, so any help and feedback would be much appreciated.

Best regards,
Kresimir Dabcevic


reply via email to

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