<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<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:11.0pt;
font-family:"Calibri",sans-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:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi all,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I don’t remember dropping the ring buffer idea completely. I think we just said that it may need to run at a reduced capacity for a particular mode/lifetime concerns. So yes, I think the capability should be there.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">73 de Nathaniel <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">TangerineSDR <tangerinesdr-bounces@lists.tapr.org> on behalf of TangerineSDR Listserv <tangerinesdr@lists.tapr.org><br>
<b>Reply-To: </b>TangerineSDR Listserv <tangerinesdr@lists.tapr.org><br>
<b>Date: </b>Tuesday, October 8, 2019 at 3:07 PM<br>
<b>To: </b>TangerineSDR Listserv <tangerinesdr@lists.tapr.org><br>
<b>Cc: </b>Phil Erickson <phil.erickson@gmail.com>, "Engelke, Bill" <bill.engelke@ua.edu><br>
<b>Subject: </b>Re: [TangerineSDR] Seeking your Review and Comment on Tangerine SBC Functional Specification<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Hi all, <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> Can someone remind me what the reason was for leaving the Ring Buffer behind? It enables a huge number of science use cases, and I'd like to understand why it is disappearing. It has implications for the default use cases in the initial
personal space weather station, for example. (The total removal of a ring buffer excludes _all_ use cases that might employ it, whereas a limited ring buffer that can handle much smaller sampling rates does not.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">73<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Phil W1PJE<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, Oct 8, 2019 at 2:57 PM Engelke, Bill via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org">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">
<p class="MsoNormal">Hello Rob - thanks for your most helpful reply - I will be incorporating your thoughts into the next version. I have a few follow-up remarks:<br>
<br>
- I will discuss the Ring Buffer concept with Nathaniel. It seems like it could be useful, it's just that it would not be practical with today's hardware to run it at the huge data rate originally envisioned.<br>
- Excellent idea to add a statement about making the system able to survive power cycles. That was one of the things that made me abandon Linux for a number of years after it first became available - if the power went off, the system would often get bricked.
I have been delighted to find that this is not the case with more modern implementations (i.e., Raspberry, Odroid N2 etc)<br>
- Discoverability: I am not sure of the value of this either, it is an artifact from how the OpenHPSDR-compatible systems work. With TangerineSDR, we do plan to support the config where there are multiple units on the same network (institutional setting); but
the plan is that these would be individually configured using a web running in the SBC.<br>
- Operating system: you mention Debian several times. The Odroid N2 uses Ubuntu. If someone wants to go through the effort to gen up Debian to run on it, they are welcome to do so, but I would consider that out of scope for Phase 1.<br>
- Waiting for files to close: what I mean by this is: if a file is actively being uploaded to the server, the server should not attempt to open and read that file before the transfer is complete; in fact, I would expect the file transfer process to maintain
exclusive rights to the file until transfer is done (and file closed). What I have been imagining for Use Case 3 (data pre-processed by GNURadio in TangerineSDR) is that the FFT snapshots (of small chunks of bandwidth around WWV) would be uploaded in real
time and stored as database records (rather than files), which makes them immediately available for real-time analysis on the server. (This is not to say we can't also support Use Case 1, which involves uploading large files from the ring buffer - in which
case we have the condition of waiting for a file transfer to complete before we can access the file on the server). I'm sure there are other ways to "skin this cat," - if I am missing something, please advise.<br>
- Yes, <a href="http://mender.io" target="_blank">mender.io</a> is merely an example. I will look into how atomic updates are done with Ubuntu. QUESTION: I am guessing that some geeks (including self here) will prefer to have control over when updates are
applied, and others are happy to let the system handle these automatically; we probably should let people have the choice, shouldn't we? Maybe default to automatic, but let the user opt out of that? Or, what do you suggest?<br>
<br>
Please keep me informed of your progress on building an example system. We are being asked (by Nathaniel, et al) to make data collection methods common between TangerineSDR and the CWRU system (does it have a name?) ... I have been playing with a development
version of the SatNOGS Network, and plan to use a modified version of it for our Phase 1 Central Control System & database.<br>
<br>
-tnx es 73 - Bill AB4EJ<br>
<br>
<br>
-----Original Message-----<br>
From: Rob Wiesler <<a href="mailto:robert.wiesler@case.edu" target="_blank">robert.wiesler@case.edu</a>>
<br>
Sent: Thursday, October 3, 2019 10:02 PM<br>
To: Engelke, Bill <<a href="mailto:bill.engelke@ua.edu" target="_blank">bill.engelke@ua.edu</a>><br>
Cc: TAPR TangerineSDR Modular Software Defined Radio <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>>; Ward Silver <<a href="mailto:hwardsil@gmail.com" target="_blank">hwardsil@gmail.com</a>>; Atkison, Travis <<a href="mailto:atkison@cs.ua.edu" target="_blank">atkison@cs.ua.edu</a>><br>
Subject: Re: Seeking your Review and Comment on Tangerine SBC Functional Specification<br>
<br>
On Thu, Sep 26, 2019 at 2:48 PM Engelke, Bill <<a href="mailto:bill.engelke@ua.edu" target="_blank">bill.engelke@ua.edu</a>> wrote:<br>
> You may notice that there are a number of things we have dreamed about which are not included in the Functional Spec (but may be included in the Future Concepts section). This spec is intended to capture Phase 1 (i.e., what we are going to do that is NSF-funded).
We plan to made the system modular so that if volunteer developers wish to contribute additional work outside the major scope, they can do that.<br>
<br>
I notice that the 24-hour ring buffer is still specified for Phase 1.<br>
I thought we had decided to remove that? It should still be possible to add back in the future. (It doesn't bother me if it stays in - I'm just trying to get my memory of the meeting at DCC in order.)<br>
<br>
Since the Local Host (SBC) is physically connected to (or at least co-located with) the DE, I'm not sure if there are any security concerns there at all? So long as unprivileged users can't reprogram the DE, and reprogramming the DE is either atomic or restartable
(i.e.<br>
a partial update won't brick the DE), that should be fine.<br>
<br>
As I mentioned at DCC, the Case PSWS has an additional "Guiding Principle" not listed in the functional specification: the system shall not enter a state during which a power cycle would break it in ways not automatically rectified when power comes back on.
This means that all updates will be atomic (which isn't really the case on Debian systems by default, although it's been getting better over time).<br>
<br>
I'm not sure I see any particular value to network discoverability<br>
(3.5.6) beyond what a normal Debian system already does, at least as far as Phase 1 is concerned. If there's anything on the local network that needs to talk to a TangerineSDR, that should probably be configured explicitly.<br>
<br>
In the caption for Figure 4 in section 3.6, I'm not sure what you mean by waiting for files to close. Closing a file in a modern operating system is not an expensive operation, so long as you don't subsequently block on syncing the file to disk (which we won't).
If you mean that you want real-time processing of data by the Central System, I don't really see an issue, as there's no reason why we couldn't send data-to-be-uploaded through the network to the database at the same time as we store it to disk (as you would
in a typical Store-Forward architecture). (If this paragraph doesn't make sense to you, that's because I'm having trouble understanding the comment at the end of the caption.)<br>
<br>
I know it was just mentioned as an example, but there's no reason to add a dependency on
<a href="http://mender.io" target="_blank">mender.io</a> . That's just extra complexity we'll have to manage, and quite possibly vaporware to boot. I'd much rather rely on a normal Debian system update, with our software packaged in a side repo, backed by
a simple system to make sure updates are atomic (btrfs snapshots and an initramfs hook to roll back partial changes in case of a powercycle, for example) and don't require user intervention (just a matter of configuring dpkg correctly) by default. In any
case, we need to make sure that operating system updates *and* PSWS-specific updates are handled identically, and are both atomic and non-interactive.<br>
<br>
(I'm going to be experimenting with setting up such a system in the near future. I'll keep you all informed.)<br>
<br>
ACK the rest of the changes.<br>
<br>
(There's some indication that the list may not like .edu addresses.<br>
Apologies if I have to resend this.)<br>
<br>
--<br>
73 DE AC8YV<br>
-- <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">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<p class="MsoNormal">----<br>
Phil Erickson<br>
<a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a><o:p></o:p></p>
</div>
</div>
</body>
</html>