[TangerineSDR] Filename structure, Node info contents, other stuff to ponder

Tue May 5 22:29:00 EDT 2020

per Rob's comments, clarifications added

John N8OBJ

John C. Gibbons
Director - Sears Undergraduate Design Laboratory
Dept. of Electrical Engineering and Computer Science
Case Western Reserve University
10900 Euclid Ave, Glennan 314
Cleveland, Ohio  44106-7071
Phone (216) 368-2816 <216-368-2816> FAX (216) 368-6888 <216-368-6888>
E-mail: jcg66 at case.edu

On Tue, May 5, 2020 at 10:04 PM John Gibbons <jcg66 at case.edu> wrote:

> Rob,
>
> Thank You for the feedback!
>
> Yes, the ISO date in the filename is for that UTC days data - will mod the
> doc to reflect that.
>
> I stayed away from . and - in the filename as Windows users would get into
> trouble here (I stuck to just the _ char) and I think we have to cater to
> that limitation of Windows 7/10/whatever.
>
> For the RasPi OS (Linux), I use a system call to define ~ which is the
> BASE of the user's directory structure (root was a BAD choice here - not
> intended to confuse it with root user)
>
> ALL Node numbers are real nodes (except N00000) like the rest of the
> higher numbered ones - I just allocated 1-99 for the development team(s)
> use to help set them apart visually
>
> I originally defined nodes 1-49 for the low cost PSWS and 51-99 for the
> high cost PSWS, with 50 being the test case for the high cost PSWS. I may
> throw that back in and see what shakes out.
>
> This will be available online when we get it into version control.
>
> Thanks for your help and I will send out v0.03 shortly.
>
> John N8OBJ
>
>
>
>
>
>
> John C. Gibbons
> Director - Sears Undergraduate Design Laboratory
> Dept. of Electrical Engineering and Computer Science
> Case Western Reserve University
> 10900 Euclid Ave, Glennan 314
> Cleveland, Ohio  44106-7071
> Phone (216) 368-2816 <216-368-2816> FAX (216) 368-6888 <216-368-6888>
> E-mail: jcg66 at case.edu
>
>
>
> On Tue, May 5, 2020 at 8:38 PM Rob Wiesler via TangerineSDR <
> tangerinesdr at lists.tapr.org> wrote:
>
>> (David is probably on the TangerineSDR list, but I don't know that for
>> sure, so he may get an extra copy of this message (sorry).)
>>
>> On Tue, May 05, 2020 at 19:06:38 -0400, John Gibbons via TangerineSDR
>> wrote:
>> > This is intended as a starting point to generate input for further
>> > refinement, so comments are welcome and encouraged.
>>
>> I like the base filename structure enough.  In particular, I like that
>> it's sortable by date in any sane locale, and both the date and the node
>> ID will align vertically (until 6 chars stops being enough for node IDs,
>> or we start worrying about the Y10K problem).
>>
>> Does the date in the filename refer to:
>> - the beginning of the record, or
>> - the end of the record, or
>> - a single day in its entirety, or
>> - at most a single day, but no (significant) part of any other day?
>>
>> It's probably obvious to everyone that a "day" is a UTC day, but it's
>> not in the specification, and it wouldn't hurt to add.
>>
>> I agree that the zero node ought to be set aside.
>>
>> We should use another letter or two for the "testing" and high/low-cost
>> PSWS bits instead of allocating node IDs within specific ranges.  How
>> about we (where X is 0-9 and * is any (possibly empty) sequence of A-Z):
>> - use either NXXXXXL or LXXXXX for low-cost  PSWS nodes
>> - use either NXXXXXH or HXXXXX for high-cost PSWS nodes
>> - set aside  N00000*, L00000*, and/or H00000* as a test nodes with
>>   invalid data and/or for other purposes
>> - not explicitly denote valid data from testing systems in the filename
>>
>> A couple questions to answer on that subject:
>> - What makes testing systems with valid data more/less important/notable
>>   than other systems?
>> - Can a testing system migrate to a production system without changing
>>   its node ID?
>> - Is it sufficient that testing systems will necessarily have low node
>>   IDs in most cases?
>>
>> Let's at least specify WWVdata/ as existing relative to "the user"'s
>> home directory, instead of /home/pi (it can't hurt to be explicit).
>> Also, you have a typo, where you say that "~" is the "root filesystem
>> for user", which is not a thing (you mean "home directory").
>>
>> Is there a reason you're avoiding a second '.' in the filename?  It's a
>> little awkward to use 2p5 for 2.5, and that second period isn't going to
>> confuse any software or upend the sorting.
>>
>> > We should probably create a mechanism for additions / refinements to
>> this
>> > document for further work rather than this email thread.
>>
>> We can always have both :)
>>
>> > I have the original .doc that created this - let me how we should handle
>> > version control from here.  (Nathaniel?)
>>
>> Please turn this into a plain text file.  I can read PDFs, but it's not
>> ideal, and I'm getting sick and tired of specification documents in
>> other non-textual formats.  A plain text specification file has these
>> properties:
>>
>> - Small file size (because this is 2020 and it totally matters)
>> - Less wasted visual space when the document isn't all that long (again,
>>   wishlist-grade)
>> - Universally readable
>> - Universally modifiable by the recipient (so recipients can offer
>>   suggestions formatted as a pull request)
>> - Diffs between revisions can be generated trivially, so that recipients
>>   can:
>>   - offer suggestions formatted as a patch
>>   - figure out what changed without scanning the entire document for
>>     thin red/yellow lines on a white background (very important to me)
>> - Mergeable when put in version control (in addition to all the other
>>   properties above you would want for version-controlled documents)
>>
>> --
>> TangerineSDR mailing list
>> TangerineSDR at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20200505/4a2dcab0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PSWS_FileNameRequirementsV0_03.pdf
Type: application/pdf
Size: 46311 bytes
Desc: not available
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20200505/4a2dcab0/attachment-0001.pdf>