Upgrading from HackRF One to bladeRF x40
From Nuand:
- bladeRF x40, $420 (not including any recent discounts)
- bladeRF case, $20
- 2x 2.4 GHz Omidirectional SMA Antennas, $20
versus the competing product from Great Scott Gadgets:
The bladeRF is in many ways superior, or at least more costly, how does it compare to the trusty HackRF One?
Assembly & Accessories
The bladeRF doesn’t come with a case, but a clear polycarbonate case can be purchased separately, or you could make your own. The HackRF in contrast has an injection molded plastic enclosure:
Neither include an antenna, although the bladeRF ships with two SMA cables for some reason; I haven’t had a use for them yet, instead preferring to connect the antennas directly to the bladeRF. HackRF recommends the ANT500, which can be adjusted in length to optimize for 75 MHz — 1 GHz, and only one antenna is needed since, being half-duplexed, the HackRF transmits and receives on the same antenna port. Nuand sells a pair of 2.4 GHz antennas, one each for the transmit and receive ports.
Both use the popular SMA connector port. I’ll use the ANT500 and 2.4 GHz antennas in this review.
bladeRF ships with a USB 3.0 SuperSpeed cable with gold-plated connectors, USB-A to USB-B. HackRF with a micro USB 2 cable. I only have USB 2 on my host computer, but am looking forward to taking advantage of the higher speed of USB 3 (5 Gbit/s SuperSpeed > 480 Mbit/s for USB 2.0 High-Speed) for greater sampling rates and/or bandwidth in the possibly distant future as I upgrade my computer systems. Many new computers are already including USB 3 as standard, so its nice to know the bladeRF can use it over USB 2.
(Interestingly, Ettus has developed USRPs interfacing to the host computer using Gigabit Ethernet (USRP N210/N200), to overcome the speed limitations of USB 2, although they now have USRP B210/B200 using 3.0)
The bladeRF supports several other accessories, but I didn’t buy any of them: Amplifier, GPIO expansion board (requires a different case, if you want a case), power supply, and a LF/MF/HF/VHF transverter. The power supply could prove useful for standalone operation, but is not necessary since the bladeRF can be powered over the USB port.
Initial setup
Inserted the bladeRF x40 into the bladeRF case, screwed in the four Phillips screws, attached the 2.4 GHz antennas, plugged in the USB cable into the bladeRF and my computer. Fired up gqrx I had been using with HackRF, and:
UHD Error:
bladerf_get_timestamp() returned -1 — An unexpected failure occurred
FATAL: getHardwareTime() -1 — An unexpected failure occurred
“D1” lights up on the board, but LED1–3 stay dark.
Updated to the latest fx3 firmware image (v1.9.0 at this time):
bladeRF-cli -f bladeRF_fw_latest.img
…but what was missing was loading the fpga (used v0.5.0):
bladeRF-cli --load-fpga hostedx40-latest.rbf
Loading fpga…
[INFO @ version_compat.c:85] Firmware version (v1.9.0) is newer than entries in libbladeRF’s compatibility table. Please update libbladeRF if problems arise.
[INFO @ version_compat.c:116] FPGA version (v0.5.0) is newer than entries in libbladeRF’s compatibility table. Please update libbladeRF if problems arise.
Done.
After performing this required step, LED1–3 lights up, and then can run gqrx. LED2 continuously blinks when I’m running gqrx, indicating the bladeRF device is open.
FPGA autoloading
bladeRF-cli --load-fpga only loads the FPGA bitstream, but it does not persist after restarting the bladeRF. This can be useful since other FPGA images can be loaded, such the hardware ADS-B decoder (adsbx40.rbf), intended to offer better performance than more-heavily-software-based solutions e.g. dump1090-mutability with an RTL-SDR.
But for general usage, the hostedx40-latest.rbf image can be written to flash for autoloading on boot: bladeRF-cli --flash-fpga hostedx40-latest.rbf
Rebooting the bladeRF by removing and re-inserting the USB cable confirms the FPGA is loaded successfully, the LEDs light up & gqrx runs without error.
At this point it is worth noting the difference between the two bladeRF models, the x40 ($420) and x115 ($650): the size of the Cyclone 4 FPGA in kLE. Nuand says the larger FPGA “provides additional room for hardware accelerators and signal processing chains including FFTs, Turbo Decoders, transmit modulators/filters, and receive acquisition correlators for burst modems”, but in just starting out I’m fine with the 40 kLE FPGA so far.
Calibration
Having previously calibrated the HackRF, gqrx Input Controls > Freq. correction was set to -7.7 ppm. This is of course no longer accurate for the bladeRF, so I reset it back to 0.0 ppm. It’ll have to be changed back manually in gqrx if I switch between devices (TODO: possible automate this? Cubic?)
bladeRF is calibrated at the factory to 20ppb, but to confirm, lets try kalibrate-bladeRF. This is yet another fork of the venerable kalibrate, among kalibrate-hackrf and kalibrate-rtl, but for bladeRF.
But first, bladeRF-cli -i can be used to view the factory calibration:
VCTCXO DAC calibration: 0x9040
Attempting to compile kalibrate-bladeRF on OS X failed, opened a pull request fixing the complex number assignment compile error, ported over from kalibrate-hackrf. From the tutorial on using kalibrate-bladeRF:
./src/kal -s GSM850 -m2
Using the Nuand 2.4 GHz antennas: no channels found.
Try with ANT500 antenna for RX on bladeRF, no difference.
Unclear why I’ve not have much success using kalibrate to find and calibrate against GSM channels. Fortunately there is an LTE-Cell-Scanner tool for calibrating against LTE frequencies, I can readily receive in my area, and @JiaoXianjun as extended it to support bladeRF. @cgommel added PPM output, I merged the changes and others into my branch at rxseger/LTE-Cell-Scanner.
LTE-Cell-Scanner’s hardware support is configured at build time, to enable both bladeRF and HackRF support:
mkdir build
cd build
cmake ../ -DUSE_BLADERF=1 -DUSE_HACKRF=1
make
(TODO: homebrew formula to enable both bladeRF and HackRF and use rxseger/LTE-Cell-Scanner?)
Then scanning for LTE cells:
./src/CellSearch — freq-start 715e6 — freq-end 768e6
results in:
DPX CID A fc freq-offset RXPWR C nRB P PR CrystalCorrection ppm
FDD 459 2 739M -458h -12.1 N 50 N one 0.999999380493036 -0.62
FDD 237 2 751M -475h -12.1 N 50 N one 0.999999367581029 -0.632
Within less than <1 ppm, not bad. Some SDR software does not even allow specifying error corrections less than a part per million, so I’ll consider this device well-calibrated out of the box. No further adjustment needed.
Frequency Range
bladeRF’s 300 MHz to 3.8 GHz is a smaller range than HackRF 0.1 MHz to 6 GHz. It encompasses all of the UHF range, but no VHF or lower, including FM or AM (mediumwave) stations, TV channels 2–13, some (but not all) public safety two-way radio, etc.
In my ~/.config/gqrx/bookmarks.csv, I had 113 bookmarks below 300 MHz, from playing around with HackRF and tagging various interesting signals, and only 50 above.
The tradeoff is better quality in the smaller range. A transverter can be used to transceive to lower frequencies, but I didn’t test with one. The XB-200 LF/MF/HF/VHF transverter’s extended range of 60 kHz — 300 MHz is quite appealing, but it was out of stock at the time of this writing. The transverter is also not compatible with the regular case, without modification. So I still enjoy the convenience of HackRF’s wide range for surveying a large spectrum.
Below UHF with other devices
For comparison, consider the HackRF. In the presentation SDR Tricks with the hackrf, Michael Ossmann at Defcon Wireless village 2014, the design goal was 100 MHz to 6 GHz, but after components the lower limit was extended to 30 MHz, and the after beta release down to 10 MHz. Michael Ossmann shows the HackRF can receive at even lower frequencies, but with less power, even a 125 kHz RFID loop can be read at close range:
Mario on Hackaday, March 25, 2016 reports:
“have recently tried the HackRF One on the AM broadcast band (530–1710 KHz) using a 43 foot vertical antenna and am very pleased with the reception. Have not ventured below that, such as 285–325 KHz where DGPS beacons are. A good antenna is the key to good reception.”
Wikipedia’s radio bands by frequency shows what’s below even further:
- 300–30 MHz (VHF): FM, TV, ATC, ham, land/marine, weather radio
- 30–3 MHz (HF): shortwave, CB, RFID, skywave, marine, radiotelephony
- 3000–300 kHz (MF): AM radio broadcasts, amateur radio
- 300–30 kHz (LF): navigation, clock time, RFID, amateur radio, DGPS
- 30–3 kHz (VLF): navigation, time, submarine, geophysics
- 3000–300 Hz (ULF): submarine communication, earth mines
- 300–30 Hz (SLF): submarines
- 30–3 Hz (ELF): submarines
bladeRF’s XB-200 transverter would cover VHF/HF/MF/LF.
The fundamental minimum frequency, or equivalently the maximum wavelength, is only limited by the size of the universe — about 0.7 attohertz for width of observable universe — but practical minimum is limited by antenna size required, about a quarter of the wavelength. Large antennas could be used for submarines, but not in your pocket or on your desk. Nonetheless, kilohertz range is home to many interesting amateur radio bands.
The Ettus research USRP supports DC — 6 GHz, but costs thousands of $. Other upconverters for other devices, besides the XB-200:
- AirSpy Spyverter ($60): 1 kHz to 60 MHz
- NooElec Ham It Up ($50): “down to 100kHz and below”
The SDRplay RSP ($149) directly supports down to 100 kHz. The low-end RTL-SDR can be enhanced with a direct sampling modification, with varying results.
Low-frequency SDR could be an interesting area of future exploration, but it will have to wait for another time. For now, without expansion boards, the bladeRF x40 is suitable for Ultra High Frequency.
Receiving ATSC digital television with bladeRF
Follow-up to Receiving ATSC digital television with an SDR, where I used a HackRF One. bladeRF can receive the UHF channels (>14), although not VHF without a transverter, but there are more interesting UHF channels than VHF channels in my area so this is not a major downside.
Rerun the same file_atsc_rx2.py.. nothing–or rather, no video output. Log:
UHD Warning: Setting DC offset compensation is not possible on this device.
UHD Warning: Setting DC offset is not possible on this device.
UHD Warning: Setting IQ balance is not possible on this device.
[INFO @ bladerf.c:648] Clamping bandwidth to 1500000Hz
1.5 MHz is not nearly enough to receive ATSC (6 MHz).
Appears to be coming from this code:
} else if (bandwidth > BLADERF_BANDWIDTH_MAX) {
bandwidth = BLADERF_BANDWIDTH_MAX;
log_info(“Clamping bandwidth to %dHz\n”, bandwidth);
but why would BLADERF_BANDWIDTH_MAX be 1.5 MHz, when up to 124 MHz bandwidth is achievable (by rapidly tuning)? The actual _MAX is 28 MHz, the minimum is 1.5 MHz. Channel 36 is 602 MHz — 608 MHz, centered at 605 MHz, but without enough bandwidth the edges are not visible:
Turns out the ‘Ch0: Bandwidth (Hz)’ variable in the osmocom Source was not set, 0 defaulting to 1.5e6. Changed it to 8e6 (8 MHz) and the full signal is visible, including the 602.309441 MHz pilot tone:
At this point, the MPEG stream can be decoded, but with significant errors:
With the HackRF, I found reasonable results with the osmocom Source set to RF gain 14, IF gain 16, and BB gain 20. bladeRF gains control lnagain, rxvga1, rxvga2. Experimenting with the values, an RF gain of 30, IF 20, and BB 20 gives a visible picture:
- file_atsc_rx2.grc for bladeRF
At this point I run into the same problem described in Receiving ATSC digital television with an SDR: choppy video, demux and atsc_fs_checker PN63 errors. Since it occurs with both the HackRF and bladeRF, presumably this is not a problem with the device itself, but my ANT500 starter antenna. Haven’t got around to it yet, but using an amplified antenna intended for HDTV should give better results.
Final Thoughts
The HackRF One remains my favorite for casual signal exploration with its large 0.1 MHz–6 GHz frequency range, and the RTL-SDR family cannot be beat for a low-cost introduction to SDR. Nonetheless:
bladeRF offers a narrower frequency range of 300 MHz — 3.8 GHz without the transverter expansion board, but with a 12-bit ADC instead of 8-bit, native 28 MHz instanteous bandwidth instead of 20 MHz or 2–4 MHz, full-duplex instead of half-duplex or no transmit, USB 3 instead of USB 2, a 40 kLE FPGA, optional standalone power, and GPIO expansion.
This blog post as a first look at the bladeRF didn’t really go into its advantages, but I look forward to taking advantage of them in the future with other projects, references: Projects, Papers, and Blogs, OpenBTS.
Update 2016/07/07: Using the amplified HDTV antenna, attached to the bladeRF’s SMA port using a DHT Electronics RF coaxial coax cable assembly SMA male to F female 6' adapter, can now receive fairly smooth video, sometimes!
But it is very sensitive to CPU usage, so much as switching to another application causes overruns (000..) in the receiver, as the decoder can’t keep up. This software-based ATSC receiver is not much of a practical replacement for watching TV compared to a hardware-based decoder, in a TV set (or a USB ATSC TV stick, also hardware-based), but it’s neat to know it is possible. VHF ham radio and other signals can also be received clearly through this HDTV antenna connected to the bladeRF, so I’ll probably be keeping this setup for some time.
