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

[Aidan Montare]

Wanted to add my thoughts on some of the earlier comments (on the topic of
what to do when data collection stops and then starts again):

I also want to point out that continuing the same file where it was left
off might create problems if the new data has different metadata than the
old data.

One case we should handle is when a user makes modifications to their
station setup in the middle of the day. What happens then? We might want a
way to distinguish the end of data collected with an old instrument and the
beginning of data with a new instrument, for example.

Also, I like Nathaniel's comment of having the filename be just for
convenience, and all the relevant bits that were used to create it be
included in the file.

On Wed, May 6, 2020 at 8:27 PM Bill Liles via TangerineSDR <
tangerinesdr at lists.tapr.org> wrote:

> Sorry, I meant 3 dipoles and 3 loops.
>
> Bill NQ6Z
>
> 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
>>>
>> --
> TangerineSDR mailing list
> TangerineSDR at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>


-- 
Sincerely,

Aidan Montare
CWRU Class of 2021
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20200506/d15e4050/attachment.html>