Posted on Tuesday, October 23rd, 2012 in open source, RF, SDR by the machinegeek

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.

This entry was posted
on Tuesday, October 23rd, 2012 at 6:02 pm and is filed under open source, RF, SDR.
You can follow any responses to this entry through the RSS 2.0 feed.
You can skip to the end and leave a response. Pinging is currently not allowed.

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.

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.

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.

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!

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

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.

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?

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