[TangerineSDR] Local Host Functional Specification, Version 0.1

Mon May 13 16:55:41 EDT 2019

Call the PSWS a "data spigot".  :-)

On May 13, 2019, 4:29 PM, at 4:29 PM, Scotty Cowling via TangerineSDR <tangerinesdr at lists.tapr.org> wrote:
>Hi Bill,
>
>It is good to see specifications take shape!  TAPR has a Github
>account, 
>will this be sufficient for the "parking lot"?
>
>Comments on the spec.
>
>First, my concept of the TangerineSDR *includes* the SBC. Here is the 
>block diagram from the hardware spec:
>
>
>Without confusing things too much, can we make this distinction? So 
>really, if we take a TangerineSDR and program the SBC with the PSWS 
>Local Host software, we will transform the TangerineSDR into a PSWS. 
>(Likely we would also have to re-program the FPGA with new firmware,
>and 
>ensure that the TangerineSDR had the correct hardware sub-modules (CKM,
>
>RFM, DE, Sensor shield.)
>
>The part that you refer to as the "Tangerine" is really the
>TangerineSDR 
>DE and associated components (CKM, RFM, Sensor Shield).
>
>You do mention connecting the TangerineSDR DE directly to a server. I 
>want to make sure that our terms are consistently correct (blame my 
>OCD). In the TangerineSDR world, it is a server, a connection between 
>the RF world and our network. The combination of direct UDP data
>to/from 
>the DE and/or UDP/TCP C&C plus data to/from the SBC makes up the 
>TangerineSDR "Server" function. TangerineSDR talks to "clients", 
>processors, consumers (RX) or producers (TX) of data.
>
>So in the case where the SBC is the consumer and pre-processor of data,
>
>the SBC part of my definition of TangerineSDR becomes a client to the 
>DE. It then becomes a "server" to what you refer to as the Server,
>which 
>I presume is the Central Server of All PSWS Big Data. The Central
>Server 
>then becomes a "server" to Scientific clients that which to obtain and 
>study the data collected from all the thousands of PSWS.
>
>So what is the best nomenclature to use? Perhaps we should define a
>PSWS 
>Central Server to be "SWServer" or "SWSS". And then call out the 
>specific pieces of the hardware by their names, since we are really 
>defining them in terms of function in your spec. So please use 
>"TangerineSDR DE" and either "TangerineSDR SBC" or maybe just "SBC", 
>which is clear enough. To me, TangerineSDR by itself means the whole 
>CKM, RFM, DE and SBC.
>
>Again, my goal is for "TangerineSDR" to be configurable as "PSWS", 
>"P4G", "STEM SDR", etc. All of these will include some form of SBC.
>
>The confusion is probably my fault for putting the DE hardware spec
>cart 
>before the TangerineSDR system spec horse.
>
>On GNURadio, I doubt that you will find that any affordable SBC will 
>provide GNURadio with adequate run-time resources. Have you loaded 
>loaded and run it on a RPi? My opinion is that it is a great R&D tool, 
>but it is nowhere stable enough to include in any release of automated 
>PSWS software. I can't even imagine a thousand copies of GNURadio on 
>PSWS all around the world. It would simply not work. I am willing to be
>
>proven wrong, but we will need a lot more testing to prove stability 
>before then.
>
>On system updates, I plan to have the ability for the LCC to supporting
>
>updates to the DE firmware from the SBC. In my case, I was thinking 
>manual update by connecting the SBC to a web page and letting the user 
>pick an update from a list. The Remote C&C could implement an external 
>prcedure to virtualize a firmware update to the DE via the LCC 
>interface. It could even be made automatic or a push update from the 
>SWSS, with proper authentication.
>
>73,
>Scotty WA2DFI
>
>
>On 2019-05-12 06:52, Tom McDermott wrote:
>> Hi Bill - thanks for generating the spec.  It's good to see various 
>> pieces of the project starting
>> to get documentation. It's a nice document.  Can I borrow the nice 
>> HAMSCI and TAPR logos?
>>
>> Here are some comments on the spec - it may be too early to address 
>> most of them (perhaps
>> put them in the parking lot and get back to them later?).
>>
>> 1.User Interface.  Would it be useful to have an optional status / 
>> eye-candy display
>> of space weather, propagation, or measurements?   This might be a
>selling
>> point for people to acquire a PSWS. Would it need to download
>something
>> from the central server to do this?
>>
>> 2. Does the system need a way to do unattended recovery / restart?  
>> Once the
>> system has been configured for unattended operation and measurement, 
>> should
>> the system have a GUI settable configuration to enable the ability to
>auto
>> discover radios, program them to the current observational needs 
>> (frequency, band,
>> etc.), and establish server reporting?  Essentially, get back to what
>
>> it was doing
>> before power failed, or the node was rebooted, etc.
>>
>> 3. One of the key issues will be the time required to upload data to 
>> the central
>> server. For example:  a dual-receiver 8-band 192 ks/s 15-minute 
>> observation would
>> be about 20 GB of data. Assuming a 1 Mbit/s upload speed it would
>take 
>> about 2 days
>> to upload (assuming near 100% efficiency).  During that upload the 
>> 24-hour buffer
>> would be over-written.
>>
>> 4. Could the data to be uploaded to the server be compressed 
>> effectively?  Lossless
>> compression might not achieve much reduction in data size.  Lossy 
>> compression might
>> obscure science data. Can the SBC compress data while doing other 
>> tasks (concern
>> about CPU performance).
>>
>> 5. Should Gnuradio support be optional?  It is a lot of overhead, 
>> there may be
>> lower-resource approaches to data processing.  Does Gnuradio have 
>> reliability
>> issues for long-running / continuous tasks?
>>
>> -- Tom, N5EG
>>
>>
>>
>>
>> On Sat, May 11, 2019 at 12:46 PM Engelke, Bill <bill.engelke at ua.edu 
>> <mailto:bill.engelke at ua.edu>> wrote:
>>
>>     See attached, first draft of Functional Spec for the Local Host
>>     (SBC).   Hope to discuss at Dayton.
>>
>>     -73- Bill AB4EJ
>>
>>     W. D. Engelke (Bill), Asst. Research Engr.
>>
>>     Center for Advanced Public Safety
>>
>>     Cyber Hall
>>
>>     The University of Alabama
>>
>>     Tuscaloosa, AL 35487
>>
>>     Desk: (205) 348-7244
>>
>>     Mobile: (205) 764-3099
>>
>
>
>
>------------------------------------------------------------------------
>
>-- 
>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/20190513/7fd46557/attachment.html>