Tag Archives: SDR

Getting started in Software Defined Radio – Make: Magazine

Often asked “How do I get my feet wet in SDR?” I had a cut-&-paste template email I could send on, but I knew my treatment was superficial.

SDR (Software Defined Radio) has capture a lot of people’s attention, and recently Make:Magazine On-Line did a nice intro and how-to piece that I can recommend.

“SDRs are rapidly becoming the dominant radio technology of the 21st century. Substituting math for circuitry allows for such tremendous flexibility that we can expect to see SDRs integrating into a wide range of applications and devices. Given the low cost of entry, makers with an interest in the radio spectrum can’t go wrong experimenting with this exciting technology.”

Link to article is: https://makezine.com/article/electronics/getting-started-with-software-defined-radio-sdr/



Tagged ,

Musing on the FlexRadio Experience

The Silicon Gray Beard is a really nice blog that has a lot of interesting posts.  Every now and again he does wade out a bit deeper than the knowledge he has mastered, and I was reading his post at: https://thesilicongraybeard.blogspot.com/2020/07/a-ham-radio-series-9-software-defined.html

I wanted to share here some of my FRS musings:

Whether ICOM or another, once the technology used to make a “radio-server” became affordable at the amateur equipment price price point, the neat evolution of hybrid technology was going to happen.

The knobs/no-knobs issue predates the Maestro, as with the prior “Thick-Pipe” SDR technology (where the PC is part of the processing, rather than just a platform for the end user GUI) Flex had launch the FlexControl. I bought one in 2011 for my Flex-5000A https://k9zw.wordpress.com/2011/06/09/flexcontrol-usb-controlled-tuning-knob/

Some on the Thick-Pipe vs Thin-Pipe differences: https://k9zw.wordpress.com/2013/05/19/the-future-of-sdr-fat-pipe-vs-thin-pipe/

One area that has fascinated me is how the FPGA (Field Programmable Gate Array) went from exotica to an SDR norm. The technology was there, but the economics were against widespread amateur usage. When FlexRadio announced they would be using FPGAs in a bigger way I wrote: https://k9zw.wordpress.com/2012/05/21/musing-on-the-new-flex-6000-series-smartsdr-radios/

If an SDR is just a radio server, how you controlled it was an ongoing discussion. The current FRS ecosystem allows for a end-client GUI on normal computer hardware (Windows, MacOS, and iOS on both iPhones & iPads), the Maestro for the face-plate experience, and the M-models for those who want everything in a traditional transceiver packaging. In addition to the FlexControl other hardware has been made work to give more options.

In my mind the real magic is the ability to remote, the ability to have essentially a “new radio” with a new Version of SmartSDR loaded into the radio, and in my case the amp/transceiver integration when viewed from the end-user GUI.

While I am trying this comment I’ve made a dozen or more QSOs running digital mode to my home station via remote. I’ve my choice of a radio in the next building – a 6600M – or a radio at home – a 6700 – when I remote, more to do with antenna choices than much different in capabilities. I regularly had remoted while traveling, using an iPad and a noise-cancelling boomset. https://k9zw.wordpress.com/2017/08/22/remoting-via-smartsdr-and-smartlink-v2-0-in-daily-use/

Since I bought my Flex-6700 I believe I have upgraded that radio over 50 times, which is more than the usual user experience being on the test team, but as a contrast few of my other radios have received more than a single feature upgrade while I’ve owned them. (I started with pre-release version 0.6ish to the latest 3.1.12 General Release – unfortunately I can’t tell you anything about test versions though).

While I typically run barefoot, I do have the FlexRadio/4o3a PGXL Amp, which base functions and metering are integrated in most versions of SmartSDR.

Is it all perfect, no. But that is not a problem as feature-by-feature my system will evolve as the software upgrades drive feature improvements.

Just as a counterpoint, I do keep a nice Collins setup for a traditional ham experience when I don’t want to run all the gee-wiz stuff.



Tagged , ,

What is an SDR?

SDR – Software Defined Radio

What really is it?

Would seem that a generalized radio platform that is “made into” a radio by software is kind of the limit of the dictionary SDR concept.

As amateur radio operators we have added to that definition with concepts about software updates, sampling methods, and a whole raft of features that perhaps are neither specific to an SDR nor a requirement to meet the basic SDR definition.

