[TangerineSDR] Filename structure, Node info contents, other stuff to ponder
jcg66 at case.edu
Wed May 6 10:56:08 EDT 2020
The issue of restarting anytime during the day was one of the major
modifications I made to the program. It just starts up and continues where
it left off. Same file, same date, etc.
So it's not a problem. People will also stop the data collection to use
their ham stations for their normal operations, so this had to be addressed.
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 11:01 PM Phil Erickson <phil.erickson at gmail.com>
> Hi John,
> Your files only have the YYYY-MM-DD form of the ISO date in them. This
> seems to imply that there can be only one file per day. What if the
> instrument dies for a while and then restarts on the same day? I guess I'm
> wondering why you wouldn't use the fully qualified ISO (e.g.
> 2020-05-05T03:00:00). Maybe I'm missing something obvious.
> On Tue, May 5, 2020 at 10:05 PM John Gibbons via TangerineSDR <
> tangerinesdr at lists.tapr.org> wrote:
>> 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
>>> > 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
>>> > 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
>>> > 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
>>> - Small file size (because this is 2020 and it totally matters)
>>> - Less wasted visual space when the document isn't all that long (again,
>>> - 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
>>> - 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
>> TangerineSDR mailing list
>> TangerineSDR at lists.tapr.org
> Phil Erickson
> phil.erickson at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TangerineSDR