[hpsdr] New kind of Hermes

Wed May 7 15:16:37 PDT 2014

Folks should note that for those that can/will attend the Dayton Hamvention, Scotty and I will be speaking along with Steve Hicks from Flex on future SDR directions, both generically and for OpenHPSDR in particular.  You're also always welcome to come bend our collective ears over at the TAPR booth.

On May 7, 2014, at 3:07 PM, Brian Lloyd <brian at lloyd.com> wrote:

> ***** High Performance Software Defined Radio Discussion List *****
> 
> Well, as long as I started on this outline of What Should Be, I should probably throw in a couple other systems concepts that occur to me.
> 
> One of the very first things is that hams have to relinquish their love-affair with the Collins KWM-2. For something like 60 years we have been building variations of the KWM-2 and nothing has changed appreciably. Most transceivers you see today are STILL a variation of the KWM-2. Even PowerSDR is a glorified copy of the KWM-2. Basically the KWM-2 downconverts a "channel", usually on the order of 3kHz wide, to baseband. It also upconverts from baseband to someplace in the HF spectrum. So we have this one-3kHz-wide-channel mindset/view of the world. 
> 
> With the advent of SDR and more specifically DDC/DUC SDRs, we no longer are tied to that KWM-2/superhet view of the world. But we are still trying to force DDC/DUC into that model. To me this is much like the way people treated the early "horseless carriage" which was basically a horse-drawn carriage with an internal combustion engine for power. It was still a carriage, not a car. And it sure as heck wasn't a helicopter. 
> 
> So the transition to SDR is not a technical one. We have the technology today. It is a done deal. The REAL transition is in the minds of the people using the technology. They have to start THINKING about it differently.
> 
> That being said, I am going to make some technical comments. One of the key things to this "SDR Of The Future" I am thinking of requires the ability to process HUGE chunks of spectrum concurrently, not just 3kHz. I keep seeing people talking of putting the DSP into the box with the ADC or maybe running a soft-core in the FPGA and doing the DSP in that, then outputting the 3kHz-wide channel over Ethernet. NO! Flex is going that route and it works only if you keep your mind in the KWM-2 mindset where you think that the world still lives in a single 3kHz channel. (OK, two or three 3kHz channels because you are into SO2R, but the point is the same.) We need to preserve and expand the (for want of a better word) fast-wide IF that carries our spectrum "slices" to MANY back-end processing engines. Each back-end processing engine then runs one or more CODECs. And you can build ALL kinds of CODECs. You can have the RTTY CODEC, the digital voice CODEC, the analog SSB CODEC. the WSPR CODEC, the CW Skimmer CODEC.
> 
> But I also recognize that we can't distribute a lot of 10Mbps "slices" of spectrum over the Internet. We do need to be able to distribute a single baseband channel at a lower bitrate. But that comes out of our back-end processing engine(s), not out of our fast-wide IF. We need BOTH.
> 
> And in my last rant/visionary-posting/lunacy I said I don't want any kind of reasonable limit on things in the protocol. One of the things that the Internet has taught is that, "Oh, we will NEVER need more than that," always turns out to be a lie. I might want to send a whole bunch of 4kHz I/Q channels (8kHz sample rate, 16 bits/sample). Well something like 39,000 of those will fit into a 10Gig-E ethernet. I guess that means we could get away with a 16-bit unsigned int for slice/channel ID. That being the case, let's make it 32 bits and hope it will be enough. (Yes, I am serious about that!) Remember that network capacity will ALWAYS increase and processing capacity will ALWAYS increase. So shoot for the moon, make it obscenely large, then double it for good measure. 
> 
> Hmm, we are thinking of channel/receiver ID numbers and I just came up with a legitimate way to think we could potentially have almost 40K channels on one 10Gig-E stream. But what about GLOBAL channel identifiers? They probably want to be unique, right? I suppose we could concatenate a locally-unique channel ID with a globally-unique receiver ID and produce a globally-unique channel ID that way. But the point is, we need to be thinking about how to do that NOW so we don't have to do it over again later.
> 
> OK, sorry. I got carried away. Never mind.
> 
> -- 
> Brian Lloyd, WB6RQN/J79BPL      
> 706 Flightline Drive
> Spring Branch, TX 78070
> brian at lloyd.com
> +1.916.877.5067
> _______________________________________________
> 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/

--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj at xenotropic.com

 1399500997.0