<div dir="ltr"><div>The system spec has been updated to incorporate the comments from the notes and TeamSpeak session of </div><div>June 3rd. Attached Version 0.5.1.</div><div><br></div><div><br></div><div>-- Tom, N5EG</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Tue, Jun 4, 2019 at 3:10 PM Scotty Cowling via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org">tangerinesdr@lists.tapr.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div bgcolor="#FFFFFF">
Hi Tom,<br>
<br>
Thanks for the notes!<br>
<br>
On the discovery process, I think we need to include it as an
optional feature in the LCC protocol.<br>
<br>
We could have two broadcast commands: "discovery" and "pair".<br>
<br>
A TangerineSDR always consists of a pair: one SBC acting as a Local
Host and one DE. A Client is another PC or SBC that connects to the
TangerineSDR and provides the radio GUI.<br>
<br>
The "discovery" command would only be used by Clients to identify
TangerineSDRs on the network segment. Only Clients would issue the
"discovery" command, and only Local Hosts would respond.<br>
<br>
The "pair" command would only be used by Local Hosts to identify DEs
on the local network segment. Only Local Hosts would issue the
"pair" command, and only DEs would respond.<br>
<br>
In the vast majority of cases (such as PSWS), there will only be one
Local Host and one DE on any given network segment, so pairing will
resolve. In the case where there is more than one TangerineSDR on a
network segment, the pairing will need to be resolved at the Local
Host. Assuming that the Local Host is running some kind of web
server, pairing could be resolved manually using that interface, and
stored in non-volatile memory for future re-boots.<br>
<br>
For PSWS, discovery would not be used, since there are no Clients on
the network segment.<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
<div class="gmail-m_-1414295294963001108moz-cite-prefix">On 2019-06-04 08:56, Tom McDermott via
TangerineSDR wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>Here are my notes from last night's TeamSpeak session.
Please let me know if</div>
<div>anything is captured wrong, and any key items missed.</div>
<div><br>
</div>
<div>1. Will users have upload bandwidth throttles or caps
from their ISP's that limit</div>
<div>how much data they can upload? What will the project
do if those are significant?</div>
<div>Severe caps could restrict the science that can be
done.</div>
<div><br>
</div>
<div>2. The discovery process imposes a lot of requirements
on the FPGA and DE.</div>
<div>Are there alternatives for phase 1 that simplify? If
the DE streams directly to</div>
<div>the Internet (such as UDP) it will need to know it's IP
address, the subnet mask,</div>
<div>and the Ethernet and IP addresses of the gateway.</div>
<div>A. Non-volatile memory on the DE to hold provisioning?</div>
<div>B. Use of I2C to connect to and provision the DE?</div>
<div> No decision reached yet.</div>
<div><br>
</div>
<div>3. Where to and how to code HDF5. General agreement
that the DE will</div>
<div>produce internally 24-bit 2's complement binary.
Should the DE convert to </div>
<div>single-precision floating point before sending to the
Host? Should the host</div>
<div>stream straight to disk, or HDF5format then stream to
disk? There are </div>
<div>Pros and Cons for each approach. It will depend on the
amount of data</div>
<div>captured in real time.</div>
<div><br>
</div>
<div>4. Discussion on the approach to time-mark data from
the DE. An</div>
<div>alternative approach of putting time into each packet
was discussed, the</div>
<div>advantage being that it probably works better if
packets go missing. The</div>
<div>NTP 64-bit time format (32-bits of Unix time, plus 32
bits of fractional time)</div>
<div>might be useful. Can the FPGA do this? </div>
<div><br>
</div>
<div>5. Discussion about the impact of decimation on the
time stamping accuracy.</div>
<div>Are the decimation CIC and FIR low pass filters
deterministic? The process is likely</div>
<div>very deterministic, meaning a calibration offset can be
computed for the filter and it</div>
<div>won't change run-to-run. However the CIC filters are
not phase-linear, meaning the</div>
<div>amount of time compensation changes across the +/- 192
kHz. filter passband.</div>
<div>The problem should be solvable, but may be a little
messy.</div>
<div><br>
</div>
<div>6. Agreement to use GPS time for the time stamping on
the DE. The Host or</div>
<div>central server can convert to UTC time if necessary.
The DE FPGA should not</div>
<div>need to know the history of leap seconds in order to
time stamp the packets.</div>
<div>It will have access to GPS time in hardware from the
clock module.</div>
<div><br>
</div>
<div>-- Tom, N5EG</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Tue, Jun 4, 2019 at 7:15 AM
Engelke, Bill via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div lang="EN-US" bgcolor="white">
<div class="gmail-m_-1414295294963001108gmail-m_205301747631143837WordSection1">
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Scotty:</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Good
session last night – I hope someone was keeping notes;
although I don’t recall that we made any firm
decisions.</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Just
to be clear, I am not against Discovery per se. My
concern is that we need to keep the feature set of
Phase 1 down to the minimum necessary to achieve the
mission, and guard against feature creep. (Old habit
of a Project Manager). Coming out with a second
version with more features implemented is also handy
for marketing purposes – it gives us an excuse to
publish a couple articles about the new stuff, thus
keeping the project in public awareness.</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Certainly
we can have something like Discovery available as an
option you can turn on and off with the web UI in
Local Host.</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Also
– here is an idea for your list of potential ham apps
– it is something I have working in my DWatcher app.
We can have some processes available that do things
like watch for certain callsigns, grids, or prefixes
to show up on the air (digital modes, of course), or
maybe (with clever noise analysis) to watch for a
given band to open, and send an email to a given email
address when detected. (I have configured this to send
the email to a mail-to-text site, so I get a text
message when any one of a list of D-Star users or DX
stations comes on the air). Again, probably something
for Phase 2+, but something that might be attractive
to hams.</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">-73-
Bill</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) currentColor currentColor;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span style="color:windowtext"> TangerineSDR <<a href="mailto:tangerinesdr-bounces@lists.tapr.org" target="_blank">tangerinesdr-bounces@lists.tapr.org</a>>
<b>On Behalf Of </b>Scotty Cowling via
TangerineSDR<br>
<b>Sent:</b> Monday, June 3, 2019 5:19 PM<br>
<b>To:</b> TAPR TangerineSDR Modular Software
Defined Radio <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>><br>
<b>Cc:</b> Scotty Cowling <<a href="mailto:scotty@tonks.com" target="_blank">scotty@tonks.com</a>><br>
<b>Subject:</b> Re: [TangerineSDR] Local Host
Functional Specification v 0.3 and TangerineSDR
Requirements Document V0.3</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal" style="margin-bottom:12pt">Hi Bill,<br>
<br>
Thanks for the comments. <br>
<br>
I will think a bit more on the discovery feature. Maybe
you are right, the web server obviates the need for
discovery. It might still be useful in small systems to
allow them to somewhat self-configure. Is there a way we
could include it as an implementation-optional feature
of the protocol without it being a security risk? Maybe
a feature we can turn off?<br>
<br>
My section 4 does need a lot more work. I don't want to
limit things to just WSPR and RBN, but to anything that
can be implemented in an application running on the
Local Host. I will see how I can word it. Making things
appealing to more hams is always a good thing. Maybe if
we can make the TangerineSDR do multiple things at once
(like a multi-band RBN receiver and PSWS simultaneously)
we will get more PSWS users.<br>
<br>
73,<br>
Scotty WA2DFI<span style="font-size:12pt"></span></p>
<div>
<p class="MsoNormal">On 2019-06-03 14:52, Engelke, Bill
wrote:</p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Scotty
– I have reviewed the doc you posted, and a few
comments…</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="gmail-m_-1414295294963001108gmail-m_205301747631143837MsoListParagraph"><span>-<span>
</span></span><span style="color:rgb(31,73,125)">I
will update the Local Host Functional Spec to have
section numbers.</span></p>
<p class="gmail-m_-1414295294963001108gmail-m_205301747631143837MsoListParagraph"><span>-<span>
</span></span><span style="color:rgb(31,73,125)">Regarding
the Discovery feature: recall that the Local Host
will be running a web server, via which the user
will exert control over the Local Host. The user
will be able to enter the address of a large local
client box to send data to. Do we really wish to
add the ability for the client box to grab control
of the Tangerine? This whole Discovery concept seems
to me a holdover from the days where the SDR was
little more than an ADC.
</span></p>
<p class="gmail-m_-1414295294963001108gmail-m_205301747631143837MsoListParagraph"><span>-<span>
</span></span><span style="color:rgb(31,73,125)">You
mention WSPR and RBN below (and FT8 reception could
also be added) – these will make the devices more
appealing to Hams. Perhaps you would like to add
these to Section 4.</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">-Talk
to you later – 73- Bill</span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) currentColor currentColor;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span style="color:windowtext"> TangerineSDR
<a href="mailto:tangerinesdr-bounces@lists.tapr.org" target="_blank"><tangerinesdr-bounces@lists.tapr.org></a>
<b>On Behalf Of </b>Scotty Cowling via
TangerineSDR<br>
<b>Sent:</b> Monday, June 3, 2019 1:43 PM<br>
<b>To:</b> TAPR TangerineSDR Modular Software
Defined Radio <a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">
<tangerinesdr@lists.tapr.org></a><br>
<b>Cc:</b> Scotty Cowling <a href="mailto:scotty@tonks.com" target="_blank"><scotty@tonks.com></a><br>
<b>Subject:</b> [TangerineSDR] Local Host
Functional Specification v 0.3 and TangerineSDR
Requirements Document V0.3</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal" style="margin-bottom:12pt">Hi Bill,<br>
<br>
This looks excellent! I have been working on a
TangerineSDR requirements document, which I have put
up on the web page here:<br>
<br>
<a href="http://TangerineSDR.com/TangerineSDR_documents/TangerineSDR_Requirements_V0_3.pdf" target="_blank">http://TangerineSDR.com/TangerineSDR_documents/TangerineSDR_Requirements_V0_3.pdf</a><br>
<br>
What I call the "C&C Processor" is what you call
"Local Host". I like your term better, so I will
change it in my next revision.<br>
<br>
Since the SBC can run several processes, it seems that
"Command and Control", "web browser", "data analysis",
"ring buffer storage", as well as optional functions
"GnuRadio", "WSPR", "RBN", etc are all just
applications running under the Local Host operating
system. I am not sure how to make this more clear
(maybe it is clear enough?)<br>
<br>
One other thing (maybe Tom already asked for this),
can you put section numbers on the document to make it
easier to reference to specific parts?<br>
<br>
You mentioned the Local Host's ability to program the
FPGA on the DE. While you can always plug a USB
Blaster directly onto the DE JTAG port (you will need
to do this to run the SignalTap debugging software in
the Quartus tools anyway), here is how it will
eventually work. <br>
<br>
The MAX10's configuration is in stored in SRAM cells
within the part. Being volatile, it the SRAM must be
loaded at every power up. The MAX10 uses internal
flash memory to store two configuration images. On
power up, the MAX10 automatically loads the main image
into SRAM and releases its internal reset, running the
default configuration. If this flash image gets
corrupted, the MAX10 will automatically load the
secondary image and attempt to run that.<br>
<br>
So the idea is to use the main image as the
"upgrade-able" image, while the secondary image is the
"factory" image that is never modified. Both images
contain a boot loader that implements flash erase and
write of the main image (but not the secondary one)
via the Ethernet port. Note that the MAX10 runs out of
SRAM. Any changes to the flash image only take effect
at the next reset cycle (power up or programmable
reset).<br>
<br>
So the Local Host will run an "update" application
that will talk to the MAX10's boot loader code. If the
main flash image gets corrupted (e.g., power fail
during update), the secondary image will automatically
provide the boot loader function. I like the Elecraft
model of being able to read the current DE firmware
version and hardware configuration and then go out to
the "TangerineSDR Repository" and offer the user
clickable firmware versions that match his hardware.
Firmware versions from local storage can also be
included for those intrepid souls who want to write
their own FPGA code (or for us developers
writing/updating existing code). It can all be
GUI-driven (maybe all from a web browser?) so it will
be easy.
<br>
<br>
My hope is that it will be so easy that users can
switch between applications like PSWS, RBN, WSPR at
any time. It is *software* defined, after all! :-) I
may be expecting too much, however, since external
connections will likely change for each application,
and they are *not* software defined. <br>
<br>
73,<br>
Scotty WA2DFI</p>
<div>
<p class="MsoNormal">On 2019-05-24 12:39, Engelke,
Bill wrote:</p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal">Scotty - Please see attached,
updated to include some of the things discussed at
Dayton. Next I will work on the Functional
Specifications for the Central Control &
Database system.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">If anyone would like me to start
posting to the TAPR github or somewhere, please just
text credentials to my mobile number, below. I can
assure everyone that I will not make a mess of it,
having done this before.</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>
</blockquote>
<p class="MsoNormal"><span> </span></p>
</blockquote>
<p class="MsoNormal"><span> </span></p>
</div>
</div>
-- <br>
TangerineSDR mailing list<br>
<a href="mailto:TangerineSDR@lists.tapr.org" target="_blank">TangerineSDR@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" target="_blank" rel="noreferrer">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote>
</div>
<br>
<fieldset class="gmail-m_-1414295294963001108mimeAttachmentHeader"></fieldset>
</blockquote>
<br>
</div>
-- <br>
TangerineSDR mailing list<br>
<a href="mailto:TangerineSDR@lists.tapr.org" target="_blank">TangerineSDR@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" target="_blank" rel="noreferrer">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote></div>