HackRF open source SDR

in open source, RF, SDR by the machinegeek | 12 comments


At the recently concluded Toorcon conference in San Diege, CA, developers Michael Ossmann and Jared Boone released the latest version of the HackRF board. “The HackRF project is developing an open source design for a low cost Software Defined Radio (SDR) transceiver platform. SDR technology allows a single piece of equipment to implement virtually any wireless technology (Bluetooth, GSM, ZigBee, etc.), and we hope the availability of a low cost SDR platform will revolutionize wireless communication security research and development throughout the information security community.” Known as Jawbreaker, this current incarnation is based on the MAX2837 WiMAX transceiver and MAX5864 analog front end (quadrature ADC and DAC). This combination will get and convert signals to/from 2.4 GHz to digitized quadrature baseband data streams.

We note that they used the Bus Pirate in their testing of the MAX2837.

The files for this open source project are available on GitHub.

This entry was posted in open source, RF, SDR.

Comments

  1. Jared Boone says:

    We also used the Bus Blaster to program the Xilinx CPLD. Both the Bus Pirate and Bus Blaster are invaluable tools!

    There’s also an RFMD RFFC5072 that acts as a second conversion stage, which enables 30MHz to 6GHz operation.

    This iteration of the board is “Jawbreaker”. Jawbone is a Bluetooth accessory company, whose copyrights we’d very much like to avoid. :-)

    • the machinegeek says:

      Thanks for the comment. This definitely looks like an interesting open source project that we’d like to take for a spin. The 30 MHz to 6 GHz range in a single unit is something not found even in the USRP products! (Fixed the board name.) Keep us posted on any updates.

      • Jared Boone says:

        Thanks for the updates. The USRPs definitely have their place — they’re wildly capable and flexible devices. But they are relatively expensive. That said, I wouldn’t be surprised at all to see HackRF create a whole new set of customers for Ettus USRP products. And that will be good for everybody. But for getting into SDR and doing general RF security research, we think the HackRF will be hard to beat.

        We’ll definitely keep you posted as the beta progresses.

  2. the machinegeek says:

    Any plans for HackRF to work with GNURadio?

    • Jared Boone says:

      Absolutely. We demo’ed HackRF receiving with GNU Radio, albeit with a nasty hack. I used mkfifo to create a conduit between the record-to-file utility we have and the GNU Radio file source block. It works great, but doesn’t give you any control of HackRF’s tuning, gain, and sample rate settings. Going forward, libhackrf (our C interface library) will be used for *real* GNU Radio integration. We have a couple of volunteers who’ve already expressed interest in helping us out there, so with luck, by the time the beta hardware arrives, GNU Radio integration will be fully-baked.

  3. erdabyz says:

    Haven’t looked at the design very deeply but I am currently working on something pretty similar in concept (but for broadband modulations and MIMO and things like those at up to 8GHz) and as far as I can (I’ve just taken a quick look at the board) tell the RF layout isn’t very good. There are long RF microstrip traces running close together and close to digital traces and having quite some bendings, and when you have long RF traces with bendings 50ohms are no longer 50ohms and become something that you can only accurately predict using ADS momentum or similar EM simulation tools. Having traces close together can induce undesired couplings and long traces with bendings tend to radiate some power too. When you work at respectable frequencies (and 6GHz is very respectable) with substrates that are not that good for RF (regular off the shelf FR4 is basically usable crap for RF) you gotta either be really careful or use the shortest possible traces (lambda/20 – lambda/10 or less). Even the soldermask does shift your transmission lines impedance by an unpredictable (but most times significant) amount.

    Looking at the PCB it seems to me that the problem comes from the components placement. For me it looks like rotating a couple of IC’s 90º and tweaking their position you could get all the RF stuff packed with RF traces no longer than 1-2cm.

    As I said I just took a quick look at the layout so I might be wrong, but the pourpose of this is just to provide some criticism so you can improve and get better. I don’t consider myself an RF pro (RF is like black magic and every single day you learn something new that you’d never imagined) but I have some experience and some succesful designs and I just wanted to share my opinion.

    I hope everything turns out well and you end with an affordable and open source SDR. I’d certainly build/buy one!

    • Jared Boone says:

      @erdabyz: Thanks for the criticism. It’s very much appreciated. I should point out that HackRF is focused primarily on short-range wireless security testing. It’s not something you’d want to implement a mobile base station or backhaul link with, or use to enter ham radio contests. Among other reasons, the ADC and DAC channels are eight bits, and won’t give you a lot of dynamic range or sensitivity. But it’s a great platform for prototyping wireless protocol vulnerability demonstrations.

      We’ve observed in testing that the less-than-ideal RF routing is not an issue given the range and precision requirements of HackRF. However, you make some very good points, and I’d anticipate future revisions will take into account the things you mention — particularly reorienting some of the ICs, and eliminating an unnecessary IC to open up space for cleaner routing.

      • mossmann says:

        Yes, thanks for the comments, erdabyz. The only RF traces that could be made significantly shorter (with layout-only changes) are actually the IF lines that carry signals at a maximum frequency of 2.7 GHz, so the loss isn’t anywhere near as bad as it would be at twice that frequency. Also the nearby data lines are all typically inactive during RF operation. They are for things like switching between TX and RX. We certainly have some performance roll-off from losses above about 4.5 GHz, but we never expected to have fabulous performance way up there.

  4. NsN says:

    Do I understand the specs correctly, This allows recieving and transmitting in the range of 30 MHz to 6 GHz?

    I’m currently looking into GSM and UMTS security as a topic for my masters thesis, and I would love to have a less expensive option than the URSP line. What are the timing tolerances for your device, can i synchronize it with a GPS or other source signal? Is the software side exact enough to allow a BTS?

    And most importantly when and where can I get this marvelous device?

    • Jared Boone says:

      @NsN: You’re correct, the range is 30MHz to 6GHz. There is an optional connector for injecting your own clock reference from external hardware. You might run into challenges regarding USB latency to and from the host, but I’m not sure how stringent GSM/UMTS is.

      The HackRF is entering its beta phase in the next couple of months. Check out this video for more details: HackRF Keynote at ToorCon 14.

  5. Perpetual Rabbit says:

    Can the device not go down as far as 27MHz? It would be really cool if it could, because of course 27MHz is unlicensed spectrum.

Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Notify me of followup comments via e-mail. You can also subscribe without commenting.