<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<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;}
p.gmail-m9035196836942227800gmail-m2547716944428976612gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph, li.gmail-m9035196836942227800gmail-m2547716944428976612gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph, div.gmail-m9035196836942227800gmail-m2547716944428976612gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph
{mso-style-name:gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-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;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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:488521997;
mso-list-type:hybrid;
mso-list-template-ids:1374209874 -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;}
@list l1
{mso-list-id:1067998280;
mso-list-type:hybrid;
mso-list-template-ids:1293420082 -1696147714 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1: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 l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
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]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Scotty – OK, maybe I am starting to get more clear on your concept. I understand now that Tangerine is a new general purpose radio, not specific to PSWS. In
fact, from the requirements you have outlined, it sounds like our own flavor of FlexRadio. To me, that suggests it will need to have (between the FPGA and the DE) some additional functionality that I hadn’t realized before, such as….<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![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">A web server (Alpine?) which talks to a user’s browser, so that the user can configure, enter user-ID and password (or token), enter server hostname
(or IP), select SBC (if desired), etc.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![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">A way for the user to find the radio on the network for the first time (maybe by having it respond when the user enters a hostname, a portion of which
is the DE’s MAC address (e la Red Pitaya).<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo2"><![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">Ability to securely handshake with the server, and provide some diagnostic information to the user when there are connectivity problems, etc. For security,
probably we need to specify that DE-to-server connectivity must be initiated by the DE.<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">We should ensure we have a security concept so that the system is not subject to being attacked by hackers – for home systems, we may need to specify how the
user configures their router to allow DE-to-server traffic. For systems in institutions, we just need to tell IT what firewall ports need to be opened, for what traffic.<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">Any related thoughts? -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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<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 <tangerinesdr-bounces@lists.tapr.org>
<b>On Behalf Of </b>Scotty Cowling via TangerineSDR<br>
<b>Sent:</b> Thursday, May 9, 2019 5:53 PM<br>
<b>To:</b> tangerinesdr@lists.tapr.org<br>
<b>Cc:</b> Scotty Cowling <scotty@tonks.com><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>
UDP over Internet is not necessarily needed for PSWS, but it is a requirement for TangerineSDR. PSWS requirements are intended to be subset of TangerineSDR capabilities.<br>
<br>
It will also be requirement if the SBC cannot keep up with the traffic, but the network can.<br>
<br>
Even if the normal case is that the SBC can saturate *most* users' Internet connection, some will have high speed connections that would permit us to collect more data than an SBC might be able to process. I just want to keep the option open in the architecture
if we need it.<br>
<br>
The programmable nature of the FPGA (and of course the SBC) makes a lot of these paths possible, but I assume that we will likely pick one path that will work for PSWS. It migth not be the path that works for P4G or different applications.<br>
<br>
73,<br>
Scotty WA2DFI<o:p></o:p></p>
<div>
<p class="MsoNormal">On 2019-05-08 09:23, Engelke, Bill via TangerineSDR 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">It is possible to stream UDP over the Internet – that’s how FlexRadio achieves its remote access for SmartSDR. I’m wondering though… what is the reason why this
is necessary? The PSWS is going to generate high data volumes; I thought the whole idea was to have a local Host SBC (which might cost like $50) so that we could realistically cope with the wide variety of different Internet speeds and network situations
without making the DE accommodate all those issues. Again, remember, the more we generalize the system, the more difficult to implement and the more difficult for a user to get set up and running, and the more things to go wrong… -73- Bill</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"> TangerineSDR
<a href="mailto:tangerinesdr-bounces@lists.tapr.org"><tangerinesdr-bounces@lists.tapr.org></a>
<b>On Behalf Of </b>Tom McDermott via TangerineSDR<br>
<b>Sent:</b> Tuesday, May 7, 2019 7:07 PM<br>
<b>To:</b> TAPR TangerineSDR Modular Software Defined Radio <a href="mailto:tangerinesdr@lists.tapr.org">
<tangerinesdr@lists.tapr.org></a><br>
<b>Cc:</b> Tom McDermott <a href="mailto:tom.n5eg@gmail.com"><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"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">HI Scotty - if the DE is going to stream out over the Internet then:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1. It must know and use the destination IP address. This could be done by management<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">action (i.e. a provisioning step that sets the address into DE), or some other way.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2. Some way to punch the appropriate hole in the firewall. Normally when you send,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">that will open the corresponding incoming firewall hole for a few minutes. The other end<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">needs to do the same, but if that's a server then it has resources to do that.<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">On Tue, May 7, 2019 at 12:34 PM Scotty Cowling via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org">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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi Tom,<br>
<br>
OK, so discovery in the LCC will work the same way as HPSDR (i.e., endpoints on the same subnet). It will not get passed on by routers or gateways. This is desirable protection.<br>
<br>
Discovery in the RCC, if there will be such a thing, will be handled by the SBC and not the DE, so the FPGA does not need to worry about it. (Someone will have to worry about it, though.)<br>
<br>
So if the DE needs to send a UDP stream out over the Internet, can we just send it to a gateway address and let the gateway take care of it? On my local network at home, my DSL modem should handle the routing, right?<br>
<br>
73,<br>
Scotty WA2DFI<o:p></o:p></p>
<div>
<p class="MsoNormal">On 2019-05-07 11:49, Tom McDermott via TangerineSDR wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222;background:white">> 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 > d</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222;background:white">designated IP address via UDP.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Hi Scotty - to allow the DE to stream to an address on a different subnet (i.e. over the Internet) the protocol 1 and (apparently 2) requires a proxy and a gateway. That is because HPSDR protocols require that the two endpoints be on the
same subnet (for discovery and data sending). That simplifies the FPGA because it can just use Ethernet layer 2 to send the packet. The discovery process is handled at layer 2 with no involvement of routers. In order to send to a different subnet, the DE must
know about a Gateway device (or a proxy that interposes itself). The gateway figures out that the destination is not on the local subnet, and routes it to the Internet. Routing requires that the IP source address be modified to what the Internet Service Provider
(ISP) assigned, and it must keep track of port mapping for NAT (since the ISP normally only gives out one IPv4 address). Internet modems generally do all that stuff. If discovery requests have to go end-to-end over the Internet then a proxy is needed because
the router won't have a clue about HPSDR layer 2 proprietary discovery packets (which are broadcast). Routers stop subnet broadcast packets to the Internet (for good reason). The proxy translates the IP address of the remote side to lie within our current
subnet address range, then retransmits the discovery request to the DE with the new IP address. Additionally is replies with the discovery ack in the opposite direction with address translation.<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">On Tue, May 7, 2019 at 11:08 AM Scotty Cowling via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<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">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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<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-m9035196836942227800gmail-m2547716944428976612gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph">
<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-m9035196836942227800gmail-m2547716944428976612gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph">
<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-m9035196836942227800gmail-m2547716944428976612gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph">
<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-m9035196836942227800gmail-m2547716944428976612gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph" style="margin-left:.25in">
<span style="font-size:11.0pt;font-family:Symbol">·</span><span style="font-size:11.0pt"> </span><span style="font-size:11.0pt;font-family:Symbol">
</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-m9035196836942227800gmail-m2547716944428976612gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph" style="margin-left:.25in">
<span style="font-size:11.0pt;font-family:Symbol">·</span><span style="font-size:11.0pt"> </span><span style="font-size:11.0pt;font-family:Symbol">
</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-m9035196836942227800gmail-m2547716944428976612gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph" style="margin-left:.25in">
<span style="font-size:11.0pt;font-family:Symbol">·</span><span style="font-size:11.0pt"> </span><span style="font-size:11.0pt;font-family:Symbol">
</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-m9035196836942227800gmail-m2547716944428976612gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph" style="margin-left:.25in">
<span style="font-size:11.0pt;font-family:Symbol">·</span><span style="font-size:11.0pt"> </span><span style="font-size:11.0pt;font-family:Symbol">
</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-m9035196836942227800gmail-m2547716944428976612gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph" style="margin-left:.25in">
<span style="font-size:11.0pt;font-family:Symbol">·</span><span style="font-size:11.0pt"> </span><span style="font-size:11.0pt;font-family:Symbol">
</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-m9035196836942227800gmail-m2547716944428976612gmail-m-8848661953787744719gmail-m-1650918065519285657msolistparagraph" style="margin-left:.25in">
<span style="font-size:11.0pt;font-family:Symbol">·</span><span style="font-size:11.0pt"> </span><span style="font-size:11.0pt;font-family:Symbol">
</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">
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"><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"><bill.engelke@ua.edu></a><br>
<b>Cc:</b> TAPR TangerineSDR Modular Software Defined Radio <a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">
<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">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">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">bill.engelke@ua.edu</a>><br>
<b>Cc:</b> TAPR TangerineSDR Modular Software Defined Radio <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">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">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">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">tangerinesdr@lists.tapr.org</a>><br>
<b>Cc:</b> Tom McDermott <<a href="mailto:tom.n5eg@gmail.com" target="_blank">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">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">tangerinesdr@lists.tapr.org</a> <mailto:<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">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">tangerinesdr@lists.tapr.org</a> <mailto:<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">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">TangerineSDR@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" target="_blank">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">TangerineSDR@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" target="_blank">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>
<p class="MsoNormal">-- <br>
TangerineSDR mailing list<br>
<a href="mailto:TangerineSDR@lists.tapr.org" target="_blank">TangerineSDR@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
</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">TangerineSDR@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>