Poll: Are You Interested in Roadtesting a USB Software-Defined Radio Platform?

The SDR knowledge well is both deep and wide. A far cry from the SDR USB dongle I dabbled with a few years ago. Bring it on.

On initial discovery I found this RoadTest poll of interest. The picture of the product is deceiving.  According to manufactures docs, The USRP B205mini-i delivers a 1×1 SDR/cognitive radio in the size of a business card. It is just a little guy!

GL Gough Lui makes reference to antennas in his post and that piqued my interest. To conduct a review of this product the reviewer will need some resources. I suggest if the product becomes a candidate for RoadTest the following list of materials be included, if not reviewers need to be aware you may have some purchases to make if you are not an SDR dabbler already.

• Enclosure
• External power supply
• Antenna(s)

I was unable to locates schematics for the B205mini-i, the links produced a B200 only, even though they indicated the mini device. I'm wondering if the product is fairly new? I also found little information on antenna requirements. I had hoped there was a kit page that provided suggestions. I had no luck on the antenna side. Maybe if someone else takes up the baton for research on this product they can post their findings.

Here are some links I recorded on the product. I suggest, if researchers find other links they can post them to assist possible reviewers.

• https://www.ettus.com/all-products/USRP-B205mini-i/
• https://kb.ettus.com/B200/B210/B200mini/B205mini_Getting_Started_Guides
• https://kb.ettus.com/B200/B210/B200mini/B205mini

Product is not new, it is similar to the B200. You can get dirty cheap monopoles to plug into it.

I have a LimeSDR, which is a similar but slightly different product, so can maybe help answer some generic questions.

Most of the high-end SDR boards are not designed for directly connecting an antenna for working the airwaves, although it is possible to do that, and people have done that successfully. They are missing bits that a normal receiver/transceiver would have.

The input/output is 50 ohm impedance, so any potential antenna would ideally need to be matched to that. However, depending on what's the aim, it may also need any of these:

Low noise amplifier (rx), power amplifier (tx), filters, attenuator, even lightning protection. Without these, it may not even perform as well as a non-SDR receiver. For example, if there is a high power transmitter nearby, that will overload the SDR unless there's a filter at a minimum. Any typical decent receiver will have that, even if it's a non-SDR receiver.

