<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Bill,<br>
<br>
I like your (or SatNOGS) simple connection procedure. I agree that
data encryption is not needed. Do we need any encryption on the
command channel?<br>
<br>
The answer to all three of your questions is yes.<br>
<br>
It may seem like an unnecessary burden, and for PSWS that may be
true. But TAPR has much greater plans for this hardware, and we
would like to be able to use the same protocol that we are going to
develop for PSWS.<br>
<br>
So perhaps PSWS can limit the connections in its implementation, I
would like the protocol at least to support all of the connection
options. I call the radios "servers" and the SBCs "clients". I would
like any number of clients to request data from any number of
servers. I do not envision server-to-server or client-to-client
paths, unless you see a use for them.<br>
<br>
Can you see any use to having servers talk to servers, or clients
talk to clients?<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
<div class="moz-cite-prefix">On 2019-05-08 09:06, Engelke, Bill
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:cb84a48a4d4e4f3fa1fbb35f8c10435d@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;}
code
{mso-style-priority:99;
font-family:"Courier New";}
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;}
p.gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph, li.gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph, div.gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph
{mso-style-name:gmail-m_-8848661953787744719gmail-m_-1650918065519285657msolistparagraph;
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-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:1674528947;
mso-list-type:hybrid;
mso-list-template-ids:2100459046 -1696147714 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:4;
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;}
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
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">I
just now saw this, as yesterday I got caught up in a project
of having to move my desk to a new location and all the mess
that goes along with it (moving computers, getting them
working, etc.) … I haven’t read the entire backlog of mail
on this, but I would like to mention a few things about the
Host SBC devices connecting to central.<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">Here
is what I envision (this is similar to how SatNOGS does it,
and it works well) –<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:l0 level1 lfo1"><!--[if !supportLists]--><code><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></code><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">When
a new user wants to connect his system to central, he goes
to central and creates an account. (This is then verified
thru email). Once the user is registered, he gets access to
a profile page where there will be a Token (something
like
</span><code><span style="font-size:10.0pt">3f127e21ba3@50d301cbe76a086ca0b6a77d8d37).</span></code><code><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></code></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 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">The
user copies & pastes the token into a config panel for
the radio connection service of the Host SBC.<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 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">The
Host SBC uses the token when connecting to the central
control system.
<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 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">I
don’t see any need to encrypt data in transit – seems like
an unnecessary processing burden.<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
have obtained the specs and code for the HPSDR and openHPSDR
projects and I am going thru the discovery code line by
line. I know we want to do some things differently, but this
is a starting point. I have my Odroid to where it will
successfully go thru the discovery process for a Red Pitaya
running Pavel Demin’s HPSDR firmware, spitting out all kinds
of logging info along the way.<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">QUESTIONS
FOR YOU:<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:l0 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">Do
we need to be able to support multiple radios on the same
network?<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 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">Do
we need to be able to support multiple Host SBC devices on
the same network?<o:p></o:p></span></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 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">Do
we need to be able to allow multi-to-multi operation? i.e.,
a given radio simuiltaneously connected to multiple Hosts
and/or vice-versa and all at the same time? <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<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> Tuesday, May 7, 2019 1:09 PM<br>
<b>To:</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>Cc:</b> Scotty Cowling <a class="moz-txt-link-rfc2396E" href="mailto:scotty@tonks.com"><scotty@tonks.com></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 Tom,<br>
<br>
Yes, I was dismayed to see that limitation carried over to
protocol 2. My planned network has one server and multiple
clients, something that neither HPSDR protocol can handle.<br>
<br>
The LCC can live with the discovery limitation, can it not?
Since it is intended to be Host<-->SDR communications
and never be exposed to the outside world (for security
reasons), it will only ever communicate on one subnet.<br>
<br>
The RCC, however, should not have that limitation. I am not
sure how individual stations will "hook in" to the network.
Will they have to register with a central server? Will they
then be polled? Or will they push data, once set up by the
central server? How is authentication done?<br>
<br>
The limitations of the IP stack in the FPGA certainly
contributed to the limitations. Phil VK6PH implemented it as a
state machine. I would not do it that way. I would use a
soft-core CPU (NIOS II) and a steerable state machine to make
it more easily programmable. Protocol changes would then be
mostly (if not all) software changes. They would still be FPGA
changes, but not low-level hardware changes to state machines.<br>
<br>
My intent for the protocol is to provide for discovery,
re-programming (for updates) and control using UDP with an ACK
layer added. The "control" part would be for hardware specific
control, as well as for setting up stream to/from the SDR and
external IP addresses. By external addresses, I mean the SBC's
address, other hosts' addresses on the local subnet as well as
addresses anywhere else on the Internet. These streams are set
up by the SBC, but once set up, stream directly between SDR
and designated IP address via UDP.<br>
<br>
We should define several different formats for streams, and
leave it open to add formats as desired. For example, we could
have a 32-bit I/Q format (16 bits I and 16 bits Q) a 16-bit
raw sample format (16-bit samples, back-to-back), a 64-bit
192Ksps I/Q stream (32-bits I and 32-bits Q), etc, etc. Each
stream would be set up with sample rate, data width, bit/byte
order, packet size, etc. Include a stream format ID (or maybe
this is implied, since the stream was set up in advance), and
we can add formats as needed. So we would have a Meta-tagged
format that included a metadata header with GPS time stamp,
timing mark, etc. followed by I/Q or raw samples (maybe
multiple different formats as required).<br>
<br>
One other comment on your PSWS spec v 0.2. I still think that
the delineation between the host and SDR is dictating an
SBC-centric architecture. It is not clear to me that the
"host" and "DE" are processes and not hardware blocks.<br>
<br>
73,<br>
Scotty WA2DFI<o:p></o:p></p>
<div>
<p class="MsoNormal">On 2019-05-07 09:58, Tom McDermott wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">HI Scotty - I did not know Protocol 2
had the same single endpoint IP address issues. The
limitations of protocol 1<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">made remote discovery impossible
without a proxy (the IP address of both devices have to
be on the same subnet).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Is it possible that the FPGA
intellectual property (IP stack) was responsible for
this limitation? If so, is something<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">else without those limitations
available for this project?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">LCC has a couple of key requirements
(listed in the System Spec) needed for PSWS. First is
the need to mark
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">which sample is aligned with the
timing mark, and identification of GPS time for the
frame data. It's really fundamental<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">to the project. I mention it in
section 6, but not in section 8. Probably should update
the document for that.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The other requirements for Section 6
could be handled outside of the data packets in any of
several different ways.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Nathaniel sent me the grant he wrote,
and some ideas on Ham usage. I will try to wrap all
that and the user cases into<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">some kind of document.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Nathaniel also said they are working
on finalizing the Magnetometer decision.<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>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, May 6, 2019 at 4:31 PM Scotty
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 #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<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">
<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">Hello
Tom & Scotty:</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">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"
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="gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-</span><span
style="font-size:7.0pt;color:#1F497D">
</span><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="gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-</span><span
style="font-size:7.0pt;color:#1F497D">
</span><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="gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-</span><span
style="font-size:7.0pt;color:#1F497D">
</span><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"
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">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"
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">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="gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph"
style="margin-left:.25in">
<span style="font-size:11.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><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="gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph"
style="margin-left:.25in">
<span style="font-size:11.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><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="gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph"
style="margin-left:.25in">
<span style="font-size:11.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><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="gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph"
style="margin-left:.25in">
<span style="font-size:11.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><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="gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph"
style="margin-left:.25in">
<span style="font-size:11.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><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="gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph"
style="margin-left:.25in">
<span style="font-size:11.0pt;font-family:Symbol">·</span><span
style="font-size:7.0pt">
</span><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"
target="_blank" 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"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </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">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"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </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">-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"><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"> </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 8:36 PM<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 - one of the problems when writing a new
specification is that the author has
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">undocumented
assumptions in their mind. The review process
helps get those discovered<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">and
then written into the spec or some other
document.<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">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"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">and
perhaps more later on.<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>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</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 1:16 PM 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">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>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <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>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
</body>
</html>