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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
