<div dir="ltr"><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Within the context of the current hardware, even limited to 100BASE-T Ethernet, there could easily be:</div><div class="gmail_extra"><br></div><div class="gmail_extra">- 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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">- 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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">- Support for transmit from any instance of a digi mode program on any receiver (just like You Know Who).</div><div class="gmail_extra"><br></div><div class="gmail_extra">- 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).</div><div class="gmail_extra"><br></div><div class="gmail_extra">- Clients for every operating system and platform, local and remote (just like You Know Who).</div><div class="gmail_extra"><br></div><div class="gmail_extra">- Local low latency sidetone for both phone and CW on all clients.</div><div class="gmail_extra"><br></div><div class="gmail_extra">- Contesting features, the list is endless, starting with a more comprehensive set of band stack and VFO controls.</div><div class="gmail_extra"><br></div><div class="gmail_extra">- 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.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">- And probably a dozen other things I never thought of or have forgotten about.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Write all that code and you wouldn't even recognize our radios. </div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">73,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Scott/w-u-2-o</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>