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

[Kresimir Dabcevic]

-----Original Message-----
From: Michael Ossmann [mailto:address@hidden]
Sent: Thu 24/02/2011 16:53
To: Kresimir Dabcevic
Cc: address@hidden; Dominic Spill
Subject: Re: [Discuss-gnuradio] Bluetooth implementation frequency hopping restrictions

On Thu, Feb 24, 2011 at 16:53:41PM +0100, Michael Ossmann wrote:

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

Dear Mr. Ossmann, thank you for your response.


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

Our primary goal is getting familiar with the SDR technology, and USRP /
GNU Radio seem like a way to start - it has been recommended to us by
multiple sources as inexpensive equipment suitable for academic
research. The open-source nature of GNU Radio also appeals to us.

At the moment, we have an ongoing project called TESLA,
http://www.mrtc.mdh.se/progress/index.php?choice=projects&id=0289
and our latest research has been done regarding measuring the power
consumption of technologies that operate in the 2.4 GHz band (focusing
on Bluetooth and ZigBee). The paper will hopefully come out next week,
and I can send you a copy once it is published if you are interested.

Following that, we would like to be able to implement ZigBee
and Bluetooth via an SDR platform, try to make a power consumption
measurements of such an implementation and compare results to the
aforementioned research.


>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:

Thank you for the link, I will be sure to watch it later today.


>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.

At this point, I cannot say whether we will have the time or resources
to look into that in the near future, but if that does prove to be the
case, we will try.


>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:

The Ubertooth platform looks really interesting, however from what I
understood from the video conference from your blog, we wouldn't be able
to integrate it with USRP and GNU Radio at the moment?
If that is the case, it will probably nevertheless be interesting to the
guys from our research group that are finishing the power-consumption of
"hardware"-based 2.4GHz-based technologies research I mentioned, so I will
notify them about it.


>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.

At the moment, we haven't been discussing researching BLE, but that
might change depending on the pace and progress of our research.


Kresimir