Bluetooth implementation frequency hopping restrictions

GNU Radio
1

Hello all!

My name is Kresimir Dabcevic and am currently a masters student at
Mlardalen 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 S. 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

2

On Thu, Feb 24, 2011 at 02:06:41PM +0100, Kresimir Dabcevic wrote:

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.

Hi, Kresimir. I’m Michael O., one of the gr-bluetooth developers
and also developer of the new Ubertooth hardware platform:

http://ubertooth.sourceforge.net/

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.

Can you tell us more about what you hope to accomplish with the USRP /
GNU Radio platform?

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?

Theoretically, yes, but development will be required on the FPGA to
accomplish this. Also you’ll run into daughterboard bandwidth
limitations. The RFX2400 has a 20 MHz low pass filter on both the I and
Q receive paths, resulting in 40 MHz of baseband bandwidth at the ADC.
In my talk with Dominic S. (the other gr-bluetooth developer and one
of the authors of the paper you mention below) at ShmooCon 2009, I
talked about how I removed that filter to achieve all-channel monitoring
with intentional aliasing. You should watch the video:

http://shmoocon.org/2009/videos/Bluetooth-Ossman.m4v

That was a fairly crude proof-of-concept. A better approach would be to
modify the filter to pass 80 to 100 MHz of bandwidth rather than
removing it entirely. Even then you would probably have a fairly
non-flat frequency response which you would have to take into account
if, for example, you are trying to use the received waveform to estimate
transmit power.

The XCVR2450 has even narrower bandwidth restrictions, and the filters
are implemented on-chip, so I don’t think you’d be able to modify them.

Also, the following article by Dominic S. and Andrea Bittau:
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.”

Rereading this after years of working on Bluetooth, I realize that this
should be revisited. Bluetooth time slots are 625 microseconds long,
but the maximum length single-slot packet is 393 microseconds, leaving
232 microseconds of tuning time. Looking at the multi-slot packet
types, they all leave at least that much time for tuning. It looks like
the XCVR2450 can tune faster than the RFX2400, so it should be possible
to hop, even accounting for extra time to determine the next frequency
and issue the command to the daughterboard.

The trickiest problem to deal with here is the latency of the control
path. It would not be possible to control the hopping from the host
computer due to the USB or Ethernet latency, so you’d have to do the
control on the USRP motherboard. If I recall correctly, the
daughterboard tuning commands on the USRP1 are issued by the USB
controller, not the FPGA, so the relatively straightforward approach of
hopping controlled by the FPGA would not work. I’m not sure about the
situation on the newer USRP models, but it is worth looking into. You
would certainly have to do FPGA and/or firmware development to
accomplish this, but it would be a valuable contribution to the
community.

I have come upon the implementation GR-Bluetooth,

The gr-bluetooth link you included is an ancient release. You should
check out the current code from the git repo here:

http://gr-bluetooth.sourceforge.net/

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

Possibly, but it’s hard to say without knowing exactly what you hope to
accomplish. It may be that your needs would be better met by the
Ubertooth platform which has frequency hopping capability (the code for
hopping is not finished yet but will be soon). If you would like a
board, I’m doing an initial production run of Ubertooth One hardware
that you can get in on for four more days:

http://www.kickstarter.com/projects/mossmann/ubertooth-one-an-open-source-bluetooth-test-tool

Since your research is on power consumption, are you looking at
Bluetooth Low Energy? That is an area I’m starting to look at more, and
I hope to have BLE sniffing code in Ubertooth soon.

Mike

3

On Thu, Feb 24, 2011 at 02:06:41PM +0100, Kresimir Dabcevic wrote:

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?

Oh, and perhaps this goes without saying, but 4 bits of dynamic range is
extremely low for digital modulations. If you just want to detect
transmissions, it should be sufficient, but, if you want to decode
Bluetooth packets, the likelihood of decoding errors would be very high.

You could operate with 100 MHz bandwidth at the full dynamic range of
the ADC if you do your demodulation on the FPGA. This was a direction
Dominic and I thought about pursuing but never did. You don’t
necessarily have to implement packet decoding on the FPGA; you could
just channelize the waveform into 79 channels, demodulate each one into
a 1 Mbps stream, and dump them all over Ethernet to a host computer to
do the packet detection and decoding.