[hpsdr] NVIDIA Jetson Nano SBC - YouTube video

[Scotty Cowling]

Hi Scott,

Agreed that you can either keep up in real time or you can't.

What about the "economy" SBCs that can't quite keep up? If I have extra 
hp in the FPGA, I can make up for a lack of CPU power in the SBC. And if 
my FPGA is a server, all of the clients (i.e., low power SBCs) benefit.

Latency can also come from other sources, such as large packetization or 
communications channel latency.

So while I agree that once you are fast enough, "more faster" doesn't 
buy you anything, slower (i.e., cheaper, lower power) can hurt you.

My interest lies along the lines of leveraging FPGA/GPU power in a 
server to reduce the demands on the clients to where we can use simple, 
cheap SBCs as multiple clients connected to a single server. I am more 
of a hardware/FPGA guy, so that is where my focus lies. :-)

73,
Scotty WA2DFI

On 2019-04-30 04:35, Scott Traurig wrote:
> 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 
> <mailto: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/d48cb4da/attachment.html>