[hpsdr] Hermes II
Scott Traurig
scott.traurig at gmail.com
Sat Jan 20 11:02:00 PST 2018
Everyone in this game is far too hardware-centric. We have not even
scratched the surface of what the present day hardware can do because it is
hamstrung by an ancient user interface and a thick client software
architecture.
If I was king, and I'm pretty sure I'm not ;-), and if I knew anything
about writing software, which I don't, I'd be working full steam ahead on
an entirely new set of client-server software applications. Continuing to
use the outstanding WDSP library for all signal processing, of course.
Within the context of the current hardware, even limited to 100BASE-T
Ethernet, there could easily be:
- Support for more receivers, at least 7 at 192KHz each, CuSDR is proof of
that. And receivers need not be dedicated to transmit functions like
PureSignal, at the expense of some latency they could be switched between
RX and TX support as required.
- Support for VAC outputs to/from each RX (just like You Know Who). And
they could be fully time coherent for radio astronomy, and VAC
channelization could be made more flexible for those obscure app's that
need it.
- Support for transmit from any instance of a digi mode program on any
receiver (just like You Know Who).
- True client-server architecture, the server being another Windows or
Linux PC. The server could support GPU processing for FFTs (already being
done in SDR Console).
- Clients for every operating system and platform, local and remote (just
like You Know Who).
- Local low latency sidetone for both phone and CW on all clients.
- Contesting features, the list is endless, starting with a more
comprehensive set of band stack and VFO controls.
- More modern coding and UI design, with a fully modular interface that
supports multiple receivers and transmitters in a logical way (multiple
windows with docking capabilities, etc.)
- And probably a dozen other things I never thought of or have forgotten
about.
Write all that code and you wouldn't even recognize our radios.
AND...fix the timing problems in Protocol 2, and every receiver could
provide 1.5MHz of bandwidth. GPU FFT support on the server would deal with
that handily.
We don't need new hardware, we need new software, because, after all, this
is SOFTWARE defined radio. The hardware we've already got outstrips the
performance of the software handily.
73,
Scott/w-u-2-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20180120/67938cd3/attachment.html>
More information about the Hpsdr
mailing list