(EDIT: The long connector at the side is possibly (I've not checked the documentation) for that purpose, i.e. to control all the extra bits that may be required when integrated into a system like a radio receiver say).

This board is a module, but not necessarily for direct connection to the antenna, without all the bits in-between.

Also, for some bands (e.g. HF if it was desired, although this is very overkill for that) frequency translation would be needed.

There are several topologies for SDR, one popular one a couple of decades ago (since high-speed high resolution ADCs were not available) was to always have a mixer stage preceding the SDR portion, i.e. the SDR would accept the intermediate frequency (IF) (in other words, an SDR radio would look like a non-SDR radio apart from everything from IF stage onward). That's become less necessary with these high-end SDRs, but might still be required.

The very high bandwidth makes this useful for test equipment too (e.g. simulate new radio protocols, act as BLE sniffers, real-time spectral analysis etc). It makes an extremely powerful signal generator for RF too, since anything can be created/modulated.

Even for non-radio use, SDR can be an extremely useful/universal tool. From my perspective the LimeSDR is let down by poor software though : ( And although GNU radio works with Lime theoretically, it's quite tough to get it working always.. LimeSDR also has a simpler software toolset, but that was missing features (might be more feature-rich nowadays).

Forgot to mention one important detail. To receive any antenna could be plugged and worse that can happen is that you will get poor performance. When it comes to transmitting though, you just can't plug anything to it.

The most supported SDR appear to be the RTL-SDR. What kind of software do you miss for the limesdr?

There's an alternative (kind of) for GNU Radio, called Pothos, which is simpler to use, but was lacking functionality, but I might give it a go again. Like GNU radio, it allows graphic blocks to be joined to create like a processing pipeline for samples. The RTL-SDR is more ready-made receiver software I think, it may be supported. Incidentally, it would be awesome if GNU Radio or some alternative supported a feature of compiling of the processing pipeline into something the SDR devices could directly support at a low level (say if there was a Zync chip, or DSP of some sort) and upload that to the board, to offload the processing.. or a palette of building blocks that were specific to the SDR, so that if those building blocks are used then that portion is offloaded.

Software support has always been a sore point for many SDRs. Some nice apps are built only for certain SDRs (RTL-SDR gained popularity because it was cheap, but its 8-bit resolution + front ends made it a bit nasty), while other apps have support for "plugins" - e.g. ExtIO DLLs under Windows, they may not always be stable or reliable (e.g. occasional dropped samples, crashes). GNU Radio may sometimes need to be built from sources to support some SDRs (which means a lot of downloading and waiting around for things to build). While I did consider LimeSDR, the main reason I still don't have one is (as you guessed) the software situation.

Even my Nuand BladeRF was not the best for software but had a decent CLI interface for configuration, support in SDR# and various other SDR softwares (via a DLL). I chose it along with the XB-200 transverter because I literally could and did just hook up an antenna to the input port and enjoyed it for what it could do - it has an input LNA, multiple stages of configurable IF gain, onboard band-pass filters (mainly centred on ham bands) and a configurable "option" filter output which lets you hook up any filter you wanted (so I chucked a 2-30MHz HF band-pass there to watch the whole HF band at once - https://goughlui.com/2016/08/05/getting-started-nuand-bladerfx40-xb-200-transverter-case-sdrsharp/ ).

The B205mini-i, as per your observations, doesn't seem to have filtering but does have some adjustable gain which could well work. Otherwise, you'll need to use your own bandpass filters or perhaps live with less SNR and just whack on an attenuator or two. Of course, without a case or screened cans, you're likely going to get some signal intrusion into the chain directly, plus you're going to be vulnerable to ESD, lightning damage etc. But it was pretty good going for the most part until the connector broke off. The fact the B205mini-i uses a USB3.0-microB does make me a little apprehensive, as Nuand moved to a full-size USB3.0-A because it "anchors" through-hole on the board so it won't get "karate-chopped" off the board in an accident.

The BladeRF also had the option of a 40kLE or an 105kLE FPGA for onboard processing, but that was never really used for any major processing - I never found the time to develop for it, nor did I find much in the way of images that others had developed (last time I looked). I suspect this capability is quite niche and many are still happy enough to offload processing to a connected host, which might be much less efficient and vulnerable to issues with timing.

As for transmission, sure, you should always have a nice matched antenna (SWR as low as possible, preferably <1.5) to prevent signal reflections and standing waves from forming voltages that could kill the output transistors. However, most of these boards do not develop all that much transmit power, so they might tolerate some abuse more so than a high-power transmitter. But the bigger issue is to be careful to only transmit where you are licensed to do so - I've seen a few supposedly cool "run your own GSM BTS" demos where they've "borrowed" a frequency used by the local telco and that's not cool. Unless you have a license, or can comply with an existing class license, you probably shouldn't be transmitting at all.

But my experience with transmissions and SDRs is that it could be a whole world of pain sometimes. I/Q amplitude or phase imbalances can cause image signals to get developed, sample losses or timing errors can cause transmission discontinuities and wide spectrum effects ("blips"). Wide bandwidths makes things a lot more demanding, and the low power output makes feeding linear amplifiers a little tricky if you want full power. Otherwise you could just be spewing out a lot of broad spectrum noise out of the amplifier and not improving the signal-to-noise one bit, while degrading adjacent channels.

It's because of this that I'm unlikely to do anything major transmit-wise on SDRs ... the BladeRF could do it, but I never really exercised the capability. But perhaps I should - it could probably make a good tool as a tracking generator in concert with another SDR or a spectrum analyzer to do some analysis of cable transmission losses (for example).

- Gough

So it's not just me! I did think I was losing my mind why I couldn't even get a piece of software to work.. I did build GNU Radio from scratch but it would crash on me : ( This is a couple of years ago though!

Did you try GNU radio on windows or linux? I've tried it on Windows and it always appeared to be unstable and not fully supported.

I've only ever been able to build it in Linux ... never managed to get it working in Windows ... but even then performance often left a lot to be desired as well.

- Gough

Thought it was broken only for Windows. Eventually its just the GUI and not the Python lib, but who knows. I never tried the lib, but to be honest the instability always bothered me, every time I gave GNU Radio a new chance and installed it, I ended up uninstalling it a few hours later because of the frustration...

Thought it was broken only for Windows. Eventually its just the GUI and not the Python lib, but who knows. I never tried the lib, but to be honest the instability always bothered me, every time I gave GNU Radio a new chance and installed it, I ended up uninstalling it a few hours later because of the frustration...

neuromodulator  wrote:

Thought it was broken only for Windows. Eventually its just the GUI and not the Python lib, but who knows. I never tried the lib, but to be honest the instability always bothered me, every time I gave GNU Radio a new chance and installed it, I ended up uninstalling it a few hours later because of the frustration...

For what it is worth, I have been using 3.7.13.4 on Windows for a couple of years without (much) trouble. I installed from these binaries. My frustration is that it creates "yet another python" install. But it seems to make GNU Radio happy.

That said, I haven't updated to 3.8.x (or 3.9.x now?) because it was much a pain to get running. But once running, it seems to be better than it was many years ago.

If I come up with a reason to explore GNURadio software in the future I'm hoping to use the 3.9 version. I have read the release notes for product. It seems prudent to be at that release. Unfortunately you may not have as many souls of experience to rely on to help.  I'm running Linux as my primary operating system so that install appears to have more fish ladders to get over the installation water falls, than the blue screen of death operating system.