<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Bill,</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)">Your station is given a node number to define its location. So yes, you have a single node number.</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)">If the receivers are coordinated to take their data all at the same time, you would have a single file with (I'm guessing) 6 frequency measurements and 6 amplitude measurements  for the 6 receivers per sample instance (with a timestamp that goes with it).</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">This would be contained all within 1 file for the given (WWV) frequency being measured and submitted daily.</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)">If the data is being taken independently, you would have 6 sets of measurements each with their own unique timestamp.  </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The MOD field of the LC PSWS proposal could easily handle this case as you would define how it's being structured and stored.</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)">Depending on what you're collecting, this data structure would be defined by you as an addition to the file I've started if this is part of the Low Cost PSWS.  </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I see no problems with this as the MOD identifier field would define this structure for the database.</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)">How fast are the data samples being taken?  Once per second?  10Khz?  At RF frequencies?  </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)">Is this part of the Tangerine project?  If so, then I believe that they have a DRF  (Digital RF?) file format that they will be using for RF data rates and data storage.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">If this is the case, the Tangerine team will be defining that file naming and data structure themselves.</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)">Either way I don't see any roadblocks to do this within the structure being presented here or the DRF Tangerine Structure that they will define if you're sampling at RF frequencies.</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)">Hope this helps.</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><div dir="ltr" class="gmail_signature"><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>John C. Gibbons<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></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 6, 2020 at 6:50 PM Bill Liles <<a href="mailto:lilesw@gmail.com">lilesw@gmail.com</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><div><div dir="auto">I am not clear on something. Assume I have four receivers connected to the RPi. How many node numbers do I have? Just one?</div></div><div dir="auto"><br></div><div dir="auto">If only one and I collect the same freq range on all four receivers, then in the FRQ field, I represent each separate receiver such as WWV5A, WWV5B, etc, etc. Is this correct?</div></div><div dir="auto"><br></div><div dir="auto">Or do I have 4 nodes running on the same RPi since in the node description there is antenna information and all the antennas are different?</div><div dir="auto"><br></div><div dir="auto">My actual use case is 6 synced receivers covering the same frequency range at the same time, all connected to a vector sensor antenna consisting of 6 dipoles and 6 loops. I am just not sure how to handle.</div><div dir="auto"><br></div><div dir="auto">Or is all 6 separate collections merged into one file?</div><div dir="auto"><br></div><div dir="auto">Could someone please explain how I am to handle this situation?</div><div dir="auto"><br></div><div dir="auto">Thank you.</div><div dir="auto"><br></div><div dir="auto">Bill NQ6Z</div><div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 6, 2020 at 6:16 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">On Wed, May 06, 2020 at 16:42:44 -0400, John Gibbons wrote:<br>
> Update to spec - tried to be concise but specific for definitions so there<br>
> is no confusion.<br>
<br>
Thanks.<br>
<br>
Nits:<br>
<br>
'#' is called "hash", not "hashtag".  Children call it "hashtag" because<br>
Twitter made them stick a "hash" in front of their "tags", and they<br>
started conflating the hash ('#'), the tag ("getoffmylawn"), and the<br>
entire hashtag ("#getoffmylawn").  If that bothers you, call it an<br>
octothorpe.<br>
<br>
There's a typo immediately after that ("Metadata,txt" vs.<br>
"Metadata.txt").<br>
<br>
<br>
More serious issues:<br>
<br>
Please don't set aside any node ID other than "N00000".  Feel free to<br>
tag any nodes as test nodes either in the database or in the metadata,<br>
but no spec should try to list them all if there's going to be more than<br>
just the one (or a larger range of test node IDs).<br>
<br>
Again, Windows 7/10/etc. allow the use of '.' in filenames [0].  If you<br>
disagree, try running this on a Windows machine:<br>
<br>
        python -c "open('foo-2.5-bar.txt', 'w').close()"<br>
<br>
[0] <a href="https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file</a><br>
<br>
Please provide your specifications as plain text files so that I and<br>
others can make diffs of it instead of having to re-read the whole thing<br>
every single time (unless you don't want me nitpicking anymore?).  Also,<br>
you wanted these specifications to end up in version control, right?<br>
Turning them into plain text is step 1.<br>
<br>
<br>
Really serious issues:<br>
<br>
Don't specify the Python code to be anywhere inside the user's home<br>
directory!  Ever!  We're going to at least try to package up all of the<br>
code, right?  We'll put our Python modules in a proper namespace, and<br>
they will be installed in a standard location according to the FHS,<br>
Python convention, and the distribution's rules for Python packages.<br>
There's no reason for you to specify any location other than that.  Our<br>
importable modules will live in PYTHONPATH.  Our binaries will live in<br>
PATH.  Lintian may scream at us for the state of our packages, but it<br>
will *not* complain about us trying to install files in /home .<br>
<br>
Don't use "/temp" as a temp directory!  Either use "/tmp" (which exists,<br>
and is part of the FHS, and actually tends to be temporary), or better<br>
yet, use some combination of mktemp(1), mkdtemp(3), et. al. to generate<br>
temp files/directories subdirectory correctly.  In Python, take a look<br>
at the "tempfile" module.<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></div>
</div>
</blockquote></div>