<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Bill,<br>
<br>
It is good to see specifications take shape! TAPR has a Github
account, will this be sufficient for the "parking lot"?<br>
<br>
Comments on the spec.<br>
<br>
First, my concept of the TangerineSDR *includes* the SBC. Here is
the block diagram from the hardware spec:<br>
<br>
<img src="cid:part1.C4A13385.01E086F3@tonks.com" alt=""><br>
Without confusing things too much, can we make this distinction? So
really, if we take a TangerineSDR and program the SBC with the PSWS
Local Host software, we will transform the TangerineSDR into a PSWS.
(Likely we would also have to re-program the FPGA with new firmware,
and ensure that the TangerineSDR had the correct hardware
sub-modules (CKM, RFM, DE, Sensor shield.)<br>
<br>
The part that you refer to as the "Tangerine" is really the
TangerineSDR DE and associated components (CKM, RFM, Sensor Shield).<br>
<br>
You do mention connecting the TangerineSDR DE directly to a server.
I want to make sure that our terms are consistently correct (blame
my OCD). In the TangerineSDR world, it is a server, a connection
between the RF world and our network. The combination of direct UDP
data to/from the DE and/or UDP/TCP C&C plus data to/from the SBC
makes up the TangerineSDR "Server" function. TangerineSDR talks to
"clients", processors, consumers (RX) or producers (TX) of data.<br>
<br>
So in the case where the SBC is the consumer and pre-processor of
data, the SBC part of my definition of TangerineSDR becomes a client
to the DE. It then becomes a "server" to what you refer to as the
Server, which I presume is the Central Server of All PSWS Big Data.
The Central Server then becomes a "server" to Scientific clients
that which to obtain and study the data collected from all the
thousands of PSWS.<br>
<br>
So what is the best nomenclature to use? Perhaps we should define a
PSWS Central Server to be "SWServer" or "SWSS". And then call out
the specific pieces of the hardware by their names, since we are
really defining them in terms of function in your spec. So please
use "TangerineSDR DE" and either "TangerineSDR SBC" or maybe just
"SBC", which is clear enough. To me, TangerineSDR by itself means
the whole CKM, RFM, DE and SBC.<br>
<br>
Again, my goal is for "TangerineSDR" to be configurable as "PSWS",
"P4G", "STEM SDR", etc. All of these will include some form of SBC.<br>
<br>
The confusion is probably my fault for putting the DE hardware spec
cart before the TangerineSDR system spec horse.<br>
<br>
On GNURadio, I doubt that you will find that any affordable SBC will
provide GNURadio with adequate run-time resources. Have you loaded
loaded and run it on a RPi? My opinion is that it is a great R&D
tool, but it is nowhere stable enough to include in any release of
automated PSWS software. I can't even imagine a thousand copies of
GNURadio on PSWS all around the world. It would simply not work. I
am willing to be proven wrong, but we will need a lot more testing
to prove stability before then.<br>
<br>
On system updates, I plan to have the ability for the LCC to
supporting updates to the DE firmware from the SBC. In my case, I
was thinking manual update by connecting the SBC to a web page and
letting the user pick an update from a list. The Remote C&C
could implement an external prcedure to virtualize a firmware update
to the DE via the LCC interface. It could even be made automatic or
a push update from the SWSS, with proper authentication.<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
<br>
<div class="moz-cite-prefix">On 2019-05-12 06:52, Tom McDermott
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACO3nRR_bLOVi1KtA4r_=h6Nfa8qjOFJQk7wV2rnspisBpjvww@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div>Hi Bill - thanks for generating the spec. It's good to
see various pieces of the project starting</div>
<div>to get documentation. It's a nice document. Can I borrow
the nice HAMSCI and TAPR logos?<br>
</div>
<div><br>
</div>
<div>Here are some comments on the spec - it may be too early
to address most of them (perhaps</div>
<div>put them in the parking lot and get back to them later?).</div>
<div><br>
</div>
<div>1.User Interface. Would it be useful to have an optional
status / eye-candy display<br>
of space weather, propagation, or measurements? This might
be a selling<br>
point for people to acquire a PSWS. Would it need to
download something<br>
from the central server to do this?</div>
<div><br>
</div>
<div>2. Does the system need a way to do unattended recovery /
restart? Once the<br>
system has been configured for unattended operation and
measurement, should<br>
the system have a GUI settable configuration to enable the
ability to auto<br>
discover radios, program them to the current observational
needs (frequency, band,<br>
etc.), and establish server reporting? Essentially, get
back to what it was doing<br>
before power failed, or the node was rebooted, etc.</div>
<div><br>
</div>
<div>3. One of the key issues will be the time required to
upload data to the central<br>
server. For example: a dual-receiver 8-band 192 ks/s
15-minute observation would<br>
be about 20 GB of data. Assuming a 1 Mbit/s upload speed it
would take about 2 days<br>
to upload (assuming near 100% efficiency). During that
upload the 24-hour buffer<br>
would be over-written. </div>
<div><br>
</div>
<div>4. Could the data to be uploaded to the server be
compressed effectively? Lossless</div>
<div>compression might not achieve much reduction in data
size. Lossy compression might</div>
<div>obscure science data. Can the SBC compress data while
doing other tasks (concern</div>
<div>about CPU performance).</div>
<div><br>
</div>
<div>5. Should Gnuradio support be optional? It is a lot of
overhead, there may be</div>
<div>lower-resource approaches to data processing. Does
Gnuradio have reliability<br>
issues for long-running / continuous tasks?</div>
<div><br>
</div>
<div>-- Tom, N5EG</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Sat, May 11, 2019 at 12:46
PM Engelke, Bill <<a href="mailto:bill.engelke@ua.edu"
moz-do-not-send="true">bill.engelke@ua.edu</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div lang="EN-US">
<div class="gmail-m_6775360553136096715WordSection1">
<p class="MsoNormal">See attached, first draft of
Functional Spec for the Local Host (SBC). Hope to
discuss at Dayton.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">-73- Bill AB4EJ</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">W. D. Engelke (Bill), Asst. Research
Engr.</p>
<p class="MsoNormal">Center for Advanced Public Safety</p>
<p class="MsoNormal">Cyber Hall</p>
<p class="MsoNormal">The University of Alabama</p>
<p class="MsoNormal">Tuscaloosa, AL 35487</p>
<p class="MsoNormal">Desk: (205) 348-7244</p>
<p class="MsoNormal">Mobile: (205) 764-3099</p>
<p class="MsoNormal"> </p>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>