<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" 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="moz-cite-prefix">On 2019-05-07 09:58, Tom McDermott
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACO3nRQtdgkk1C=2P4_MbtwuhiD53HcC=8ftgHvjnw9ky0dfmg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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 dir="ltr" class="gmail_attr">On Mon, May 6, 2019 at 4:31 PM
Scotty Cowling via TangerineSDR <<a
href="mailto:tangerinesdr@lists.tapr.org" target="_blank"
moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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_-8848661953787744719gmail-m_-1650918065519285657moz-cite-prefix">On
2019-05-06 14:29, Engelke, Bill wrote:<br>
</div>
<blockquote type="cite">
<div
class="gmail-m_-8848661953787744719gmail-m_-1650918065519285657WordSection1">
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Hello
Tom & Scotty:</span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">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="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span></p>
<p
class="gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><span>-<span
style="font:7pt "Times New Roman"">
</span></span></span><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Functional
Specifications for the Central Control system and
related database</span></p>
<p
class="gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><span>-<span
style="font:7pt "Times New Roman"">
</span></span></span><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Remote
Command and Control Protocol</span></p>
<p
class="gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><span>-<span
style="font:7pt "Times New Roman"">
</span></span></span><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Functional
Specifications for the local control system (this is
the SBC often referred to as the Host)</span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">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="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif">If
I would suggest to use openHPDSR protocol (or at
least a subset/superset of it). Reasons:</span></p>
<p
class="gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph"
style="margin-left:0.25in"> <span
style="font-size:11pt;font-family:Symbol"><span>·<span
style="font:7pt "Times New Roman"">
</span></span></span><span
style="font-size:11pt;font-family:"Calibri",sans-serif">We
can stand on the shoulders of the existing, proven
design.</span></p>
<p
class="gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph"
style="margin-left:0.25in"> <span
style="font-size:11pt;font-family:Symbol"><span>·<span
style="font:7pt "Times New Roman"">
</span></span></span><span
style="font-size:11pt;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></p>
<p
class="gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph"
style="margin-left:0.25in"> <span
style="font-size:11pt;font-family:Symbol"><span>·<span
style="font:7pt "Times New Roman"">
</span></span></span><span
style="font-size:11pt;font-family:"Calibri",sans-serif">We
may be able to re-use some existing working code.</span></p>
<p
class="gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph"
style="margin-left:0.25in"> <span
style="font-size:11pt;font-family:Symbol"><span>·<span
style="font:7pt "Times New Roman"">
</span></span></span><span
style="font-size:11pt;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></p>
<p
class="gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph"
style="margin-left:0.25in"> <span
style="font-size:11pt;font-family:Symbol"><span>·<span
style="font:7pt "Times New Roman"">
</span></span></span><span
style="font-size:11pt;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></p>
<p
class="gmail-m_-8848661953787744719gmail-m_-1650918065519285657MsoListParagraph"
style="margin-left:0.25in"> <span
style="font-size:11pt;font-family:Symbol"><span>·<span
style="font:7pt "Times New Roman"">
</span></span></span><span
style="font-size:11pt;font-family:"Calibri",sans-serif">I
have found the openHPSDR-Protocol-2 online at
<a
class="gmail-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" moz-do-not-send="true">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-size:11pt;font-family:"Calibri",sans-serif"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;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></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif">-73-
Bill, AB4EJ</span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><b><span
style="font-size:11pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11pt;font-family:"Calibri",sans-serif"> Tom
McDermott <a
class="gmail-m_-8848661953787744719gmail-m_-1650918065519285657moz-txt-link-rfc2396E"
href="mailto:tom.n5eg@gmail.com" target="_blank"
moz-do-not-send="true"><tom.n5eg@gmail.com></a>
<br>
<b>Sent:</b> Sunday, May 5, 2019 8:36 PM<br>
<b>To:</b> Engelke, Bill <a
class="gmail-m_-8848661953787744719gmail-m_-1650918065519285657moz-txt-link-rfc2396E"
href="mailto:bill.engelke@ua.edu" target="_blank"
moz-do-not-send="true"><bill.engelke@ua.edu></a><br>
<b>Cc:</b> TAPR TangerineSDR Modular Software
Defined Radio <a
class="gmail-m_-8848661953787744719gmail-m_-1650918065519285657moz-txt-link-rfc2396E"
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank" moz-do-not-send="true"><tangerinesdr@lists.tapr.org></a><br>
<b>Subject:</b> Re: [TangerineSDR] PSWS System
Specification preliminary Ver 0.1</span></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" moz-do-not-send="true">bill.engelke@ua.edu</a>>
wrote:</p>
</div>
<blockquote style="border-color:currentcolor
currentcolor currentcolor
rgb(204,204,204);border-style:none none none
solid;border-width:medium medium medium
1pt;padding:0in 0in 0in
6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">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="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><b><span
style="font-size:11pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11pt;font-family:"Calibri",sans-serif"> Tom
McDermott <<a
href="mailto:tom.n5eg@gmail.com"
target="_blank" moz-do-not-send="true">tom.n5eg@gmail.com</a>>
<br>
<b>Sent:</b> Sunday, May 5, 2019 10:23 AM<br>
<b>To:</b> Engelke, Bill <<a
href="mailto:bill.engelke@ua.edu"
target="_blank" moz-do-not-send="true">bill.engelke@ua.edu</a>><br>
<b>Cc:</b> TAPR TangerineSDR Modular
Software Defined Radio <<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank" moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>><br>
<b>Subject:</b> Re: [TangerineSDR] PSWS
System Specification preliminary Ver 0.1</span></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" moz-do-not-send="true">bill.engelke@ua.edu</a>>
wrote:</p>
</div>
<blockquote style="border-style:none none none
solid;border-width:medium medium medium
1pt;padding:0in 0in 0in 6pt;margin:5pt 0in
5pt 4.8pt;border-color:currentcolor
currentcolor currentcolor rgb(204,204,204)">
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">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="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">Also
I have a concern about the statement
in System Spec rev 0.2 - </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </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="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">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="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">-73-
Bill AB4EJ</span></p>
<p class="MsoNormal"><span
style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><b><span
style="font-size:11pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11pt;font-family:"Calibri",sans-serif">
TangerineSDR <<a
href="mailto:tangerinesdr-bounces@lists.tapr.org"
target="_blank"
moz-do-not-send="true">tangerinesdr-bounces@lists.tapr.org</a>>
<b>On Behalf Of </b>Tom McDermott
via TangerineSDR<br>
<b>Sent:</b> Sunday, May 5, 2019
8:13 AM<br>
<b>To:</b> TAPR TangerineSDR Modular
Software Defined Radio <<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank"
moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>><br>
<b>Cc:</b> Tom McDermott <<a
href="mailto:tom.n5eg@gmail.com"
target="_blank"
moz-do-not-send="true">tom.n5eg@gmail.com</a>><br>
<b>Subject:</b> Re: [TangerineSDR]
PSWS System Specification
preliminary Ver 0.1</span></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"
moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>>
wrote:</p>
</div>
<blockquote style="border-style:none
none none solid;border-width:medium
medium medium 1pt;padding:0in 0in
0in 6pt;margin:5pt 0in 5pt
4.8pt;border-color:currentcolor
currentcolor currentcolor
rgb(204,204,204)">
<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"
moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>
<mailto:<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank"
moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>>>
wrote:<br>
> <br>
> Hi Tom,<br>
> <br>
> Regarding the clocks, it
seems that the AD5344 addresses
this<br>
> problem with the
cross-point switch and synchronous
dividers.<br>
> <br>
> We can feed two outputs
with one synthesizer if we like,
for a fixed<br>
> (and very small) phase
offset. Routing one clock output
to two RF<br>
> Modules is problematic,
especially with LVDS outputs.
Wouldn't this<br>
> work?<br>
> <br>
> Alternatively, we could
put a clock distribution chip on
the DE to<br>
> take one Clock Module
output and distribute it to FPGA,
RFM1 and<br>
> RFM2, but then we lose
the capability to clock the RFMs
at different<br>
> frequencies (for example,
when one is a TX and one is an
RX).<br>
> <br>
> One thing to keep in mind
is that the FPGA has multiple
clock<br>
> inputs, so we can route
one from each RFM, one from the
Clock Module<br>
> and one from a local
oscillator and let the FPGA code
decide which<br>
> one to use. Of course, we
would have to either let the FPGA
generate<br>
> the RFM clocks or route
multiple clocks to each RFM to
clock the<br>
> ADCs directly. The reason
I bring this up is that I want to
use an<br>
> on-board inexpensive
oscillator (and no Clock Module at
all) as the<br>
> inexpensive, entry-level
SDR. No, the performance would not
be as<br>
> good. But the cost would
be much lower than with any clock
module,<br>
> and it would be
selectable by simply loading the
FPGA with a<br>
> different image and
unplugging the Clock Module.<br>
> <br>
> The section 7 comment was
not intended to dictate a data
flow path.<br>
> I just wanted to show
that we need (and will have) two
GbE ports to<br>
> use that path in case we
want to handle data in this way
(for<br>
> example, if the SBC
cannot keep up). We can word it in
whatever way<br>
> makes it clear that we
can do it either way. Isn't your
description<br>
> implementation specific
also (i.e., data flows through the
SBC)?<br>
> <br>
> Maybe for PSWS, the data
has to flow through the SBC? That
is the<br>
> impression I got, and I
am not sure we want to restrict
the<br>
> architecture that way,
but we could if that is our
intent.<br>
> <br>
> 73,<br>
> Scotty WA2DFI<br>
> <br>
> <br>
> On 2019-05-03 04:09, Tom
McDermott wrote:<br>
>> Thanks for the good
comments, Scotty !<br>
>><br>
>> Section 3: the ADC
clocks MUST come from the same one
synthesizer<br>
>> output. If they<br>
>> come from two
different outputs there is a big
problem...<br>
>><br>
>> The clocks to the two
ADCs must be (and remain) phase
coherent.<br>
>> If the ADC clocks
come<br>
>> from different
outputs of the synthesizer, then
each time the<br>
>> synthesizer starts,
there could<br>
>> be any phase
difference between the two.
Further they could drift<br>
>> back and forth
relative to one another<br>
>> a little bit because
of the way synthesizers work.
Thus the phase<br>
>> between them under<br>
>> the best case would
be +/- 180 degrees. At 30 MHz
that would<br>
>> represent +/- 45
degrees. This<br>
>> means that the
baseband sampled signal at 30 MHz
would also have<br>
>> an unknown phase<br>
>> difference of +/- 45
degrees. That completely wrecks
the ability<br>
>> to discriminate
polarization.<br>
>><br>
>> There can be a
difference in phase between the
two ADC clocks, but<br>
>> it must remain
constant over time.<br>
>> Any difference will
be calibrated out when the
antennas and<br>
>> feedlines are
calibrated for phase delay.<br>
>> But then the phase
differences cannot change. The
only way I see<br>
>> to do that is to have
one<br>
>> synthesizer output
that is distributed to the two ADC
clocks. If<br>
>> the ADCs are on
different modules<br>
>> then one clock signal
has to be routed to the two of
them in some<br>
>> manner (parallel,
daisy-chained, etc.)<br>
>> Maybe there is some
other way but it's difficult to
see.<br>
>><br>
>> This is one of those
things that makes phase coherent
receivers<br>
>> very difficult, and
why off-the-shelf units<br>
>> have to be carefully
evaluated, as virtually none of
the ones I've<br>
>> seen address this
problem properly.<br>
>> It's the Radio
Astronomy problem.<br>
>><br>
>> Section 7: The spec
attempts to be
implementation-non-specific. <br>
>> Forcing a particular
method<br>
>> to distribute
Ethernet data may eliminate all
other potential<br>
>> solutions. The
approach you outline<br>
>> is a really good and
elegant solution, but the spec
should not<br>
>> mandate it (it should
allow it).<br>
>><br>
>> Section 8: great
comment. I will restructure as
you outline.<br>
>><br>
>> -- Tom, N5EG<br>
>><br>
>><br>
>><br>
>> On Thu, May 2, 2019
at 5:27 PM Scotty Cowling via
TangerineSDR<br>
>> <<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank"
moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>
<mailto:<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank"
moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>>><br>
>> wrote:<br>
>><br>
>> Hi Tom,<br>
>><br>
>> Here are my
comments on your excellent
document.<br>
>><br>
>> 73,<br>
>> Scotty WA2DFI<br>
>><br>
>> Notes on PSWS
Specification V 0.1 5 May 2019<br>
>><br>
>> Section 3.0<br>
>> Clock module will
have 4 *programmable clock*
outputs:<br>
>> 1. FPGA<br>
>> 2. RF Module #1<br>
>> 3. RF Module #2<br>
>> 4. High-speed
Reference Clock<br>
>><br>
>> In addition, two
more outputs:<br>
>> 5. 1 PPS timing<br>
>> 6. 10MHz fixed
reference<br>
>><br>
>> Clock outputs
should be differential LVDS.
Single ended clocks<br>
>> will be<br>
>> too noisy,
especially across a connector
boundary.<br>
>><br>
>> The FPGA should
not provide the ADC clocks, they
should come<br>
>> directly<br>
>> from the clock
module. The ADC may supply a
source-synchronous<br>
>> data<br>
>> clock to the
FPGA.<br>
>><br>
>> Section 4.0<br>
>> Magnetometer
interface can be I2C, SPI, serial
UART or RS-485.<br>
>><br>
>> The magnetometer
will almost certainly need to be
remotely<br>
>> mounted. In<br>
>> this case, RS-485
is recommended. We can specify
two-wires for<br>
>> communictions and
two wires for power (typically
5V).<br>
>><br>
>> Section 5.0<br>
>> It is not
immediately clear that *each* RF
Module has two<br>
>> synchronous<br>
>> channels.<br>
>><br>
>> Note that the
*pluggable filter* can be bypassed
with a<br>
>> jumper, making<br>
>> it optional.
Maybe call it "optional pluggable
filter".<br>
>><br>
>> Section 6.<br>
>> The DE shall also
be capable of sourcing or sinking
UDP data<br>
>> streams<br>
>> to/from any IP
address, under direction of the
host processor.<br>
>><br>
>> The DE will have
a three-port GbE switch,
connecting the FPGA,<br>
>> host PC<br>
>> and external
network. How do you want to
explain this?<br>
>><br>
>> Section 7.0<br>
>> Processing the
stream from the DE is optional,
since it may<br>
>> not be able<br>
>> to process this
much data. The metadata tasks will
fall to the<br>
>> DE in<br>
>> this case.<br>
>><br>
>> The host will not
always transmit the data to the
central<br>
>> server. The<br>
>> host may direct
the DE to stream data directly to
the central<br>
>> server if<br>
>> it cannot process
the volume or rate of data.<br>
>><br>
>> Section 8.<br>
>> I have been using
"Command and Control Protocol" for
the<br>
>> protocol used<br>
>> between the
central server and the host PC. I
have been using<br>
>> "Local SDR<br>
>> Protocol" for the
protocol between the host PC and
the DE.<br>
>><br>
>> We could use
"Remote Command and Control", or
"RCC" for the<br>
>>
host<-->central server
communications, and "Local Command
and<br>
>> Control"<br>
>> or "LCC" for
host<-->DE communications.
Whatever we use, we<br>
>> should<br>
>> define it.<br>
>><br>
>> The Remote
Command and Control section seems
to be missing<br>
>> (although you<br>
>> refer to it once
in section 10). Even though we
don't know<br>
>> what the<br>
>> protocol is, I
think it should be mentioned (as
defined an<br>
>> a separate<br>
>> document?)<br>
>><br>
>> I think we need
to make a clear distinction
between Remote C&C<br>
>> and Local<br>
>> SDR C&C. We
will need security and maybe
encryption on the<br>
>> Remote C&C,<br>
>> but not so much
on the Local SDR protocol.<br>
<br>
<br>
<br>
-- <br>
TangerineSDR mailing list<br>
<a
href="mailto:TangerineSDR@lists.tapr.org"
target="_blank"
moz-do-not-send="true">TangerineSDR@lists.tapr.org</a><br>
<a
href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org"
target="_blank"
moz-do-not-send="true">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a></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"
moz-do-not-send="true">TangerineSDR@lists.tapr.org</a><br>
<a
href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>