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

Thu May 7 07:48:59 EDT 2020

Hi Bill,

  I'll reply off-list with Digital RF information, so as not to use
bandwidth here.

73
Phil W1PJE

On Thu, May 7, 2020 at 7:47 AM Bill Liles via TangerineSDR <
tangerinesdr at lists.tapr.org> wrote:

> Thanks for all the replies.
>
> My interest is doing oblique ionosondes from transmitters of opportunity,
> including ionosondes. Thus, I want to separate the X and O wave signals.
> Also, I want to see how the path direction (AZ and EL) changes with time
> and from the great circle path. This helps with understanding TIDs,
> especially if I can have multiple sites join in collects.
>
> Thus the requirement for a vector sensor antenna, so actually have 6
> antennas.
>
> I guess I will be using the DRF format since I would like to collect I/Q
> and time from each antenna at each site. Do DRF files have a separate file
> naming convention?
>
> It is important to associate which data is associated with which antenna
> so can combine the data properly to get polarization, AZ and EL.
>
> Thank you.
>
> Bill NQ6Z
>
>
> On Thu, May 7, 2020 at 12:40 AM John Gibbons via TangerineSDR <
> tangerinesdr at lists.tapr.org> wrote:
>
>>
>> Being we don't know the nature of Bill's data collection yet, let's get
>> all the data collection requirements straight before we jump into the
>> solution space to solve the problem...
>>
>> That's the intent of this document - to flush out and to understand ALL
>> of the experiments going on and create a database that can ultimately
>> handle them.  No one understands them all yet.
>>
>> I don't know anything that has been decided for the Tangerine Project
>> which is why they will define their portion of the project.
>>
>> Bill's project is another example of this.  Multiple nodes at the
>> same location may fix one problem, but it creates others.  Not appropriate
>> at this stage to do that yet.
>>
>> Let's get the data collection document to a level of completion that
>> we're all happy with first. Then we can understand and solve the overall
>> data collection problem.
>>
>> 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 Thu, May 7, 2020 at 12:14 AM Rob Wiesler via TangerineSDR <
>> tangerinesdr at lists.tapr.org> wrote:
>>
>>> On Wed, May 06, 2020 at 23:25:41 -0400, John Gibbons wrote:
>>> > 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 6 copies of fldigi (or any program) are writing to the same file,
>>> you're going to have data corruption.  There are four reasonable ways to
>>> proceed:
>>>
>>> - Add some field to the name of the file that fldigi's writing to, so
>>>   you're writing to 6 files per day, one from each process, then somehow
>>>   tell fldigi what value of that field to use.  The best way to do that
>>>   probably involves an environment variable that fldigi reads.  Then
>>>   relax or work around the one-upload-per-day-per-node restriction
>>>   somehow.
>>> - Have 6 different nodes, and somehow tell fldigi which node it is.  The
>>>   best way to do that probably involves an environment variable that
>>>   fldigi reads.  Since all nodes have exactly the same metadata
>>>   (right?), I don't think you'd even have to modify John's metadata
>>>   directory scheme.  This is probably saner than the previous option.
>>> - Instead of having fldigi write to a file directly, have it send its
>>>   measurements to a daemon via a UNIX socket (or a TCP socket bound to
>>>   127.0.0.1).  The daemon then takes care of reading the metadata,
>>>   creating the .csv files, and rotating them each UTC day.  This doesn't
>>>   involve any environment variables (so long as only one node is used
>>>   and the metadata is all the same), but would effectively undo all the
>>>   effort John went through to get his changes upstreamed.  Still, I
>>>   think this is the sanest option so far.  Actually, I proposed
>>>   something like this very early in the project, when David was setting
>>>   up the first prototype of the system, and I was shot down because it
>>>   seemed too complicated.  If you want to go this route, I can write the
>>>   code - it'll take a fraction of a Saturday or Sunday to go from zero
>>>   to having a finished pair of packages (one for the modifications to
>>>   fldigi, another for the daemon).
>>> - Run fldigi as 6 different users, all belonging to the same set of
>>>   groups, each with their own unique home directory.  Then they can
>>>   share or not share metadata and/or node IDs as desired.  This is the
>>>   least sane option, but (when using different nodes) requires no
>>>   changes to existing and planned code.
>>>
>>> I wrote the above list under the assumption that it is okay for the
>>> antenna that generated each record not to be associated with that
>>> record.  I did that intentionally for the sake of argument only.
>>> Actually, I don't think that's okay at all, and there needs to be a
>>> different node for each antenna (because the metadata must be
>>> different).  Probably Phil and/or Nathaniel should jump in and tell us
>>> what they want/need.
>>>
>>> --
>>> 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
>>
> --
> TangerineSDR mailing list
> TangerineSDR at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>

-- 
----
Phil Erickson
phil.erickson at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20200507/1c81a958/attachment.html>