Share this project

Done

Share this project

Done
Transmit or receive any radio signal from 30 MHz to 6000 MHz on USB power with HackRF.
Transmit or receive any radio signal from 30 MHz to 6000 MHz on USB power with HackRF.
1,991 backers pledged $602,960 to help bring this project to life.

Use this space to cheer the creator along, ask questions, and talk to your fellow backers. Please remember to be respectful and considerate. Thanks!

    1. Creator Michael Ossmann on August 24, 2013

      Håvard: The RX/TX turn-around time hasn't been optimized yet, but it should be under 100 microseconds, not milliseconds. That would be achievable when controlled by the microcontroller; USB would add some latency if it is controlled by the host computer. The implications of adding too much delay vary considerably by application. For FRS two-way radio, the USB latency should be no problem at all. For 802.11, it would be a problem specifically because acknowledgment (ACK) packets need to be transmitted in a timely fashion; a possible workaround might be implementing ACKs on the microcontroller while implementing data packets on the host computer.

    2. Creator Håvard Fjær on August 24, 2013

      I see that the half duplex has a switching time of 100 ms + USB latency. What would the practical implications be on this, say when emulating a two-way RF remote, or a wi-fi network card? Would the data transfer just go slower, or would the communication loose its timing and not work at all?

    3. Creator Michael Ossmann on August 23, 2013

      Thanks for the info, Marc, and the offer, Rolf-Dieter! ExtIO certainly looks like something that could be supported. People have already compiled libhackrf for various things on Windows.

    4. Creator Rolf-Dieter Klein on August 23, 2013

      @Michael, just went through their DLL example and header, looks really easy to implement, there are only around Function calles to be implemented (minimum) of course some more for more functionality, looks good documented -- If you want I can help with implementing the DLL later in the timeline.

    5. Creator Rolf-Dieter Klein on August 23, 2013

      @Michael, yes you have to write a DLL accoring to their interface, thats all. HDSDR is working with the Funcube Pro+ for example (which I had used already).
      WOuld be cool to get support for HDSDR

    6. Creator Marc Linde on August 23, 2013

      I meant SDR Hardware ..

    7. Creator Marc Linde on August 23, 2013

      @Michael
      ExtIO is some kind of abstraction layer that helps HDSDR/Winrad to communicate with all kinds of SDR software. see http://www.hdsdr.de/faq.html for more information.

    8. Creator Jason Hsu on August 23, 2013

      Michael: Thanks for the clarification. The Jawbreaker board is already pretty compact, but i'm wondering if you might be able to shrink the footprint down even further. Some potential strategies to pursue: further optimizing the frontside layout, double sided PCB (components on the back), using 4-layer PCB, etc. Idk if you've crunched the numbers on any of that, but maybe double sided could be a nice stretch goal?

    9. Creator Michael Ossmann on August 23, 2013

      Marc: I'm not sure what Extio is. I found some relevant search results but no clear description.

    10. Creator Michael Ossmann on August 23, 2013

      Jason: The SMA connector will almost certainly be edge-mounted, but the final form factor and enclosure have not been designed yet.

    11. Creator Matthew O'Gorman on August 22, 2013

      woot stretch goal met!

    12. Creator Marc Linde on August 22, 2013

      Extio supported already?

    13. Creator Jason Hsu on August 22, 2013

      Bleh, meant to say: "Will the SMA connector on the final version be mounted in the same location and orientation as the Jawbreaker beta board?"

    14. Creator Jason Hsu on August 22, 2013

      Will the SMA connector also be mounted in the same location and orientation? Would somewhat prefer an edge-mount connector instead.

    15. Creator Michael Ossmann on August 19, 2013

      Curtis: HackRF can be used for many FHSS implementations. Some FHSS systems use a range of channels that fits within 20 MHz of bandwidth. For those systems, you can implement frequency hopping entirely in software, leaving the hardware tuned to the midpoint of the channel range. For FHSS systems with a wider range of channels, you must tune the hardware on each hop; to do so fast enough would probably require custom HackRF firmware.

    16. Creator Curtis on August 18, 2013

      Would HackRF be able to capture and send signals using Frequency-hopping spread spectrum (FHSS)? For my purposes I would know the pseudorandom sequence being used.

    17. Creator Michael Ossmann on August 18, 2013

      Kyle: Yes, HackRF will have an SMA antenna connector.

    18. Creator Kyle Litz on August 17, 2013

      Michael,
      Too many comments to weed through, so I apologize in advance if this has been asked and answered. The jawbreaker image shows an SMA (?) antennae attachment point. Will the same attachment accessory be available in the kickstarter version of 1/2014?
      Thanks

    19. Creator Ed Hemphill on August 17, 2013

      On a lot of SOCs AES is implemented in hardware, but it's on the micro-controller side - not the radio side. This should be a great dev tool.

    20. Creator John on August 16, 2013

      Ah, I figured it'd bee software side but wasn't sure whether or not this came with a recommended program or not. Here's hoping for $400k. :D

    21. Creator Rolf-Dieter Klein on August 16, 2013

      Thats a great project. I just got a radiocube pro+ which is a receiver only, but this wil lbecome a wonderful device with such a large range (without gaps I assume).

    22. Creator Michael Ossmann on August 15, 2013

      The clock input and output features on Jawbreaker are untested, but I hope to test them by August 24th. I will post an update about that after I have completed the testing.

    23. Creator Michael Ossmann on August 15, 2013

      Johnathan: AES would typically be implemented on the attached host computer. Whether or not encryption is implemented isn't really relevant to the HackRF design itself.

    24. Creator Paul on August 15, 2013

      *DOH* no edit button. No sorry, not the schematic, I meant the board file.

    25. Creator Paul on August 15, 2013

      @Andrew & @Jason
      Running KiCAD and opening the schematic file shows 2 clock connections.
      (https://github.com/mossmann/hackrf/blob/master/hardware/jawbreaker/jawbreaker.brd)
      P2 CLKOUT
      P16 CLKIN

      And a jumper which at a guess is to select the CLKIN signal as the clock.
      P17 CLKIN_JMP

      But no SMA headers or jumper pins are soldered to these connections, at least on the beta boards.
      The 3 connections are in a column between the middle of the board and the SMA antenna connection on the bottom left of the board.
      https://github.com/mossmann/hackrf/blob/master/doc/jawbreaker.jpeg

    26. Creator cybergibbons - Andrew Tierney on August 15, 2013

      (as an aside, not sure if it has been stated here - one thing a single HackRF won't do is be able to act as a base station using OpenBTS as it requires full duplex - two could be used, but you would need a very stable and synchronised clock between the two)

    27. Creator John on August 14, 2013

      Since so much of this system is computer based, will it have support for AES encrypted communications?

    28. Creator jason on August 14, 2013

      I am with Andrew, the external clock input/output would be highly useful

    29. Creator cybergibbons - Andrew Tierney on August 14, 2013

      I know that external clock input has been discussed on the Jawbreaker - any chance this will make it to the HackRF? It would be very helpful for GSM tomfoolery.

    30. Creator Michael Ossmann on August 12, 2013

      Gil: It might be possible to make a special case for HackRF plus Ham It Up, but we don't know the final form factor for either device yet. I don't plan on building such an enclosure, but an open source contribution would be welcome. That's what we did for Jawbreaker, and quite a few people have had laser cut enclosures made from the design:
      https://github.com/mossmann/hackrf/tree/master/hardware/jawbreaker/SoBv1_DP17298

    31. Creator Michael Ossmann on August 12, 2013

      jason: The main changes from the Jawbreaker design will be the removal of the PCB antenna and the addition of an enclosure. We also have some less significant potential changes listed on the wiki:
      https://github.com/mossmann/hackrf/wiki/Future-Hardware-Modifications

    32. Creator Gil on August 11, 2013

      Any possibility of an acrylic case that would hold the HackRF and also Ham It Up in one case?

    33. Creator jason on August 11, 2013

      Any other design changes we should know about besides the pcb antenna?

    34. Creator Michael Ossmann on August 11, 2013

      Curtis: The PCB antenna will be removed from the design. No modification or switching will be necessary.

    35. Creator Michael Ossmann on August 11, 2013

      scrybo: It's safe to say at this point that HackRF will be available for sale post-Kickstarter. I don't know the final price yet, but I estimate $300.

    36. Creator Curtis on August 11, 2013

      Any chance of adding some type of switch to avoid having to do the antenna mod? It would be nice to not lose the built in antenna for on the go use. http://www.youtube.com/watch…

    37. Creator Scrybo.com on August 9, 2013

      Congratulations, just wanted to know will this be available for separate purchase?

    38. Creator Bob on August 8, 2013

      Great Project guys!. All the best to you guys.
      By the Way I just saw that you guys made #2 for CrowdFundingForum.com's Hottest new Crowdfunding projects list for the week:
      http://crowdfundingforum.com/showthread.php/6853-Hot-CrowdFunded-Projects-This-Week-Emotiv-Insight-HackRF-(Aug-8th)

    39. Creator Michael Ossmann on August 7, 2013

      Paul and DP: Yes, those are things that are worth experimenting with. We certainly want to at least support decimation to lower sample rates with improved bit depth. This doesn't have to use as much computation as you might think because we can get some help from the switchable baseband filters in the MAX2837.

    40. Creator Paul on August 7, 2013

      @DP I saw this and it got me wondering if it would be possible on the ARM in the hackRF.
      http://stackoverflow.com/questions/11574081/compression-libraries-for-arm-cortex-m3-4
      "20KB data is compressed in 0.5mSec using an ARM Cortex M4. Stack requirement is about 16Kb (configurable down to 4)." - it might just be possible, or maybe not. Anyhow it is not needed, I just curious if the hardware could support an attempt at implementing this in software later, I know it is a long shot, but it would be very nice to have if it was possible.

    41. Creator DP on August 7, 2013

      Paul, I think it would need to me more lightweight than LZ4 given the throughput rates they quote for the algorithm on a Core i5-3340M @2.7GHz vs the ARM that's on this board. There are other options for compression though, and I wonder if the CPLD could be used to increase the bit depth of the samples by decimation. At 22 Msps you could decimate to 5.5 Msps and get 9-bits, 10-bits at 1.375 Msps, 11-bits at 343 Ksps, and so on (divide by 4 for each bit added). Or maybe average groups of samples to reduce the LSB noise.

    42. Creator Paul on August 7, 2013

      "maximum bandwidth of HackRF is 20 MHz", "I+Q" are both 8 bits each, so that would mean that 38.15MiB/sec of raw data has to pass through a USB 2.0 interface. That has to be very close to the maximum effective throughput of USB 2.0.
      Looking at the MAX5864 (ADC/DAC), it have a maximum sample rate of 22Msps. I was just wondering if compressing the data on the ARM processor with an ultra fast and light algorithm like L4Z (https://code.google.com/p/lz4/) would allow the full 22mps to flow through USB .

      Is it possible that this is something that could be added in software by the community after hackRF is released, or is there hardware limiting the upper data rate into the ARM ? Maybe the ARM does not have enough number crunching power/RAM and this is just a mad idea that will not work in practice.

    43. Creator Michael Ossmann on August 7, 2013

      Gil, I am certainly interested in looking for ways to maximize the HackRF operating frequency range, but I don't think that the addition of a third conversion is the right way to do it. The Ham It Up upconverter design is quite large and would increase the size of HackRF. Since it is already manufactured on its own and works so well with HackRF, I like being able to include it as a separate add-on. However, I am contemplating whether or not it would be practical to provide some sort of direct path into the ADC/DAC that could be used for custom data acquisition or low frequency RF. There is a good chance that such a solution wouldn't perform as well or be as easy to use as Ham It Up for MF/HF operation without some additional external circuitry, so I recommend getting the Ham It Up upconverter if you want to be able to operate under 30 MHz. Also note that Ham It Up can be used with various other equipment such as low cost rtl-sdr dongles.

    44. Creator Michael Ossmann on August 7, 2013

      Tim, Jawbreaker power output hasn't been characterized any more precisely than that. The final HackRF board will be tested more thoroughly, but it should be within the range specified for Jawbreaker.

    45. Creator Tim Mattison on August 7, 2013

      The FAQ for the Jawbone ( https://github.com/mossmann/hackrf/wiki/Jawbreaker ) is where I thought I should get the power output specs. Is that correct?

      When looking at those specs there are multiple values for each frequency that is on a boundary. For example, 100 MHz is listed as 15 dBm and 0 dBm. I assume this is because there are different hardware components that generate each band of frequencies but if I were to transmit on exactly 100 MHz what should I expect the power output to be? Does it depend on how wide the signal is?

    46. Creator Gil on August 6, 2013

      Is there any chance of integrating the upconverter onto the board, since it is open source? Stretch goal?

    47. Creator Matthew O'Gorman on August 5, 2013

      BladeRF:
      full duplex
      300mhz-3.8ghz
      28mhz filtered bandwidth
      usb 3.0
      12 bit adc/dac
      physically larger than hackrf
      closed hardware
      more expensive

      HackRF:
      half-duplex (100 microsecond switchable internally. if done over usb add usb latency)
      30mhz-6ghz (with upverter 300khz-6ghz)
      20mhz bandwidth
      usb 2.0
      8 bit adc/dac
      cheaper and open hardware

    48. Creator Michael Ossmann on August 3, 2013

      Range is primarily dependent on the transmit output power. (See the FAQ.) In general, you can operate across a room but not over greater distances. Larger range can be achieved with external amplification and filtering, but you need to be careful of interference and regulatory compliance.

    49. Creator Michael Ossmann on August 3, 2013

      We haven't optimized the TX/RX switching time or frequency tuning time yet, but they should be in the neighborhood of 100 microseconds if controlled by the on-board ARM. If controlled by the host computer, those times will be increased by USB latency.

Show older comments