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

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.

One of the difficulties with GNURadio can be software revision related. I discovered that first hand while developing a tutorial for GNRadio. Some of the stuff you could do in version 3.7 was deprecated in 3.8. Release 3.8 wasn't backward compatible. Information that was readily available on the internet was for the software was all 3.7 and earlier based. If you started with 3.8 release some stuff just didn't work.

I see there is a 3.9 release available. The posts about it being difficult to get working is nothing new from my initial experiences. RTL-SDR and GNURadio is not for the faint of heart.

I dabbled in SDR around the beginning of 2020. My formal electronics training and RF experienced was an asset as a foundation to start learning about the technology. Even with that, I found it extremely difficult.

I blame myself for some of the difficulties. I didn't want to specialise in the subject. My interest was because I was fascinated by the direction RF technology had taken since I started with transmitting and receiving with vacuum tubes. I am not a HAM operator so using it for that purpose didn't interest me. It appeared there was no middle ground at that time between novice and expert.

I would like to RoadTest this unit with GNURadio by developing an AM/FM receiver layout. It sounds simplistic but my spidey sense tells me, a lot can go wrong.

Same as Gough, I've only tried that on Linux. And normally I'm as confident as the next person to get something running in some way or another, but suffered run-time crashes, which I couldn't get to the bottom of, eventually gave up : ( Also it seemed most of the LimeSDR demonstrations were not using GNU Radio at the time, so I wanted to wait for things to mature.

Regarding performance, I'd hoped one day it could be possible to design on the PC, but then be able to program in the processing pipeline into the SDR hardware, e.g. special syntax/API if not compiled for specific targets. Maybe it's a bad idea I don't know. Other non-radio industries do such things, e.g. develop traffic generation scripts in a special language for the industry, and then that gets compiled and pushed into the device. I wish some uni student with time would pursue such a project to investigate.. sadly there seems too much traction with the status quo of GNU Radio.

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...

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

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.

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!

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

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.

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