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

John Gibbons jcg66 at case.edu
Wed May 6 23:25:41 EDT 2020


Your station is given a node number to define its location. So yes, you
have a single node number.

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).
This would be contained all within 1 file for the given (WWV) frequency
being measured and submitted daily.

If the data is being taken independently, you would have 6 sets of
measurements each with their own unique timestamp.
The MOD field of the LC PSWS proposal could easily handle this case as you
would define how it's being structured and stored.

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.
I see no problems with this as the MOD identifier field would define this
structure for the database.

How fast are the data samples being taken?  Once per second?  10Khz?  At RF

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.
If this is the case, the Tangerine team will be defining that file naming
and data structure themselves.

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.

Hope this helps.

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 Wed, May 6, 2020 at 6:50 PM Bill Liles <lilesw at gmail.com> wrote:

> I am not clear on something. Assume I have four receivers connected to the
> RPi. How many node numbers do I have? Just one?
> 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?
> 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?
> 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.
> Or is all 6 separate collections merged into one file?
> Could someone please explain how I am to handle this situation?
> Thank you.
> Bill NQ6Z
> On Wed, May 6, 2020 at 6:16 PM Rob Wiesler via TangerineSDR <
> tangerinesdr at lists.tapr.org> wrote:
>> On Wed, May 06, 2020 at 16:42:44 -0400, John Gibbons wrote:
>> > Update to spec - tried to be concise but specific for definitions so
>> there
>> > is no confusion.
>> Thanks.
>> Nits:
>> '#' is called "hash", not "hashtag".  Children call it "hashtag" because
>> Twitter made them stick a "hash" in front of their "tags", and they
>> started conflating the hash ('#'), the tag ("getoffmylawn"), and the
>> entire hashtag ("#getoffmylawn").  If that bothers you, call it an
>> octothorpe.
>> There's a typo immediately after that ("Metadata,txt" vs.
>> "Metadata.txt").
>> More serious issues:
>> Please don't set aside any node ID other than "N00000".  Feel free to
>> tag any nodes as test nodes either in the database or in the metadata,
>> but no spec should try to list them all if there's going to be more than
>> just the one (or a larger range of test node IDs).
>> Again, Windows 7/10/etc. allow the use of '.' in filenames [0].  If you
>> disagree, try running this on a Windows machine:
>>         python -c "open('foo-2.5-bar.txt', 'w').close()"
>> [0] https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file
>> Please provide your specifications as plain text files so that I and
>> others can make diffs of it instead of having to re-read the whole thing
>> every single time (unless you don't want me nitpicking anymore?).  Also,
>> you wanted these specifications to end up in version control, right?
>> Turning them into plain text is step 1.
>> Really serious issues:
>> Don't specify the Python code to be anywhere inside the user's home
>> directory!  Ever!  We're going to at least try to package up all of the
>> code, right?  We'll put our Python modules in a proper namespace, and
>> they will be installed in a standard location according to the FHS,
>> Python convention, and the distribution's rules for Python packages.
>> There's no reason for you to specify any location other than that.  Our
>> importable modules will live in PYTHONPATH.  Our binaries will live in
>> PATH.  Lintian may scream at us for the state of our packages, but it
>> will *not* complain about us trying to install files in /home .
>> Don't use "/temp" as a temp directory!  Either use "/tmp" (which exists,
>> and is part of the FHS, and actually tends to be temporary), or better
>> yet, use some combination of mktemp(1), mkdtemp(3), et. al. to generate
>> temp files/directories subdirectory correctly.  In Python, take a look
>> at the "tempfile" module.
>> --
>> 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/20200506/f0bf6741/attachment-0001.html>

More information about the TangerineSDR mailing list