[hpsdr] openHPSDR at the forefront of SDR development

[Chris Smith]

Hi Phil

I had a feeling, when I saw your paper and Hermann's at Friedrischafen, that DFC was the way things were going. Which is why I jumped on the TK1 bandwagon.

Will there ever be a way of using the Mercury front end to supply the raw packets, perhaps with a bespoke daughter board?

Congrats to John whom I had the pleasure of speaking to at Friedrischafen. I'm sure we all look forward to the new era of SDR in the amateur radio arena.

Cheers & 73

Chris G4NUX

On 20 Aug 2014, at 08:31, Phil Harman <phil at pharman.org> wrote:

> ***** High Performance Software Defined Radio Discussion List *****
> 
> All,
> 
> I'm delighted to be able to report that we have been able to develop, to
> proof-of-concept stage, a new SDR architecture.
> 
> Current SDRs use the software equivalent of zero IF techniques, i.e. DDC,
> in order to provide (multiple) receivers.   Whist this is quite effective,
> much of the initial DSP work is done using FPGAs, or a combination of FPGA
> plus dedicated DSP chips and microprocessors, rather than totally within
> the PC.
> 
> As more complex features are added, the size and complexity of the FPGA
> and DSP code increases. The skills to write, debug and maintain this code
> is only available via a small percentage of software engineers, or
> enthusiasts, in comparison to those able to write code for PC based
> hardware.
> 
> In order to open the SDR world to those with PC software skills we are in
> the process of developing a new SDR architecture.
> 
> This architecture digitises the entire 0 to 30MHz radio spectrum in real
> time and passes the 'raw' samples directly to an associated computer.
> 
> This computer then calculates the FFT of the raw samples and subsequently
> processes the result as the user requires.
> 
> This is not a totally new concept since both the cuSDR and KISS Konsole
> software uses raw ADC samples to provide the wideband bandscope displays.
> 
> However, for this requirement the FFT only needs to be done at the
> bandscope update rate of a few 10's of times per second, which hardly
> taxes a modern PC at all.
> 
> The new concept requires that we take the FFT of all samples in real-time.
> 
> This has been possible in the past - if you had access to a Cray super
> computer!
> 
> Well now we do have access to very low cost computers that provide the
> processing power we need.  One example of this is the new Nvidia Jetson
> TK1 single board computer.  At a cost of $192 this board contains four ARM
> CPUs plus 192 CUDA processors.
> 
> More details of this remarkable board can be found here:
> 
> https://developer.nvidia.com/jetson-tk1
> 
> Since the CUDA cores can process data in parallel, we can use these to
> perform the high speed FFT.
> 
> John, G0ORX, has written preliminary code for the Jetson board and has
> confirmed that it has the necessary performance we require.
> 
> The test environment consisted of a Jetson board connected via Gigabit
> Ethernet to an Angelia board.  A special version of FPGA code was written
> for the Angelia board that sent raw 16 bit ADC samples at 61.44Msps to the
> Jetson board.
> 
> We used raw Ethernet frames over the Gigabit link, in order to maximise
> the link bandwidth, since we require a sustained 983Mbps transfer rate.
> 
> Whilst it's still early days, and there is much more to be done, this
> critical early success does indicate that this new architecture has a very
> promising future.
> 
> The Jetson board is taking the role of an 'SDR Server' which I have
> written about in the past.
> 
> In which case what benefits does this new architecture provide to openHPSR?
> 
> 1. The FPGA code is greatly simplified, is easier to write and maintain,
> and hence uses a small percentage of the space available with a subsequent
> reduction in power consumption.
> 
> 2. The protocol between the SDR hardware and the SDR Server is greatly
> simplified since the SDR hardware only has to connect to a single,
> dedicated,  SBC or PC.  Hence ARP, DHCP, ping, UDP/IP etc are no longer
> required.  The SDR Server simply needs to know the MAC address of the SDR
> hardware in order to communicate.  It should be possible for a single SDR
> hardware board to feed multiple SDR Servers, but that's something for the
> future.
> 
> 3. Virtually all the signal processing is undertaken on the associated
> single board computer (SBC) or (suitable) PC.  If sufficient processing
> power is available then the GUI can run on the same SBC. Alternatively the
> user's normal PC (which does not require to be high performance since it
> does not do any significant digital signal processing) or a Tablet, cell
> phone etc could be used.
> 
> 4. Many more users have the necessary skills and experience to support,
> maintain and further develop the code. New features are added to the SDR
> Server code rather than the FPGA code.
> 
> 5. Extends the useful life of openHPSDR Hermes boards where otherwise FPGA
> and/or power supply restrictions may have limited adding new features.
> 
> 6. Future hardware upgrades will be to the associated SBC where faster and
> lower cost options can be expected.  Nvidia have already indicated that a
> 64 bit board will be available in the near future.
> 
> 7. Remote access to an SDR via the Internet will enable multiple users to
> share the SDR with each selecting their desired frequency, bandwidth and
> mode.
> 
> There are other potential benefits relating to simpler and lower cost SDR
> hardware, but that is for the future.
> 
> For want of a name we are calling this new architecture 'Direct Fourier
> Conversion' (DFC).
> 
> For those that are already experimenting with the Jetson board we do
> intend to release the DFC FPGA code for both Angelia and Hermes boards and
> I will advise when, and where, this is available.
> 
> John's code is presently not available, so please don't pester him, but as
> soon as it reaches Beta stage it will be released.
> 
> Please join me in congratulating John on this exciting development.
> 
> 73 Phil....VK6PH
> 
> 
> 
> 
> 
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/


 1408520578.0