[hpsdr] NVIDIA Jetson Nano SBC - YouTube video

[Scott Traurig]

Scotty,

Doing FFTs in a GPU or FPGA will not reduce latency. Our CPUs are plenty
fast enough. They have to be because we are successfully processing
real-time signals. The latency comes from the length of the FFT pipeline,
which of course is determined by the sample rate and the bin size one wants
to achieve in the FFT (or IFFT). Thus no latency improvement can be had by
using a faster processor when they are all already more than fast enough.

With all ancillary processing turned off (noise reduction on RX,
compression on TX, etc.), the openHPSDR firmware and PowerSDR, with
PowerSDR set to use the speedy min. phase FIR "low latency" filters,
latency is now approx. 20mS. This is commensurate with any conventional "IF
DSP" radio on the market and quite a bit faster than most if not all other
direct sampling radios except the Icom 7300 and 7610.

73!

Scott/w-u-2-o


On Tue, Apr 30, 2019 at 6:03 AM Scotty Cowling <scotty at tonks.com> wrote:

>
> Hi Scott,
>
> You make a good point. This is one of the things I would like to do with
> the new TAPR TangerineSDR. We should be able to essentially do all of the
> filtering and demodulation in the FPGA, and let the SBC just do command and
> control and the GUI. Another (good) side effect of this might just be
> reduced latency, since the FPGA can likely perform the DSP tasks more
> quickly than a (relatively) slow general-purpose CPU can. Of course, maybe
> the Cuda cores could do it fast enough just by splitting the software into
> two pieces as you suggest, and using the GPU for part of it and the CPU for
> the rest. If Phil can do a massive FFT in real time with the Jetson board,
> why not have it demodulate and filter a narrow-band signal in real time?
>
> 73,
> Scotty WA2DFI
>
> On 2019-04-29 08:13, Scott Traurig wrote:
>
> These embedded computing platforms would have a lot more merit if someone
> where to split PowerSDR/Thetis into thin client/server pieces, and the
> server could run on the inexpensive but reasonably powerful embedded
> platform. Alas, no one has taken on this challenge (and I can't because I'm
> not a software developer). Because I set the bar for radio functionality at
> the "PowerSDR or better" level, unless and until someone comes up with
> something that really is better, functionally not philosophically, then to
> me a Windows platform remains a must-have.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20190430/51fba2cc/attachment.html>