Tag Archives: SDR

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

To SDR or To Not SDR? Is That Really Even a Question?

Debate about SDR (Software Defined Radio), like the Flex-Radio, Genesis Radio, SoftRock and the many other SDR offerings has been in our hobby magazines, nets and blogs.

Many of the arguments go on in length to explain why this or that author is not adopting SDR and why they are staying/clinging/satisfied with some various past generation of radios – whether their prized Collins Gold Dust Twins, their 1990’s Contest worn FT-1000 (but only after and only before certain factory mods), or even new IC-7800 class rig – and many go to explain that SDR isn’t what amateur radio is about in their estimation.

Discussions fall into at least a couple groups:

  • “Real Radios” have knobs (guess the TenTec Pegasus, the Kachina and the computer only Kenwood TS-B2000 weren’t real, despite having been around for years….).
  • It has to live in just one box to be a “Real Radio” (How does the Yaesu FT-2000 type system, with the DMU and external DX Tuning Coils fit as a “real radio” much less the TX/RX/VFO/Exciter stations of years gone?)
  • Computer, Computer – a real radio don’t need no stinkin’ computer! (not understanding that embedded processors are also computers?).

Ever since the spark & crystal gave way to tubes, then to transistors, then to IC Chips, there has been those who argue that the next wave of technology was somehow “Bad” or somehow “less good” than the “old way.”

It is easy to dismiss these opinions as the incantations of technological Luddites, but they hold some truth – that usually with each step forward we do loose something. There is a trade-off in innovation that does have a cost.

Often though what is seen as technological innovation is really nothing more than our being exposed and allowed to “touch” components that have been part of our radios for years, and secondly bringing expensive established technology to the hobbyist affordable price point.

Even though they have knobs, many modern transceivers are largely software driven, and some do signal processing partially using the same technologies that SDR offers. It is just that their “computer(s)” live inside the box with knobs.

Reading current transceiver ads you’ll notice  a focus on what main processor a particular brand’s “box” has, and how many DSP IC Chips it uses.  Advertising responds to the market’s perception that the imbedded computers have become important marketing material.

Didn’t we go from factory-upgradable firmware, to user replaceable PROMs, then to EPROMs we could use a special connection & process to update, then to Flash Updates, on to the SD-card personality Updating, and now system updating by built in internet ability?

Who would have thought when we were building the wonderful radios we now call “boat anchors” that tomorrow’s radios would share audio & RF input/output connection types, but otherwise little else?

The IP Address many new fully with-knob rigs would have you configure so they can exist on your network, wasn’t even being talked about as fantasy just a couple product cycles back!

SDR is here to stay.

The real question is not whether to SDR or Not SDR, but rather a series of questions about architecture and man/machine interface.

While the Panadapter band view of many SDRs is a huge tool, it has existed in some form for decades. The very advanced SDR processing again is accessible to regular hams, but also has existed in other forms for those able to put together a serious station.

Current SDR has brought these sorts of features to a technological access point and economic cost/benefit point where any Radio Amateur could implement the technology in their shack.

Of course no one needs to adopt the latest technology the instant it appears on the horizon. To be realistic the current SDR user group has expanded to include “regular hams” who are implementing rather than experimenting.

Isn’t that what most of us do anyway? We pick and choose various station components, many of them “black boxes” we will never open up, modify or develop any further than flashing someone else’s updated software/firmware into, and assemble the pieces into a station.

Even in the “old days” we sourced parts – tubes, transformers and whatnot – to build usually following fairly well established circuit designs.

In each case we follow paths well worn, with books, best practice manuals (and now the internet) to guide us, and basically do little more than acquire a taste of knowledge while building what amounts to “adult Lego building” in assembling a station.

It is the uncommon radio amateur who knows the block diagram of his knobs & buttons transceiver, much less the detailed circuit layout – IF the manufacturer even provides a copy.

It will become that way for SDR too, through time. Those hobbyists less interested in “how it works” than they are in “just make it work for me” will be served by the marketplace with non-technically demanding SDR offerings. Even now the present level of SDR offerings include all-in-one-box SDR with on-board computer rigs like the Flex-Radio 5000C, which basically becomes a high end radio sans-physical controls.

At the other end you can build modules and assemble your own SDR from offerings from TAPR, Genesis Radio and others. You can roll-your-own software, again using modules or starting from your own source code.

In many ways the current state of SDR amateur radio is embracing experimentation, individual development and the intense learning that characterized the very essence of the nostalgic memories of some anti-SDR sentiments.

A pragmatic development, there is an interesting development in the SDR world addressing the no-knobs machine/interface debate, with the offering of several tuning-pod and faux-frontplate knob & switch offerings.

These offerings, just like the current all-in-one-box mainstream transceivers, use rotary digital or optical encoders to tune, and translate your knob movement into digital commands.

The same technology, but somehow different? Seems more ironic the clinging to the past when you realize the past is the same (albeit more expensive) as this (affordable) SDR future.



Tagged , , ,