<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Bill,<br>
<br>
I think that the web server is the way to go. But it will reside on
the SBC, not on the DE. The DE will not generally be directly
controllable without the SBC, just like you cannot control a Hermes
board without PowerSDR or HDSDR. So we will run an APP on the SBC to
talk to the DE. The user side of this APP should be a web interface.
Alternately, if the SBC is powerful enough, the user side could be
on the resident graphics controller. If the SBC has bluetooth or
WiFi, the GUI could be a phone APP. (The Bluetooth and/or WiFi
interface on the DE is used to stream data or LCC, not RCC.)<br>
<br>
I think "server" is OK, as long as it is clear what is being served
up. I think Tom's intent is to define needed processes. You are
trying to define exactly what the SBC is goign to be responsible
for, correct? So your spec is inherently on a lower and more
detailed level.<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
<div class="moz-cite-prefix">On 2019-05-14 12:52, Engelke, Bill
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e729558ae9384077b3afdb05104b0c7c@ua.edu">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<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;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:117187428;
mso-list-type:hybrid;
mso-list-template-ids:2068853702 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">A
few remarks…<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">My only concern with the term "server" is
that we may have several functional pieces that fit that
definition, like when the TangerineSDR (including the SBC)
acts like a server to users that want to connect to get RX
data streams in a non-SWPC use case. So as long as we can be
unambiguous in the use, I am OK with the term.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Maybe
I need to quit using the term “server” entirely, because it
is ambiguous. I just started using it because Tom reminded
me that some big institutions will have powerful “servers”
to which the Tangerine DE could upload to directly (without
the involvement of the SBC). I just don’t know what else to
call them.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">QUESTION
FOR YOU: Will the Tangerine DE have a web service (e.g.,
Alpine or something) running on it, or will the user
configure it using a terminal interface (like Red Pitaya) ?
Or??</span><br>
<br>
I will want to define the DE-to-SBC protocol in terms of
Server and Client functions, and it will have nothing to do
with the Central Server concept.<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Understood.</span><o:p></o:p></p>
<p class="MsoNormal"><br>
When referring to the DE, can you please define it as the
"TangerineSDR Data Engine (DE)" the first time, as a
definition?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Will
do.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-73-
Bill AB4EJ<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
TangerineSDR <a class="moz-txt-link-rfc2396E" href="mailto:tangerinesdr-bounces@lists.tapr.org"><tangerinesdr-bounces@lists.tapr.org></a>
<b>On Behalf Of </b>Scotty Cowling via TangerineSDR<br>
<b>Sent:</b> Monday, May 13, 2019 7:06 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> Scotty Cowling <a class="moz-txt-link-rfc2396E" href="mailto:scotty@tonks.com"><scotty@tonks.com></a><br>
<b>Subject:</b> Re: [TangerineSDR] Local Host Functional
Specification, Version 0.1<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi Bill,<br>
<br>
My only concern with the term "server" is that we may have
several functional pieces that fit that definition, like when
the TangerineSDR (including the SBC) acts like a server to
users that want to connect to get RX data streams in a
non-SWPC use case. So as long as we can be unambiguous in the
use, I am OK with the term. <br>
<br>
I will want to define the DE-to-SBC protocol in terms of
Server and Client functions, and it will have nothing to do
with the Central Server concept.<br>
<br>
When referring to the DE, can you please define it as the
"TangerineSDR Data Engine (DE)" the first time, as a
definition?<br>
<br>
73,<br>
Scotty WA2DFI<o:p></o:p></p>
<div>
<p class="MsoNormal">On 2019-05-13 14:56, Engelke, Bill wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Hello
Scotty:</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="mso-list:Ignore">1.<span style="font:7.0pt
"Times New Roman"">
</span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">On
terminology, how about this…. In the SBC documentation, I
need some way refer to the Data Engine. The first couple
of versions of the SBC Functional Spec call it the
Tangerine; but now I understand that you mean for the
Tangerine to include the SBC. I can update the SBC spec
to refer to the Data Engine (instead of calling it the
Tangerine).</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="mso-list:Ignore">2.<span style="font:7.0pt
"Times New Roman"">
</span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I
have already started a Parking Lot document on the Google
Drive. See
<a
href="https://drive.google.com/drive/folders/1FYlmw3pINacZMEnYCFQg2sNzPeM-NElK"
moz-do-not-send="true">
https://drive.google.com/drive/folders/1FYlmw3pINacZMEnYCFQg2sNzPeM-NElK</a>
We can copy this stuff to github at some point if needed.</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="mso-list:Ignore">3.<span style="font:7.0pt
"Times New Roman"">
</span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">On
the “server” – I mention the DE-to-server data path
primarily because Tom wants to account for organizations
like MIT Haystack which will have virtually unlimited
bandwidth to an enormous server. Most users will not have
that, and the Central Control system / Database will not
be sized to allow uploading at full speed (25
Megabytes/sec). In > 90% of cases, the data will have
to go from DE to SBC and then be throttled and or
preprocessed/compressed to be uploaded to the Central
System.</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="mso-list:Ignore">4.<span style="font:7.0pt
"Times New Roman"">
</span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">GNURadio:
I have installed it on an Oxdroid XU4 and it works quite
well handling data at 100 ksps (IQ, single slice) from
Red Pitaya. The Odroid N2 seems to be about 15% faster
according to benchmarks. I am going to further
characterize what it can do. GNURadio has been used
successfully in the SatNOGS project. Remember that it does
not have to run in real time to pre-process data (for an
FFT, for example) for upload.</span><o:p></o:p></p>
<p class="MsoListParagraph"
style="text-indent:-.25in;mso-list:l0 level1 lfo2"><!--[if !supportLists]--><span
style="mso-list:Ignore">5.<span style="font:7.0pt
"Times New Roman"">
</span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Compression:
Phil Erickson is strongly urging us to consider storing
(and maybe also transporting) data in HDF5 format. I have
worked with that in the past and today ran some tests to
see what kind of compression we can get. It compresses wav
files down to about 40% of their initial size (I
understand we need to verify that this is lossless).</span><o:p></o:p></p>
<p class="MsoListParagraph"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoListParagraph"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">More
to come tomorrow. I will also go more closely thru your
comments and make sure to address everything in some way.
Are you going to be at the TAPR/AMSAT dinner at Dayton?
-73- Bill</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
TangerineSDR
<a href="mailto:tangerinesdr-bounces@lists.tapr.org"
moz-do-not-send="true"><tangerinesdr-bounces@lists.tapr.org></a>
<b>On Behalf Of </b>Scotty Cowling via TangerineSDR<br>
<b>Sent:</b> Monday, May 13, 2019 3:30 PM<br>
<b>To:</b> Tom McDermott <a
href="mailto:tom.n5eg@gmail.com"
moz-do-not-send="true"><tom.n5eg@gmail.com></a>;
Engelke, Bill
<a href="mailto:bill.engelke@ua.edu"
moz-do-not-send="true"><bill.engelke@ua.edu></a><br>
<b>Cc:</b> Scotty Cowling <a
href="mailto:scotty@tonks.com"
moz-do-not-send="true"><scotty@tonks.com></a>;
Nathaniel A. Frissell
<a href="mailto:nathaniel.a.frissell@njit.edu"
moz-do-not-send="true"><nathaniel.a.frissell@njit.edu></a>;
<a href="mailto:tangerinesdr@lists.tapr.org"
moz-do-not-send="true">tangerinesdr@lists.tapr.org</a><br>
<b>Subject:</b> Re: [TangerineSDR] Local Host
Functional Specification, Version 0.1</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">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 style="width:9.2708in;height:4.0833in"
id="_x0000_i1025"
src="cid:part8.5095779C.47FD9346@tonks.com" class=""
width="890" height="392" border="0"><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>
<o:p></o:p></p>
<div>
<p class="MsoNormal">On 2019-05-12 06:52, Tom McDermott
wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal">Hi Bill - thanks for generating
the spec. It's good to see various pieces of the
project starting<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">to get documentation. It's a nice
document. Can I borrow the nice HAMSCI and TAPR
logos?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Here are some comments on the
spec - it may be too early to address most of them
(perhaps<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">put them in the parking lot and
get back to them later?).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">4. Could the data to be uploaded
to the server be compressed effectively? Lossless<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">compression might not achieve
much reduction in data size. Lossy compression
might<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">obscure science data. Can the SBC
compress data while doing other tasks (concern<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">about CPU performance).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">5. Should Gnuradio support be
optional? It is a lot of overhead, there may be<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">lower-resource approaches to data
processing. Does Gnuradio have reliability<br>
issues for long-running / continuous tasks?<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>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">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:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">See
attached, first draft of Functional Spec for the
Local Host (SBC). Hope to discuss at Dayton.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">-73-
Bill AB4EJ<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">W.
D. Engelke (Bill), Asst. Research Engr.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Center
for Advanced Public Safety<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Cyber
Hall<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The
University of Alabama<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Tuscaloosa,
AL 35487<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Desk:
(205) 348-7244<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Mobile:
(205) 764-3099<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>
</blockquote>
</div>
</blockquote>
<p class="MsoNormal"> <o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
</body>
</html>