[hpsdr] openHPSDR at the forefront of SDR development

Wed Aug 20 04:37:31 PDT 2014

Hi Chris.

Alternatively, you could make a small PCB that plugged into J5 on Mercury 
that held the PHY, 25MHz clock and Ethernet socket. Since you no longer need 
any DDC code in the FPGA you would have plenty of room to house the raw 
Ethernet code.

'Weekend Project' anyone ?

73 Phil....VK6PH

-----Original Message----- 
From: Chris Smith
Sent: Wednesday, August 20, 2014 4:48 PM
To: phil at pharman.org
Cc: hpsdr at lists.openhpsdr.org
Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development

Hi Phil

I realised that the bottle-neck would be the Atlas backplane which is why I 
floated the idea of a bespoke daughter board for Mercury. Any control that 
Mercury needed could still be supplied by Atlas but the raw packets would be 
syphoned off via a gigabit e'net gizmo on the daughter board. Sorry can't 
remember the TLA for the gizmo - brain fade! :-)

Cheers

Chris

On 20 Aug 2014, at 09:22, "Phil Harman" <phil at pharman.org> wrote:

> Hi Chris,
>
> The limitation of using the Mercury board together with Metis is the
> bandwidth of the Alex bus.
>
> If would could couple the two boards together in a suitable way then we
> can use the existing Mercury board.
>
> 73 Phil...VK6PH
>
>
>> 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/
>>
>>
>>
>

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

 1408534651.0