[hpsdr] SDR Architectures

[Phil Harman]

All,

There has been some very interesting discussions recently relating to
current and future SDR Architectures.  Last year I had a two part article
published in the RSGB RadCom magazine that discussed some of these
architectures and their pros and cons.

The RSGB have kindly agreed to me making the articles public and you will
find them here:

<http://openhpsdr.org/wiki/index.php?title=HPSDRwiki_talk:Community_Portal>

I've made no secret of the fact that my preferred future architecture is
an ADC/DAC sending/receiving raw samples from either a high performance PC
or a dedicated high performance, low cost, single board computer (SBC),
operating as an  "SDR Server".

Given that we have no control of what the user will run on their PC then
I'm going to concentrate on the SBC solution.  We may have enough
processing power to run the GUI on the server, if not a low end
PC/MAC/Tablet/Phone provides the user interface.

My concept is the SDR hardware be simplified to the point were the
absolute minimum processing is done in the hardware. Instead the role of
the hardware is to convert the raw ADC samples to a suitable format to
send to the SBC.  With our current hardware and SBCs this will be raw
Ethernet frames at a Gigabit.

Using a Hermes board and a Gigabit link we can send the RF spectrum from 0
to  30MHz,  using 16 bit ADC data,  to the SBC.

The number of independent  receivers, and features,  is then limited by
the available processing power of the SBC rather than the size of FGPA
used when the hardware was built.

However, this is by no means a new architecture since its been very
successfully used by the public access WebSDR at the University of Twente
since 2008,  see:

<<http://websdr.ewi.utwente.nl:8901/>http://websdr.ewi.utwente.nl:8901/>

So how does this architecture  sit with Joe Ham?  Since the SBC ideally
only runs  the SDR Sever software then potentially User Support can
be provided remotely via the Internet directly to the SBC.   Remote
support of Linux based systems is a very mature industry and one we can
piggy-back on as needed.

Since the SBC can be  isolated from Joe's main PC/MAC/Tablet/Phone
numerous security issues disappear.

The protocol between the SBC and SDR hardware becomes almost trivial and
any complexity now moves to the protocol between the SBC and
PC/MAC/Tablet/Phone.  Even there, since the DSP has been done in the SBC,
the protocol is mainly concerned with the selection of various features
and options.

Here, the separation of DSP and GUI opens up the possibility of those with
graphical programming skills making a significant contribution.

With 10Gigabit Ethernet starting to appear on consumer PC hardware we can
expect a migration to this format in the future.  This will allow multiple
ADCs and sampling into the VHF spectrum.

I'm thinking of the SDR hardware to be along the lines of a USB TV Dongle
on "steroids"!

With such a simple architecture the SDR hardware is going to be low cost
and stable for long periods.  Upgrades will be done by swapping out the
SBC for the latest/faster/cheaper model.

There are literally thousands of SBC on the market.  Almost daily new,
lower cost and higher performance boards appear.  This is being driven
by the needs of other markets which we simply benefit from.

If we want keep the current level of DSP in an FPGA then an SBC such as
the Raspberry Pi will meet our needs. However, to process raw ADC samples
at a Gigabit will require a SBC with more processing power.

Today we can purchase a 192 CUDA core SBC for $192.  This runs a full
version of Ubuntu Linux and all the required software development tools
needed are freely available.

<https://developer.nvidia.com/jetson-tk1>

Being able to develop the code you want to finally run on the actual SBC
hardware, rather than needed to cross compile, is a bonus and greatly 
simplifies the development process.

By removing the DSP processing from an FPGA on the SDR hardware you move
from programming that can only be done by 0.01% of our members to an
environment were potentially  many can contribute.

The alternative approach of doing more processing in the SDR, via an
embedded microprocessor also deserves a mention.  For sure, the embedded
marked will drive higher performance, lower cost and more features. By
off-loading processing that needs to be done in real-time to the FPGA by
the microprocessor then, by comparison to a state-of-the-art SBC,
useful performance is achieved.

However,  a  performance up-grade could be an expensive exercise compared
with spending a few $100 on the latest and greatest SBC.

I'm not suggesting that this is going to be a simple and straight forward
journey.  Just because an SBC has numerous CUDA processors does
not necessary mean we can use them efficiently. There's a lot to learn and
we are sure to run into some dead ends.  One thing is for sure and
that it's going to be an exciting journey!

So, first step is to port Warren's wdsp  to a CUDA  based SBC..... a
journey we have already started.

73 Phil...VK6PH