We're going to want a type that just identifies one PLL, and is
consistent with how the PLLs are numbered in register settings.
The current si5351c_pll_t is a bitmask which allows referring to
both PLLs. Let's make that a different type, and name things more
clearly when using it.
There are multiple similar but different things called a "source"
or "clock source", or that are set in a register called "SRC", in the
context of the Si5351 and its usage in HackRF.
One place we can be unambiguous is that there are only two inputs to
the Si5351C itself: XTAL and CLKIN. Let's have a type for that alone,
and name it as such when we use it.
There should be no functional changes in this commit.
Previously the CLKIN switch defaulted to P22_CLKIN, enabling usage of
the clock input on pin header P22 but not on SMA port P1. This change
enables use of clock input on P1 and disables P22_CLKIN by default.
Previously it was possible, though rare, for an update of an RX gain
setting to be displayed during TX mode or for an update of a TX gain
setting to be displayed during RX mode.
The PortaPack UI hides leading zeros in the most significant digits.
Previously zeros in the 1 MHz column and above were hidden. Now zeros in
the 10 MHz column and above are hidden.
Recent versions include a suffix in brackets, e.g:
$ clang-format --version
Debian clang-format version 21.1.8 (3+b1)
Require a specific version rather than a minimum one, due to differences
in output between versions.
On most platforms, we previously set PLL A to use XTAL input and PLL B
to use CLKIN, switching from one PLL to the other to change clock
source. Now we use PLL A at all times, switching the PLL input to change
clock source.
This avoids output clock phase inconsistencies that can happen when
switching output multisynths from one PLL to another. It also makes it
possible in the future to use one PLL for sample rate and the other PLL
for reference clocks.
Previously we zeroed all RFFC5072 frequency synthesizer control
registers, resulting in an invalid configuration which could adversely
affect start-up if the part is enabled before a valid frequency is set.
Simplified the filter architecture by using an adder tree for obtaining
the final sum of the subfilters (vs systolic array). Previously, no
backpressure (always_ready=True) worked fine but otherwise we lost
samples.
On the CCC 2015 rad1o badge, the Si5351C clock generator is powered
by the RF section supply (named VDD on the schematic).
So clock_gen_init() must be called after enable_rf_power().
Since the Si5351C is off when the RF power is off, there should be
no need for the shutdown/init calls at startup.
For compatibility with old host software, the analog baseband filter is
automatically selected based on the sample rate and offset tuning
configuration. The bandwidth set by legacy vendor request is ignored.
The 100 Hz setting that is recommended by the data sheet doesn't seem to
work correctly. The other settings would be appropriate only with the
extended precision RX gateware.
The 600 kHz setting seems like it should be useful with higher sample
rates, but it increases LPF roll-off.
Simplified the filter architecture by using an adder tree for obtaining
the final sum of the subfilters (vs systolic array). Previously, no
backpressure (always_ready=True) worked fine but otherwise we lost
samples.
Portions of pin_setup() that establish a safe, low-power state are moved
into the new pin_shutdown(). Use pin_shutdown() to prepare for sleep or
reset or prior to calling pin_setup().
Reliable oscillator start-up requires several hundred milliseconds which
is longer than we are willing to wait at every boot. We could add an
on-demand test in the future instead of an automatic self-test.
Co-authored-by: mndza <diego.hdmp@gmail.com>
Co-authored-by: Martin Ling <martin-git@earth.li>
Co-authored-by: Antoine van Gelder <antoine@greatscottgadgets.com>
PC_FFTW3f_FOUND indicates that FFTW3f was found via pkg-config.
It can also be found without pkg-config, if the necessary paths
are supplied. This fixes hackrf_sweep not being built in that case.
The libtarget variable isn't defined here (it's used in a helper
function above). This caused libhackrf to be built and installed without
a version number.
Refactor HackRF build system with a more modern CMake style.
Install files to allow library users using CMake to
find_project(HackRF CONFIG) and obtain HackRF::hackrf
and/or HackRF::hackrf_static library targets.
Add options ENABLE_STATIC_LIB and ENABLE_SHARED_LIB
to allow shared or static library to be disabled.
(Default builds both shared and static libraries.)
Add option ENABLE_HACKRF_SWEEP, when disabled allows
building without FFT library. (Default enabled.)
Add option DISABLE_USB_DEVICE_DISCOVERY for a compile definition
which could be used to alter libusb usage as needed on Android.
I added the Information about radioconda. I would still suggest leaving the hint about the build artifacts in the documentation, as this is currently the only source of the binaries that don't require any third party.
Previously we were calculating the dfu-suffix CRC and then modifying the
image, invalidating the check.
This re-orders the operations to apply the boot image header first and
then run dfu-suffix.
Counter-intuitively, this actually saves us two cycles because we unroll
the first iteration of the loop that spins on the interrupt flag, saving
a branch in the case that the flag is clear the first time.
The previous markdown was not valid and yielded the following warning:
```sh
⬛make html
Running Sphinx v5.3.0
WARNING: Invalid configuration value found: 'language = None'. Update your configuration to a valid language code. Falling back to 'en' (English).
making output directory... done
building [mo]: targets for 0 po files that are out of date
building [html]: targets for 34 source files that are out of date
updating environment: [new config] 34 added, 0 changed, 0 removed
reading sources... [100%] virtual_machines
hackrf/docs/source/list_of_hardware_revisions.rst:36: WARNING: Title underline too short.
HackRF One r10
~~~~~~~~~~~~~
hackrf/docs/source/list_of_hardware_revisions.rst:36: WARNING: Title underline too short.
HackRF One r10
~~~~~~~~~~~~~
looking for now-outdated files... none found
pickling environment... done
checking consistency... done
preparing documents... done
writing output... [100%] virtual_machines
generating indices... genindex done
writing additional pages... search done
copying images... [100%] ../images/noisereducingcablescreenshot.jpeg
copying static files... done
copying extra files... done
dumping search index in English (code: en)... done
dumping object inventory... done
build succeeded, 3 warnings.
The HTML pages are in build/html.
```
Congratulations on double digits.
* Add artifact publish step for Windows libraries and host tools.
* Replace runner.workspace with github.workspace.
* Update checkout task to v4 to supress warning.
* Update CMAKE for libhackrf and hackrf-tools to also install DLLs on WIN32 platforms.
* Update uploadartifact task to v4 since v3 uses an end-of-life node version 16.
* Add a new windows variable for the vcpkg cmake toolchain makefile.
Previously we thought we were configuring the ADC for 8-bit values, but
we did so incorrectly. We were throwing away the top two bits of a
10-bit value. This never caused a problem because the only fixed
voltages we used were at the extreme minimum or maximum of the ADC
range.
This commit is between r8 and r9 and will be used as the basis for r10.
It includes some of the changes in r9 but predates the major changes to
the clock generator and IF transceiver ICs.
Compiling with clang-cl, gives this error:
```c
hackrf-tools/src/hackrf_sweep.c(685,3): error: call to undeclared function '_setmode'; ISO C99 and later do not support implicit function
declarations [-Wimplicit-function-declaration]
685 | _setmode(_fileno(stdout), _O_BINARY);
| ^
```
fixed by simply adding `#include <io.h>`.
* Call fftw_execute once prior to starting IQ streaming
* Add options to use/save to an FFTW wisdom file and specify plan
* Fix bug where using -P would also enable one-shot mode
Fixes#1366Fixes#1260
Addresses #863
* mask all signals in libhackrf transfer_threadproc
hackrf_transfer uses pause() and SIGALRM to print statistics and POSIX doesn't
specify which thread must recieve the signal, block all signals here, so we
don't interrupt their reception by hackrf_transfer or any other app which uses
the library (#1323)
* fix windows build and remove empty line
* Initial commit of hackrf_biast
* Cleaned up hackrf_biast
* Cleaned up usage info
* Include getopt.h for non-GNU systems
* Add support for overriding HackRF's default antenna power behavior in firmware. Add support for specifying antenna power behavior in libhackrf.
* Moved bias tee config routines into user_config.c, cleaned up operation of hackrf_biast
* hackrf_biast now calls usage() and exits when invoked with no arguments
* Fixed minor documentation error in usage()
* minor syntax cleanup
* Add some documentation to the host API call
* Add proper declaration magic in hackrf.h to hackrf_set_user_bias_t_opts() to appease Visual Studio
* Documentation changes suggested by @martinling
* Moved bias t setting above switch statement, removed line that explicit turned bias t off when entering OFF mode
* Change hackrf_set_user_bias_t_opts() to use a friendly struct() instead of a bitmask. User friendliness fixes to hackrf_biast options. More clang-format appeasement.
* Removed support for integer mode args from hackrf_biast
* clang-format error fixes
* Tweaked position of comment for clang-format v14
* Reformat files with clang-format v14 instead of 16
* Remove internal numeric modes for bias T settings
Co-authored-by: Martin Ling <martin-github@earth.li>
* Fix documentation error in hackrf_biast.c
---------
Co-authored-by: Martin Ling <martin-github@earth.li>
* Document & comment code
* document functions & add pages for groups
* Run clang-format
* Fix most review change requests
* Fix typos, add information on using multiple Opera Cake boards
* Update documentation
* Changes requested by @Straithe
- update project brief
- set paper type to letter
- move doxyfile
* Changes requested by @martinling
Excluding the USB API versioning
* Remove incomplete USB version info
The required versions were only noted at a few places. Will add complete info later, but for now, it's removed
* reorganize and update existing HackRF documentation
* include changes suggested by martinling
* Update software support page
* fix typo
* Update acrylic case link
* docs: make adjustments based on feedback from epenelope
Previously we checked for OG support instead of r9 support because we
didn't yet have a way to tag firmware binaries with support for multiple
platforms.
During r9 hardware development it was thought that the MAX2839 would use
a different GPIO pin for chip select, but it ended up being the same pin
as is used for MAX2837 on other hardware revisions.
This takes the MAX283x abstraction a bit further and fixes a bug with
hackrf_debug -m.
The bootloader is configured by pin straps on certain pins. We use some
of those for other purposes in r9 which causes the bootloader to
misbehave if the device is reset from software. By switching these pins
from outputs to inputs just before reset this problem is avoided.
On the first spin of r9 one of the pins used for platform detection is
pulled up to VAA, not VCC, and VAA hasn't been switched on yet at the
time of platform detection. This results in r9 being misidentified as OG
from time to time.
As a temporary workaround until the next board spin, change the platform
from OG to r9 if it is detected as OG but has r9 pin straps.
Writing to the output bits in the TIMER3 external match register
resulted in intermittent failures that varied in likelihood from board
to board and from commit to commit for no apparent reason.
We've always specified that CLKIN should be DC (based on the Si5351C
documentation), but it has worked with AC input. AC coupling the buffer
input restores this undocumented feature.
- move CLKIN_DETECT to U23 pin 15, P4_8, CTIN_5
- move SGPIO13 to U23 pin 91, P2_5, GPIO5[5]
- rename SGPIO13 to TRIGGER_EN
This allows TIMER1/TIMER2 instead of TIMER3/TIMER0 to be used for CLKIN
detection, avoiding conflicts with PortaPack firmware.
SGPIO13 was never used for SGPIO, so it is renamed to reflect current
usage.
- move EN_1V8 to P5_0, U23 pin 37
- move !VAA_ENABLE to P6_10, U23 pin 100
- move !RX_AMP_PWR back to P2_12, U23 pin 106
Platform detection is now performed using P5_0 and P6_10 which avoids
the complication of having to detect a pull-up to VAA which may not yet
be switched on.
Additionally swap:
- EN_1V8, P6_10, U23 pin 100 (pull-down)
- !RX_AMP_PWR, P2_12, U23 pin 106 (pull-up)
Detecting which has the pull-up and which has the pull-down enables
version detection that may be more reliable than the ADC method.
We were only setting this to Release, so there is no current need for an
environment variable.
Removing it allows us to reuse some steps for Windows, where the syntax
to insert an environment variable is different.
* Remove default titles from issue forms
* Update technical-support.yml
Issue template: reversed an option in the technical support template.
Co-authored-by: Straithe <b@straithe.com>
The rad1o was not starting the M0 when powered up by inserting a USB
cable. Interestingly the M0 does start when toggling the power switch.
Resetting the M0 before starting it in `main()` solves this issue.
Starting with this release we will no longer use "unknown" as the
default software version string used in cases where the version cannot
be determined from context. Instead we commit the release version string
to git so that any software built from the tagged commit will have the
appropriate release version string. After the release we will commit a
post-release version string as the new default.
We will continue to use the commit hash as version string when the
software is built inside a git repository.
On macOS 12.6 running libusb 1.0.26, the host was seen to sometimes
make an incomplete ClearFeature(ENDPOINT_HALT) request when
ClearPipeStallBothEnds was called from libusb_cancel_transfer.
The host would send the SETUP packet, and the firmware would
call usb_transfer_schedule_ack to acknowledge the upcoming IN
token. However, the host would then not send the IN token,
proceeding directly to the next SETUP.
Since an empty transfer was queued to schedule the ACK, the
firmware would leak one transfer from the free_transfers list.
After a few iterations of this, the firmware would run out of
free transfers and the next request would hang waiting for one.
Fix this by flushing the transfer queues for the control endpoint
when a new SETUP is received, since that token implicitly cancels
any previously ongoing request.
This avoids a confusing condition when hackrf_transfer is reading from
stdin with -R in which it does not repeat previous data but repeatedly
restarts reading new data after the user types Ctrl-D to indicate EOF.
The -R option should repeat previous data or should do nothing if the
input file cannot be rewound.
Previously these calls were leaving the amplifiers on, since the
control settings passed were missing SWITCHCTRL_NO_TX_AMP_PWR and
SWITCHCTRL_NO_RX_AMP_PWR. Use the predefined SWITCHCTRL_SAFE here.
Also move these calls before setting the GPIO pins to output mode,
to avoid driving them to the wrong states briefly first.
Where our callback is called with a status other than COMPLETED,
something abnormal has happened and we no longer want to either
submit further transfers or await a flush. So clear the streaming
and flush flags, and proceed to transfer_finished.
Do the same in the case where libusb_submit_transfer fails when
called to submit the flush transfer.
Fixes a bug introduced in 8a9af7a: Statistics skipped for initial
buffers not only when preloaded in TX mode but also in RX mode with no
preloading.
The total bytes transferred may appear inflated in RX mode when
receiving a small number of samples with -n, but the stats represent
data transferred over USB, some of which may have been discarded by the
host.
Instead of sending a signal to the process group, get our own process ID
and send the signal to it. This fixes a bug that prevented termination
when called from a script.
dBFS is defined in AES Standard AES17-1998, IEC 61606, and ITU-T Recs.
P.381 and P.382, such that the RMS value of a full-scale sine wave is
designated 0 dBFS.
A full scale sine wave on HackRF has the range -127 to 127.
We calculate the full scale ratio relative to a signal in which both I
and Q are held at 127. This represents a signal with sqrt(2) times
the amplitude, and thus twice the power, of a full scale sine wave.
Therefore to obtain dBfs by the above definition, we add 3dB.
The power measurement depends on the number of bytes that were valid
from the previous use of the transfer buffer.
The number of bytes to be read to fill the next transfer, is the full
size of the buffer.
Firmware now detects the hardware it is running on at startup and
refuses to run if it is compiled for the wrong platform. The board ID
returned by firmware to the host is now derived from run-time detection
rather than a compile-time value. A separate method to retrieve
compile-time supported platform is added.
On HackRF One, pin straps are checked to determine hardware revision.
This is informational to aid troubleshooting and does not affect any
function.
The statistics reported to the user now reflect only completed USB
transfers and do not include information about the empty buffers that
are preloaded with data at the start of a TX operation.
Applications may need to learn the size of the USB transfer buffer
queue, for example to determine how many bytes will be preloaded with
calls to the TX callback.
description:Ask a question not covered by current hackrf.rtfd.io documentation
labels:["question"]
body:
- type:markdown
attributes:
value:|
Thank you for taking the time to ask your question! If you need technical support, want to open a feature request, or need to file a bug report, please abandon this issue, open a new issue, and choose the correct template. If you do not choose the correct template, you will be asked to re-open your issue with the correct template.
Thank you for taking the time to fill out this technical support request form! Please note that technical support requests can expect a response time of two weeks.
- type:textarea
id:expected-outcome
attributes:
label:What outcome were you hoping for?
placeholder:Please be detailed in what you expected to happen
validations:
required:true
- type:textarea
id:actual-outcome
attributes:
label:What outcome actually happened?
placeholder:Please be detailed in what did happen
validations:
required:true
- type:textarea
id:operating-systems
attributes:
label:What operating systems are you seeing the problem on?
validations:
required:true
- type:textarea
id:hackrf_info-output
attributes:
label:What is the output of ```hackrf_info```?
description:Please put the output of the command in the box below or indicate N/A.
validations:
required:true
- type:textarea
id:third-party-software
attributes:
label:Are you using any third-party software?
description:Please list the software you are using with your HackRF or indicate N/A. Please list version numbers where possible.
placeholder:GNU Radio, GQRX, etc.
validations:
required:true
- type:textarea
id:third-party-hardware
attributes:
label:Are you using any third-party hardware?
description:Please list any hardware you are using with your HackRF or indicate N/A.
@ -15,14 +15,19 @@ Information on HackRF and purchasing HackRF: https://greatscottgadgets.com/hackr
# Documentation
Documentation for HackRF can be viewed on [Read the Docs](https://hackrf.readthedocs.io/en/latest/). The raw documenation files for HackRF are in the [docs folder](https://github.com/mossmann/hackrf/tree/master/docs) in this repository and can be built locally by installing [Sphinx Docs](https://www.sphinx-doc.org/en/master/usage/installation.html) and running `make html`. Documentation changes can be submitted through pull request and suggestions can be made as GitHub issues.
Documentation for HackRF can be viewed on [Read the Docs](https://hackrf.readthedocs.io/en/latest/). The raw documentation files for HackRF are in the [docs folder](https://github.com/mossmann/hackrf/tree/master/docs) in this repository and can be built locally by installing [Sphinx Docs](https://www.sphinx-doc.org/en/master/usage/installation.html) and running `make html`. Documentation changes can be submitted through pull request and suggestions can be made as GitHub issues.
To create a PDF of the HackRF documentation from the HackRF repository while on Ubuntu:
* run `sudo apt install latexmk texlive-latex-extra`
* navigate to hackrf/docs on command line
* run the command `make latex`
* run the command `make latexpdf`
--------------------
# Getting Help
Before asking for help with HackRF, check to see if your question is listed in the [FAQ](https://hackrf.readthedocs.io/en/latest/faq.html).
Before asking for help with HackRF, check to see if your question is listed on the [troubleshooting page](https://hackrf.readthedocs.io/en/latest/troubleshooting.html).
For assistance with HackRF general use or development, please look at the [issues on the GitHub project](https://github.com/greatscottgadgets/hackrf/issues). This is the preferred place to ask questions so that others may locate the answer to your question in the future.
d="m 16.933335,136.52501 h 1.058333 v -2.11667 h 2.116667 v 2.11667 h 2.116667 v -2.11667 h 2.116666 v 2.11667 h 2.116666 v -2.11667 h 2.116669 v 2.11667 h 1.058334"
d="m 16.933336,153.45836 h 1.058333 v -2.11667 h 2.116667 v 2.11667 h 2.116667 v -2.11667 h 2.116666 v 2.11667 h 2.116666 v -2.11667 h 2.116669 v 2.11667 h 1.058334"
d="m 16.933335,136.52501 h 1.058333 v -2.11667 h 2.116667 v 2.11667 h 2.116667 v -2.11667 h 2.116666 v 2.11667 h 2.116666 v -2.11667 h 2.116669 v 2.11667 h 1.058334"
d="m 16.933336,153.45836 h 1.058333 v -2.11667 h 2.116667 v 2.11667 h 2.116667 v -2.11667 h 2.116666 v 2.11667 h 2.116666 v -2.11667 h 2.116669 v 2.11667 h 1.058334"
The NXP LPC43xx microcontrollers have an interesting, programmable serial peripheral called the SGPIO (Serial GPIO). It consists of a slew of counters and shift registers that can be configured to serialize and deserialize many channels of data. Channels can be grouped to create multi-bit parallel data streams.
The current HackRF design entails using the SGPIO peripheral to move quadrature baseband receive and transmit data between the USB interface and the baseband ADC/DAC IC. Because the baseband ADC/DAC IC (MAX5864) uses DDR signaling, we expect to use a CPLD to convert bus signaling. The CPLD may also help manage bus turnaround (between transmit and receive modes) or interfacing two narrower but faster interfaces to the LPC43xx to facilitate full-duplex.
Because the Jellybean board wasn't completed at the time of these experiments, I used the Diolan LPC-4350-DB1-A development board. Despite using an LPC4350 in an BGA256 package, the SGPIO peripheral's signals can be mapped to many different pins. So reworking code to a new set of SGPIO pins should be a trivial matter of switching the SGU configuration for the affected pins.
SGPIO Examples
~~~~~~~~~~~~~~
Some SGPIO peripheral examples can be found in `the LPCWare repository <http://sw.lpcware.com/?p=lpc43xx.git&a=summary>`__. All source I've found so far is focused on generating many I2S interfaces, which is not very similar to HackRF's needs. But reviewing the code is still valuable in grasping how the SGPIO peripheral operates.
There are a few common details to setting up the SGPIO peripheral:
.. code-block :: C
// Configure the PLL to generate a reasonable clock. The SGPIO
// will operate with a clock of up to 204MHz (the same as the
My first full-on SGPIO experiment involved serializing a data pattern from slice A, using slice D to generate a SGPIO_CLK/2 data rate. I derived the code from examples that configured the SGPIO as I2S interfaces:
It would be great if we could, as that would free up lots of processor time. Unfortunately, the GPDMA scheme in the LPC43xx does not seem to support peripheral-to-memory and memory-to-peripheral transfers with the SGPIO peripheral.
Eventually, the HackRF project may result in multiple hardware designs, but the initial goal is to build a single wideband transceiver peripheral that can be attached to a general purpose computer for software radio functions.
Primary goals:
* half-duplex transceiver
* operating freq: 100 MHz to 6 GHz
* maximum sample rate: 20 Msps
* resolution: 8 bits
* interface: High Speed USB
* power supply: USB bus power
* portable
* open source
Wish list:
* full-duplex (at reduced max sample rate)
* external clock reference
* dithering
* parallel interface for external FPGA, etc.
If there is a primary goal we miss, it will probably be the operating frequency range. The wideband front end is the part of the design furthest from completion. At an absolute minimum, the board should do 900 MHz and 2.4 GHz.
The design is FPGA-less. There will be a tiny bit of DSP capability (ARM Cortex-M4), but mostly we're just trying to get samples to and from a host computer.
We are trading resolution and DSP capability for cost, portability, and frequency range. Considering that we'll be able to support oversampling for many applications and that we should be able to implement AGC, it should be a pretty good trade.
The commercial version of HackRF One from Great Scott Gadgets ships with an injection molded plastic enclosure, but it is designed to fit two optional enclosures:
Commercial versions of both HackRF Pro and HackRF One from Great Scott Gadgets ship with an injection molded plastic enclosure but are also designed to fit two optional enclosures:
* Hammond 1455J1201: HackRF One fits this extruded aluminum enclosure and other similar models from Hammond Manufacturing. In order to use the enclosure's end plates, you will have to drill them. An end plate template can be found in the HackRF One KiCad layout.
* Hammond 1455J1201: Both HackRF Pro and HackRF One fit this extruded aluminum enclosure and other similar models from Hammond Manufacturing. In order to use the enclosure's end plates, you will have to drill them. An end plate template can be found in the HackRF One KiCad layout.
* Acrylic sandwich: You can also use a laser cut acrylic enclosure with HackRF One. This is a good option for access to the expansion headers. A design can be found in the HackRF One hardware directory. Use any laser cutting service or purchase from a `reseller <http://greatscottgadgets.com/acrylic_case/>`__.
* Acrylic sandwich: You can also use a laser cut acrylic enclosure with either HackRF Pro or HackRF One. This is a good option for access to the expansion headers. A design can be found in the HackRF hardware directory. Use any laser cutting service or purchase from a `reseller <https://greatscottgadgets.com/hackrf/acrylic-case/>`__.
The HackRF One expansion interface consists of headers P9, P20, P22, and P28. These four headers are installed on the commercial HackRF One from Great Scott Gadgets.
P9 Baseband
^^^^^^^^^^^
A direct analog interface to the high speed dual ADC and dual DAC.
.. list-table ::
:header-rows:1
:widths:1 1
* - Pin
- Function
* - 1
- GND
* - 2
- GND
* - 3
- GND
* - 4
- RXBBQ-
* - 5
- RXBBI-
* - 6
- RXBBQ+
* - 7
- RXBBI+
* - 8
- GND
* - 9
- GND
* - 10
- TXBBI-
* - 11
- TXBBQ+
* - 12
- TXBBI+
* - 13
- TXBBQ-
* - 14
- GND
* - 15
- GND
* - 16
- GND
The common HackRF expansion interface consists of headers P20, P22, and P28. These headers are present on both HackRF Pro and HackRF One, and support hardware add-ons including PortaPack and Opera Cake.
P20 GPIO
^^^^^^^^
@ -65,15 +17,15 @@ Providing access to GPIO, ADC, RTC, and power.
@ -211,26 +163,70 @@ SDIO, GPIO, clocks, and CPLD.
* - 12
- GND
* - 13
- GCK2
- GCK2 (One) / P5_6 (Pro)
* - 14
- GCK1
- GCK1 (One) / P5_7 (Pro)
* - 15
- B1AUX14
- Trigger out: B1AUX14 (One) / TRIGGER.OUT (Pro)
* - 16
- B1AUX13
- Trigger in: B1AUX13 (One) / TRIGGER.IN (Pro)
* - 17
- CPLD_TCK
* - 18
- BANK2F3M2
- BANK2F3M2 (One) / PE_0 (Pro)
* - 19
- CPLD_TDI
- CPLD_TDI (One) / I2S0_RX_SDA (Pro)
* - 20
- BANK2F3M6
- BANK2F3M6 (One) / P9_1 (Pro)
* - 21
- BANK2F3M12
- BANK2F3M12 (One) / P5_3 (Pro)
* - 22
- BANK2F3M4
- BANK2F3M4 (One) / P1_7 (Pro)
P9 Baseband (HackRF One)
^^^^^^^^^^^^^^^^^^^^^^^^
A direct analog interface to the high speed dual ADC and dual DAC.
.. list-table ::
:header-rows:1
:widths:1 1
* - Pin
- Function
* - 1
- GND
* - 2
- GND
* - 3
- GND
* - 4
- RXBBQ-
* - 5
- RXBBI-
* - 6
- RXBBQ+
* - 7
- RXBBI+
* - 8
- GND
* - 9
- GND
* - 10
- TXBBI-
* - 11
- TXBBQ+
* - 12
- TXBBI+
* - 13
- TXBBQ-
* - 14
- GND
* - 15
- GND
* - 16
- GND
Additional unpopulated headers and test points are available for test and development, but they may be incompatible with some enclosure or expansion options.
Refer to the schematics and component documentation for more information.
Refer to the schematics and component documentation for more information.
HackRF One produces a 10 MHz clock signal on CLKOUT. The signal is a 10 MHz square wave from 0 V to 3 V intended for a high impedance load.
.._external_clock_interface:
The CLKIN port on HackRF One is a high impedance input that expects a 0 V to 3 V square wave at 10 MHz. Do not exceed 3.3 V or drop below 0 V on this input. Do not connect a clock signal at a frequency other than 10 MHz (unless you modify the firmware to support this). You may directly connect the CLKOUT port of one HackRF One to the CLKIN port of another HackRF One.
HackRF Pro
~~~~~~~~~~
HackRF Pro has two configurable SMA ports, P1 and P2. By default, P1 is configured as CLKIN and P2 as CLKOUT. The default behaviour of these signals is as described for HackRF One below.
A second CLKIN signal is available on header P22 pin 2. Unlike HackRF One, HackRF Pro's P22_CLKIN is a separate signal from P1_CLKIN. To enable P22_CLKIN instead of P1_CLKIN use ``hackrf_clock -c p22``.
Various internal signals can be connected to P1 or P2 instead of the default CLKIN and CLKOUT signals. Use ``hackrf_clock -1`` or ``hackrf_clock -2`` to select a different signal.
HackRF One
~~~~~~~~~~
HackRF One produces a 10 MHz clock signal on the CLKOUT SMA port. The signal is a 3.3 V, 10 MHz square wave intended for a high impedance load.
The CLKIN SMA port on HackRF One is a high impedance input that expects 3.3 V square wave at 10 MHz. Do not exceed 3.3 V or drop below 0 V on this input. Do not connect a clock signal at a frequency other than 10 MHz (unless you modify the firmware to support this). You may directly connect the CLKOUT port of one HackRF One to the CLKIN port of another HackRF.
The CLKIN signal is also connected to header P22 pin 2. Unlike HackRF Pro, HackRF One has only one CLKIN signal shared between P22 pin 2 and the CLKIN port. Do not connect input signals to both CLKIN and P22 pin 2 simultaneously.
HackRF One uses CLKIN instead of the internal crystal when a clock signal is detected on CLKIN. The switch to or from CLKIN only happens when a transmit or receive operation begins.
To verify that a signal has been detected on CLKIN, use ``hackrf_clock -i``. The expected output with a clock detected is `CLKIN status: clock signal detected`. The expected output with no clock detected is `CLKIN status: no clock signal detected`.
To activate CLKOUT, use ``hackrf_clock -o 1``. To switch it off, use ``hackrf_clock -o 0``.
HackRF One's absolute maximum TX power varies by operating frequency:
* 1 MHz to 10 MHz: 5 dBm to 15 dBm, generally increasing as frequency increases (see this `blog post <https://greatscottgadgets.com/2015/05-15-hackrf-one-at-1-mhz/>`__)
* 10 MHz to 2150 MHz: 5 dBm to 15 dBm, generally decreasing as frequency increases
* 2150 MHz to 2750 MHz: 13 dBm to 15 dBm
* 2750 MHz to 4000 MHz: 0 dBm to 5 dBm, decreasing as frequency increases
* 4000 MHz to 6000 MHz: -10 dBm to 0 dBm, generally decreasing as frequency increases
Through most of the frequency range up to 4 GHz, the maximum TX power is between 0 and 10 dBm. The frequency range with best performance is 2150 MHz to 2750 MHz.
Overall, the output power is enough to perform over-the-air experiments at close range or to drive an external amplifier. If you connect an external amplifier, you should also use an external bandpass filter for your operating frequency.
Before you transmit, know your laws. HackRF One has not been tested for compliance with regulations governing transmission of radio signals. You are responsible for using your HackRF One legally.
----
What is the Receive Power of HackRF?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The maximum RX power of HackRF One is -5 dBm. Exceeding -5 dBm can result in permanent damage!
In theory, HackRF One can safely accept up to 10 dBm with the front-end RX amplifier disabled. However, a simple software or user error could enable the amplifier, resulting in permanent damage. It is better to use an external attenuator than to risk damage.
----
What is the minimum signal power level that can be detected by HackRF?
This isn't a question that can be answered for a general purpose SDR platform such as HackRF. Any answer would be very specific to a particular application. For example, an answerable question might be: What is the minimum power level in dBm of modulation M at frequency F that can be detected by HackRF One with software S under configuration C at a bit error rate of no more than E%? Changing any of those variables (M, F, S, C, or E) would change the answer to the question. Even a seemingly minor software update might result in a significantly different answer. To learn the exact answer for a specific application, you would have to measure it yourself.
HackRF's concrete specifications include operating frequency range, maximum sample rate, and dynamic range in bits. These specifications can be used to roughly determine the suitability of HackRF for a given application. Testing is required to finely measure performance in an application. Performance can typically be enhanced significantly by selecting an appropriate antenna, external amplifier, and/or external filter for the application.
----
Is HackRF full-duplex?
~~~~~~~~~~~~~~~~~~~~~~
HackRF One is a half-duplex transceiver. This means that it can transmit or receive but not both at the same time.
----
Why isn't HackRF One full-duplex?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HackRF One is designed to support the widest possible range of SDR applications in a single, low cost, portable device. Many applications do not require full-duplex operation. Full-duplex support would have made HackRF larger and more expensive, and it would have required an external power supply. Since full-duplex needs can be met by simply using a second HackRF One, it made sense to keep the device small, portable, and low cost for everyone who does not require full-duplex operation.
----
How could the HackRF One design be changed to make it full-duplex?
The HackRF One hardware design is actually full-duplex (at lower sample rates) from the USB connection through the ADC/DAC. The RF section is the only part of the design that cannot support full-duplex operation. The easiest way to make HackRF One full-duplex would be to create an add-on board that duplicates the RF section and also provides an external power input (from a wall wart, for example) for the additional power required. This would also require software effort; the firmware, CPLD, libhackrf, and other host software would all need work to support full-duplex operation.
If you were to try to redesign the RF section on HackRF One to support full-duplex, the main thing to focus on would be the MAX2837 (intermediate frequency transceiver). This part is half-duplex, so you would either need two of them or you would have to redesign the RF section to use something other than the MAX2837, likely resulting in a radically different design. If you used two MAX2837s you might be able to use one RFFC5071 instead of two RFFC5072s.
----
Are those connectors SMA or RP-SMA?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Some connectors that appear to be SMA are actually RP-SMA. If you connect an RP-SMA antenna to HackRF One, it will seem to connect snugly but won't function at all because neither the male nor female side has a center pin. RP-SMA connectors are most common on 2.4 GHz antennas and are popular on Wi-Fi equipment. Adapters are available.
----
.._bigspike:
What is the big spike in the center of my received spectrum?
If you see a large spike in the center of your FFT display regardless of the frequenecy you are tuned to, you are seeing a DC offset (or component or bias). The term "DC" comes from "Direct Current" in electronics. It is the unchanging aspect of a signal as opposed to the "alternating" part of the signal (AC) that changes over time. Take, for example, the signal represented by the digital sequence:
This periodic signal contains a strong sinusoidal component spanning from -2 to 9. If you were to plot the spectrum of this signal, you would see one spike at the frequency of this sinusoid and a second spike at 0 Hz (DC). If the signal spanned from values -2 to 2 (centered around zero), there would be no DC offset. Since it is centered around 3.5 (the number midway between -2 and 9), there is a DC component.
Samples produced by HackRF are measurements of radio waveforms, but the measurement method is prone to a DC bias introduced by HackRF. It's an artifact of the measurement system, not an indication of a received radio signal. DC offset is not unique to HackRF; it is common to all quadrature sampling systems.
There was a bug in the HackRF firmware (through release 2013.06.1) that made the DC offset worse than it should have been. In the worst cases, certain Jawbreakers experienced a DC offset that drifted to a great extreme over several seconds of operation. This bug has been fixed. The fix reduces DC offset but does not do away with it entirely. It is something you have to live with when using any quadrature sampling system like HackRF.
A high DC offset is also one of a few symptoms that can be caused by a software version mismatch. A common problem is that people run an old version of gr-osmosdr with newer firmware.
----
What gain controls are provided by HackRF?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HackRF (both Jawbreaker and One) provides three different analog gain controls on RX and two on TX.
The three RX gain controls are at these stages:
- RF ("amp", 0 or 14 dB)
- IF ("lna", 0 to 40 dB in 8 dB steps)
- baseband ("vga", 0 to 62 dB in 2 dB steps)
The two TX gain controls are at these stages:
- RF (0 or 14 dB)
- IF (0 to 47 dB in 1 dB steps)
----
Why is the RF gain setting restricted to two values?
HackRF has two RF amplifiers close to the antenna port, one for TX and one for RX. These amplifiers have two settings: on or off. In the off state, the amps are completely bypassed. They nominally provide 14 dB of gain when on, but the actual amount of gain varies by frequency. In general, expect less gain at higher frequencies. For fine control of gain, use the IF and/or baseband gain options.
----
Why are the LEDs on HackRF different colours?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Each LED is a single color. There are no multi-colored LEDs on HackRF One. Adjacent LEDs are different colors in order to make them easier to distinguish from one another. The colors do not mean anything.
----
Where can I purchase HackRF?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HackRF is designed and manufactured by Great Scott Gadgets. We do not sell low volumes of HackRFs to people individually; instead we have agreements with specific resellers. Please see our reseller list on the Great Scott Gadgets website for availability: `http://greatscottgadgets.com/hackrf/ <http://greatscottgadgets.com/hackrf/>`__.
HackRF is open source hardware, so you can also build your own.
Things to consider for post-Jawbreaker hardware designs:
----
Antenna
^^^^^^^
The PCB antenna on Jawbreaker was included to facilitate beta testing. Future designs likely will not include a PCB antenna.
SMA connectors will be PCB edge-mounted.
----
Baseband
^^^^^^^^
The interfaces between the MAX2837 and MAX5864 have some signals inverted. Theoretically, that's fine if compensated for in software. However, I'm theorizing that RX/ADC DC offset compensation assumes that both channels have the same DC polarity. I've fixed the inversion in the CPLD. However, a PCB experiment should be conducted to see if the DC offset is reduced by un-inverting the RX Q channel connections to the MAX5864.
----
CPLD
^^^^
The CPLD could be removed, but some sort of multiplexer would be needed to meet the MAX5864 i/o requirements. Depending on the particular LPC43xx part used, it might be possible to use the System Control Unit (SCU) for this.
----
Clocking
^^^^^^^^
The clock signal from the Si5351C to the LPC43xx's GP_CLKIN pin may need different passives, but the documentation on that clock input is thin (acceptable peak-to-peak voltage anyone?).
An unpopulated footprint for a 32.768 kHz RTC crystal would be nice. Also break out RTC battery pins to an expansion header.
----
USB
^^^
Would support for host mode on the second USB PHY be useful somehow? This is only possible with a larger LPC43xx package that exposes the second PHY's ULPI signals. Unless, of course, a mere full-speed PHY is acceptable.
----
Power Management
^^^^^^^^^^^^^^^^
The MAX5864 appears to come up in "Tx" or "Rcvr" mode -- I have observed that the part will pass DA bus data to ID/QD without any SPI configuration. If we're worried about USB power and minimizing current consumption, it might be good to have this device on a power regulator with an ENABLE pin, or have a FET power switch. Yes, let's add a high side switch for the whole RF section.
----
Regulators
^^^^^^^^^^
U21 (the TPS62410) FB1 pin is connected on the far side of jumper P8 (VCC), which puts the jumper inside the feedback path. If the jumper trace is cut, the regulator may go nuts because the FB pin is floating.
----
Buttons
^^^^^^^
Add a reset button (for the LPC43xx). Maybe add a DFU button too.
----
Shielding
^^^^^^^^^
Maybe add a can around the RF section.
----
Footprints
^^^^^^^^^^
Tighten up holes for USB connector support legs to improve placement consistency. Make some of the QFN pads bigger (especially on the RF switches) for better soldering.
----
Shield Support
^^^^^^^^^^^^^^
If support for add-on shields is considered valuable, here are some tweaks I'd suggest:
Any reason P28 (SD) pin 12 isn't grounded or doing something useful? Same goes for P25 (LPC_ISP) pin 3 -- maybe make it VCC, the signaling voltage for the ISP interface? The SPIFI connector could also use a reference voltage (GND?).
I'd like to see an I2C bus exposed somewhere, and perhaps an I2S0_RX_SDA signal, so I don't have to steal it from the CPLD interface. The I2S0 will function in "four-wire mode" with only one more pin (RX_SDA), so why not?
Provide a way to inject a supply voltage into the board? Having diodes managing multiple voltage sources would be lossy, so a more expensive solution would be necessary on the Jawbreaker board, adding cost.
If an LPC43xx package with a higher pin-count is used, it would be stellar to expose the LCD interface and quadrature encoder peripheral pins.
The RTC would be handy for stand-alone use. This would require a crystal (32.768kHz) between RTCX1 and RTCX2, and exposing VBAT to a shield for battery backup (disconnecting it from VCC) or providing a coin cell footprint on the HackRF PCB.
Coalesce separate headers into fewer, larger banks of headers, to reduce the number of unique, small header receptacles required for mating? Reducing the header count will also increase the amount of board space around the perimeter of a shield for components and connectors.
One of the significant hardware changes in :ref:`HackRF Pro <hackrf_pro>` is the replacement of the CPLD with a FPGA. While the older CPLD primarily provided glue logic between the MCU and RF front end, the FPGA in HackRF Pro introduces more logic and DSP capability. This enables offloading digital signal processing tasks from the MCU.
FPGAs are highly flexible devices whose behavior is defined by *gateware*: hardware descriptions that configure the internal logic fabric. HackRF Pro gateware is written in `Amaranth HDL <https://amaranth-lang.org/>`__, a Python-based hardware description language.
The specific FPGA device used in HackRF Pro is the Lattice iCE40UP5K, which features
5280 LUT4s and 8 dedicated DSP (multiply-accumulate) blocks. We rely on the `open-source iCE40 FPGA toolchain <https://github.com/YosysHQ/icestorm>`__ to build the required bitstreams that are bundled in the firmware.
All gateware source code lives under `firmware/fpga/` in the HackRF repository. Top-level designs reside in `firmware/fpga/top/` and are the primary entry points for different operational modes.
By default, a standard gateware configuration is loaded at boot. However, the firmware can dynamically reconfigure the FPGA at runtime to switch between different gateware variants.
Standard gateware
~~~~~~~~~~~~~~~~~
The standard gateware is used by default when the firmware has not requested an alternative bitstream.
The standard gateware provides a balanced configuration optimized for general-purpose operation. It implements configurable digital signal processing paths for the reception and transmission paths, capable of (limited) frequency translation and supporting a wide range of sample rates.
* SPI control interface for register configuration
* Double data rate (DDR) interface to RF transceiver
* Interface to MCU (SGPIO)
Half-precision gateware
~~~~~~~~~~~~~~~~~~~~~~~
The half-precision gateware reduces sample width to 4 bits per I/Q component, enabling higher throughput within the constraints of the USB interface (up to 40 Msps).
This configuration is intended for applications where bandwidth is more critical than dynamic range, such as wideband spectrum monitoring.
* SPI control interface for register configuration
* Double data rate (DDR) interface to RF transceiver
* Interface to MCU (SGPIO)
Extended-precision gateware (RX and TX)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The extended-precision gateware increases internal signal processing precision and output sample width to improve signal quality. The main drawback is that the minimum decimation or interpolation factor is 16x. Due to increased logic requirements, this gateware is split in two top-level designs (RX and TX).
Samples are 16-bit I/Q, while the effective number of bits (ENOB) depends on the selected configuration and typically ranges between 9 and 11 bits.
The increased dynamic range of the output makes it particularly useful for weak and/or narrowband signals.
Before asking for help with HackRF, check to see if your question is listed in the :ref:`FAQ <faq>` or has already been answered in `GitHub issues <https://github.com/mossmann/hackrf/issues>`__ or the `mailing list archives <https://pairlist9.pair.net/pipermail/hackrf-dev/>`__.
Before asking for help with HackRF, check to see if your question is answered in this documentation, listed in the :ref:`Troubleshooting <troubleshooting>` page, or addressed in the `HackRF GitHub repository issues <https://github.com/greatscottgadgets/hackrf/issues>`__.
For assistance with HackRF use or development, please look at the `issues on the GitHub project <https://github.com/mossmann/hackrf/issues>`__. This is the preferred place to ask questions so that others may locate the answer to your question in the future.
For assistance with HackRF general use or development, please look at the `issues on the GitHub project <https://github.com/greatscottgadgets/hackrf/issues>`__. This is the preferred place to ask questions so that others may locate the answer to your question in the future.
Many users spend time in the `#hackrf channel on Discord <https://discord.gg/rsfMw3rsU8>`__.
We invite you to join our community discussions on `Discord <https://discord.gg/rsfMw3rsU8>`__. Note that while technical support requests are welcome here, we do not have support staff on duty at all times. Be sure to also submit an issue on GitHub if you’ve found a bug or if you want to ensure that your request will be tracked and not overlooked.
If you wish to see past discussions and questions about HackRF, you may also view the `mailing list archives <https://pairlist9.pair.net/pipermail/hackrf-dev/>`__.
We recommend getting started by watching the `Software Defined Radio with HackRF <https://greatscottgadgets.com/sdr/>`__ video series. This series will introduce you to HackRF One, software including GNU Radio, and teach you the fundamentals of Digital Signal Processing (DSP) needed to take full advantage of the power of Software Defined Radio (SDR). Additional helpful information follows.
.._try_pentoo:
Try Your HackRF with Pentoo Linux
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The easiest way to get started with your HackRF and ensure that it works is to use Pentoo, a Linux distribution with full support for HackRF and GNU Radio. Download the latest Pentoo .iso image from one of the mirrors listed at `http://pentoo.ch/downloads/ <https://pentoo.ch/downloads>`__. Then burn the .iso to a DVD or use `UNetbootin <http://unetbootin.sourceforge.net/>`__ to install the .iso on a USB flash drive. Boot your computer using the DVD or USB flash drive to run Pentoo. Do this natively, not in a virtual machine. (Unfortunately high speed USB operation invariably fails when people try to run HackRF from a virtual machine.)
Once Pentoo is running, you can immediately use it to :ref:`update firmware <updating_firmware>` on your HackRF or use other HackRF command line tools. For a walkthrough, watch `SDR with HackRF, Lesson 5: HackRF One <http://greatscottgadgets.com/sdr/5/>`__.
To verify that your HackRF is detected, type ``hackrf_info`` at the command line. It should produce a few lines of output including "Found HackRF board." The 3V3, 1V8, RF, and USB LEDs should all be illuminated and are various colors.
You can type ``startx`` at the command line to launch a desktop environment. Accept the "default config" in the first dialog box. The desktop environment is useful for GNU Radio Companion and other graphical applications but is not required for basic operations such as firmware updates.
Now you can use programs such as gnuradio-companion or gqrx to start experimenting with your HackRF. Try the Examples below. If you are new to GNU Radio, an excellent place to start is with the `SDR with HackRF <http://greatscottgadgets.com/sdr/>`__ video series or with the `GNU Radio guided tutorials <https://wiki.gnuradio.org/index.php/Tutorials>`__.
**Alternative: GNU Radio Live SDR Environment**
The `GNU Radio Live SDR Environment <https://wiki.gnuradio.org/index.php/GNU_Radio_Live_SDR_Environment>`__ is another nice bootable Linux .iso with support for HackRF and, of course, GNU Radio.
Software Setup
~~~~~~~~~~~~~~
As mentioned above, the best way to get started with HackRF is to use Pentoo Linux. Eventually you may want to install software to use HackRF with your favorite operating system.
If your package manager includes the most recent release of libhackrf and gr-osmosdr, then use it to install those packages in addition to GNU Radio. Otherwise, the recommended way to install these tools is by using `PyBOMBS <https://github.com/gnuradio/pybombs>`__.
See the :ref:`Operating System Tips <operating_system_tips>` page for information on setting up HackRF software on particular Operating Systems and Linux distributions.
If you have any trouble, make sure that things work when booted to Pentoo. This will allow you to easily determine if your problem is being caused by hardware or software, and it will give you a way to see how the software is supposed to function.
Examples
~~~~~~~~
A great way to get started with HackRF is the `SDR with HackRF <http://greatscottgadgets.com/sdr/>`__ video series. Additional examples follow:
Testing the HackRF
#. Plug in the HackRF
#. run the hackrf_info command ``$ hackrf_info``
If everything is OK, you should see something similar to the following:
..code-block:: sh
hackrf_info version: 2017.02.1
libhackrf version: 2017.02.1 (0.5)
Found HackRF
Index: 0
Serial number: 0000000000000000################
Board ID Number: 2 (HackRF One)
Firmware Version: 2017.02.1 (API:1.02)
Part ID Number: 0x######## 0x########
**FM Radio Example**
This Example was derived from the following works:
* `RTL-SDR FM radio receiver with GNU Radio Companion <http://www.instructables.com/id/RTL-SDR-FM-radio-receiver-with-GNU-Radio-Companion/>`__
* `How To Build an FM Receiver with the USRP in Less Than 10 Minutes <https://www.youtube.com/watch?v=KWeY2yqwVA0>`__
#. Download the FM Radio Receiver python file `here <https://raw.githubusercontent.com/rrobotics/hackrf-tests/master/fm_radio/fm_radio_rx.py>`__
#. Run the file ``$ python ./fm_radio_rx.py``
#. You can find the GNU Radio Companion source file `here <https://raw.githubusercontent.com/rrobotics/hackrf-tests/master/fm_radio/fm_radio_rx.grc>`__
The connectors on both HackRF Pro and HackRF One are SMA.
**Note:** SMA connectors and RP-SMA connectors are visually very similar. If you connect an RP-SMA antenna to a HackRF, it will seem to connect snugly but won't function at all because neither the male nor female side has a center pin. RP-SMA connectors are most common on 2.4 GHz antennas and are popular on Wi-Fi equipment. Adapters are available.
HackRF requires you to supply 500 mA at 5 V DC to your HackRF via the USB port. If your host computer has difficulty meeting this requirement, you may need to use a powered USB hub.
There is no specific minimum CPU requirement for the host computer when using a HackRF, but SDR is generally a CPU-intensive application. If you have a slower CPU, you may be unable to run certain SDR software or you may only be able to operate at lower sample rates.
Most users will want to stream data to or from the HackRF at high speeds. This requires that the host computer supports Hi-Speed USB. Some Hi-Speed USB hosts are better than others, and you may have multiple host controllers on your computer. If you have difficulty operating your HackRF at high sample rates (10 Msps to 20 Msps), try using a different USB port on your computer. If possible, arrange things so that the HackRF is the only device on the bus.
HackRF One is the current hardware platform for the HackRF project. It is a Software Defined Radio peripheral capable of transmission or reception of radio signals from 1 MHz to 6 GHz. Designed to enable test and development of modern and next generation radio technologies, HackRF One is an open source hardware platform that can be used as a USB peripheral or programmed for stand-alone operation.
.._hackrf_one:
..image:: ../images/HackRF-One-fd0-0009.jpeg
:alt:HackRF One
HackRF One was the first production hardware platform for the HackRF project. It is a Software Defined Radio peripheral capable of transmission or reception of radio signals from 1 MHz to 6 GHz. Designed to enable test and development of modern and next generation radio technologies, HackRF One is an open source hardware platform that can be used as a USB peripheral or programmed for stand-alone operation.
| `Where to buy <https://greatscottgadgets.com/hackrf/one/#purchasing>`_
Features
~~~~~~~~
@ -15,11 +21,44 @@ Features
* resolution: 8 bits
* interface: High Speed USB (with USB Micro-B connector)
* power supply: USB bus power
* software-controlled antenna port power (max 50 mA at 3.3 V)
* software-controlled antenna port power (max 50 mA at 3.0 to 3.3 V)
* SMA female antenna connector (50 ohms)
* SMA female clock input and output for synchronization
* convenient buttons for programming
* pin headers for expansion
* portable
* open source
Maximum input power
~~~~~~~~~~~~~~~~~~~
The maximum input power of HackRF One is -5 dBm. Exceeding -5 dBm can result in permanent damage!
In theory, HackRF One can safely accept up to 10 dBm with the front-end RX amplifier disabled. However, a simple software or user error could enable the amplifier, resulting in permanent damage. It is better to use an external attenuator than to risk damage.
Minimum detectable input power
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This isn't a question that can be answered for a general purpose SDR platform such as HackRF. Any answer would be very specific to a particular application. For example, an answerable question might be: What is the minimum power level in dBm of modulation M at frequency F that can be detected by HackRF One with software S under configuration C at a bit error rate of no more than E%? Changing any of those variables (M, F, S, C, or E) would change the answer to the question. Even a seemingly minor software update might result in a significantly different answer. To learn the exact answer for a specific application, you would have to measure it yourself.
HackRF's concrete specifications include operating frequency range, maximum sample rate, and dynamic range in bits. These specifications can be used to roughly determine the suitability of HackRF for a given application. Testing is required to finely measure performance in an application. Performance can typically be enhanced significantly by selecting an appropriate antenna, external amplifier, and/or external filter for the application.
Typical maximum transmit power
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HackRF One's maximum TX power varies by operating frequency:
* 1 MHz to 10 MHz: 5 dBm to 15 dBm, generally increasing as frequency increases (see this `blog post <https://greatscottgadgets.com/2015/05-15-hackrf-one-at-1-mhz/>`__)
* 10 MHz to 2170 MHz: 5 dBm to 15 dBm, generally decreasing as frequency increases
* 2170 MHz to 2740 MHz: 13 dBm to 15 dBm
* 2740 MHz to 4000 MHz: 0 dBm to 5 dBm, decreasing as frequency increases
* 4000 MHz to 6000 MHz: -10 dBm to 0 dBm, generally decreasing as frequency increases
Through most of the frequency range up to 4 GHz, the maximum TX power is between 0 and 10 dBm. The frequency range with best performance is 2170 MHz to 2740 MHz.
Overall, the output power is enough to perform over-the-air experiments at close range or to drive an external amplifier. If you connect an external amplifier, you should also use an external bandpass filter for your operating frequency.
Before you transmit, know your laws. HackRF One has not been tested for compliance with regulations governing transmission of radio signals. You are responsible for using your HackRF One legally.
HackRF Pro is the current hardware platform for the HackRF project. It is a Software Defined Radio peripheral capable of transmission or reception of radio signals from 100 kHz to 6 GHz. HackRF Pro is designed to be backwards compatible with software and hardware developed for use with
:ref:`HackRF One <hackrf_one>`,
whilst introducing many new features and improvements.
[-f freq_min:freq_max] # minimum and maximum frequencies in MHz
[-p antenna_enable] # Antenna port power, 1=Enable, 0=Disable
[-l gain_db] # RX LNA (IF) gain, 0-40dB, 8dB steps
[-g gain_db] # RX VGA (baseband) gain, 0-62dB, 2dB steps
[-n num_samples] # Number of samples per frequency, 8192-4294967296
[-w bin_width] # FFT bin width (frequency resolution) in Hz
[-1] # one shot mode
[-B] # binary output
[-I] # binary inverse FFT output
-r filename # output file
Output fields
~~~~~~~~~~~~~
``date, time, hz_low, hz_high, hz_bin_width, num_samples, dB, dB, ...``
Running ``hackrf_sweep -f 2400:2490`` gives the following example results:
.. list-table ::
:header-rows:1
:widths:1 1 1 1 1 1 1 1 1 1 1
* - Date
- Time
- Hz Low
- Hz High
- Hz bin width
- Num Samples
- dB
- dB
- dB
- dB
- dB
* - 2019-01-03
- 11:57:34.967805
- 2400000000
- 2405000000
- 1000000.00
- 20
- -64.72
- -63.36
- -60.91
- -61.74
- -58.58
* - 2019-01-03
- 11:57:34.967805
- 2410000000
- 2415000000
- 1000000.00
- 20
- -69.22
- -60.67
- -59.50
- -61.81
- -58.16
* - 2019-01-03
- 11:57:34.967805
- 2405000000
- 2410000000
- 1000000.00
- 20
- -61.19
- -70.14
- -60.10
- -57.91
- -61.97
* - 2019-01-03
- 11:57:34.967805
- 2415000000
- 2420000000
- 1000000.00
- 20
- -72.93
- -79.14
- -68.79
- -70.71
- -82.78
* - 2019-01-03
- 11:57:34.967805
- 2420000000
- 2425000000
- 1000000.00
- 20
- -67.57
- -61.61
- -57.29
- -61.90
- -70.19
* - 2019-01-03
- 11:57:34.967805
- 2430000000
- 2435000000
- 1000000.00
- 20
- -56.04
- -59.58
- -66.24
- -66.02
- -62.12
Two ranges of 5 MHz are analyzed at once from the same set of samples, so a single timestamp applies to the whole range.
The fifth column tells you the width in Hz (1 MHz in this case) of each frequency bin, which you can set with ``-w``. The sixth column is the number of samples analyzed to produce that row of data.
Each of the remaining columns shows the power detected in each of several frequency bins. In this case there are five bins, the first from 2400 to 2401 MHz, the second from 2401 to 2402 MHz, and so forth.
[-f freq_min:freq_max] # minimum and maximum frequencies in MHz
[-p antenna_enable] # Antenna port power, 1=Enable, 0=Disable
[-l gain_db] # RX LNA (IF) gain, 0-40dB, 8dB steps
[-g gain_db] # RX VGA (baseband) gain, 0-62dB, 2dB steps
[-w bin_width] # FFT bin width (frequency resolution) in Hz, 2445-5000000
[-1] # one shot mode
[-N num_sweeps] # Number of sweeps to perform
[-B] # binary output
[-I] # binary inverse FFT output
-r filename # output file
Output fields
^^^^^^^^^^^^^
``date, time, hz_low, hz_high, hz_bin_width, num_samples, dB, dB, ...``
Running ``hackrf_sweep -f 2400:2490`` gives the following example results:
.. list-table ::
:header-rows:1
:widths:1 1 1 1 1 1 1 1 1 1 1
* - Date
- Time
- Hz Low
- Hz High
- Hz bin width
- Num Samples
- dB
- dB
- dB
- dB
- dB
* - 2019-01-03
- 11:57:34.967805
- 2400000000
- 2405000000
- 1000000.00
- 20
- -64.72
- -63.36
- -60.91
- -61.74
- -58.58
* - 2019-01-03
- 11:57:34.967805
- 2410000000
- 2415000000
- 1000000.00
- 20
- -69.22
- -60.67
- -59.50
- -61.81
- -58.16
* - 2019-01-03
- 11:57:34.967805
- 2405000000
- 2410000000
- 1000000.00
- 20
- -61.19
- -70.14
- -60.10
- -57.91
- -61.97
* - 2019-01-03
- 11:57:34.967805
- 2415000000
- 2420000000
- 1000000.00
- 20
- -72.93
- -79.14
- -68.79
- -70.71
- -82.78
* - 2019-01-03
- 11:57:34.967805
- 2420000000
- 2425000000
- 1000000.00
- 20
- -67.57
- -61.61
- -57.29
- -61.90
- -70.19
* - 2019-01-03
- 11:57:34.967805
- 2430000000
- 2435000000
- 1000000.00
- 20
- -56.04
- -59.58
- -66.24
- -66.02
- -62.12
Each sweep across the entire specified frequency range is given a single time stamp.
The fifth column tells you the width in Hz (1 MHz in this case) of each frequency bin, which you can set with ``-w``. The sixth column is the number of samples analyzed to produce that row of data.
Each of the remaining columns shows the power detected in each of several frequency bins. In this case there are five bins, the first from 2400 to 2401 MHz, the second from 2401 to 2402 MHz, and so forth.
The RESET button resets the microcontroller. This is a reboot that should result in a USB re-enumeration.
This information is applicable to both HackRF Pro and HackRF One.
The DFU button invokes a USB DFU bootloader located in the microcontroller's ROM. This bootloader makes it possible to unbrick a HackRF One with damaged firmware because the ROM cannot be overwritten.
The **RESET button** resets the microcontroller. This is a reboot that should result in a USB re-enumeration.
To invoke DFU mode: Press and hold the DFU button. While holding the DFU button, reset the HackRF One either by pressing and releasing the RESET button or by powering on the HackRF One. Release the DFU button.
The **DFU button** invokes a USB DFU bootloader located in the microcontroller's ROM. This bootloader makes it possible to unbrick a HackRF with damaged firmware because the ROM cannot be overwritten.
The DFU button only invokes the bootloader during reset. This means that it can be used for other functions by custom firmware.
The DFU button only invokes the bootloader during reset. This means that it can be used for other functions by custom firmware.
To invoke DFU mode: Press and hold the DFU button. While holding the DFU button, reset the HackRF either by pressing and releasing the RESET button or by powering on the HackRF. Release the DFU button.
* There's also a register map document that Mike received directly from Maxim. Send an email to Mike or submit a support request to Maxim if you want a copy.
* `AN619: Manually Generating an Si5351 Register Map <http://www.silabs.com/Support%20Documents/TechnicalDocs/AN619.pdf>`__
* `Datasheet <http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf>`__ - this document is a mess of typos, and best used in conjunction with AN619, which has its own typos. Usually, you can reconcile what's true by comparison and a bit of thought.
* `Datasheet <http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf>`__ - see AN619 for the complete register map.
* `Other Documentation <http://www.silabs.com/products/clocksoscillators/clock-generators-and-buffers/Pages/clock+vcxo.aspx>`__ - includes application notes, user guides, and white papers.
HackRF transmit and receive operations can be synchronized with another HackRF or with other external equipment by using the trigger input and output. Triggering provides time synchronization with error of less than one sample period.
HackRF Pro has two configurable SMA ports, P1 and P2, which can be set up to provide both clock synchronization and triggering.
HackRF One has CLKIN and CLKOUT ports for clock synchronization, but hardware triggering requires opening the case to access the P28 header.
Clock Synchronization
~~~~~~~~~~~~~~~~~~~~~
When triggering one HackRF from another, it is often desirable to first ensure that the two devices share a common frequency reference. This has an added benefit of grounding the HackRFs to each other, eliminating one of the wires required for triggering. See :ref:`External Clock Interface <external_clock_interface>` for instructions.
Either HackRF may serve as the clock source for the other regardless of which is providing the trigger output.
Usage
~~~~~
Use ``hackrf_info`` to discover the serial numbers of both HackRFs. Using the serial number of the HackRF to be triggered, use ``hackrf_transfer -H`` to set up a triggered operation. For example:
The command will print "Waiting for trigger..." until a trigger signal is detected on the device's trigger input.
In another terminal, use the serial number of the triggering HackRF One to initiate an operation to take place at the same time as the triggered operation. For example:
Note that no special argument is required to activate the trigger output.
Both ``hackrf_transfer`` commands will start sampling RF signals at the same time, accurate to less than one sample period.
Additional Devices
~~~~~~~~~~~~~~~~~~
Multiple HackRFs may be triggered by a single HackRF. Ensure that all the devices share a common ground and then connect one device's trigger output to the trigger inputs of the other devices (with jumpers connected via a breadboard, for example).
Equipment other than a HackRF may be connected to a HackRF's trigger input or output. The trigger signal is a 3.3 V pulse that triggers on the rising edge.
HackRF One Triggering Requirements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To connect two HackRF Ones for triggering you will need:
* a male-to-male jumper wire for 0.1" pin headers
* an SMA cable for clock synchronization or a second jumper wire
.._open_your_hackrf_one:
Open Your HackRF One
~~~~~~~~~~~~~~~~~~~~
If your HackRF Ones are not bare boards, you will need to open up their cases to access the pin headers on the HackRF Ones. Each HackRF One case has small plastic clips holding it together. These clips may be damaged when the case is opened, but typically the case can still be used after such damage. Please follow the instructions in `this video <https://www.youtube.com/watch?v=zuXJtpTSEJM>`__ by `Jared Boone <https://twitter.com/sharebrained>`__ to open your HackRF One cases.
Identify the Trigger Pins
~~~~~~~~~~~~~~~~~~~~~~~~~
HackRF One has four normally-populated pin headers, three of which are arranged in a 'C' shape. On the circuit board these are marked P28, P22, and P20. P28 is the header nearest to the center of the board. Locate pins 15 (trigger output) and 16 (trigger input) on header P28.
..image:: ../images/trigger-pins.png
:align: center
Connect the Trigger Output to the Trigger Input
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
First ensure that the two devices share a common ground. This may be accomplished by connecting one's CLKIN to the other's CLKOUT as recommended above. Alternatively, connect a jumper wire from P28 pin 2 on one HackRF One to P28 pin 2 on the other HackRF One.
Next use a jumper wire to connect P28 pin 15 (trigger output) on one HackRF One to P28 pin 16 (trigger input) on the other HackRF One.
References
~~~~~~~~~~
HackRF's trigger mechanism was contributed by the authors of `Synchronisation of Low-Cost Open Source SDRs for Navigation Applications <http://spcomnav.uab.es/docs/conferences/Bartolucci_NAVITEC_2016.pdf>`__ which provides details about the implementation and background.
HackRF software includes HackRF Tools and libhackrf. HackRF Tools are the commandline utilities that let you interact with your HackRF. libhackrf is a low level library that enables software on your computer to operate with HackRF.
Install Using Package Managers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -58,17 +62,23 @@ OS X (10.5+): MacPorts
Windows: Binaries
+++++++++++++++++
Binaries are provided as part of the PothosSDR project, they can be downloaded `here <http://downloads.myriadrf.org/builds/PothosSDR/?C=M;O=D>`__.
Windows users can use `radioconda <https://github.com/ryanvolz/radioconda>`__ to get the required binaries installed.
Alternatively, binaries are available as build artifacts under the 'Actions'-tab on github `here <https://github.com/greatscottgadgets/hackrf/actions>`__ (GitHub Login needed).
-----------
Installing From Source
~~~~~~~~~~~~~~~~~~~~~~
Linux / OS X / \*BSD: Building HackRF Software From Source
Acquire the source for the HackRF tools from either a `release archive <https://github.com/mossmann/hackrf/releases>`__ or git: ``git clone https://github.com/mossmann/hackrf.git``
Acquire the source for the HackRF tools from either a `release archive <https://github.com/greatscottgadgets/hackrf/releases>`__ or git: ``git clone https://github.com/greatscottgadgets/hackrf.git``
Once you have the source downloaded, the host tools can be built as follows:
@ -84,60 +94,32 @@ Once you have the source downloaded, the host tools can be built as follows:
If you have HackRF hardware, you may need to :ref:`update the firmware <updating_firmware>` to match the host tools versions.
Windows: Prerequisites for Cygwin, MinGW, or Visual Studio
* cmake-2.8.12.1 or later from http://www.cmake.org/cmake/resources/software.html
* libusbx-1.0.18 or later from http://sourceforge.net/projects/libusbx/files/latest/download?source=files
* fftw-3.3.5 or later from http://www.fftw.org/install/windows.html
* Install Windows driver for HackRF hardware or use Zadig see http://sourceforge.net/projects/libwdi/files/zadig
* If you want to use Zadig select HackRF USB device and just install/replace it with WinUSB driver.
Note for Windows build: You shall always execute hackrf-tools from Windows command shell and not from Cygwin or MinGW shell because on Cygwin/MinGW Ctrl+C is not managed correctly and especially for hackrf_transfer the Ctrl+C (abort) will not stop correctly and will corrupt the file.
Install `Visual Studio Community <https://visualstudio.microsoft.com/vs/community/>`__ (2015 or later) and `CMake <https://cmake.org/>`__ (at least version 3.21.4).
CMake will produce a solution file named ``HackRF.sln`` and a series of project files which can be built with msbuild as follows: ``c:\hackrf\host\build> msbuild HackRF.sln``
set PKG_CONFIG=C:\vcpkg\installed\x64-windows\tools\pkgconf\pkgconf.exe
set PKG_CONFIG_PATH=C:\vcpkg\installed\x64-windows\lib\pkgconfig
set CMAKE_TOOLCHAIN_FILE=C:\vcpkg\scripts\buildsystems\vcpkg.cmake
cmake -B host\build host
cmake --build host\build
CMake will generate a ``HackRF.sln`` project file which you can open in Visual Studio for editing and development.
HackRF Jawbreaker is the beta test hardware platform for the HackRF project.
..image:: ../images/jawbreaker.JPG
:alt:Jawbreaker
(Jawbreaker picture provided by `fd0 <https://github.com/fd0>`__ with Creative Commons License CC BY 3.0.)
Features
~~~~~~~~
@ -20,53 +26,48 @@ Features
Set your Jawbreaker Free!
~~~~~~~~~~~~~~~~~~~~~~~~~
Hardware Documentation
~~~~~~~~~~~~~~~~~~~~~~
Jawbreaker has an SMA antenna connector but also includes a built-in PCB antenna intended for operation near 900 MHz. It isn't a very good antenna. Seriously. A paperclip stuck into the SMA connector would probably be better. You can free your Jawbreaker to operate with better antennas by cutting the PCB trace to the PCB antenna with a knife. This enables the SMA connector to be used without interference from the PCB antenna.
A video that demonstrates the antenna modification is on YouTube: `HackRF Antenna Modification <http://youtu.be/B2gwgNoqMxI>`__
The trace to be cut is between the two solder pads inside a box labeled R44 in the `assembly diagram <https://github.com/mossmann/hackrf/blob/master/doc/hardware/jawbreaker-assembly.pdf?raw=true>`__. There is an arrow pointing to it printed on the board.
Due to a manufacturing error, there is solder on R44. R44 may appear as a single solder blob. If you have a soldering iron and solder wick/braid, use a soldering iron and fine solder wick to remove as much solder as you can from the two R44 pads. Then, use a pen knife to gently cut away the area between the two R44 pads. Make multiple, gentle cuts, instead of one or two forceful cuts. As you cut, you'll break through the black solder mask, then the copper trace between the pads, and stop when you reach fiberglass. Remove the copper trace completely, so just the two R44 pads remain. Use a multimeter or continuity tester to verify that the two R44 pads are no longer connected.
If you don't have a soldering iron, you can cut through the copper trace and the solder blob all at once, but it requires a bit more effort.
The only reason not to do this is if you want to try Jawbreaker but don't have any antenna with an SMA connector (or adapter).
If you want to restore the PCB antenna for some reason, you can install a 10 nF capacitor or a 0 ohm resistor on the R44 pads or you may be able to simply create a solder bridge.
SMA, not RP-SMA
~~~~~~~~~~~~~~~
Some connectors that appear to be SMA are actually RP-SMA. If you connect an RP-SMA antenna to Jawbreaker, it will seem to connect snugly but won't function at all because neither the male nor female side has a center pin. RP-SMA connectors are most common on 2.4 GHz antennas and are popular on Wi-Fi equipment.
Schematic diagram, assembly diagram, and bill of materials can be found at `https://github.com/greatscottgadgets/hackrf/tree/master/hardware <https://github.com/greatscottgadgets/hackrf/tree/master/hardware>`__
Transmit Power
~~~~~~~~~~~~~~
The maximum TX power varies by operating frequency:
The maximum TX power for Jawbreaker varies by operating frequency:
* 30 MHz to 100 MHz: 5 dBm to 15 dBm, increasing as frequency decreases
* 100 MHz to 2300 MHz: 0 dBm to 10 dBm, increasing as frequency decreases
* 2300 MHz to 2700 MHz: 10 dBm to 15 dBm
* 2170 MHz to 2740 MHz: 10 dBm to 15 dBm
* 2700 MHz to 4000 MHz: -5 dBm to 5 dBm, increasing as frequency decreases
* 4000 MHz to 6000 MHz: -15 dBm to 0 dBm, increasing as frequency decreases
Overall, the output power is enough to perform over-the-air experiments at close range or to drive an external amplifier. If you connect an external amplifier, you should also use an external bandpass filter for your operating frequency.
Before you transmit, know your laws. Jawbreaker has not been tested for compliance with regulations governing transmission of radio signals. You are responsible for using your Jawbreaker legally.
Before you transmit, know the laws for the region you are transmitting in. Jawbreaker has not been tested for compliance with regulations governing transmission of radio signals. You are responsible for using your Jawbreaker legally.
Hardware Documentation
~~~~~~~~~~~~~~~~~~~~~~
SMA, not RP-SMA
~~~~~~~~~~~~~~~
Schematic diagram, assembly diagram,and bill of materials can be found at `https://github.com/mossmann/hackrf/tree/master/doc/hardware <https://github.com/mossmann/hackrf/tree/master/doc/hardware>`__
The connectors on Jawbreaker are SMA, not RP-SMA. SMA connectors and RP-SMA connectors look extremely similar, the difference is that SMA connectors have a center pin. RP-SMA connectors are common on 2.4 GHz antennas and are popular on Wi-Fi equipment. If you connect an RP-SMA antenna to Jawbreaker, it will seem to connect snugly but won't function at all because neither the male nor female side has a center pin.
Recommended PCB and Antenna Changes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jawbreaker has an SMA antenna connector and it also includes a built-in PCB antenna intended for operation near 900 MHz. The built-in PCB antenna isn't a very good antenna. A paperclip stuck into the SMA connector of the Jawbreaker is likely to be better. We recommend that you free your Jawbreaker to operate with better antennas by cutting the PCB trace to the PCB antenna with a knife. This enables the SMA connector to be used without interference from the PCB antenna.
The trace to be cut is between the two solder pads inside a box labeled R44. There is an arrow printed on the board that points to the R44 box. A video that demonstrates the antenna modification is on YouTube: `HackRF Antenna Modification <http://youtu.be/B2gwgNoqMxI>`__.
Due to a manufacturing error, there is solder on the pads in box R44 that you should try to remove before you cut the trace. R44 may appear as a single solder blob. If you have a soldering iron and solder wick/braid, use a soldering iron and fine solder wick to remove as much solder as you can from the two R44 pads. Then, use a pen knife to gently cut away the area between the two R44 pads. Make multiple, gentle cuts, instead of one or two forceful cuts. As you cut, you'll break through the black solder mask, then the copper trace between the pads, and stop when you reach fiberglass. Remove the copper trace completely, so just the two R44 pads remain. Use a multimeter or continuity tester to verify that the two R44 pads are no longer connected. If you don't have a soldering iron, you can cut through the copper trace and the solder blob all at once, but it requires a bit more effort. The only reason not to cut the PCB trace is if you want to try Jawbreaker but don't have any antenna with an SMA connector (or adapter).
If you want to restore the PCB antenna for some reason, you can install a 10 nF capacitor or a 0 ohm resistor on the R44 pads or you may be able to simply create a solder bridge.
@ -536,14 +537,14 @@ Cut P17 short (trace) to enable external clock input. If short is cut, a jumper
More
^^^^
Additional headers are available. See the `board files <https://github.com/mossmann/hackrf/tree/master/hardware/jawbreaker>`__ for additional details.
Additional headers are available. See the `board files <https://github.com/greatscottgadgets/hackrf/tree/master/hardware/jawbreaker>`__ for additional details.
Differences between Jawbreaker and HackRF One
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jawbreaker was the beta platform that preceded HackRF One. HackRF One incorporates the following changes and enhancements:
Jawbreaker was the beta platform that preceded HackRF One. HackRF One incorporates the following changes and enhancements (at minimum):
* Antenna port: No modification is necessary to use the SMA antenna port on HackRF One.
* PCB antenna: Removed.
@ -556,5 +557,5 @@ Jawbreaker was the beta platform that preceded HackRF One. HackRF One incorporat
* Real-Time Clock: An RTC is installed on HackRF One.
* LPC4320 microcontroller: Jawbreaker had an LPC4330.
* RF shield footprint: An optional shield may be installed over HackRF One's RF section.
* Antenna port power: HackRF One can supply up to 50 mA at 3.3 V DC on the antenna port for compatibility with powered antennas and other low power amplifiers.
* Antenna port power: HackRF One can supply up to 50 mA at 3.0 to 3.3 V DC on the antenna port for compatibility with powered antennas and other low power amplifiers.
* Enhanced frequency range: The RF performance of HackRF One is better than Jawbreaker, particularly at the high and low ends of the operating frequency range. HackRF One can operate at 1 MHz or even lower.
When HackRF Pro is plugged in to a USB host, four LEDs should turn on: MCU, FPGA, RF, and USB. The MCU LED indicates that the primary internal power supply is working properly and that firmware is running. The FPGA and RF LEDs indicate that firmware has switched on additional internal power supplies. The USB LED indicates that the HackRF Pro is communicating with the host over USB.
HackRF One
~~~~~~~~~~
When HackRF One is plugged in to a USB host, four LEDs should turn on: 3V3, 1V8, RF, and USB. The 3V3 LED indicates that the primary internal power supply is working properly. The 1V8 and RF LEDs indicate that firmware is running and has switched on additional internal power supplies. The USB LED indicates that the HackRF One is communicating with the host over USB.
Both versions
~~~~~~~~~~~~~
The RX and TX LEDs indicate that a receive or transmit operation is currently in progress.
Each LED is a single color. There are no multi-colored LEDs on either HackRF One or HackRF Pro. Adjacent LEDs are different colors in order to make them easier to distinguish from one another. The colors do not mean anything.
Board draws approximately 24mA from +3V3 when power is applied. This seems a bit high, but may be expected if not all parts are capable of low-power mode, or aren't configured for low power at power-on. I need to review the schematic and datasheets and see what can be done.
When I put my finger on the MAX2837, current consumption goes up. This suggests there may be floating nodes in that region of the circuit.
Si5351 I2C
~~~~~~~~~~
Attached crystal is 25MHz. For now, I'm assuming 10pF "internal load capacitance" is good enough to get the crystal oscillating. The crystal datasheet should be reviewed and measurements made...
Be sure to reference Silicon Labs application note 619 (AN619). The datasheet is a terrible mess (typos and lack of some details). AN619 appears to be less of a mess, on the whole. And as a bonus, AN619 has PDF bookmarks for each register.
Connections
^^^^^^^^^^^
* Bus Pirate GND to P7 pin 1
* Bus Pirate +3V3 to P7 pin 2 (through multimeter set to 200mA range)
* Bus Pirate CLK to P7 pin 3
* Bus Pirate MOSI to P7 pin 5
Bus Pirate I2C Initialization
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
..code-block:: sh
# set mode
m
# I2C mode
4
# ~100kHz speed
3
# power supplies ON
W
# macro 1: 7-bit address search
(1)
Searching I2C address space. Found devices at:
0xC0(0x60 W) 0xC1(0x60 R)
I2C A0 address configuration pin (not available on QFN20 package) is apparently forced to "0".
# Set to 10pF (until I find out what loading the crystal/PCB likes best)
[0xC0 183 0xE4]
# Register 187: Fanout Enable
# Turn on XO fanout only.
[0xC0 187 0x40]
# Register 15: PLL Input Source
# CLKIN_DIV=0 (Divide by 1)
# PLLB_SRC=0 (XTAL input)
# PLLA_SRC=0 (XTAL input)
[0xC0 15 0x00]
# Registers 16 through 23: CLKx Control
# CLK0:
# CLK0_PDN=0 (powered up)
# MS0_INT=1 (integer mode)
# MS0_SRC=0 (PLLA as source for MultiSynth 0)
# CLK0_INV=0 (not inverted)
# CLK0_SRC=0 (XTAL as clock source for CLK0)
# CLK0_IDRV=3 (8mA)
[0xC0 16 0x43 0x80 0x80 0x80 0x80 0x80 0x80 0x80]
# Enable CLK0 output only.
[0xC0 3 0xFE]
Clocking Scheme (Work In Progress)
++++++++++++++++++++++++++++++++++
From AN619: If Fxtal=25MHz, Fvco = Fxtal * (a + (b / c)). If we want Fvco = 800MHz, a = 32, b = 0, c = don't care.
..code-block:: sh
MSNA_P1[17:0] = 128 * a + floor(128 * b / c) - 512
= 128 * a + floor(0) - 512
= 128 * 32 + 0 - 512
= 3584 = 0xE00
MSNA_P1[17:16] (register 28) = 0x00
MSNA_P1[15: 8] (register 29) = 0x0E
MSNA_P1[ 7: 0] (register 30) = 0x00
MSNA_P2[19:0] = 128 * b - c * floor(128 * b / c)
= 128 * 0 - 0 * floor(128 * 0 / X)
= 0
MSNA_P3[19:0] = 0
MultiSynth0 should output 40MHz (800MHz VCO divided by 20):
..code-block:: sh
a = 20, b = 0, c = X
MS0_P1[17: 0] = 128 * a + floor(128 * b / c) - 512
= 2048 = 0x800
MS0_P1[17:16] (register 44) = 0x00
MS0_P1[15: 8] (register 45) = 0x08
MS0_P1[ 7: 0] (register 46) = 0x00
MS0_P2[19:0] = 0
MS0_P3[19:0] = 0
MultiSynth1 should output 20MHz (800MHz VCO divided by 40) or some smaller integer fraction of the VCO:
..code-block:: sh
a = 40, b = 0, c = X
MS1_P1[17: 0] = 128 * a + floor(128 * b / c) - 512
= 4608 = 0x1200
MS1_P1[17:16] (register 52) = 0x00
MS1_P1[15: 8] (register 53) = 0x12
MS1_P1[ 7: 0] (register 54) = 0x00
MS1_P2[19:0] = 0
MS1_P3[19:0] = 0
Initialization:
..code-block:: sh
# Disable all CLKx outputs.
[0xC0 3 0xFF]
# Turn off OEB pin control for all CLKx
[0xC0 9 0xFF]
# Power down all CLKx
[0xC0 16 0x80 0x80 0x80 0x80 0x80 0x80 0x80 0x80]
# Register 183: Crystal Internal Load Capacitance
# Reads as 0xE4 on power-up
# Set to 10pF (until I find out what loading the crystal/PCB likes best)
[0xC0 183 0xE4]
# Register 187: Fanout Enable
# Turn on XO and MultiSynth fanout only.
[0xC0 187 0x50]
# Register 15: PLL Input Source
# CLKIN_DIV=0 (Divide by 1)
# PLLB_SRC=0 (XTAL input)
# PLLA_SRC=0 (XTAL input)
[0xC0 15 0x00]
# MultiSynth NA (PLL1)
[0xC0 26 0x00 0x00 0x00 0x0E 0x00 0x00 0x00 0x00]
# MultiSynth NB (PLL2)
...
# MultiSynth 0
[0xC0 42 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00]
# MultiSynth 1
[0xC0 50 0x00 0x00 0x00 0x12 0x00 0x00 0x00 0x00]
# Registers 16 through 23: CLKx Control
# CLK0:
# CLK0_PDN=0 (powered up)
# MS0_INT=1 (integer mode)
# MS0_SRC=0 (PLLA as source for MultiSynth 0)
# CLK0_INV=0 (not inverted)
# CLK0_SRC=3 (MS0 as input source)
# CLK0_IDRV=3 (8mA)
# CLK1:
# CLK1_PDN=0 (powered up)
# MS1_INT=1 (integer mode)
# MS1_SRC=0 (PLLA as source for MultiSynth 1)
# CLK1_INV=0 (not inverted)
# CLK1_SRC=3 (MS1 as input source)
# CLK1_IDRV=3 (8mA)
[0xC0 16 0x4F 0x4F 0x80 0x80 0x80 0x80 0x80 0x80]
# Enable CLK0 output only.
[0xC0 3 0xFC]
Si5351 output phase relationships
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Tested CLK4 and CLK5 (integer division only):
With CLK4 set to MS4 and CLK5 set to MS5, even with both multisynths configured identically, there was no consistent phase between the two. Once started, the clocks maintained relative phase with each other, but when stopped and restarted the initial phase offset was unpredictable.
With CLK4 and CLK5 both set to MS4, the phase of both outputs was identical when no output (R) divider was selected. When an output divider was selected on both MS4 and MS5, the relative phase became predictable only within the constraints of the divider (e.g. with R=2 the relative phase was always either 0 or half a cycle, with R=4 the relative phase was always either 0, a quarter, a half, or three quarters of a cycle). With R=1 on MS4 and R=2 on MS5, the two outputs were consistently in phase with each other. The output (R) dividers supposedly tied to the multisynths are actually tied to the outputs.
This document describes the functions, data structures and constants that libHackRF provides. It should be used as a reference for using libHackRF and the HackRF hardware.
If you are writing a generic SDR application, i.e. not tied to the HackRF hardware, we strongly recommend that you use either gr-osmosdr or SoapySDR to provide support for the broadest possible range of software defined radio hardware.
For example usage of many of these functions, see the `hackrf_transfer <https://github.com/mossmann/hackrf/blob/master/host/hackrf-tools/src/hackrf_transfer.c>`__ tool.
Setup, Initialization and Shutdown
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HackRF Init
^^^^^^^^^^^
Initialize libHackRF, including global libUSB context to support multiple HackRF hardware devices.
**Syntax:**``int hackrf_init()``
**Returns:** A value from the hackrf_error constants listed below.
**Returns:** A pointer to a hackrf_device_list_t struct, a list of HackRF devices attached to the system. The contents of the hackrf_device_list_t struct are decribed in the data structures section below.
HackRF Device List Open
^^^^^^^^^^^^^^^^^^^^^^^
Open and acquire a handle on a device from the hackrf_device_list_t struct.
**Syntax:**``int hackrf_device_list_open(hackrf_device_list_t* list, int idx, hackrf_device** device)``
**Params:**
``list`` - A pointer to a hackrf_device_list_t returned by ``hackrf_device_list()``
``idx`` - The list index of the HackRF device to open
``device`` - Output location for hackrf_device pointer. Only valid when return value is HACKRF_SUCCESS.
**Returns:** A value from the hackrf_error constants listed below.
**Returns:** A value from the hackrf_error constants listed below.
HackRF Exit
^^^^^^^^^^^
Cleanly shutdown libHackRF and the underlying USB context. This does not stop in progress transfers or close the HackRF hardware. ``hackrf_close()`` should be called before this to cleanly close the connection to the hardware.
**Syntax:**``int hackrf_exit()``
**Returns:** A value from the hackrf_error constants listed below.
``typedef int (*hackrf_sample_block_cb_fn)(hackrf_transfer* transfer)``
Enumerations
~~~~~~~~~~~~
Supported board versions
^^^^^^^^^^^^^^^^^^^^^^^^
These values identify the board type of the connected hardware. This value can be used as an indicator of capabilities, such as frequency range, bandwidth or antenna port power.
.. list-table ::
:header-rows:1
:widths:1 1 1 1
* - Board
- Frequency range
- Bandwidth
- Antenna port power
* - HackRF One
- 1MHz - 6Ghz
- 20MHz
- Yes
* - Jawbreaker
- 10MHz - 6GHz
- 20MHz
- No
* - Rad1o
- 50MHz - 4GHz
- 20MHz
- Unknown
* - Jellybean
- N/A
- 20MHz
- No
Most boards will identify as HackRF One, Jawbreaker or Rad1o. Jellybean was a pre-production revision of HackRF. No hardware device should intentionally report itself with an invalid board ID.
.. code-block :: sh
enum hackrf_board_id {
BOARD_ID_JELLYBEAN = 0,
BOARD_ID_JAWBREAKER = 1,
BOARD_ID_HACKRF_ONE = 2,
BOARD_ID_RAD1O = 3,
BOARD_ID_INVALID = 0xFF,
};
USB Product IDs
^^^^^^^^^^^^^^^
.. code-block :: sh
enum hackrf_usb_board_id {
USB_BOARD_ID_JAWBREAKER = 0x604B,
USB_BOARD_ID_HACKRF_ONE = 0x6089,
USB_BOARD_ID_RAD1O = 0xCC15,
USB_BOARD_ID_INVALID = 0xFFFF,
};
Transceiver Mode
^^^^^^^^^^^^^^^^
HackRF can operate in three main transceiver modes, Receive, Transmit and Signal Source. There is also a CPLD update mode which is used to write firmware images to the CPLD.
The transceiver mode can be changed with ``hackrf_set_transceiver_mode`` with the value parameter set to one of the following:
..code-block:: sh
enum transceiver_mode_t {
TRANSCEIVER_MODE_OFF = 0,
TRANSCEIVER_MODE_RX = 1,
TRANSCEIVER_MODE_TX = 2,
TRANSCEIVER_MODE_SS = 3,
TRANSCEIVER_MODE_CPLD_UPDATE = 4
};
Receive mode (TRANSCEIVER_MODE_RX) is used to stream samples from the radio to the host system. Use ``hackrf_set_freq`` to set the center frequency of receiver and ``hackrf_set_sample_rate`` to set the sample rate (effective bandwidth).
Transmit mode (TRANSCEIVER_MODE_TX) is used to stream samples from the host to the radio.
See `hackrf_transfer <https://github.com/mossmann/hackrf/blob/master/host/hackrf-tools/src/hackrf_transfer.c>`__ for an example of setting transmit and receive mode and transferring data over USB.
Hardware revisions exist mainly to deal with changes in component availability. Each revision of a product meets the same performance specifications that are measured in the factory.
HackRF Pro
~~~~~~~~~~
The initial production revision of HackRF Pro is r1.2.1.
HackRF One
~~~~~~~~~~
HackRF One r1–r4
~~~~~~~~~~~~~~~~
^^^^^^^^^^^^^^^^
The first revision of HackRF One shipped by Great Scott Gadgets starting in 2014 was labeled r1. Subsequent manufacturing runs incremented the revision number up to r4 without modification to the hardware design. Manufacturing years: 2014–2020
HackRF One r5
~~~~~~~~~~~~~
^^^^^^^^^^^^^
This experimental revision has not been manufactured.
HackRF One r6
~~~~~~~~~~~~~
^^^^^^^^^^^^^
SKY13350 RF switches were replaced by SKY13453 due to component availability. Although the SKY13453 uses simplified control logic, it did not require a firmware modification. Manufacturing year: 2020
SKY13350 RF switches were replaced by SKY13453. Although the SKY13453 uses simplified control logic, it did not require a firmware modification. Hardware revision detection pin straps were added. Manufacturing year: 2020
HackRF One r7
~~~~~~~~~~~~~
^^^^^^^^^^^^^
SKY13453 RF switches were reverted to SKY13350 due to component availability. USB VBUS detection resistor values were changed to better protect the LPC4320. Manufacturing year: 2021
SKY13453 RF switches were reverted to SKY13350. USB VBUS detection resistor values were updated. Manufacturing year: 2021
HackRF One r8
~~~~~~~~~~~~~
^^^^^^^^^^^^^
SKY13350 RF switches were replaced by SKY13453 due to component availability. Manufacturing years: 2021–2022
SKY13350 RF switches were replaced by SKY13453. Manufacturing years: 2021–2022
HackRF One r9
^^^^^^^^^^^^^
MAX2837 was replaced by MAX2839. Si5351C was replaced by Si5351A with additional clock distribution. A series diode was added to the antenna port power supply. Manufacturing year: 2023
HackRF One r10
^^^^^^^^^^^^^^
This revision is based on r8, reverting most of the changes made in r9. A series diode was added to the antenna port power supply. Manufacturing year: 2024
Hardware Revision Identification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
HackRF Ones manufactured by Great Scott Gadgets have the revision number printed on the PCB top silkscreen layer near the MAX5864 (U18).
Starting with HackRF One r6, hardware revisions are detected by firmware and reported by ``hackrf_info``.
Some files were not shown because too many files have changed in this diff
Show more