Re: [Discuss-gnuradio] Bluetooth implementation frequency hopping restrictions

[Michael Ossmann]

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 Ossmann, 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 Spill (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 Spill 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