[hpsdr] New kind of Hermes

[Brian Lloyd]

On Tue, May 6, 2014 at 10:44 PM, <lstoskopf at cox.net> wrote:

> ***** High Performance Software Defined Radio Discussion List *****
>
> Boy will there be enough questions at Hamvention.  There is always the
> problem of upgrading and yet leaving the orphans behind.  I guess somewhere
> there is a need to do the Apple thing and totally start over, but meanwhile
> lots of good boards get left in the dust.


No.

What needs to be done is to define a standard interface so that as new
hardware is developed, existing software will work with it. Think about it,
we do this all the time on the Internet. Need a faster computer? Get one
and everything runs better on it. The protocols remain the same. Same for a
router, an access point, etc.

Think about it. We are talking about DDC/DUC "front ends". The ADC samples
the spectrum. The FPGA has the "code" to filter and decimate a "slice" of
the spectrum and deliver that over the ethernet to some other processing
engine for further processing. If you make the protocol over the ethernet
the same, you can have different ADCs, different FPGAs (or some kind of
ASIC) and experiment to your heart's content and still all the same
software running in the processing back-end will continue to work.

Bottom line: it's all about the protocols on the wire.

So the protocol needs to evolve to encompass future needs. As it occurs to
me here for about 15 seconds:

   1. Support for 'N' "slices" or "receivers" where 'N' is an unbounded
   number. (You want that so you can keep the same protocol as you move to
   gig-E and 10Gig-E or beyond.)
   2. Support for high-accuracy time-stamping of samples or sample buffers.
   (We might want to do some form of interferometry, beam-steering, or n-way
   diversity down the road.)
   3. Support for multiple TX channels concurrently. No reason we can't do
   multiplexed TX in the future. I can see HF protocol use for multiplexed TX
   if TX IMD is controlled to a reasonable level.
   4. Support for multiple data "sinks" for streams. If the hardware can
   produce twenty 384kbps I/Q "slice" streams for downstream processing, I can
   see where it might be desirable to have more than one consumer of those
   streams. 10 medium-power computers will be a lot easier to procure than 1
   super-duper high-power machine. And then you can be running different
   software to process those streams. Why not have dedicated machines for CW,
   SSB, digital, WinLink, WSPR, etc.? (Does multiplexed TX start to sound more
   interesting now?)

And why assume that your "station" will be all in one place? Why not put
your receiver(s) on one side of town and your transmitter(s) on another.
100Mbps Internet connection are becoming more commonplace. (I have 80Mbps
fiber service to my house and it is only limited to 80Mbps
administratively.) Park the TX at your buddy's place and the receivers at
your place and then share them. He can work whatever he likes and you can
work whatever you like.

Oh, and you both can work full duplex. QSK? Full-duplex is the ultimate
QSK. Stop thinking about RX/TX turnaround times when you don't ever have to
switch from RX to TX and back again.

And all this is possible TODAY.

-- 
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/d30e781e/attachment-0004.htm>