<html xmlns:v="urn:schemas-microsoft-com:vml" 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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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;}
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: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-family:"Calibri",sans-serif;}
@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:1325819704;
mso-list-type:hybrid;
mso-list-template-ids:1081404738 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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi John,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Two thoughts:<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">While I think the filename is important, I think it should be more for convenience than for actual storage of real information. That is, the file itself should also contain all of
the data/metadata to recreate the filename. It is the data inside of the file that should be considered the definitive record.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">Regarding node numbers, perhaps an alpha-numeric approach is better, than just numeric? It gives a lot more flexibility in the naming space.<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">73 de Nathaniel W2NAF<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> TangerineSDR <tangerinesdr-bounces@lists.tapr.org>
<b>On Behalf Of </b>John Gibbons via TangerineSDR<br>
<b>Sent:</b> Wednesday, May 6, 2020 11:54 AM<br>
<b>To:</b> TAPR TangerineSDR Modular Software Defined Radio <tangerinesdr@lists.tapr.org><br>
<b>Cc:</b> John Gibbons <jcg66@case.edu>; David Kazdan <dxk10@cwru.edu><br>
<b>Subject:</b> Re: [TangerineSDR] Filename structure, Node info contents, other stuff to ponder<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Rob,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Any node can be collecting multiple files - that's what the TYP and MOD fields are for. When finished, the LC PSWS will be collecting 6 files (4 FREQ [with freq
modifier added] data sets, 1 MAG and 1 TMP) per day per node for any given node per given UTC day.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">If data collection is interrupted, the system just continues adding data for that UTC day in the already existing file for that data set [i.e. appends and does not
start over]. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">That was one of the major mods I did to FLDIGI to accommodate this situation. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Collecting the exact same data set on two different machines at the same node on the same UTC day makes no sense and is not allowed. A node will only be allowed
to submit one file per specific data set per UTC day.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">There will be no merging of files upstream.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">As far as the indication of UTC day (using the ISO format) in the filename, I'm already doing that and there is no simpler way to indicate this and anyone using the
system already understands this. Adding anything here just makes the filename longer.... and it's not necessary for the developers.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">As I've stated in the spec, data sets are based on UTC day and labeled (in ISO format) as such. It doesn't get much simpler than this.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">The file naming scheme (using the ISO date) is intended to help someone who knows what they are doing to visually determine the UTC day's contents of the file (per
Nathaniel's request). I believe I've achieved this as simply as possible.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Semantics about user root and user pi are why I did the system call - someone may choose a different username and I've already accommodated this situation. And it
does work (David Kazdan tested this).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">And any user should NOT be running as root - breaks all the protections and is bad practice in general. Nuf' said.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">Using a system call in PYTHON to get the ENV variable for the home directory is an acceptable practice to determine this. We're going to be setting up the systems,
so this is not going to be a problem long term.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">We have to be able to have our files usable on WIN7/10 systems, so the use of special characters in the filename that linux can handle is simply not allowed. We
have to be compatible.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">And now that I think about it, the - [minus] sign IS usable in WIN7/10, so I'll fix that in the spec. (And I'm using it in the filename - OOPS!)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black">John N8OBJ<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">John C. Gibbons<o:p></o:p></p>
</div>
<p class="MsoNormal">Director - Sears Undergraduate Design Laboratory<o:p></o:p></p>
</div>
<p class="MsoNormal">Dept. of Electrical Engineering and Computer Science<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">Case Western Reserve University <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">10900 Euclid Ave, <span style="font-size:9.5pt">Glennan 314</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:9.5pt;font-family:"Helvetica",sans-serif;color:black">Cleveland, Ohio 44106-7071<br>
Phone </span><a href="tel:216-368-2816" target="_blank"><span style="font-size:9.5pt;font-family:"Helvetica",sans-serif;color:#1155CC">(216) 368-2816</span></a><span style="font-size:9.5pt;font-family:"Helvetica",sans-serif;color:black"> FAX </span><a href="tel:216-368-6888" target="_blank"><span style="font-size:9.5pt;font-family:"Helvetica",sans-serif;color:#1155CC">(216)
368-6888</span></a><span style="font-size:9.5pt;font-family:"Helvetica",sans-serif;color:black"><br>
E-mail: </span><a href="mailto:jcg66@case.edu" target="_blank"><span style="font-size:9.5pt;font-family:"Helvetica",sans-serif;color:#1155CC">jcg66@case.edu</span></a><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Tue, May 5, 2020 at 11:50 PM Rob Wiesler 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">On Tue, May 05, 2020 at 23:01:15 -0400, Phil Erickson via TangerineSDR wrote:<br>
> On Tue, May 5, 2020 at 10:05 PM John Gibbons via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>> wrote:<br>
>> On Tue, May 5, 2020 at 8:38 PM Rob Wiesler via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>> wrote:<br>
>>> (David is probably on the TangerineSDR list, but I don't know that for<br>
>>> sure, so he may get an extra copy of this message (sorry).)<br>
<br>
David is *not* on the list. That's good to know. Maybe I should stop<br>
my habit of trimming the Cc header so aggressively for this list.<br>
<br>
>>> Does the date in the filename refer to:<br>
>>> - the beginning of the record, or<br>
>>> - the end of the record, or<br>
>>> - a single day in its entirety, or<br>
>>> - at most a single day, but no (significant) part of any other day?<br>
><br>
> Your files only have the YYYY-MM-DD form of the ISO date in them. This<br>
> seems to imply that there can be only one file per day. What if the<br>
> instrument dies for a while and then restarts on the same day? I guess I'm<br>
> wondering why you wouldn't use the fully qualified ISO (e.g.<br>
> 2020-05-05T03:00:00). Maybe I'm missing something obvious.<br>
<br>
This hasn't been answered yet exactly, but the current low-cost PSWS<br>
fldigi scheme rotates the file at the end of the UTC day, so there's a<br>
one-to-one correspondence between UTC day and filename. This is<br>
entirely unclear from the filename specification, though.<br>
<br>
In any case, I find it entirely too likely that we'll see two different<br>
files from nonoverlapping times with the same name from the same node.<br>
Imagine that someone sets up a system, starts it logging, forgets the<br>
root password an hour later, and sets it back up again. Are we going to<br>
merge the two files upstream? I would rather not have to.<br>
Misconfigured systems (for instance, cloned systems containing duplicate<br>
node IDs) are something we have to look out for, but this is a case of a<br>
correctly-configured system that just happens to have lost its memory.<br>
<br>
Using the full ISO date (minus the (to us) useless time zone offset<br>
portion) corresponding to the time of the first record in the file would<br>
fix this problem.<br>
<br>
>>> Let's at least specify WWVdata/ as existing relative to "the user"'s<br>
>>> home directory, instead of /home/pi (it can't hurt to be explicit).<br>
>>> Also, you have a typo, where you say that "~" is the "root filesystem<br>
>>> for user", which is not a thing (you mean "home directory").<br>
>><br>
>> For the RasPi OS (Linux), I use a system call to define ~ which is the<br>
>> BASE of the user's directory structure (root was a BAD choice here - not<br>
>> intended to confuse it with root user)<br>
<br>
It would be even worse to get it confused with the real root directory,<br>
which is "/". Or with "user root"'s directory, which is typically<br>
"/root" (pronounced "slash-root" to disambiguate).<br>
<br>
Don't call it a "base", please. This one one of those cases where<br>
there's one right term with no competitors. Just call it the user's<br>
"home directory".<br>
<br>
For today's dose of useless pedantry from Rob, ~ is expanded to the real<br>
path of the user's home directory by a globbing function, based on the<br>
value of the HOME environment variable. Since environment variables are<br>
loaded into the process's memory space literally before they get a<br>
chance to start, this doesn't involve a system call at all (system calls<br>
are a way for userspace processes to invoke functions provided by the<br>
kernel, not a generic term for functions provided by the system at<br>
large).<br>
<br>
>>> Is there a reason you're avoiding a second '.' in the filename? It's a<br>
>>> little awkward to use 2p5 for 2.5, and that second period isn't going to<br>
>>> confuse any software or upend the sorting.<br>
>><br>
>> I stayed away from . and - in the filename as Windows users would get into<br>
>> trouble here (I stuck to just the _ char) and I think we have to cater to<br>
>> that limitation of Windows 7/10/whatever.<br>
<br>
Only when renaming files from the GUI does this become difficult on<br>
Windows, and in any case, we don't want users doing that. Not exactly a<br>
feature, but not a bug, either.<br>
<br>
>>>> I have the original .doc that created this - let me how we should handle<br>
>>>> version control from here. (Nathaniel?)<br>
>>><br>
>>> Please turn this into a plain text file. I can read PDFs, but it's not<br>
>>> ideal, and I'm getting sick and tired of specification documents in<br>
>>> other non-textual formats. A plain text specification file has these<br>
>>> properties:<br>
>>><br>
>>> - Small file size (because this is 2020 and it totally matters)<br>
>>> - Less wasted visual space when the document isn't all that long (again,<br>
>>> wishlist-grade)<br>
>>> - Universally readable<br>
>>> - Universally modifiable by the recipient (so recipients can offer<br>
>>> suggestions formatted as a pull request)<br>
>>> - Diffs between revisions can be generated trivially, so that recipients<br>
>>> can:<br>
>>> - offer suggestions formatted as a patch<br>
>>> - figure out what changed without scanning the entire document for<br>
>>> thin red/yellow lines on a white background (very important to me)<br>
>>> - Mergeable when put in version control (in addition to all the other<br>
>>> properties above you would want for version-controlled documents)<br>
>><br>
>> This will be available online when we get it into version control.<br>
<br>
So long as it's not a PDF in version control, please. The only thing<br>
sadder than a sourceless binary in version control is one that also has<br>
the wrong permission bits set.<br>
<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>
</div>
</body>
</html>