<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Scott,<br>
<br>
Agreed that you can either keep up in real time or you can't.<br>
<br>
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.<br>
<br>
Latency can also come from other sources, such as large
packetization or communications channel latency.<br>
<br>
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.<br>
<br>
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.
:-)<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
<div class="moz-cite-prefix">On 2019-04-30 04:35, Scott Traurig
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGK9zXrcd1hM-1CWmJqXM1iMyqqgyQeeMUpNbUDiraWh2RRBkA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Scotty,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>73!</div>
<div><br>
</div>
<div>Scott/w-u-2-o</div>
<div><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Apr 30, 2019 at 6:03
AM Scotty Cowling <<a href="mailto:scotty@tonks.com"
moz-do-not-send="true">scotty@tonks.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><br>
<div bgcolor="#FFFFFF"> Hi Scott,<br>
<br>
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?<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
<div class="gmail-m_-5409304110769795526moz-cite-prefix">On
2019-04-29 08:13, Scott Traurig wrote:</div>
<blockquote type="cite">
<div dir="ltr">
<div>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.</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>