<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Bill,<br>
<br>
I think it is unworkable.<br>
<br>
The HPSDR protocol is hardwired to talk from exactly one SDR
(referred to as "SDR hardware") to exactly one Host (referred to as
"PC").<br>
<br>
No provision is made for multiple discovery requests, and you cannot
stream data to more than one IP address. So all 192K slice receivers
would have to stream to the same hardware (same IP address). Command
and control definitions are so married to the HPSDR and ANAN
hardware that we would probably not be compatible with any
off-the-shelf radios anyway.<br>
<br>
While I think we can base the protocol loosely on the HPSDR protocol
as a starting point, I think it is too restricted to be of general
use. I am working on a more general-purpose protocol for LCC that
would eliminate most, if not all, hardware-specific restrictions. We
can use some SDR hardware that I have already built to develop the
protocol, or use existing TAPR or Apache Labs Hermes boards or even
ANAN radios. They all have FPGAs in them, so we can program them to
do the SDR end of the protocol for testing. I would be willing to
work on the FPGA end if someone wants to work on the Host end so we
can get a system up and running.<br>
<br>
My goal is a hardware-agnostic, multiple client, multiple server
protocol that would handle streaming of I/Q data, raw sample data,
RX audio, TX audio, and control commands, as well as re-programming
of the hardware over Ethernet. HPSDR protocol 2 is far from this
goal.<br>
<br>
Do you have a networking expert (maybe that would be you?) that we
can get in on the definition?<br>
<br>
I don't want to interfere with your progress, but the above were
features that I wanted to be included in protocol 2 that were not. I
think that the use of different (changeable) ports for every RX
stream, but no changeable ports (or limited ports) for other types
of streams makes too many assumptions on the hardware that is on
each end.<br>
<br>
So can we start with a clean slate? Pretty please? :-)<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
<div class="moz-cite-prefix">On 2019-05-06 14:29, Engelke, Bill
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6f9c5bc1161b45cdbe780a076a271516@ua.edu">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:45763683;
mso-list-type:hybrid;
mso-list-template-ids:-2053207600 -1696147714 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.25in;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.75in;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.25in;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.75in;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.25in;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.75in;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.25in;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:523830260;
mso-list-type:hybrid;
mso-list-template-ids:2136610984 -1696147714 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:Calibri;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2
{mso-list-id:1033503204;
mso-list-type:hybrid;
mso-list-template-ids:-919992376 1106694796 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.25pt;
text-indent:-20.25pt;}
@list l2:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.5in;
text-indent:-.25in;}
@list l2:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:1.0in;
text-indent:-9.0pt;}
@list l2:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.5in;
text-indent:-.25in;}
@list l2:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.0in;
text-indent:-.25in;}
@list l2:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:2.5in;
text-indent:-9.0pt;}
@list l2:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.0in;
text-indent:-.25in;}
@list l2:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.5in;
text-indent:-.25in;}
@list l2:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:4.0in;
text-indent:-9.0pt;}
@list l3
{mso-list-id:1517693256;
mso-list-type:hybrid;
mso-list-template-ids:-1196682496 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l3:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.25in;
text-indent:-.25in;
font-family:Symbol;}
@list l3:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;
font-family:"Courier New";}
@list l3:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;
font-family:Wingdings;}
@list l3:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.75in;
text-indent:-.25in;
font-family:Symbol;}
@list l3:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.25in;
text-indent:-.25in;
font-family:"Courier New";}
@list l3:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.75in;
text-indent:-.25in;
font-family:Wingdings;}
@list l3:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.25in;
text-indent:-.25in;
font-family:Symbol;}
@list l3:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.75in;
text-indent:-.25in;
font-family:"Courier New";}
@list l3:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.25in;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hello
Tom & Scotty:<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Nathaniel
has given me the go-ahead to start working on the specs for
the software, which I understand to include:<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l1 level1 lfo1"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><span
style="mso-list:Ignore">-<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Functional
Specifications for the Central Control system and related
database<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l1 level1 lfo1"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><span
style="mso-list:Ignore">-<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Remote
Command and Control Protocol<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l1 level1 lfo1"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><span
style="mso-list:Ignore">-<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Functional
Specifications for the local control system (this is the SBC
often referred to as the Host)<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I
guess a part of this would touch on the Local Command and
Control Protocol (between the Host and Data Engine). Here’s
my 2 cents:<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-indent:-.25in"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">If
I would suggest to use openHPDSR protocol (or at least a
subset/superset of it). Reasons:<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:.25in;text-indent:-.25in;mso-list:l3 level1
lfo4">
<!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:Symbol"><span
style="mso-list:Ignore">·<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">We
can stand on the shoulders of the existing, proven design.<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:.25in;text-indent:-.25in;mso-list:l3 level1
lfo4">
<!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:Symbol"><span
style="mso-list:Ignore">·<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">If
somebody has another SDR (e.g., Red Pitaya, Hermes, etc.)
they could use these as the radio for the PSWS. (Note that
the central database will know what kind of radio every
observation came from, and if you are concerned about the
quality of data from a different type of radio, you can
simply exclude from any analysis that is sensitive to that
factor. WE WILL NOT SUPPORT any of these different radios
except to conform to our selected ported of the spec).<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:.25in;text-indent:-.25in;mso-list:l3 level1
lfo4">
<!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:Symbol"><span
style="mso-list:Ignore">·<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">We
may be able to re-use some existing working code.<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:.25in;text-indent:-.25in;mso-list:l3 level1
lfo4">
<!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:Symbol"><span
style="mso-list:Ignore">·<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Maybe
a user could use their PSWS as a radio (a receiver, at
least) under PowerSDR if they wanted to.<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:.25in;text-indent:-.25in;mso-list:l3 level1
lfo4">
<!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:Symbol"><span
style="mso-list:Ignore">·<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">We
can get started with software development even before the
new hardware is ready, because there are radios that conform
to the spec.<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="margin-left:.25in;text-indent:-.25in;mso-list:l3 level1
lfo4">
<!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:Symbol"><span
style="mso-list:Ignore">·<span style="font:7.0pt
"Times New Roman"">
</span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
have found the openHPSDR-Protocol-2 online at
<a class="moz-txt-link-freetext" href="https://github.com/TAPR/OpenHPSDR-Firmware/blob/master/Protocol%202/Documentation/openHPSDR%20Ethernet%20Protocol%20v3.8.pdf">https://github.com/TAPR/OpenHPSDR-Firmware/blob/master/Protocol%202/Documentation/openHPSDR%20Ethernet%20Protocol%20v3.8.pdf</a><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">If
anyone thinks this is definitely not workable, please let me
know, so that I can learn; I expect there are aspects of
this that I am not aware of, so I am open to all feedback…
thanks….<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">-73-
Bill, AB4EJ<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Tom
McDermott <a class="moz-txt-link-rfc2396E" href="mailto:tom.n5eg@gmail.com"><tom.n5eg@gmail.com></a>
<br>
<b>Sent:</b> Sunday, May 5, 2019 8:36 PM<br>
<b>To:</b> Engelke, Bill <a class="moz-txt-link-rfc2396E" href="mailto:bill.engelke@ua.edu"><bill.engelke@ua.edu></a><br>
<b>Cc:</b> TAPR TangerineSDR Modular Software Defined Radio
<a class="moz-txt-link-rfc2396E" href="mailto:tangerinesdr@lists.tapr.org"><tangerinesdr@lists.tapr.org></a><br>
<b>Subject:</b> Re: [TangerineSDR] PSWS System Specification
preliminary Ver 0.1<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Hi Bill - one of the problems when
writing a new specification is that the author has
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">undocumented assumptions in their
mind. The review process helps get those discovered<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">and then written into the spec or some
other document.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This thread is good because it has
uncovered several of those that need writing out.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">For this project, it is apparent that
we need a use case document, covering the two cases,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">and perhaps more later on.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-- Tom, N5EG<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Sun, May 5, 2019 at 1:16 PM Engelke,
Bill <<a href="mailto:bill.engelke@ua.edu"
moz-do-not-send="true">bill.engelke@ua.edu</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Tom
– OK, I get it. Thanks for being patient with me,
I’m trying to understand as much as possible about
this so that I can properly guide the software
development. There are indeed people / organizations
that have major local horsepower, and it is
certainly advisable to ensure they can roll their
own system if they wish to. -73- Bill AB4EJ</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Tom
McDermott <<a href="mailto:tom.n5eg@gmail.com"
target="_blank" moz-do-not-send="true">tom.n5eg@gmail.com</a>>
<br>
<b>Sent:</b> Sunday, May 5, 2019 10:23 AM<br>
<b>To:</b> Engelke, Bill <<a
href="mailto:bill.engelke@ua.edu" target="_blank"
moz-do-not-send="true">bill.engelke@ua.edu</a>><br>
<b>Cc:</b> TAPR TangerineSDR Modular Software
Defined Radio <<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank" moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>><br>
<b>Subject:</b> Re: [TangerineSDR] PSWS System
Specification preliminary Ver 0.1</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi
Bill - Your understanding is one particular
implementation, it's the same implementation that
Scotty is assuming.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Given
today's silicon technology it may be the only
practical implementation. Given tomorrow's
technology maybe not.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">There
could be several use cases: the one you are
assuming, where the remote PSWS is accessed over
the Internet. and<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">where
remote-->server bandwidth is a significant
limitation. For that case Nathaniel laid out the
need for the remote station to
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">stream
to local non-volatile storage, then be triggered
during an event of interest to send a small data
subset back to a central<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">server.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">But
there is another use case where the PSWS is
located on the same LAN as the server. Phil
Erickson expressed interest<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">in
this case. For this case perhaps folks would want
to stream continuously over the LAN to that
server, providing greater<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">data
capture capability. For this use case an
inexpensive Host function might not be able to
keep up. Essentially, it's replacing<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">the
low-cost host function with one that's a lot more
powerful, perhaps integrated with a local server.
With software modularity<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">perhaps
the host software could be portable, or maybe
that's phase 2 (or maybe phase never).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">So
the spec is drafted in an attempt to try not to
limit the use case.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">--
Tom, N5EG<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On
Sun, May 5, 2019 at 7:23 AM Engelke, Bill <<a
href="mailto:bill.engelke@ua.edu"
target="_blank" moz-do-not-send="true">bill.engelke@ua.edu</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid
windowtext 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-color:currentcolor
currentcolor currentcolor rgb(204,204,204)">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hi
Tom – a couple of notes – My understanding
is that the Host Computer (local control
system, SBC) will be connected to the DE vu
gigabit Ethernet.</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Also
I have a concern about the statement in
System Spec rev 0.2 -
</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:9.0pt">If the DE and Host
are physically separate devices, then the DE
may need to stream data directly to the
central server if the Host cannot process
fast enough.</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">There
will not be sufficient capacity either in
the central sever nor the user’s internet
bandwidth to stream directly. Very high
speed upload is the exception rather than
the rule in the US, and we can’t assume we
will have the funding for a central host
able to receive this data rate from lots of
PSWS units at once. I think we have to
<b>ensure that the local control system is
able to process fast enough</b> by how we
design the whole system. If I am missing
something, please let me know.</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-73-
Bill AB4EJ</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
TangerineSDR <<a
href="mailto:tangerinesdr-bounces@lists.tapr.org"
target="_blank" moz-do-not-send="true">tangerinesdr-bounces@lists.tapr.org</a>>
<b>On Behalf Of </b>Tom McDermott via
TangerineSDR<br>
<b>Sent:</b> Sunday, May 5, 2019 8:13 AM<br>
<b>To:</b> TAPR TangerineSDR Modular
Software Defined Radio <<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank" moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>><br>
<b>Cc:</b> Tom McDermott <<a
href="mailto:tom.n5eg@gmail.com"
target="_blank" moz-do-not-send="true">tom.n5eg@gmail.com</a>><br>
<b>Subject:</b> Re: [TangerineSDR] PSWS
System Specification preliminary Ver 0.1</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi
Scotty<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The
spec says that there is a DE function and
a Host Computer function - it doesn't say
how they are<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">physically
connected or implemented. If that is
unclear then the spec is not written well
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">enough
and other folks will likely make the same
(mis)interpretation, so it should be
reworded.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks
for idea about the synthesizer. You are
right, the SL spec does say that the
output dividers are all<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">synchronously
reset at power up and can also be reset by
the programmer to re-sync. It also says
they<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">will
maintain phase-sync across outputs that
are derived from the same synthesizer. I
will make some<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">measurements
on the Eval Board across the 4 outputs to
see how well they stay aligned. I hope
it's<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">not
susceptible to glitches un-syncing them.
That would be a dog to debug in the field.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">--
Tom, N5EG<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On
Sat, May 4, 2019 at 6:27 PM Scott Cowling
via TangerineSDR <<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank" moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid
windowtext 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-color:currentcolor
currentcolor currentcolor rgb(204,204,204)">
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi
Tom,<br>
<br>
OK, I was thinking that the four outputs
of the AD5344 would be our <br>
Clock Module outputs. One to the FPGA, one
to each RF Module, one <br>
external. If you wanted two or more of
them phase-coherent, just drive <br>
them from the same AD5344 synthesizer.
Then the AD5344 output block <br>
would perform our clock distribution,
making an additional chip <br>
unnecessary. The variable frequency
provided by the AD5344 synthesizers <br>
would be used to configure clock outputs
for different kinds of RFMs. <br>
This would enable us to build a low-cost
LowFER RFM (100kHz-500KHz) that <br>
samples at, say, 10MHz if we want to. NCOs
are totally under the control <br>
of the DE, so they can be designed as one
shared NCO or multiple NCOs as <br>
desired.<br>
<br>
Yes, the whole point it to have the
hardware that is best suited to each <br>
task, do that task.<br>
<br>
Implementing a full TCP/IP stack or SSH in
the FPGA is an expensive use <br>
of hardware (so let the SBC do it).
Implementing decimation and slice <br>
filtering in the SBC puts an unreasonable
burden on a low-cost <br>
general-purpose SBC (so let the FPGA do
it).<br>
<br>
Tom, it just seemed like you were picking
one way over another in your <br>
document by having a DE section 6 and a
Host PC section 7. I agree that <br>
we need to specify the tasks, but not
necessarily the hardware that does <br>
each one. Hopefully it will become obvious
where each task is best <br>
handled when we document the needed steps.
And I am trying really hard <br>
to keep the SBC out of the main flow, if
possible. (Maybe it is not.)<br>
<br>
It was never my intention to allow the
user to pick any old SBC for <br>
PSWS. My intent was to be flexible enough
that *we* could pick from many <br>
alternatives and pick the one that works
best for us.<br>
<br>
All these options will get out of control
very quickly if we let users <br>
pick whichever ones they want. It will
turn out exactly as you describe! <br>
Just look at the early days of Flex, when
users got to pick their own <br>
sound card to use with the SDR-1000. Total
mayhem, even after Flex TOLD <br>
them to use "brand X, model Y" cards.<br>
<br>
The options are for US to more easily
build something that meets the <br>
requirements that this specification is
enumerating (and others that we <br>
decide to support). And if users want to
play, that is fine. They do so <br>
at their own skill level. We support only
those configurations that we <br>
have engineered to meet specific targets.<br>
<br>
OK, I'm off my soapbox now. :-)<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
<br>
On 5/3/19 8:36 AM, Tom McDermott wrote:<br>
> Hi Scotty - yes, having one
synthesizer output feed two clock drivers
<br>
> (one per RFM) would be fine.<br>
> It's not a problem to have a phase
offset, provided that offset does not <br>
> change.<br>
> <br>
> I don't think it's a problem to have
fixed frequency on the ADC clocks. <br>
> That clock is not used to tune the
receiver,<br>
> the NCO in the DE is used to tune the
receiver. So the DE can implement <br>
> one NCO for the synchronous case,<br>
> and two NCOs for the case where we
want the two receivers to tune to <br>
> different frequencies.<br>
> <br>
> While the spec describes SBC and DE,
those two functions could <br>
> theoretically co-exist on on module
(for<br>
> example the Red Pitaya) where the
FPGA does both the DE function, and <br>
> via the CPU-block does the SBC<br>
> function. A concern with having the
FPGA do both is the lack of <br>
> sufficient computational capability
in the<br>
> limited CPU performance that's
implemented on the FPGA die. So the <br>
> spec tries to separate the
functionality<br>
> without saying where it's physically
implemented.<br>
> <br>
> I do hope we restrict ourselves to
one implementation. If folks can <br>
> choose any SBC, any Receiver, etc.
then there<br>
> will be no end of "The software
doesn't work on my combination", "My <br>
> hardware receivers aren't coherent",<br>
> "My hardware is overflowing buffers",
"My hardware doesn't support <br>
> amplitude calibration" ad nauseum.<br>
> The data that is produced risks being
largely garbage.<br>
> <br>
> -- Tom, N5EG<br>
> <br>
> <br>
> <br>
> On Fri, May 3, 2019 at 7:08 AM Scotty
Cowling via TangerineSDR <br>
> <<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank" moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>
<mailto:<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank" moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>>>
wrote:<br>
> <br>
> Hi Tom,<br>
> <br>
> Regarding the clocks, it seems
that the AD5344 addresses this<br>
> problem with the cross-point
switch and synchronous dividers.<br>
> <br>
> We can feed two outputs with one
synthesizer if we like, for a fixed<br>
> (and very small) phase offset.
Routing one clock output to two RF<br>
> Modules is problematic,
especially with LVDS outputs. Wouldn't
this<br>
> work?<br>
> <br>
> Alternatively, we could put a
clock distribution chip on the DE to<br>
> take one Clock Module output and
distribute it to FPGA, RFM1 and<br>
> RFM2, but then we lose the
capability to clock the RFMs at different<br>
> frequencies (for example, when
one is a TX and one is an RX).<br>
> <br>
> One thing to keep in mind is that
the FPGA has multiple clock<br>
> inputs, so we can route one from
each RFM, one from the Clock Module<br>
> and one from a local oscillator
and let the FPGA code decide which<br>
> one to use. Of course, we would
have to either let the FPGA generate<br>
> the RFM clocks or route multiple
clocks to each RFM to clock the<br>
> ADCs directly. The reason I bring
this up is that I want to use an<br>
> on-board inexpensive oscillator
(and no Clock Module at all) as the<br>
> inexpensive, entry-level SDR. No,
the performance would not be as<br>
> good. But the cost would be much
lower than with any clock module,<br>
> and it would be selectable by
simply loading the FPGA with a<br>
> different image and unplugging
the Clock Module.<br>
> <br>
> The section 7 comment was not
intended to dictate a data flow path.<br>
> I just wanted to show that we
need (and will have) two GbE ports to<br>
> use that path in case we want to
handle data in this way (for<br>
> example, if the SBC cannot keep
up). We can word it in whatever way<br>
> makes it clear that we can do it
either way. Isn't your description<br>
> implementation specific also
(i.e., data flows through the SBC)?<br>
> <br>
> Maybe for PSWS, the data has to
flow through the SBC? That is the<br>
> impression I got, and I am not
sure we want to restrict the<br>
> architecture that way, but we
could if that is our intent.<br>
> <br>
> 73,<br>
> Scotty WA2DFI<br>
> <br>
> <br>
> On 2019-05-03 04:09, Tom
McDermott wrote:<br>
>> Thanks for the good comments,
Scotty !<br>
>><br>
>> Section 3: the ADC clocks
MUST come from the same one synthesizer<br>
>> output. If they<br>
>> come from two different
outputs there is a big problem...<br>
>><br>
>> The clocks to the two ADCs
must be (and remain) phase coherent.<br>
>> If the ADC clocks come<br>
>> from different outputs of the
synthesizer, then each time the<br>
>> synthesizer starts, there
could<br>
>> be any phase difference
between the two. Further they could drift<br>
>> back and forth relative to
one another<br>
>> a little bit because of the
way synthesizers work. Thus the phase<br>
>> between them under<br>
>> the best case would be +/-
180 degrees. At 30 MHz that would<br>
>> represent +/- 45 degrees.
This<br>
>> means that the baseband
sampled signal at 30 MHz would also have<br>
>> an unknown phase<br>
>> difference of +/- 45
degrees. That completely wrecks the
ability<br>
>> to discriminate polarization.<br>
>><br>
>> There can be a difference in
phase between the two ADC clocks, but<br>
>> it must remain constant over
time.<br>
>> Any difference will be
calibrated out when the antennas and<br>
>> feedlines are calibrated for
phase delay.<br>
>> But then the phase
differences cannot change. The only way I
see<br>
>> to do that is to have one<br>
>> synthesizer output that is
distributed to the two ADC clocks. If<br>
>> the ADCs are on different
modules<br>
>> then one clock signal has to
be routed to the two of them in some<br>
>> manner (parallel,
daisy-chained, etc.)<br>
>> Maybe there is some other way
but it's difficult to see.<br>
>><br>
>> This is one of those things
that makes phase coherent receivers<br>
>> very difficult, and why
off-the-shelf units<br>
>> have to be carefully
evaluated, as virtually none of the ones
I've<br>
>> seen address this problem
properly.<br>
>> It's the Radio Astronomy
problem.<br>
>><br>
>> Section 7: The spec attempts
to be implementation-non-specific. <br>
>> Forcing a particular method<br>
>> to distribute Ethernet data
may eliminate all other potential<br>
>> solutions. The approach you
outline<br>
>> is a really good and elegant
solution, but the spec should not<br>
>> mandate it (it should allow
it).<br>
>><br>
>> Section 8: great comment. I
will restructure as you outline.<br>
>><br>
>> -- Tom, N5EG<br>
>><br>
>><br>
>><br>
>> On Thu, May 2, 2019 at 5:27
PM Scotty Cowling via TangerineSDR<br>
>> <<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank" moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>
<mailto:<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank" moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>>><br>
>> wrote:<br>
>><br>
>> Hi Tom,<br>
>><br>
>> Here are my comments on
your excellent document.<br>
>><br>
>> 73,<br>
>> Scotty WA2DFI<br>
>><br>
>> Notes on PSWS
Specification V 0.1 5 May 2019<br>
>><br>
>> Section 3.0<br>
>> Clock module will have 4
*programmable clock* outputs:<br>
>> 1. FPGA<br>
>> 2. RF Module #1<br>
>> 3. RF Module #2<br>
>> 4. High-speed Reference
Clock<br>
>><br>
>> In addition, two more
outputs:<br>
>> 5. 1 PPS timing<br>
>> 6. 10MHz fixed reference<br>
>><br>
>> Clock outputs should be
differential LVDS. Single ended clocks<br>
>> will be<br>
>> too noisy, especially
across a connector boundary.<br>
>><br>
>> The FPGA should not
provide the ADC clocks, they should come<br>
>> directly<br>
>> from the clock module.
The ADC may supply a source-synchronous<br>
>> data<br>
>> clock to the FPGA.<br>
>><br>
>> Section 4.0<br>
>> Magnetometer interface
can be I2C, SPI, serial UART or RS-485.<br>
>><br>
>> The magnetometer will
almost certainly need to be remotely<br>
>> mounted. In<br>
>> this case, RS-485 is
recommended. We can specify two-wires for<br>
>> communictions and two
wires for power (typically 5V).<br>
>><br>
>> Section 5.0<br>
>> It is not immediately
clear that *each* RF Module has two<br>
>> synchronous<br>
>> channels.<br>
>><br>
>> Note that the *pluggable
filter* can be bypassed with a<br>
>> jumper, making<br>
>> it optional. Maybe call
it "optional pluggable filter".<br>
>><br>
>> Section 6.<br>
>> The DE shall also be
capable of sourcing or sinking UDP data<br>
>> streams<br>
>> to/from any IP address,
under direction of the host processor.<br>
>><br>
>> The DE will have a
three-port GbE switch, connecting the
FPGA,<br>
>> host PC<br>
>> and external network. How
do you want to explain this?<br>
>><br>
>> Section 7.0<br>
>> Processing the stream
from the DE is optional, since it may<br>
>> not be able<br>
>> to process this much
data. The metadata tasks will fall to the<br>
>> DE in<br>
>> this case.<br>
>><br>
>> The host will not always
transmit the data to the central<br>
>> server. The<br>
>> host may direct the DE to
stream data directly to the central<br>
>> server if<br>
>> it cannot process the
volume or rate of data.<br>
>><br>
>> Section 8.<br>
>> I have been using
"Command and Control Protocol" for the<br>
>> protocol used<br>
>> between the central
server and the host PC. I have been using<br>
>> "Local SDR<br>
>> Protocol" for the
protocol between the host PC and the DE.<br>
>><br>
>> We could use "Remote
Command and Control", or "RCC" for the<br>
>> host<-->central
server communications, and "Local Command
and<br>
>> Control"<br>
>> or "LCC" for
host<-->DE communications. Whatever
we use, we<br>
>> should<br>
>> define it.<br>
>><br>
>> The Remote Command and
Control section seems to be missing<br>
>> (although you<br>
>> refer to it once in
section 10). Even though we don't know<br>
>> what the<br>
>> protocol is, I think
it should be mentioned (as defined an<br>
>> a separate<br>
>> document?)<br>
>><br>
>> I think we need to make a
clear distinction between Remote C&C<br>
>> and Local<br>
>> SDR C&C. We will need
security and maybe encryption on the<br>
>> Remote C&C,<br>
>> but not so much on the
Local SDR protocol.<br>
<br>
<br>
<br>
-- <br>
TangerineSDR mailing list<br>
<a
href="mailto:TangerineSDR@lists.tapr.org"
target="_blank" moz-do-not-send="true">TangerineSDR@lists.tapr.org</a><br>
<a
href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org"
target="_blank" moz-do-not-send="true">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>