<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Bill,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">If the DRF data is being taken in, let's say,  1 minute epochs and the request for data from the Central host is for a 'set of 30' 1 minute data blocks makes perfect sense.  The data already exists and is packaged and sent back to the Central Host without any data manipulation.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">IF the blocks are not refined that small, will the request for data (presumably after the fact) from the Central host be in a block / time segment size that it has already been collected in or will the node have to massage the data to comply?  </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">I guess what I'm getting at is if the data sets are pre-recorded in 5 minutes long blocks synced to 00 minutes (0,5,10,15,20, etc data blocks being collected), will the host ever ask for data from 00:02 to 00:08 (8 minutes of data imbedded within 2 already existing data blocks) and force some data crunching to reply?  </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Or am I trying to read tooo much into this....</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">John N8OBJ</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="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><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 9, 2020 at 12:38 PM Engelke, Bill via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org">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">

<div lang="EN-US">

<div class="gmail-m_6383104140183795322WordSection1">

<p class="MsoNormal">Hello All:<u></u><u></u></p>

<p class="MsoNormal"><u></u> <u></u></p>

<p class="MsoNormal">I have a prototype of a process working for moving (raw) spectrum data from the TangerineSDR to the Central Host; I would like any interested colleagues to review and comment on it, since it is such an important piece of the system. I have

 a mockup running in Ubuntu on a virtual server, but the final Central Host process will run under CentOS and Django. Here’s how the process works:<u></u><u></u></p>

<p class="MsoNormal"><u></u> <u></u></p>

<ol style="margin-top:0in" start="1" type="1">

<li class="gmail-m_6383104140183795322MsoListParagraph" style="margin-left:0in">When in Ringbuffer mode, the TangerineSDR collects one to 16 bands of spectrum data, saving it in a ring buffer in Digital RF format. (Typical actual use would probably be the ~ 5

bands of WWV).</li><li class="gmail-m_6383104140183795322MsoListParagraph" style="margin-left:0in">Every so often (say, 120 seconds), the TangerineSDR sends a heartbeat packet to the Central Host.

</li><li class="gmail-m_6383104140183795322MsoListParagraph" style="margin-left:0in">If the Central Host has been given a data collection command (by a superuser), it will reply to the heartbeat with a Data Request that has a start and end time.</li><li class="gmail-m_6383104140183795322MsoListParagraph" style="margin-left:0in">The TangerineSDR finds all the files and metadata collected during the requested time frame and uses tar to put into a single file (optionally compressed).

<u></u><u></u></li><li class="gmail-m_6383104140183795322MsoListParagraph" style="margin-left:0in">The upload file gets named according to the (still being refined) CWRU naming convention (except that band info will not appear in the file name since a DRF file will usually contain

 multiple bands).<u></u><u></u></li><li class="gmail-m_6383104140183795322MsoListParagraph" style="margin-left:0in">The TangerineSDR optionally sets the maximum upload rate (“throttle”) and uses the utility lftp to send the file to the sftp server running on the Central Host. Each user has their

 own “incoming” directory. <u></u><u></u></li><li class="gmail-m_6383104140183795322MsoListParagraph" style="margin-left:0in">The Central Host checks the incoming directories at certain intervals; when it finds a file package, it moves it to a central collection and puts a cross-reference into the relational

 database.<u></u><u></u></li></ol>

<p class="MsoNormal"><u></u> <u></u></p>

<p class="MsoNormal">Notes: I thought about a number of different ways of moving the data from TangerineSDR to the Central Host; this way seems promising because it offers the following benefits –<u></u><u></u></p>

<p class="MsoNormal"><u></u> <u></u></p>

<ul style="margin-top:0in" type="disc">

<li class="gmail-m_6383104140183795322MsoListParagraph" style="margin-left:0in"><span style="font-family:"Courier New"">lftp</span> is restartable in case the upload is interrupted. Some uploads will run for a long time.<u></u><u></u></li><li class="gmail-m_6383104140183795322MsoListParagraph" style="margin-left:0in">Using sftp as the protocol protects the data in transit.<u></u><u></u></li><li class="gmail-m_6383104140183795322MsoListParagraph" style="margin-left:0in">The Central Host can handle a lot of uploads at once without burdening the website.<u></u><u></u></li><li class="gmail-m_6383104140183795322MsoListParagraph" style="margin-left:0in">Since each user has a unique UID and password, and data travels encrypted, we should be able to minimize hackers uploading garbage.<u></u><u></u></li><li class="gmail-m_6383104140183795322MsoListParagraph" style="margin-left:0in">The TangerineSDR has another mode (“snapshotter”) which pre-processes raw spectrum into frequency domain data – this will be handled differently (more to come on that).<u></u><u></u></li></ul>

<p class="gmail-m_6383104140183795322MsoListParagraph"><u></u> <u></u></p>

<p class="gmail-m_6383104140183795322MsoListParagraph" style="margin-left:0.25in">I’m sure I have not thought of everything though;  if you have a suggestion on how to do this better, it is most welcome – thanks for your help!   -73- Bill  AB4EJ

<u></u><u></u></p>

</div>

</div>

-- <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>