<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Bill,<br>
<br>
I guess it would be good to scan through the protocol 2 document,
just to see how they did it. I do not have a requirements document.
Can we get together at Hamvention next week and see what we can do
about that?<br>
<br>
I can send you the (work-in-progress) sections from my (now called)
LCC spec. It outlines how I think protocol should work, but doesn't
have all the definitions behind it yet. Might get us on the same
page (even if it is a low-numbered one :-) anyway.<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
<div class="moz-cite-prefix">On 2019-05-07 09:24, Engelke, Bill
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5a1e8e76de0d43a1b2194aed15374ce1@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;
color:black;}
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;
color:black;}
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;
color:black;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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:523830260;
mso-list-type:hybrid;
mso-list-template-ids:2136610984 -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;
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;
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;
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;
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;
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;
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;
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;
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;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:1517693256;
mso-list-type:hybrid;
mso-list-template-ids:-1196682496 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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 l1: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">Scotty
– thanks for the info; absolutely we can start with a clean
slate, if we need functionality the existing protocol can’t
provide. (Although, I’d respectfully suggest that we be
really sure that all the notional added functionality is
really necessary so that we don’t create something that is a
real bear to implement if we don’t have to. Traditionally,
IBM has often done that – specifying something that is so
general purpose that you can’t hope to use it without
attending a 120 hour class). <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">Do
you have the design goals in a document? Again, this would
help me to learn. I have the disadvantage that I was not
involved in any earlier TAPR work, so I have a bit of a
learning curve.<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">Regarding
a network expert, if something is beyond my knowledge level,
I do have plenty of people to pull in. The one concern at
this point is that we are starting serious work on this
before funding is available. This is no problem for me
personally, but I have to be careful about asking for too
many “pro bono” hours from colleagues without funding,
because that can impact other projects that ARE funded, and
that can attract unwanted attention from legal people. I am
available to write some Host code, and I have a variety of
computers available, including R-Pi and Odroid, as well as
VMWare that will run a variety of different O/Ss.<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">-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>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
TangerineSDR <a class="moz-txt-link-rfc2396E" href="mailto:tangerinesdr-bounces@lists.tapr.org"><tangerinesdr-bounces@lists.tapr.org></a>
<b>On Behalf Of </b>Scotty Cowling via TangerineSDR<br>
<b>Sent:</b> Monday, May 6, 2019 6:31 PM<br>
<b>Cc:</b> Scotty Cowling <a class="moz-txt-link-rfc2396E" href="mailto:scotty@tonks.com"><scotty@tonks.com></a>; 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>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">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<o:p></o:p></p>
<div>
<p class="MsoNormal">On 2019-05-06 14:29, Engelke, Bill wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hello
Tom & Scotty:</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></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:</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="font-family:"Calibri",sans-serif"><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</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="font-family:"Calibri",sans-serif"><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</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="font-family:"Calibri",sans-serif"><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)</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></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:</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></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:</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:.25in;text-indent:-.25in;mso-list:l1
level1 lfo4">
<!--[if !supportLists]--><span style="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.</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:.25in;text-indent:-.25in;mso-list:l1
level1 lfo4">
<!--[if !supportLists]--><span style="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).</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:.25in;text-indent:-.25in;mso-list:l1
level1 lfo4">
<!--[if !supportLists]--><span style="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.</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:.25in;text-indent:-.25in;mso-list:l1
level1 lfo4">
<!--[if !supportLists]--><span style="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.</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:.25in;text-indent:-.25in;mso-list:l1
level1 lfo4">
<!--[if !supportLists]--><span style="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.</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="margin-left:.25in;text-indent:-.25in;mso-list:l1
level1 lfo4">
<!--[if !supportLists]--><span style="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
href="https://github.com/TAPR/OpenHPSDR-Firmware/blob/master/Protocol%202/Documentation/openHPSDR%20Ethernet%20Protocol%20v3.8.pdf"
moz-do-not-send="true">
https://github.com/TAPR/OpenHPSDR-Firmware/blob/master/Protocol%202/Documentation/openHPSDR%20Ethernet%20Protocol%20v3.8.pdf</a></span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></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….</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">-73-
Bill, AB4EJ</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></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 href="mailto:tom.n5eg@gmail.com" moz-do-not-send="true"><tom.n5eg@gmail.com></a>
<br>
<b>Sent:</b> Sunday, May 5, 2019 8:36 PM<br>
<b>To:</b> Engelke, Bill <a
href="mailto:bill.engelke@ua.edu" 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"
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"> <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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<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>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
</body>
</html>