Some things market expectations have added to the SDR concept is:

  • Ability to be updated by the end user, by download
  • Direct Sampling
  • Feature growth and bug correction by software updates
  • Tight integration with a computer
  • Panadaptors
  • Digital Signal Processing
  • Touch Screens
  • Remote Capabilities
  • IOT (Internet of Things) Capabilities
  • Station Integration with other station components

Continue reading

Tagged ,

The Future of SDR – Fat-Pipe vs. Thin-Pipe

One thing that discussions, seminars, and banquets made very clear to me is the fundamental change in SDR design from Fat-Pipe design to Thin-Pipe design.

First what is meant by these terms?

Fat-Pipe is an SDR software and processing distribution with the on-board in-the-black-box hardware needing an external significant computer to make the radio work.  Usually this is a PC running Windows or Linux/OS-X where the PC is doing many parts of the signal conversion.  Analogue-Digital Conversions typically take place both in the radio box and in the PC.

Thin-Pipe is the SDR design where the in-the-black-box radio hardware does everything except the GUI (Graphical User  Interface) and HMI (Human-Machine Interface).  Thin-Pipe SDR radios often do not need a PC to operate “per say” but require the external device to change settings, display values and possibly handle audio I/O (some Thin-Pipe SDR designs can do their own direct audio I/O as well).

The darling of a experimenter building their own SDR from scratch or kit, Thick-Pipe SDR systems significantly are affected by the Host PC.  The data transfer between the SDR and PC is multi path, complex and data intensive.  Variations in the host PC capabilities, resource allocation/availability and every bit of software running are huge issues.  Going remote is more easily handled by adding a Thin-Pipe between a remote PC and the host PC as the Thin-Pipe model better dealing with latency and thru-put complications.

It is non-trivial to open and sustain the broad multi-channel low-latency connection between the SDR with a remote Thick-Pipe PC.

Personal experience with PowerSDR Thick-Pipe configuration has shown the operating capabilities, present operating state of other software and the bluntly  #%@$& issues of Windows driver, updates, conflicts, and foibles and endless set of issues.

So why has the move to Thin-Pipe first started now?

Processing Power and use of FPGA architecture.

When Thick-Pipe SDR designs rolled out the high end Host PC  had  4 to 8 GFLOPS (billion floating point operations per second) capability against a typical all-in-the-box radio having perhaps 0.1-0.2 GFLOPS.  The processing power in the SDR box was not significant.  None of the hardware was hot enough to even worry about calculating GMACS (billion multiply-accumulate operations per second) which is arguably more important for SDR performance.

The new “SDR Radio Server” designs roll in onboard processors in the 100 plus GFLOPS range (right there with the biggest and meanest new PC processors) but with huge GMACS numbers running 300 plus.

The FPGA to a lay person like myself can basically be thought of like having 400-500 processor cores running parallel.

Basically this means that any PC is a weakling compared to the processing inside the box of a Thin-Pipe “SDR Radio Server” and the Host PC is an I/O manager if used at all.

In the Thin-Pipe design the Host PC puts the “pretty face” on the “SDR Radio Server” with displays of the SDR Radio Server’s settings, state and output.  The Host PC also downloads to the SDR Radio Server the user’s audio (microphone/key/digital) , commands and simple functions like PTT (Push to Talk).

A Thick-Pipe SDR guru told me the data rate  between SDR and Host PC differential between his state of the art imported Thick-Pipe SDR and the state of the art Thin-Pipe SDR design was 165 times heavier for the Thick-Pipe design even though it was working with less than 1/10th the sampled bandwidth of the Thin-Pipe SDR design.

This basically roughs up to the Thin-Pipe being content with the connectivity of a 2/3rds of a Skype connection, which is manageable (and affordable).

Will Thick-Pipe go away?  Not likely.  The cost point of a reasonable Thick-Pipe SDR complete station – especially  if overall station performance envelope is not excessive – is attractive.  Also many hobbyists are more comfortable tweaking their PC and PC’s software than are able to directly work with massive processing with FPGAs, which will keep the Thick-Pipe a favorite for the experimenter.

It is predictable that the leading edge of SDR performance will be Thin-Pipe – the brute force in the SDR Radio Server is so huge that the Thick-Pipe design doesn’t have a chance.

Now let’s categorize some real world SDR software by pipe type.

PowerSDR is Thick-Pipe in most implementations, with some implementations hybrid or Thin-Pipe control display I/O only.  In most instances PowerSDR and interchangeable similar packages are Thick-Pipe.  Connectivity is typically direct hardware hardwired, Firewire/1394, or high speed USB.  Other mainly Thick-Pipe packages include Thick-Pipe include GSDR, CWExpert, SDRRadio and SDR#.

