<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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<br>
<br>
<div class="moz-cite-prefix">On 2019-05-08 09:23, Engelke, Bill via
TangerineSDR wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1c2d91de045e40cf9ec3ffe019dcea0c@ua.edu">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"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;}
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.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;}
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;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">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<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"><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 class="moz-txt-link-rfc2396E" 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 class="moz-txt-link-rfc2396E" href="mailto:tangerinesdr@lists.tapr.org"><tangerinesdr@lists.tapr.org></a><br>
<b>Cc:</b> Tom McDermott <a class="moz-txt-link-rfc2396E" href="mailto:tom.n5eg@gmail.com"><tom.n5eg@gmail.com></a><br>
<b>Subject:</b> Re: [TangerineSDR] PSWS System Specification
preliminary Ver 0.1<o:p></o:p></span></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"
moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi 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" moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid
#CCCCCC 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi
Tom,<br>
<br>
Yes, I was dismayed to see that limitation
carried over to protocol 2. My planned network
has one server and multiple clients, something
that neither HPSDR protocol can handle.<br>
<br>
The LCC can live with the discovery limitation,
can it not? Since it is intended to be
Host<-->SDR communications and never be
exposed to the outside world (for security
reasons), it will only ever communicate on one
subnet.<br>
<br>
The RCC, however, should not have that
limitation. I am not sure how individual
stations will "hook in" to the network. Will
they have to register with a central server?
Will they then be polled? Or will they push
data, once set up by the central server? How is
authentication done?<br>
<br>
The limitations of the IP stack in the FPGA
certainly contributed to the limitations. Phil
VK6PH implemented it as a state machine. I would
not do it that way. I would use a soft-core CPU
(NIOS II) and a steerable state machine to make
it more easily programmable. Protocol changes
would then be mostly (if not all) software
changes. They would still be FPGA changes, but
not low-level hardware changes to state
machines.<br>
<br>
My intent for the protocol is to provide for
discovery, re-programming (for updates) and
control using UDP with an ACK layer added. The
"control" part would be for hardware specific
control, as well as for setting up stream
to/from the SDR and external IP addresses. By
external addresses, I mean the SBC's address,
other hosts' addresses on the local subnet as
well as addresses anywhere else on the Internet.
These streams are set up by the SBC, but once
set up, stream directly between SDR and
designated IP address via UDP.<br>
<br>
We should define several different formats for
streams, and leave it open to add formats as
desired. For example, we could have a 32-bit I/Q
format (16 bits I and 16 bits Q) a 16-bit raw
sample format (16-bit samples, back-to-back), a
64-bit 192Ksps I/Q stream (32-bits I and 32-bits
Q), etc, etc. Each stream would be set up with
sample rate, data width, bit/byte order, packet
size, etc. Include a stream format ID (or maybe
this is implied, since the stream was set up in
advance), and we can add formats as needed. So
we would have a Meta-tagged format that included
a metadata header with GPS time stamp, timing
mark, etc. followed by I/Q or raw samples (maybe
multiple different formats as required).<br>
<br>
One other comment on your PSWS spec v 0.2. I
still think that the delineation between the
host and SDR is dictating an SBC-centric
architecture. It is not clear to me that the
"host" and "DE" are processes and not hardware
blocks.<br>
<br>
73,<br>
Scotty WA2DFI<o:p></o:p></p>
<div>
<p class="MsoNormal">On 2019-05-07 09:58, Tom
McDermott wrote:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">HI Scotty - I did not
know Protocol 2 had the same single
endpoint IP address issues. The
limitations of protocol 1<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">made remote discovery
impossible without a proxy (the IP address
of both devices have to be on the same
subnet).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Is it possible that the
FPGA intellectual property (IP stack) was
responsible for this limitation? If so,
is something<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">else without those
limitations available for this project?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">LCC has a couple of key
requirements (listed in the System Spec)
needed for PSWS. First is the need to
mark
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">which sample is aligned
with the timing mark, and identification
of GPS time for the frame data. It's
really fundamental<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">to the project. I
mention it in section 6, but not in
section 8. Probably should update the
document for that.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The other requirements
for Section 6 could be handled outside of
the data packets in any of several
different ways.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Nathaniel sent me the
grant he wrote, and some ideas on Ham
usage. I will try to wrap all that and
the user cases into<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">some kind of document.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Nathaniel also said
they are working on finalizing the
Magnetometer decision.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-- Tom, N5EG<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, May 6, 2019 at
4:31 PM Scotty Cowling via TangerineSDR
<<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank" moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">Hi Bill,<br>
<br>
I think it is unworkable.<br>
<br>
The HPSDR protocol is hardwired to talk
from exactly one SDR (referred to as
"SDR hardware") to exactly one Host
(referred to as "PC").<br>
<br>
No provision is made for multiple
discovery requests, and you cannot
stream data to more than one IP address.
So all 192K slice receivers would have
to stream to the same hardware (same IP
address). Command and control
definitions are so married to the HPSDR
and ANAN hardware that we would probably
not be compatible with any off-the-shelf
radios anyway.<br>
<br>
While I think we can base the protocol
loosely on the HPSDR protocol as a
starting point, I think it is too
restricted to be of general use. I am
working on a more general-purpose
protocol for LCC that would eliminate
most, if not all, hardware-specific
restrictions. We can use some SDR
hardware that I have already built to
develop the protocol, or use existing
TAPR or Apache Labs Hermes boards or
even ANAN radios. They all have FPGAs in
them, so we can program them to do the
SDR end of the protocol for testing. I
would be willing to work on the FPGA end
if someone wants to work on the Host end
so we can get a system up and running.<br>
<br>
My goal is a hardware-agnostic, multiple
client, multiple server protocol that
would handle streaming of I/Q data, raw
sample data, RX audio, TX audio, and
control commands, as well as
re-programming of the hardware over
Ethernet. HPSDR protocol 2 is far from
this goal.<br>
<br>
Do you have a networking expert (maybe
that would be you?) that we can get in
on the definition?<br>
<br>
I don't want to interfere with your
progress, but the above were features
that I wanted to be included in protocol
2 that were not. I think that the use of
different (changeable) ports for every
RX stream, but no changeable ports (or
limited ports) for other types of
streams makes too many assumptions on
the hardware that is on each end.<br>
<br>
So can we start with a clean slate?
Pretty please? :-)<br>
<br>
73,<br>
Scotty WA2DFI<o:p></o:p></p>
<div>
<p class="MsoNormal">On 2019-05-06
14:29, Engelke, Bill wrote:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hello
Tom & Scotty:</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Nathaniel
has given me the go-ahead to start
working on the specs for the
software, which I understand to
include:</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p
class="gmail-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"
moz-do-not-send="true">
https://github.com/TAPR/OpenHPSDR-Firmware/blob/master/Protocol%202/Documentation/openHPSDR%20Ethernet%20Protocol%20v3.8.pdf</a></span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">If
anyone thinks this is definitely
not workable, please let me know,
so that I can learn; I expect
there are aspects of this that I
am not aware of, so I am open to
all feedback… thanks….</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">-73-
Bill, AB4EJ</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Tom
McDermott
<a
href="mailto:tom.n5eg@gmail.com"
target="_blank"
moz-do-not-send="true"><tom.n5eg@gmail.com></a>
<br>
<b>Sent:</b> Sunday, May 5, 2019
8:36 PM<br>
<b>To:</b> Engelke, Bill <a
href="mailto:bill.engelke@ua.edu"
target="_blank"
moz-do-not-send="true"><bill.engelke@ua.edu></a><br>
<b>Cc:</b> TAPR TangerineSDR
Modular Software Defined Radio <a
href="mailto:tangerinesdr@lists.tapr.org" target="_blank"
moz-do-not-send="true">
<tangerinesdr@lists.tapr.org></a><br>
<b>Subject:</b> Re: [TangerineSDR]
PSWS System Specification
preliminary Ver 0.1</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi
Bill - one of the problems when
writing a new specification is
that the author has
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">undocumented
assumptions in their mind. The
review process helps get those
discovered<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">and
then written into the spec or
some other document.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">This
thread is good because it has
uncovered several of those that
need writing out.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">For
this project, it is apparent
that we need a use case
document, covering the two
cases,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">and
perhaps more later on.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">--
Tom, N5EG<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On
Sun, May 5, 2019 at 1:16 PM
Engelke, Bill <<a
href="mailto:bill.engelke@ua.edu"
target="_blank"
moz-do-not-send="true">bill.engelke@ua.edu</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid
windowtext 1.0pt;padding:0in 0in
0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-color:currentColor
currentColor currentColor
rgb(204,204,204)">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Tom
– OK, I get it. Thanks
for being patient with me,
I’m trying to understand
as much as possible about
this so that I can
properly guide the
software development.
There are indeed people /
organizations that have
major local horsepower,
and it is certainly
advisable to ensure they
can roll their own system
if they wish to. -73-
Bill AB4EJ</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Tom
McDermott <<a
href="mailto:tom.n5eg@gmail.com"
target="_blank"
moz-do-not-send="true">tom.n5eg@gmail.com</a>>
<br>
<b>Sent:</b> Sunday, May
5, 2019 10:23 AM<br>
<b>To:</b> Engelke, Bill
<<a
href="mailto:bill.engelke@ua.edu"
target="_blank"
moz-do-not-send="true">bill.engelke@ua.edu</a>><br>
<b>Cc:</b> TAPR
TangerineSDR Modular
Software Defined Radio
<<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank"
moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>><br>
<b>Subject:</b> Re:
[TangerineSDR] PSWS System
Specification preliminary
Ver 0.1</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi
Bill - Your
understanding is one
particular
implementation, it's the
same implementation that
Scotty is assuming.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Given
today's silicon
technology it may be the
only practical
implementation. Given
tomorrow's technology
maybe not.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">There
could be several use
cases: the one you are
assuming, where the
remote PSWS is accessed
over the Internet. and<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">where
remote-->server
bandwidth is a
significant limitation.
For that case Nathaniel
laid out the need for
the remote station to
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">stream
to local non-volatile
storage, then be
triggered during an
event of interest to
send a small data subset
back to a central<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">server.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">But
there is another use
case where the PSWS is
located on the same LAN
as the server. Phil
Erickson expressed
interest<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">in
this case. For this
case perhaps folks would
want to stream
continuously over the
LAN to that server,
providing greater<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">data
capture capability. For
this use case an
inexpensive Host
function might not be
able to keep up.
Essentially, it's
replacing<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">the
low-cost host function
with one that's a lot
more powerful, perhaps
integrated with a local
server. With software
modularity<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">perhaps
the host software could
be portable, or maybe
that's phase 2 (or maybe
phase never).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">So
the spec is drafted in
an attempt to try not to
limit the use case.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">--
Tom, N5EG<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On
Sun, May 5, 2019 at 7:23
AM Engelke, Bill <<a
href="mailto:bill.engelke@ua.edu" target="_blank" moz-do-not-send="true">bill.engelke@ua.edu</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid
windowtext
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-color:currentColor
currentColor currentColor
rgb(204,204,204)">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hi
Tom – a couple of
notes – My
understanding is
that the Host
Computer (local
control system,
SBC) will be
connected to the
DE vu gigabit
Ethernet.</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Also
I have a concern
about the
statement in
System Spec rev
0.2 -
</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:9.0pt">If the DE and Host are physically separate
devices, then the
DE may need to
stream data
directly to the
central server if
the Host cannot
process fast
enough.</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">There
will not be
sufficient
capacity either in
the central sever
nor the user’s
internet bandwidth
to stream
directly. Very
high speed upload
is the exception
rather than the
rule in the US,
and we can’t
assume we will
have the funding
for a central host
able to receive
this data rate
from lots of PSWS
units at once. I
think we have to
<b>ensure that the
local control
system is able
to process fast
enough</b> by
how we design the
whole system. If I
am missing
something, please
let me know.</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-73-
Bill AB4EJ</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
TangerineSDR <<a
href="mailto:tangerinesdr-bounces@lists.tapr.org" target="_blank"
moz-do-not-send="true">tangerinesdr-bounces@lists.tapr.org</a>>
<b>On Behalf Of </b>Tom
McDermott via
TangerineSDR<br>
<b>Sent:</b>
Sunday, May 5,
2019 8:13 AM<br>
<b>To:</b> TAPR
TangerineSDR
Modular Software
Defined Radio <<a
href="mailto:tangerinesdr@lists.tapr.org" target="_blank"
moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>><br>
<b>Cc:</b> Tom
McDermott <<a
href="mailto:tom.n5eg@gmail.com"
target="_blank"
moz-do-not-send="true">tom.n5eg@gmail.com</a>><br>
<b>Subject:</b>
Re: [TangerineSDR]
PSWS System
Specification
preliminary Ver
0.1</span><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi Scotty<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The spec says
that there is a
DE function and
a Host Computer
function - it
doesn't say how
they are<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">physically
connected or
implemented. If
that is unclear
then the spec is
not written well
<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">enough and
other folks will
likely make the
same
(mis)interpretation,
so it should be
reworded.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks for
idea about the
synthesizer.
You are right,
the SL spec does
say that the
output dividers
are all<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">synchronously
reset at power
up and can also
be reset by the
programmer to
re-sync. It also
says they<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">will maintain
phase-sync
across outputs
that are derived
from the same
synthesizer. I
will make some<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">measurements
on the Eval
Board across the
4 outputs to see
how well they
stay aligned.
I hope it's<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">not
susceptible to
glitches
un-syncing them.
That would be a
dog to debug in
the field.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">-- Tom, N5EG<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Sat, May
4, 2019 at 6:27
PM Scott Cowling
via TangerineSDR
<<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank" moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid
windowtext
1.0pt;padding:0in
0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt;border-color:currentColor
currentColor
currentColor
rgb(204,204,204)">
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi Tom,<br>
<br>
OK, I was
thinking that
the four outputs
of the AD5344
would be our <br>
Clock Module
outputs. One to
the FPGA, one to
each RF Module,
one <br>
external. If you
wanted two or
more of them
phase-coherent,
just drive <br>
them from the
same AD5344
synthesizer.
Then the AD5344
output block <br>
would perform
our clock
distribution,
making an
additional chip
<br>
unnecessary. The
variable
frequency
provided by the
AD5344
synthesizers <br>
would be used to
configure clock
outputs for
different kinds
of RFMs. <br>
This would
enable us to
build a low-cost
LowFER RFM
(100kHz-500KHz)
that <br>
samples at, say,
10MHz if we want
to. NCOs are
totally under
the control <br>
of the DE, so
they can be
designed as one
shared NCO or
multiple NCOs as
<br>
desired.<br>
<br>
Yes, the whole
point it to have
the hardware
that is best
suited to each <br>
task, do that
task.<br>
<br>
Implementing a
full TCP/IP
stack or SSH in
the FPGA is an
expensive use <br>
of hardware (so
let the SBC do
it).
Implementing
decimation and
slice <br>
filtering in the
SBC puts an
unreasonable
burden on a
low-cost <br>
general-purpose
SBC (so let the
FPGA do it).<br>
<br>
Tom, it just
seemed like you
were picking one
way over another
in your <br>
document by
having a DE
section 6 and a
Host PC section
7. I agree that
<br>
we need to
specify the
tasks, but not
necessarily the
hardware that
does <br>
each one.
Hopefully it
will become
obvious where
each task is
best <br>
handled when we
document the
needed steps.
And I am trying
really hard <br>
to keep the SBC
out of the main
flow, if
possible. (Maybe
it is not.)<br>
<br>
It was never my
intention to
allow the user
to pick any old
SBC for <br>
PSWS. My intent
was to be
flexible enough
that *we* could
pick from many <br>
alternatives and
pick the one
that works best
for us.<br>
<br>
All these
options will get
out of control
very quickly if
we let users <br>
pick whichever
ones they want.
It will turn out
exactly as you
describe! <br>
Just look at the
early days of
Flex, when users
got to pick
their own <br>
sound card to
use with the
SDR-1000. Total
mayhem, even
after Flex TOLD
<br>
them to use
"brand X, model
Y" cards.<br>
<br>
The options are
for US to more
easily build
something that
meets the <br>
requirements
that this
specification is
enumerating (and
others that we <br>
decide to
support). And if
users want to
play, that is
fine. They do so
<br>
at their own
skill level. We
support only
those
configurations
that we <br>
have engineered
to meet specific
targets.<br>
<br>
OK, I'm off my
soapbox now. :-)<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
<br>
On 5/3/19 8:36
AM, Tom
McDermott wrote:<br>
> Hi Scotty
- yes, having
one synthesizer
output feed two
clock drivers <br>
> (one per
RFM) would be
fine.<br>
> It's not a
problem to have
a phase offset,
provided that
offset does not
<br>
> change.<br>
> <br>
> I don't
think it's a
problem to have
fixed frequency
on the ADC
clocks. <br>
> That clock
is not used to
tune the
receiver,<br>
> the NCO in
the DE is used
to tune the
receiver. So the
DE can implement
<br>
> one NCO for
the synchronous
case,<br>
> and two
NCOs for the
case where we
want the two
receivers to
tune to <br>
> different
frequencies.<br>
> <br>
> While the
spec describes
SBC and DE,
those two
functions could
<br>
>
theoretically
co-exist on on
module (for<br>
> example the
Red Pitaya)
where the FPGA
does both the DE
function, and <br>
> via the
CPU-block does
the SBC<br>
> function.
A concern with
having the FPGA
do both is the
lack of <br>
> sufficient
computational
capability in
the<br>
> limited CPU
performance
that's
implemented on
the FPGA die.
So the <br>
> spec tries
to separate the
functionality<br>
> without
saying where
it's physically
implemented.<br>
> <br>
> I do hope
we restrict
ourselves to one
implementation.
If folks can <br>
> choose any
SBC, any
Receiver, etc.
then there<br>
> will be no
end of "The
software doesn't
work on my
combination",
"My <br>
> hardware
receivers aren't
coherent",<br>
> "My
hardware is
overflowing
buffers", "My
hardware doesn't
support <br>
> amplitude
calibration"
ad nauseum.<br>
> The data
that is produced
risks being
largely garbage.<br>
> <br>
> -- Tom,
N5EG<br>
> <br>
> <br>
> <br>
> On Fri, May
3, 2019 at 7:08
AM Scotty
Cowling via
TangerineSDR <br>
> <<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank" moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>
<mailto:<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank" moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>>>
wrote:<br>
> <br>
> Hi Tom,<br>
> <br>
>
Regarding the
clocks, it seems
that the AD5344
addresses this<br>
> problem
with the
cross-point
switch and
synchronous
dividers.<br>
> <br>
> We can
feed two outputs
with one
synthesizer if
we like, for a
fixed<br>
> (and
very small)
phase offset.
Routing one
clock output to
two RF<br>
> Modules
is problematic,
especially with
LVDS outputs.
Wouldn't this<br>
> work?<br>
> <br>
>
Alternatively,
we could put a
clock
distribution
chip on the DE
to<br>
> take
one Clock Module
output and
distribute it to
FPGA, RFM1 and<br>
> RFM2,
but then we lose
the capability
to clock the
RFMs at
different<br>
>
frequencies
(for example,
when one is a TX
and one is an
RX).<br>
> <br>
> One
thing to keep in
mind is that the
FPGA has
multiple clock<br>
> inputs,
so we can route
one from each
RFM, one from
the Clock Module<br>
> and one
from a local
oscillator and
let the FPGA
code decide
which<br>
> one to
use. Of course,
we would have to
either let the
FPGA generate<br>
> the RFM
clocks or route
multiple clocks
to each RFM to
clock the<br>
> ADCs
directly. The
reason I bring
this up is that
I want to use an<br>
>
on-board
inexpensive
oscillator (and
no Clock Module
at all) as the<br>
>
inexpensive,
entry-level SDR.
No, the
performance
would not be as<br>
> good.
But the cost
would be much
lower than with
any clock
module,<br>
> and it
would be
selectable by
simply loading
the FPGA with a<br>
>
different image
and unplugging
the Clock
Module.<br>
> <br>
> The
section 7
comment was not
intended to
dictate a data
flow path.<br>
> I just
wanted to show
that we need
(and will have)
two GbE ports to<br>
> use
that path in
case we want to
handle data in
this way (for<br>
>
example, if the
SBC cannot keep
up). We can word
it in whatever
way<br>
> makes
it clear that we
can do it either
way. Isn't your
description<br>
>
implementation
specific also
(i.e., data
flows through
the SBC)?<br>
> <br>
> Maybe
for PSWS, the
data has to flow
through the SBC?
That is the<br>
>
impression I
got, and I am
not sure we want
to restrict the<br>
>
architecture
that way, but we
could if that is
our intent.<br>
> <br>
> 73,<br>
> Scotty
WA2DFI<br>
> <br>
> <br>
> On
2019-05-03
04:09, Tom
McDermott wrote:<br>
>>
Thanks for the
good comments,
Scotty !<br>
>><br>
>>
Section 3: the
ADC clocks MUST
come from the
same one
synthesizer<br>
>>
output. If they<br>
>>
come from two
different
outputs there is
a big problem...<br>
>><br>
>> The
clocks to the
two ADCs must
be (and remain)
phase coherent.<br>
>> If
the ADC clocks
come<br>
>>
from different
outputs of the
synthesizer,
then each time
the<br>
>>
synthesizer
starts, there
could<br>
>> be
any phase
difference
between the two.
Further they
could drift<br>
>>
back and forth
relative to one
another<br>
>> a
little bit
because of the
way synthesizers
work. Thus the
phase<br>
>>
between them
under<br>
>> the
best case would
be +/- 180
degrees. At 30
MHz that would<br>
>>
represent +/-
45 degrees.
This<br>
>>
means that the
baseband sampled
signal at 30 MHz
would also have<br>
>> an
unknown phase<br>
>>
difference of
+/- 45 degrees.
That completely
wrecks the
ability<br>
>> to
discriminate
polarization.<br>
>><br>
>>
There can be a
difference in
phase between
the two ADC
clocks, but<br>
>> it
must remain
constant over
time.<br>
>> Any
difference will
be calibrated
out when the
antennas and<br>
>>
feedlines are
calibrated for
phase delay.<br>
>> But
then the phase
differences
cannot change.
The only way I
see<br>
>> to
do that is to
have one<br>
>>
synthesizer
output that is
distributed to
the two ADC
clocks. If<br>
>> the
ADCs are on
different
modules<br>
>>
then one clock
signal has to be
routed to the
two of them in
some<br>
>>
manner
(parallel,
daisy-chained,
etc.)<br>
>>
Maybe there is
some other way
but it's
difficult to
see.<br>
>><br>
>>
This is one of
those things
that makes phase
coherent
receivers<br>
>>
very difficult,
and why
off-the-shelf
units<br>
>>
have to be
carefully
evaluated, as
virtually none
of the ones I've<br>
>>
seen address
this problem
properly.<br>
>>
It's the Radio
Astronomy
problem.<br>
>><br>
>>
Section 7: The
spec attempts to
be
implementation-non-specific.
<br>
>>
Forcing a
particular
method<br>
>> to
distribute
Ethernet data
may eliminate
all other
potential<br>
>>
solutions. The
approach you
outline<br>
>> is
a really good
and elegant
solution, but
the spec should
not<br>
>>
mandate it (it
should allow
it).<br>
>><br>
>>
Section 8:
great comment.
I will
restructure as
you outline.<br>
>><br>
>> --
Tom, N5EG<br>
>><br>
>><br>
>><br>
>> On
Thu, May 2, 2019
at 5:27 PM
Scotty Cowling
via TangerineSDR<br>
>>
<<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank" moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>
<mailto:<a
href="mailto:tangerinesdr@lists.tapr.org"
target="_blank" moz-do-not-send="true">tangerinesdr@lists.tapr.org</a>>><br>
>>
wrote:<br>
>><br>
>>
Hi Tom,<br>
>><br>
>>
Here are my
comments on your
excellent
document.<br>
>><br>
>>
73,<br>
>>
Scotty WA2DFI<br>
>><br>
>>
Notes on PSWS
Specification V
0.1 5 May 2019<br>
>><br>
>>
Section 3.0<br>
>>
Clock module
will have 4
*programmable
clock* outputs:<br>
>>
1. FPGA<br>
>>
2. RF Module #1<br>
>>
3. RF Module #2<br>
>>
4. High-speed
Reference Clock<br>
>><br>
>>
In addition,
two more
outputs:<br>
>>
5. 1 PPS timing<br>
>>
6. 10MHz fixed
reference<br>
>><br>
>>
Clock outputs
should be
differential
LVDS. Single
ended clocks<br>
>>
will be<br>
>>
too noisy,
especially
across a
connector
boundary.<br>
>><br>
>>
The FPGA should
not provide the
ADC clocks, they
should come<br>
>>
directly<br>
>>
from the clock
module. The ADC
may supply a
source-synchronous<br>
>>
data<br>
>>
clock to the
FPGA.<br>
>><br>
>>
Section 4.0<br>
>>
Magnetometer
interface can be
I2C, SPI, serial
UART or RS-485.<br>
>><br>
>>
The
magnetometer
will almost
certainly need
to be remotely<br>
>>
mounted. In<br>
>>
this case,
RS-485 is
recommended. We
can specify
two-wires for<br>
>>
communictions
and two wires
for power
(typically 5V).<br>
>><br>
>>
Section 5.0<br>
>>
It is not
immediately
clear that
*each* RF Module
has two<br>
>>
synchronous<br>
>>
channels.<br>
>><br>
>>
Note that the
*pluggable
filter* can be
bypassed with a<br>
>>
jumper, making<br>
>>
it optional.
Maybe call it
"optional
pluggable
filter".<br>
>><br>
>>
Section 6.<br>
>>
The DE shall
also be capable
of sourcing or
sinking UDP data<br>
>>
streams<br>
>>
to/from any IP
address, under
direction of the
host processor.<br>
>><br>
>>
The DE will
have a
three-port GbE
switch,
connecting the
FPGA,<br>
>>
host PC<br>
>>
and external
network. How do
you want to
explain this?<br>
>><br>
>>
Section 7.0<br>
>>
Processing the
stream from the
DE is optional,
since it may<br>
>>
not be able<br>
>>
to process this
much data. The
metadata tasks
will fall to the<br>
>>
DE in<br>
>>
this case.<br>
>><br>
>>
The host will
not always
transmit the
data to the
central<br>
>>
server. The<br>
>>
host may direct
the DE to stream
data directly to
the central<br>
>>
server if<br>
>>
it cannot
process the
volume or rate
of data.<br>
>><br>
>>
Section 8.<br>
>>
I have been
using "Command
and Control
Protocol" for
the<br>
>>
protocol used<br>
>>
between the
central server
and the host PC.
I have been
using<br>
>>
"Local SDR<br>
>>
Protocol" for
the protocol
between the host
PC and the DE.<br>
>><br>
>>
We could use
"Remote Command
and Control", or
"RCC" for the<br>
>>
host<-->central server communications, and "Local Command and<br>
>>
Control"<br>
>>
or "LCC" for
host<-->DE
communications.
Whatever we use,
we<br>
>>
should<br>
>>
define it.<br>
>><br>
>>
The Remote
Command and
Control section
seems to be
missing<br>
>>
(although you<br>
>>
refer to it
once in section
10). Even though
we don't know<br>
>>
what the<br>
>>
protocol is,
I think it
should be
mentioned (as
defined an<br>
>>
a separate<br>
>>
document?)<br>
>><br>
>>
I think we need
to make a clear
distinction
between Remote
C&C<br>
>>
and Local<br>
>>
SDR C&C. We
will need
security and
maybe encryption
on the<br>
>>
Remote C&C,<br>
>>
but not so much
on the Local SDR
protocol.<br>
<br>
<br>
<br>
-- <br>
TangerineSDR
mailing list<br>
<a
href="mailto:TangerineSDR@lists.tapr.org"
target="_blank" moz-do-not-send="true">TangerineSDR@lists.tapr.org</a><br>
<a
href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org"
target="_blank" moz-do-not-send="true">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
TangerineSDR mailing list<br>
<a
href="mailto:TangerineSDR@lists.tapr.org"
target="_blank" moz-do-not-send="true">TangerineSDR@lists.tapr.org</a><br>
<a
href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org"
target="_blank" moz-do-not-send="true">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><o:p></o:p></p>
</blockquote>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
TangerineSDR mailing list<br>
<a href="mailto:TangerineSDR@lists.tapr.org"
target="_blank" moz-do-not-send="true">TangerineSDR@lists.tapr.org</a><br>
<a
href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org"
target="_blank" moz-do-not-send="true">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><o:p></o:p></p>
</blockquote>
</div>
<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" moz-do-not-send="true">TangerineSDR@lists.tapr.org</a><br>
<a
href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org"
target="_blank" moz-do-not-send="true">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><o:p></o:p></p>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
<br>
</body>
</html>