[Hackrf-dev] Questions on the hackrf One

Dominic Spill dominicgs at gmail.com
Fri Aug 28 21:20:12 EDT 2015


On 28 August 2015 at 13:28, Chuck McManis <chuck.mcmanis at gmail.com> wrote:
> Very cool gizmo. I've got gnuradio installed and gqrx running and
> playing with that (fun to listen to ATC traffic around the Bay Area).

I'm glad you like it and are having fun with it.

> I tried to install gr-bluetooth with pybombs but that blew up on the
> lack of a libtbb

Pybombs should be able to install libbtbb as a dependency for
gr-bluetooth.  I'll have to investigate the recipe file.

> and in hunting that down it seems that really
> gr-bluetooh is more about the Ubertooth than the HackRF, I'm wondering
> if that is a structural problem or what?

gr-bluetooth was designed to be used with GNU Radio before either
HackRF or Ubertooth existed.  When Mike designed Ubertooth, I took the
Bluetooth baseband parts out of gr-bluetooth and put them in to their
own library.  Some parts of gr-bluetooth are able to use it, but I
don't think the transition was ever finished because nobody was using
gr-bluetooth.

> Can I use the HackRF at Bluetooh/Zigbee frequencies? (they are all 2.4Ghz range)

You certainly can, there is probably already a gr-zigbee project
available to monitor it.

> Does the Ubertooth do more? less? about the same?

Ubertooth will sniff a single channel of Bluetooth basic rate packets
and may be able to hop in some circumstances.  In theory a working
copy of gr-bluetooth with HackRF can monitor 20 simultaneous channels.

> My target is that I'm developing beacon software that will be using
> both BTLE and Zigbee. For a variety of reasons I'm using a soft radio
> and would like to be able to validate its signals beyond simply having
> at least one other non-soft radio receive the signal.

Fixing gr-bluetooth is certainly an option, although Ubertooth has
very good BLE support from Mike Ryan, so that may be a more useful way
to go if you're more interested in monitoring the BLE traffic than
writing gr-bluetooth code (which would be a very understandable set of
priorities).

Thanks,
  Dominic


More information about the HackRF-dev mailing list