Use this space to cheer the creator along, ask questions, and talk to your fellow backers. Please remember to be respectful and considerate. Thanks!
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.
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?
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.
@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.
@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
I meant SDR Hardware ..
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.
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?
Marc: I'm not sure what Extio is. I found some relevant search results but no clear description.
Jason: The SMA connector will almost certainly be edge-mounted, but the final form factor and enclosure have not been designed yet.
woot stretch goal met!
Extio supported already?
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?"
Will the SMA connector also be mounted in the same location and orientation? Would somewhat prefer an edge-mount connector instead.
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.
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.
Kyle: Yes, HackRF will have an SMA antenna connector.
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?
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.
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
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).
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.
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.
*DOH* no edit button. No sorry, not the schematic, I meant the board file.
@Andrew & @Jason
Running KiCAD and opening the schematic file shows 2 clock connections.
And a jumper which at a guess is to select the CLKIN signal as the clock.
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.
(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)
Since so much of this system is computer based, will it have support for AES encrypted communications?
I am with Andrew, the external clock input/output would be highly useful
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.
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:
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:
Any possibility of an acrylic case that would hold the HackRF and also Ham It Up in one case?
Any other design changes we should know about besides the pcb antenna?
Curtis: The PCB antenna will be removed from the design. No modification or switching will be necessary.
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.
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…
Congratulations, just wanted to know will this be available for separate purchase?
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:
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.
@DP I saw this and it got me wondering if it would be possible on the ARM in the hackRF.
"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.
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.
"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.
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.
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.
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?
Is there any chance of integrating the upconverter onto the board, since it is open source? Stretch goal?
28mhz filtered bandwidth
12 bit adc/dac
physically larger than hackrf
half-duplex (100 microsecond switchable internally. if done over usb add usb latency)
30mhz-6ghz (with upverter 300khz-6ghz)
8 bit adc/dac
cheaper and open hardware
How does this compare to the bladeRF project? (http://www.kickstarter.com/projects/1085541682/bladerf-usb-30-software-defined-radio)
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.
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.