SmartSDR is an example of Thin-Pipe SDR implementation.  Other quasi-SDR Thin-Pipe projects include WebSDR (which seems more a CAT receive only audio server).

Hope this has been helpful!



Tagged , , , , , , ,

The Ugly Soft Underbelly of SDR Software Defined Radio

Actually I shoudl have titled this post “The Ugly Soft Underbelly of SDR Software Defined Radio that Uses a Separate Windows Computer to for anything other than User Interface!”

As described my contesting weekend was a bust – with a good share being basic computer woes.

The PowerSDR version of SDR I am using in the shack is absolutely dependent on having PowerSDR running successfully.

And PowerSDR is just yet another Windows program.

My particular Dell has having huge issues with wanting to call the mothership, update everything and demanding a series of reboots and software repairs.

There was absolutely no reason for this misbehavior, having ran 100% the weekend before and the weekend before that.

So what happened?

Windows XP had a bunch of updates, triggering a series of catch-up updates for Adobe Reader, Adobe Flash, Javascript, Java and right down to Notepad++ … then in the background other programs like Apple’s iTunes stuff all started calling home too.

It was like every program on my machine wanted to get in on the update fun!

Then DDUtil either was updated or first recognized an update, and got into a locked processes battle with AVG Anti-Virus which was doing its own update,

PowerSDR crashed or part crashed every couple minutes or it if didn’t DDUtil took the lead and crashed.

AVG required a c complete removal and reinstall as it was convinced its installer had been hijacked.

Now I have Linux based computers that I shut down once a year to dust out and check. At work we even had a OS-2 Warp system that ran for years untouched.

But not Windows which just can’t seem to leave a working configuration alone.

Now this will all change with the next generation of SDR radios which return the Windows PC to what it is reasonably good at – as a user interface – and these new SDR have all real processing internal in their box with Linux running on a high powered processor.

I am sure there is amuch I can do to limit – to mitigate – the downside of Windows, but I ask “why should I have to?”



Tagged , , ,

To SDR or To Not SDR? Follow Up and Personal Observations

This is a second post expanding on To SDR or To Not SDR? Is That Really Even a Question?


A few thoughts on Bleeding Edge vs Leading Edge, Connectivity Issues, and the reality that part of the SDR is a personal computer who’s hardware & operating system will be evolving.

As a lead in, I want to be clear I am writing about “Full SDR (Software Defined Radio)” technology, not receive only processing of intermediate receiver products, CAT-less (Computer Aided Transceiver – basically full control of the Transceiver from the computer desktop) or receive only components that maybe part or all SDR, but lack SDR transmit capability.

I’ve had people comment that their “IF-tapped XYZ Transceiver plugged to a computer soundcard with their PC running audio processing of that analogue tap’s output” is somehow an SDR, and even more an SDR equal to the big-boys.

Sorry, it isn’t.  It is a neat thing, to computer process an IF-tap’s receive output – very cool!  But it is not a full blown SDR transceiver.  If you differ, lets set a Sked and talk SDR to SDR on the air… oh woops, sorry I forgot these “SDR” lack SDR-transmit….  Well maybe we can email…

All humor aside, there is a real risk in adopting a lifespan-limited SDR offering – of buying into a Bleeding Edge design that will be come unsupported.

That same fear of buying into a dead-end bound design was the number one reason I had never given serious thought to the first SDR products.

What made the SDR platform come into focus for me personally?

Two items – Ultimate Performance and Economics

Ultimate Performance in not only has SDR evolved to meet every technical achievement that conventional transceiver designs offer, but arguably the state of the art has been moved & improved upon by SDR. Having had extended opportunity to use the top of the line conventional gear I had developed pretty lofty tastes for performance, especially in receiver ability.

I’m not the only one to identify the unique, and software improvable performance lead of SDR – well known testing labs have documented the measurable figures and even our government has jumped onto SDR for mission critical intelligence work by adopting the FlexRadio Systems CDRX-3200 32-receiver 100kHz to 100MHz streaming Channelizing Digitizer Receiver.

In the case of the SDR design I am using the SO2R (Single Operator – Two Radio) design is integrated into one device in way not available in a conventional transceiver pair with SO2R interface.

