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

Thu May 7 00:06:44 EDT 2020

Aidan,

Let's say a person wants to switch the monitoring frequency mid UTC day.😵

He / she would:

1 - Stop the data collection process
2 - Force the file processing [normally done automatically at the end of
the day] which forces the data collected so far to be processed and stored
in the appropriate sub-directory.
3 - Delete the raw data file for today's date stored in the
~/WWVdata/ directory for today's UTC date.
4 - Re-tune the radio for the new frequency
5 - Restart the data collection process

Since you deleted today's raw data file, the system will recognize this and
start a new file with all the necessary metadata contained within.
It will be processed normally at the 00:00:00 time crossover [as normal] at
the new frequency and stored appropriately.

The only limitation I can see with this is if you went back to one of the
frequencies you've already saved, it will get wiped out with the 2nd data
set writing over it.
But really - that much frequency hopping in one UTC day is getting a bit
ridiculous...

Again, this frequency changing could easily be done multiple times during
the day and the system will happily do it, but it sorta defeats the purpose
of long term data collection.
The short epochs of data are not really that useful [like you saw in the
festival of frequencies].

We could simply require no repeat frequencies in a given UTC day which I
don't think is a serious restriction.

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 10:45 PM Aidan Montare via TangerineSDR <
tangerinesdr at lists.tapr.org> wrote:

> 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
> --
> 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/20200507/fa5543bb/attachment.html>