<div dir="ltr">Hi John,<div><br></div><div> 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.</div><div><br></div><div>Cheers</div><div>Phil</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 5, 2020 at 10:05 PM John Gibbons 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;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Rob,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Thank You for the feedback!</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Yes, the ISO date in the filename is for that UTC days data - will mod the doc to reflect that.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">This will be available online when we get it into version control.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Thanks for your help and I will send out v0.03 shortly.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">John N8OBJ</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><div><div><div><div><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">John C. Gibbons</span><br></div>Director - Sears Undergraduate Design Laboratory<br></div>Dept. of Electrical Engineering and Computer Science</div></div>Case Western Reserve University <br></div><div>10900 Euclid Ave, <span style="font-size:12.8px">Glennan 314</span><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px"><br></span></div></div><div><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px">Cleveland, Ohio 44106-7071</span><br style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px"><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px">Phone </span><a href="tel:216-368-2816" value="+12163684572" style="color:rgb(17,85,204);font-family:Helvetica;font-size:12.8px" target="_blank">(216) 368-2816</a><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px"> FAX </span><a href="tel:216-368-6888" value="+12163686888" style="color:rgb(17,85,204);font-family:Helvetica;font-size:12.8px" target="_blank">(216) 368-6888</a><br style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px"><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px">E-mail: </span><a href="mailto:jcg66@case.edu" style="color:rgb(17,85,204);font-family:Helvetica;font-size:12.8px" target="_blank">jcg66@case.edu</a><br style="color:rgb(0,0,0);font-family:Helvetica;font-size:12.8px"><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">(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>
On Tue, May 05, 2020 at 19:06:38 -0400, John Gibbons via TangerineSDR wrote:<br>
> This is intended as a starting point to generate input for further<br>
> refinement, so comments are welcome and encouraged.<br>
<br>
I like the base filename structure enough. In particular, I like that<br>
it's sortable by date in any sane locale, and both the date and the node<br>
ID will align vertically (until 6 chars stops being enough for node IDs,<br>
or we start worrying about the Y10K problem).<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>
It's probably obvious to everyone that a "day" is a UTC day, but it's<br>
not in the specification, and it wouldn't hurt to add.<br>
<br>
I agree that the zero node ought to be set aside.<br>
<br>
We should use another letter or two for the "testing" and high/low-cost<br>
PSWS bits instead of allocating node IDs within specific ranges. How<br>
about we (where X is 0-9 and * is any (possibly empty) sequence of A-Z):<br>
- use either NXXXXXL or LXXXXX for low-cost PSWS nodes<br>
- use either NXXXXXH or HXXXXX for high-cost PSWS nodes<br>
- set aside N00000*, L00000*, and/or H00000* as a test nodes with<br>
invalid data and/or for other purposes<br>
- not explicitly denote valid data from testing systems in the filename<br>
<br>
A couple questions to answer on that subject:<br>
- What makes testing systems with valid data more/less important/notable<br>
than other systems?<br>
- Can a testing system migrate to a production system without changing<br>
its node ID?<br>
- Is it sufficient that testing systems will necessarily have low node<br>
IDs in most cases?<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>
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>
> We should probably create a mechanism for additions / refinements to this<br>
> document for further work rather than this email thread.<br>
<br>
We can always have both :)<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>
-- <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" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote></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" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">----<br>Phil Erickson<br><a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a><br></div>