This is one of those posts that I should have compiled and put up a long time ago, but never really got around to. Right now, I probably shouldn’t be blogging (since there are more pressing things to attend to), but I suppose getting something done is better than nothing :). Anyway, lets get straight to the subject matter at hand.
I’ve always been interested in radios, and while I am a licensed (foundation) radio amateur, I’ve never really felt the need to transmit. Most of the fun and awe is in listening. My first radios were “conventional”, albeit synthesized super-heterodyne receivers which would still be considered “new” to some. For HF work, I still have my Icom IC-R75, and I still remember spending time whirling the tuning wheel around to try and catch some signals. But a change was “in the works”.
In 2010, I made the decision to spend AU$1200 on a Winradio Excalibur G31DDC software defined radio. The main reason I opted for that (as opposed to a USRP) was that it was a well-regarded “consumer-friendly” receiver which had great sensitivity, inbuilt MW filtering and attenuators, and a generous 2Mhz instantaneous bandwidth which was considered great (especially compared to the 1.4Mhz of the rival Perseus of the time). It didn’t have the band preselectors of the Perseus, but the 16-bit dynamic range was probably good enough to make up for it. It was also Australian, from a company with a reputation in making radio gear.
It very quickly became my favourite HF receiver, because I could see signals “anywhere” within the 2Mhz “window”. I could record the IF signal and play it back and catch signals while I was asleep, and I could parallel demodulate a pair of signals within the window – one on the left, and one on the right with no trouble. I made it a practice to go to more quiet places to snag weaker signals on recording to hard drive, for later analysis which helped me get a few of the QSL cards on this site.
However, it wasn’t without problems – as it was considered “early” in the SDR days, such bandwidth processing was CPU intensive and CPUs of the day weren’t particularly pleased with it (e.g. T2300E in my laptop). When I moved it to an AMD CPU, there were spurious crashes which I worked with Winradio to resolve (which turned out to be an AMD specific errata of sorts). At that time, I felt the 2Mhz was absolutely the limit – there wasn’t any way that wider bandwidths would be accommodated on such hardware due to the processing overhead. After all, the 2Mhz IF recording was actually 2.5MSPS * 16 bits * 2 channels = 10MB/s, at a time when hard drives topped out at 2Tb and USB 2.0 was all we had.
That was an expensive introduction, as merely years later in 2013, RTL-SDR became the “vogue”. I worked a little with Balint Seeber troubleshooting the ExtIO plugin for RTL dongles and FC-tuner compatibility, but it was exciting to see that the same ~2Mhz of bandwidth could be had for VHF/UHF frequencies for merely US$11, albeit at 8-bit resolution with limited immunity to out-of-band signals. But what had really changed? Computer processing got much faster, and the RTL-SDR wasn’t causing computers to break a sweat at all!
RTL-SDR users such as myself quickly ran into the limitations of the dongle, and many of us were looking for better alternatives. From that spawned the likes of HackRF, Airspy SDR and Nuand BladeRF. The alternatives that came before the RTL-SDR such as the Elad FDM-S2 were also receivers I had considered. Ultimately, I settled on an investment into the Nuand BladeRF, mainly because of my greed for bandwidth and resolution.
BladeRF HackRF Airspy Frequency Range 300Mhz - 3.8Ghz 1Mhz - 6Ghz 24Mhz - 1800Mhz 60kHz - 3.8Ghz (with XB-200) Resolution 12-bits 8-bits 12-bits Sample Rate 40MSPS 20MSPS 10MSPS (Up to 80MSPS with custom firmware) Bandwidth 28Mhz Not Specified 10Mhz (9Mhz image-free) Transmitter 6dBm (typ.) -15 to 15dBm N/A Connectivity USB 3.0 USB 2.0 USB 2.0
Because I had an interest in HF, I had to order it with the XB-200 transverter board to get coverage for that band. While I didn’t intend to do any transmitting, it was good that it had the option to do so, and the USB 3.0 connection would definitely help given the wide bandwidth and high sample rates. I suppose the biggest disadvantage of the Nuand BladeRF was that it was a “development” board without a case at the time I ordered it, and it was a little more expensive totaling around USD$700 (in 2014). While not apples-to-apples, in just four years, we’re getting a 14-fold increase in bandwidth (at a slight cost to resolution) and a much wider range of frequency coverage for a 70% of the price.
I begged them to make a case which accommodates the XB-200, but they didn’t do that and instead advised that if I wanted one, 3D printing one would be the best option at the time. As a result of this (and the fact I was very busy), it didn’t see much action. But then, just this year, my dreams came true and Nuand were selling a suitable case. It cost me a hefty AU$80 to get it due to the expensive shipping, but at last, I don’t have to fear breaking the board every time I use it.
While my G31DDC still sees some use even to this day, I’m wondering whether it would be better to use the Nuand BladeRF for monitoring HF. With 28Mhz of bandwidth, we can practically record every receivable shortwave transmission on the air simultaneously.
The hardware arrived in two cardboard fold-open boxes branded with the Nuand logo.
A logo on the side reminds us, proudly, that the unit was Made in the USA.
Included was two SMA jumpers used to connect the XB-200 board to the BladeRFx40. A USB 3.0 lead was also included, and an information sheet which basically tells you that the unit was tested at manufacturing and you’re pretty much on your own as the product is sold as-is. Not the most consumer friendly statement, but that shouldn’t put you off …
As soon as you pick up one of the PCBs, you can feel how well it’s made. A quality ENIG finish, matte-black PCB with silkscreen and very precise component population makes it look really professional.
The USB communications is handled by a Cypress EZ-USB FX3 SuperSpeed USB controller. This communicates with the “brains” – an Altera Cyclone IV EP4CE40F23C8N 40k LE FPGA. A larger version of the FPGA with 115k LE is also available for those who want to make standalone applications using the FPGA.
The RF end is handled by a Lime Microsystems LMS6002 fully-integrated multi-standard RF transceiver intended for use in LTE picocells and WiMAX stations. It’s always nice to see these “highly integrated” mixed-signal ICs being used outside of their intended purpose, as they are very versatile and flexible, although output power is not one of their strong points. There is an optional amplifier module available though.
As this is an earlier BladeRF, it has a microUSB-B connector on the input which feels a little fragile, but the latest seem to be shipping with full sized USB-B connectors which would be more robust. The power is normally supplied by the USB connector, although it can be jumper-switched to use the barrel jack if desired (e.g. better power, filtering, or standalone operation). Nice to see the jacks are branded, and the power section seems to have some filtering inductors and MLCCs.
RF input and output is via standard SMA connectors soldered to the edge of the board on both sides for a rock-solid connection.
External timing reference is via an MCX connector on the side, however whether external clocking has been implemented in the drivers is not known to me. Prospective buyers need to remember that this is still a “device in development” to some degree.
The underside has some large surface mount tantalum capacitors, and many vias which can be used as test points, as well as designated test point pads.
The XB-200 board is filled with goodness – filtering inductors everywhere, as well as a number of SMA connectors for external off-board receive and transmit filters. On board is an upconverter, which moves the whole 60khz to 300Mhz band into the receive range of the BladeRF. It is auto-detected by the library and used if available, so aside from snapping it on, it really doesn’t need much configuration at all.
There’s not much on the underside of the board, except for a few stacking connectors.
The XB-200 when stacked on top of the BladeRFx40 looks a little strange as it’s a bit shorter than the base board, but it does fit relatively securely. You do end up with a plethora of SMA plugs which need to be “plugged in”, so it’s a little intimidating.
After the long wait, I managed to get the case and throw the lot in. It’s a simple plastic case with cut-outs for all ports including the GPIO pins which feel a little exposed, but it’s much better than trying to use the board bare.
Because the case halves have to be fitted together, the connectors are given “slots” so the case can slide together without interference. It’s not as neat and protective as if it was met with a matching protrusion on the base, but that would probably complicate manufacturing somewhat.
The rear is a solid unbroken plastic baseplate with four screws to secure it together.
There is also a dual-cut-out on the power/USB connections which suggests that the more recent boards use a full-size USB-B connector. Overall, the case does make me a lot more comfortable about using the board and avoiding random damage from scraps of wire etc. However, it’s a bit sad that the case is just “basic”. If it was a shielded metal case, it would probably help the unit perform even better, but then again, I might just be asking for too much.
Once everything is in its case, then a basic set-up might look like this – with the filters “jumpered out”, the RXIF connected to RX, the TXIF connected to TX, the ADC/DAC ports left open, and antennas attached to the RXANT and TXANT ports.
However, if you’re only interested in receive, you can probably omit the TX path connections entirely and instead chuck in SMA terminators, as I later did.
Modifications for Early XB-200s
As it turned out, if you were a lucky customer with an early XB-200, there was a flaw on the circuit board which caused degraded performance. The fix was to remove R62 and R63 on the board.
These were very small surface mount resistors, right next to R61 and a raised transformer T2. Desoldering these was somewhat precarious, but I managed just by carefully adding solder until there was enough to bridge both sides and lift the solder and resistor off in a go. Take care with the angle of the soldering iron to make sure you don’t accidentally knock off or melt the transformer.
SDRSharp Setup and Caveats
So maybe you’re interested in using it to monitor and listen to some signals, and you’d rather use something you’re familiar with, namely SDRSharp. Well, the good news is that it’s definitely possible. The bad news is that it’s not as straightforward as you might want, and some functions just don’t work.
To set it up, you’ll need to:
- Download and run the latest Windows Installer from Nuand’s Support Page. You can install it with the default options (i.e. Cypress USB driver, x64 binaries in PATH on 64-bit machines). You should also update the firmware to the latest version to ensure the best performance.
- Download the latest version of SDRSharp (1450) from the Airspy webpage and unzip it into a folder.
- Download sdrsharp-bladerf from jmichelp’s GitHub as a ZIP archive.
- Unzip SDRSharp.BladeRF.dll into the same folder as your SDRSharp installation.
- Unzip all the files in LibBladeRF into the same folder as your SDRSharp installation.
- Copy all files from C:\Program Files\bladeRF\x86 to the same folder as the SDRSharp installation and agree to overwrite. This forces the libbladerf executables to be updated to the latest version that you just installed and avoids the situation where no SDR receivers are detected.
- Copy C:\Program Files\bladeRF\hostedx40.rbf (or hostedx115.rbf if you have a BladeRFx115) into the same folder as your SDRSharp installation. This allows for easy accessing the firmware file in case the SDR is connected in a cold state and you don’t want to start BladeRF-CLI just to download the firmware to the FPGA.
- Modify FrontEnds.xml and add a line of:
<add key="BladeRF" value="SDRSharp.BladeRF.BladeRFIO,SDRSharp.BladeRF" />
before the </frontendPlugins> declaration.
At this point, that should complete the installation, and you should be able to start SDRSharp and configure your BladeRF SDR. Make sure you select the right path the firmware to allow the plugin to load the firmware onto a cold BladeRF. The dialog should look something like the screenshot to the left. If so, then congratulations – you’re not far from enjoying some radio.
But before you get too excited, here’s a list of the caveats that I’ve discovered so far:
- The Correct IQ feature of SDR# does not work and appears to be a bug in the “glue” driver.
- Changing the sample rate on the fly isn’t supported properly, and will result in unspecified behaviour until the source is stopped and restarted.
- The filter bank selection has no effect whatsoever, and will remain selecting the external filter bank (i.e. RXFILT/RXFILT-ANT). This limits the flexibility somewhat.
- The audio output appears to bypass some of the SDR# processing chains, and thus plugins which operate on the audio stream will not work. This includes things like Aux VFOs, Audio Noise Reduction, Audio Processors, CTCSS/DCS decoders, etc.
Some of this is rather unfortunate, because it means that there is some level of “imaging” on the spectrogram, and the onboard filters on the XB-200 just aren’t usable. Not having parallel multiple-channel reception with Aux VFOs is also a little bit disappointing.
Also disappointing was SDR#’s behaviour under high sample rates (>30MSPS) where performance limitations became more apparent. The inbuilt recorder is practically useless too, so for long term monitoring, I recommend getting plugins from rtl-sdr.ru.
The specific plugins I recommend are Baseband Recorder and File Player. The Baseband recorder will need you to modify the Plugins.xml, whereas File Player needs an edit to FrontEnds.xml.
With the configuration set to record RIFF64 style WAV files, it’s possible to record very large WAV files and then play it back later using File Player and “jump around” back and forth. The advantage is that File Player input also works fine with the audio path, so multiple VFOs is supported on playback, as is DCS/CTCSS decoders, audio processors, etc.
You probably shouldn’t go crazy with plugins, but if you do install them all, you’ll find that your sidebar might not render properly, and it’s filled like below …
In my general use, the bandwidth was extremely impressive and satisfying to have, although the noise floor was a bit unusually shaped at times due to (what appeared to be) out of band signals causing increased noise floor (as I was using a jumper wire for the RX path filter). Some frequencies, especially in the HF range showed some hash noise patterns, and when it was connected to a laptop, showed some cyclic noise bursts which seemed related to the laptop’s internal power supply conversion circuitry. It implies that there may be a conducted/radiated noise susceptibility, so maybe a quiet linear external power supply connected to the input might help.
The Need to Filter
Many RTL-SDR users and even basic SDR users have “gotten away” without filtering, however, operating in that way is a compromise that is part of the reason why SDR’s still don’t have quite the dynamic range of conventional receivers which are architected to “focus” on the one channel.
In the case of HF monitoring, I had little choice. The problem was that the local MW (AM) broadcast band was very powerful compared to the HF signals I was looking for. If I didn’t have a filter, then I would have to set my gains such that the strongest MW stations didn’t exceed 0dB, otherwise it would “clip” and create distortion across the received bandwidth. As the signals from my local radio stations were 40-50dB stronger than the average SW broadcast (Australia doesn’t get strong SW signals), that means if I were to set the strongest MW as 0dB, then the stations would be -40 to -50dB. With 12-bits, you only have 72dB of dynamic range to play with, so your resulting SNR would be 22 – 32dB, which would make those stations intelligible (12dB necessary) but not great to listen to. It would also mean that a station just 10dB – 20dB weaker would be practically lost. If the incoming radio signal is “filtered” to attenuate just the local AM by 20dB (or more), then the SNR could improve correspondingly as we don’t have to set our gains so low to avoid clipping.
In my case, I ended up purchasing a random second hand filter from Israel, as new filters are expensive and hard to come by. It cost me AU$75, and is an AEL 2-32Mhz band-pass filter originally used for microwave IF filtering.
It was pretty much anonymous when received.
It had a beat-up BNC on one side (perfect for my antenna) and an SMA connector to go into a short jumper lead to the BladeRF.
Inside, it’s made with a bunch of toroidal inductors, and greencap capacitors with a lot of silicone on some form of strip-line PCB with the cover acting as a shielding cage. There’s evidence of water ingress at one stage, but the filter works as described. With a range of 2-32Mhz, that’s perfect for keeping the shortwave and HF and rejecting the broadcast band.
As I’m only using it for receive, it seems the 500V rating of the capacitors is very generous. This would probably have been on an IF output with a reasonable drive power I’m guessing.
With this sort of set-up, I was able to make a 30 hour recording of most of the shortwave band as received in Sydney. The total size was 10TB, as I chose some compromise sample rates (e.g. 24MSPS * 16 bits * 2 channels = 96MB/s). The AM band can be seen to almost be completely annihilated and instead the QRM in the 4-6Mhz band which never stops dominates the strong signals. The day night cycle can be seen where the recording starts at night, with the 8/10/13Mhz bands visible, which peter out during the day for higher bands in the 13/16/21Mhz range with infrequent signals, and then return at night. That’s the reason why I ended up building that RAID Box although you really do need a decent level of throughput to maintain recordings for long periods. Gigabit Ethernet is well and truly insufficient, especially if shared.
The BladeRF is a relatively inexpensive SDR when you consider its specifications and capabilities. However, because it’s more of a “development” platform which isn’t geared towards “ease of use” or any one particular purpose, you can’t expect the same level of performance as professional receivers.
In my use, I experienced some difficulties with set-up which took some time to work around and some issues with conducted/radiated interference coming out of the computer causing slightly “dirty” output. There was also some slight images from what appears to be gain imbalance/phase offset, without any ability to correct it easily within SDRSharp because of some bugs it would seem. Other bugs with the integration also mean that the XB-200 filter selection doesn’t seem to work (resulting in the external filter path being used at all times), and with the limited bandwidth filtering, out-of-band signals have a potential to affect the receive performance.
However, if you’re willing to work around the caveats, it’s not hard to surveil the whole HF band with pretty “ordinary” consumer grade equipment now. What seemed impossible and impractical in 2010 is a reality in 2016, at a lower price! Consider me amazed.
These limitations probably won’t affect you if you use different software as well – e.g. SDR Console v2, which is pretty much plug and play. I’ve also tried it a while back, but the recording and playback on SDR Console v2 wasn’t very stable for me when we were doing >24 hour records. It is a lot speedier than SDRSharp and it has much better FM RDS and MPX service detection abilities, so it’s worth trying as well.