[hpsdr] NVIDIA Jetson Nano SBC - YouTube video

[Scott Traurig]

Scotty,

Apples and oranges. Two different problem spaces. It looks like we are in
agreement about both, however. But I thought it was important to clarify
that one point.

73,

Scott


On Tue, Apr 30, 2019, 12:25 Scotty Cowling <scotty at tonks.com> wrote:

> ***** High Performance Software Defined Radio Discussion List *****
>
> 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> 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.
>>
>>
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20190430/1762c64d/attachment.html>