In terms of station integration, including bringing other station components like rotor control, antenna switching, audio recording, Watt/SWR Metering, Digital Mode, Amplifier, Logging Programs, DX Spots, and audio processing under control, the SDR opportunity allows a single shack interface through the computer. If you noticed I mixed hardware items and station software in my list – on purpose as once put to the machine their virtualization becomes an interoperability playground independent of whether the components are hardware, software or a mixture. That the various programs can share control hooks to work together is an opportunity in interoperability very difficult to achieve in the shack with non-computer based assistance (please be certain that the stand alone station aids for integration are actually small purpose built interfacing computers, or distributed processing if you will.)

In the area of Ultimate Performance there is little opportunity to implement certain SDR features in the shack on a practical basis.

Binaural audio features make use of the human mind & ears ability to gain intelligibility by the way of the head-related transfer function or HRTF, an improvement in reception not available at this time in the hamshack other than through SDR.

Having built in diversity reception is otherwise presently not achievable in the hamshack with mass market single transceivers.

The transmitted voice processing, equalizer, compender, compression and other tweaks is available in the hamshack in stand alone gear, though three pieces of specialist kit would be needed.

Economics then comes into play. With computer my present SDR setup investment is around 1/3 of what would have been spent to achieve the same feature set, the few unique SDR features set aside, at the same performance levels. When used in the SO2R configuration that 1/3 drops to more like 1/5th the investment.

That isn’t to say that a good station with conventional gear couldn’t be put together at a similar price point as my SDR setup, but such a station would not share either the performace specifications, much of the feature set, nor a fraction of the station integration.

Even when evaluating Ultimate Performance and Economics, a fear of buying into a limited life product and the knowledge that the operating system & hardware of the PC portion would be evolving played heavy on my mind.

That was before I realized I was holding more a fear of uncertainty, as the updatability is the most significant product feature of SDR.

True that someday down the road, ultimately my particular SDR purchase maybe tomorrows “boat anchor.” Actually I rather hope that our hardware keeps advancing, and I would obviously be 100% assured of having bought tomorrow’s “boat anchor” if I were to purchase any conventional transceiver currently made.

So perhaps my fear was of having a “short cycle” to obsoleteness? What sort of timeframe should I plan to “amortize” my SDR purchase over, predicting the future as best one can?

Contemporary conventional transceivers seem to be roughly on five-to-eight-year, give or take, manufacturing life-cycles before upgrades & model improvements overshadow the previous offering. Recently influences like the RoHS rules and earlier than expect processor end-of-life announcements & subsequence unavailability have modified this with a couple of premium transceivers going short cycle.

In the case of some of these rigs they are now basically unrepairable if they were to loose one of their embedded processors – onboard computers on a chip – and have become bargains for those willing to take the risk.

Did I mention that virtually none of the current conventional transceivers have a significant feature upgrade path (I would argue that the Elecraft transceivers are one of the exceptions to the locked design)? Maybe the SDR having the option to adopt computer improvements (there is no obligation of course) is an asset, rather than a liability?

The PowerSDR software, as it moves into “Deep Impact” (the working name for the newest versions) is multi-platform for both software operating system and hardware.

So it is unlikely I will find my investment seriously painted into a corner anytime soon.

Of most concern is the IEEE 1394 Firewire Port of the present design. The PC industry has an on/off history in supporting Firewire, as many clone manufacturers did not want to apy the small licensing fee, nor comply with the QC standards of Firewire. Currently some makers don’t offer it, some add it to their premium – especially media server type – PCs, and many offer it either as standard or a factory option.

Perhaps down the road a future version of USB might be more desirable (though I would think not until its throughput exceeds Firewire and until it moves its I/O overhead off the processor), which gasp – gasp – might mean I would need to update my SDR unit if I wanted to directly use say USB 6.0 as the native SDR-PC interface. Try updating your 2002 mainstream transceiver’s hardware to update connectivity – it isn’t going to happen.

Now to be fair I do want to be clear that as much as I am pleased to be operating with the Flex-5000A SDR radio I bought 18 months ago, I do enjoy being on the air more than worrying about on what specific radio, I have kept a full complement of conventional transceivers & computer controlled transceivers (not SDR, just controlled), have homebrew & QRP radios, and am in the midst of setting up a 1970’s style vintage station.

Adopting the leading edge doesn’t mean you have to forego the legacy gear that pleases you.

My question is what delights does the future offer that put my SDR transceiver into that revered status as a legacy? And how rewarding it is to be using that technology today!



Tagged , , ,