<div dir="ltr"><div>HI Scotty - if the DE is going to stream out over the Internet then:</div><div><br></div><div>1. It must know and use the destination IP address. This could be done by management</div><div>action (i.e. a provisioning step that sets the address into DE), or some other way.</div><div><br></div><div>2. Some way to punch the appropriate hole in the firewall. Normally when you send,</div><div>that will open the corresponding incoming firewall hole for a few minutes. The other end</div><div>needs to do the same, but if that's a server then it has resources to do that.</div><div><br></div><div>-- Tom, N5EG</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">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:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div bgcolor="#FFFFFF">
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<br>
<br>
<div class="gmail-m_9035196836942227800moz-cite-prefix">On 2019-05-07 11:49, Tom McDermott via
TangerineSDR wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr"><span style="text-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font-family:Arial,Helvetica,sans-serif;font-size:13.33px;font-style:normal;font-variant:normal;font-weight:400;text-decoration:none;word-spacing:0px;display:inline;white-space:normal;float:none;background-color:rgb(255,255,255)">>
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></div>
<div dir="ltr"><span style="text-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font-family:Arial,Helvetica,sans-serif;font-size:13.33px;font-style:normal;font-variant:normal;font-weight:400;text-decoration:none;word-spacing:0px;display:inline;white-space:normal;float:none;background-color:rgb(255,255,255)">designated
IP address via UDP.</span></div>
<div dir="ltr"><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>-- Tom, N5EG</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">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:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div bgcolor="#FFFFFF"> 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<br>
<br>
<div class="gmail-m_9035196836942227800gmail-m_2547716944428976612moz-cite-prefix">On
2019-05-07 09:58, Tom McDermott wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>HI Scotty - I did not know Protocol 2 had the same
single endpoint IP address issues. The limitations
of protocol 1</div>
<div>made remote discovery impossible without a proxy
(the IP address of both devices have to be on the same
subnet).</div>
<div><br>
</div>
<div>Is it possible that the FPGA intellectual property
(IP stack) was responsible for this limitation? If
so, is something</div>
<div>else without those limitations available for this
project?<br>
</div>
<div><br>
</div>
<div>LCC has a couple of key requirements (listed in the
System Spec) needed for PSWS. First is the need to
mark <br>
</div>
<div>which sample is aligned with the timing mark, and
identification of GPS time for the frame data. It's
really fundamental</div>
<div> to the project. I mention it in section 6, but
not in section 8. Probably should update the document
for that.</div>
<div>The other requirements for Section 6 could be
handled outside of the data packets in any of several
different ways.</div>
<div><br>
</div>
<div>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</div>
<div> some kind of document.<br>
</div>
<div><br>
</div>
<div>Nathaniel also said they are working on finalizing
the Magnetometer decision.</div>
<div><br>
</div>
<div>-- Tom, N5EG</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">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:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div bgcolor="#FFFFFF"> Hi Bill,<br>
<br>
I think it is unworkable.<br>
<br>
The HPSDR protocol is hardwired to talk from exactly
one SDR (referred to as "SDR hardware") to exactly
one Host (referred to as "PC").<br>
<br>
No provision is made for multiple discovery
requests, and you cannot stream data to more than
one IP address. So all 192K slice receivers would
have to stream to the same hardware (same IP
address). Command and control definitions are so
married to the HPSDR and ANAN hardware that we would
probably not be compatible with any off-the-shelf
radios anyway.<br>
<br>
While I think we can base the protocol loosely on
the HPSDR protocol as a starting point, I think it
is too restricted to be of general use. I am working
on a more general-purpose protocol for LCC that
would eliminate most, if not all, hardware-specific
restrictions. We can use some SDR hardware that I
have already built to develop the protocol, or use
existing TAPR or Apache Labs Hermes boards or even
ANAN radios. They all have FPGAs in them, so we can
program them to do the SDR end of the protocol for
testing. I would be willing to work on the FPGA end
if someone wants to work on the Host end so we can
get a system up and running.<br>
<br>
My goal is a hardware-agnostic, multiple client,
multiple server protocol that would handle streaming
of I/Q data, raw sample data, RX audio, TX audio,
and control commands, as well as re-programming of
the hardware over Ethernet. HPSDR protocol 2 is far
from this goal.<br>
<br>
Do you have a networking expert (maybe that would be
you?) that we can get in on the definition?<br>
<br>
I don't want to interfere with your progress, but
the above were features that I wanted to be included
in protocol 2 that were not. I think that the use of
different (changeable) ports for every RX stream,
but no changeable ports (or limited ports) for other
types of streams makes too many assumptions on the
hardware that is on each end.<br>
<br>
So can we start with a clean slate? Pretty please?
:-)<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
<div class="gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-m_-8848661953787744719gmail-m_-1650918065519285657moz-cite-prefix">On
2019-05-06 14:29, Engelke, Bill wrote:<br>
</div>
<blockquote type="cite">
<div class="gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-m_-8848661953787744719gmail-m_-1650918065519285657WordSection1">
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt">Hello
Tom & Scotty:</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt">Nathaniel
has given me the go-ahead to start working
on the specs for the software, which I
understand to include:</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"> </span></p>
<p class="gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"><span>-<span>
</span></span></span><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt">Functional
Specifications for the Central Control
system and related database</span></p>
<p class="gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"><span>-<span>
</span></span></span><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt">Remote
Command and Control Protocol</span></p>
<p class="gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"><span>-<span>
</span></span></span><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt">Functional
Specifications for the local control system
(this is the SBC often referred to as the
Host)</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt">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></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;font-size:11pt">If
I would suggest to use openHPDSR protocol
(or at least a subset/superset of it).
Reasons:</span></p>
<p class="gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph" style="margin-left:0.25in"> <span style="font-family:Symbol;font-size:11pt"><span>·<span>
</span></span></span><span style="font-family:"Calibri",sans-serif;font-size:11pt">We
can stand on the shoulders of the existing,
proven design.</span></p>
<p class="gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph" style="margin-left:0.25in"> <span style="font-family:Symbol;font-size:11pt"><span>·<span>
</span></span></span><span style="font-family:"Calibri",sans-serif;font-size:11pt">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></p>
<p class="gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph" style="margin-left:0.25in"> <span style="font-family:Symbol;font-size:11pt"><span>·<span>
</span></span></span><span style="font-family:"Calibri",sans-serif;font-size:11pt">We
may be able to re-use some existing working
code.</span></p>
<p class="gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph" style="margin-left:0.25in"> <span style="font-family:Symbol;font-size:11pt"><span>·<span>
</span></span></span><span style="font-family:"Calibri",sans-serif;font-size:11pt">Maybe
a user could use their PSWS as a radio (a
receiver, at least) under PowerSDR if they
wanted to.</span></p>
<p class="gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph" style="margin-left:0.25in"> <span style="font-family:Symbol;font-size:11pt"><span>·<span>
</span></span></span><span style="font-family:"Calibri",sans-serif;font-size:11pt">We
can get started with software development
even before the new hardware is ready,
because there are radios that conform to the
spec.</span></p>
<p class="gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph" style="margin-left:0.25in"> <span style="font-family:Symbol;font-size:11pt"><span>·<span>
</span></span></span><span style="font-family:"Calibri",sans-serif;font-size:11pt">I
have found the openHPSDR-Protocol-2 online
at <a class="gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-m_-8848661953787744719gmail-m_-1650918065519285657moz-txt-link-freetext" 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></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;font-size:11pt">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></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;font-size:11pt">-73-
Bill, AB4EJ</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"> </span></p>
<p class="MsoNormal"><b><span style="font-family:"Calibri",sans-serif;font-size:11pt">From:</span></b><span style="font-family:"Calibri",sans-serif;font-size:11pt"> Tom
McDermott <a class="gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-m_-8848661953787744719gmail-m_-1650918065519285657moz-txt-link-rfc2396E" 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 class="gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-m_-8848661953787744719gmail-m_-1650918065519285657moz-txt-link-rfc2396E" href="mailto:bill.engelke@ua.edu" target="_blank"><bill.engelke@ua.edu></a><br>
<b>Cc:</b> TAPR TangerineSDR Modular
Software Defined Radio <a class="gmail-m_9035196836942227800gmail-m_2547716944428976612gmail-m_-8848661953787744719gmail-m_-1650918065519285657moz-txt-link-rfc2396E" 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></p>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">Hi Bill - one of the
problems when writing a new specification
is that the author has </p>
</div>
<div>
<p class="MsoNormal">undocumented
assumptions in their mind. The review
process helps get those discovered</p>
</div>
<div>
<p class="MsoNormal">and then written into
the spec or some other document.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">This thread is good
because it has uncovered several of those
that need writing out.</p>
</div>
<div>
<p class="MsoNormal">For this project, it is
apparent that we need a use case document,
covering the two cases,</p>
</div>
<div>
<p class="MsoNormal">and perhaps more later
on.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">-- Tom, N5EG</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">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:</p>
</div>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentColor currentColor currentColor rgb(204,204,204);padding:0in 0in 0in 6pt;margin-right:0in;margin-left:4.8pt">
<div>
<div>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt">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></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"> </span></p>
<p class="MsoNormal"><b><span style="font-family:"Calibri",sans-serif;font-size:11pt">From:</span></b><span style="font-family:"Calibri",sans-serif;font-size:11pt"> 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></p>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">Hi Bill - Your
understanding is one particular
implementation, it's the same
implementation that Scotty is
assuming.</p>
</div>
<div>
<p class="MsoNormal">Given today's
silicon technology it may be the
only practical implementation.
Given tomorrow's technology maybe
not.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">There could be
several use cases: the one you
are assuming, where the remote
PSWS is accessed over the
Internet. and</p>
</div>
<div>
<p class="MsoNormal">where
remote-->server bandwidth is a
significant limitation. For that
case Nathaniel laid out the need
for the remote station to </p>
</div>
<div>
<p class="MsoNormal">stream to local
non-volatile storage, then be
triggered during an event of
interest to send a small data
subset back to a central</p>
</div>
<div>
<p class="MsoNormal">server.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">But there is
another use case where the PSWS is
located on the same LAN as the
server. Phil Erickson expressed
interest</p>
</div>
<div>
<p class="MsoNormal">in this case.
For this case perhaps folks would
want to stream continuously over
the LAN to that server, providing
greater</p>
</div>
<div>
<p class="MsoNormal">data capture
capability. For this use case an
inexpensive Host function might
not be able to keep up.
Essentially, it's replacing</p>
</div>
<div>
<p class="MsoNormal">the low-cost
host function with one that's a
lot more powerful, perhaps
integrated with a local server.
With software modularity</p>
</div>
<div>
<p class="MsoNormal">perhaps the
host software could be portable,
or maybe that's phase 2 (or maybe
phase never).</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">So the spec is
drafted in an attempt to try not
to limit the use case.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">-- Tom, N5EG</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">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:</p>
</div>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentColor currentColor currentColor rgb(204,204,204);margin:5pt 0in 5pt 4.8pt;padding:0in 0in 0in 6pt">
<div>
<div>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt">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></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt">Also
I have a concern about the
statement in System Spec rev
0.2 - </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="font-size:9pt">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></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt">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></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt">-73-
Bill AB4EJ</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:"Calibri",sans-serif;font-size:11pt"> </span></p>
<p class="MsoNormal"><b><span style="font-family:"Calibri",sans-serif;font-size:11pt">From:</span></b><span style="font-family:"Calibri",sans-serif;font-size:11pt">
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></p>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">Hi
Scotty</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">The
spec says that there is a
DE function and a Host
Computer function - it
doesn't say how they are</p>
</div>
<div>
<p class="MsoNormal">physically
connected or implemented.
If that is unclear then
the spec is not written
well </p>
</div>
<div>
<p class="MsoNormal">enough
and other folks will
likely make the same
(mis)interpretation, so it
should be reworded.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Thanks
for idea about the
synthesizer. You are
right, the SL spec does
say that the output
dividers are all</p>
</div>
<div>
<p class="MsoNormal">synchronously
reset at power up and can
also be reset by the
programmer to re-sync. It
also says they</p>
</div>
<div>
<p class="MsoNormal">will
maintain phase-sync across
outputs that are derived
from the same
synthesizer. I will make
some</p>
</div>
<div>
<p class="MsoNormal">measurements
on the Eval Board across
the 4 outputs to see how
well they stay aligned.
I hope it's</p>
</div>
<div>
<p class="MsoNormal">not
susceptible to glitches
un-syncing them. That
would be a dog to debug in
the field.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">-- Tom,
N5EG</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">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:</p>
</div>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentColor currentColor currentColor rgb(204,204,204);margin:5pt 0in 5pt 4.8pt;padding:0in 0in 0in 6pt">
<p class="MsoNormal">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></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div>
-- <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" rel="noreferrer">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote>
</div>
</blockquote>
<br>
</div>
-- <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" rel="noreferrer">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote>
</div>
<br>
<fieldset class="gmail-m_9035196836942227800mimeAttachmentHeader"></fieldset>
</blockquote>
<br>
</div>
-- <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" rel="noreferrer">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote></div>