[hpsdr] New kind of Hermes

[Brian Lloyd]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20140507/e1effef4/attachment-0003.htm>