[TangerineSDR] Local Host Functional Specification, Version 0.1

Mon May 13 12:08:10 EDT 2019

Tom – I came across the data speed computation in the PSWS specification, so no need to respond on that.  The spec mentions that SATA-2 might be needed.  What about USB-3?  To connect a SATA drive to SBC requires an additional bridge.  -73- Bill AB4EJ

From: TangerineSDR <tangerinesdr-bounces at lists.tapr.org> On Behalf Of Engelke, Bill via TangerineSDR
Sent: Monday, May 13, 2019 10:21 AM
To: Tom McDermott <tom.n5eg at gmail.com>
Cc: Engelke, Bill <bill.engelke at ua.edu>; Nathaniel A. Frissell <nathaniel.a.frissell at njit.edu>; tangerinesdr at lists.tapr.org
Subject: Re: [TangerineSDR] Local Host Functional Specification, Version 0.1

To – thanks for the great feedback.  I think we should definitely mark all our docs with the HamSci and TAPR logos – we need also a logo to identify the Tangerine itself.

Parking Lot – what is the TAPR convention for this – a separate one in each document or a single parking lot document (in sections by product line) for everything?  Probably latter works best.   Is there one out there already?  I don’t see one in the shared Google drive, so I will start one.

On the topics you mention:

1.       UI.  Some useful info shown on the home screen (of the Local Host) might be a good idea. When thinking about that, we need to keep in mind that there will be (I think)three (3) different web interfaces for the user. To wit:

a.       UI to the Tangerine. This is a web server running on the NIOS cpu, and allows the user to configure the radio part.

b.       UI to the Local Host. This web server runs on the Local Host, allowing the user to start data collection, configure the connection to Central Control, etc.

c.       UI to the Central Control. This web server lets the user create their account, see how much data they have uploaded, etc.

The eye candy or info or whatever could appear on either the Local Host or the Central Control.

2.       I will add something to the spec to specify that the user can configure the system to automatically start up into data collection mode (assuming all setup is done & correct) after a restart.

3.       On data collection and upload:

a.       Tom – could you please explain how you computed the amount of data that would be collected in 15 minutes?  I don’t doubt your number, I just need to know for my understanding. I am coming up with some different numbers, so I must be missing something, such as how much space is occupied by timing data , etc.

b.       Nathaniel – perhaps you could weigh in on what upload times and minimum data collection times would meet the science objectives.

c.       This is another case where an individual’s capabilities may dictate limits on what data they can collect. For example, it may be that if a user’s upload speed is 1 MBps (I wish mine was even that fast!) they can only run a single receiver collecting a single 192ks slice. Another approach might be to limit the data collection time; or some combination thereof.

d.       An additional consideration: using the estimate of 20 GB per 15 minutes, the ring buffer needs to be ~ 1.9 TB.  I anticipate that we will therefore need to specify that the user must have at least a 2 TB USB-3 hard drive.  However, consider this: for a little more money, the user can get a 4 TB USB-3 disk, and we can freeze a portion of it for upload.

e.       See also my remarks on GNURadio, below.

4.       Compression: we will need to test this with some sample SBCs and see what they can actually do. Also, we need to see how much compression we can get (both lossy and lossless) on this specific type of data. I will try this at home with I&Q data collected from my Red Pitaya.

5.       GNUradio support is not a high priority, but we might need it to cope with bandwidth limitations. That is, where people have major problems with upload speeds, we could use GNURadio to do batch FFTs and just upload the waterfall (instead of the raw data).  I think we have always had this in the back of our mind for coping with bandwidth limitations, and the SatNOGS system does exactly this, with good results. Also, the geeks who are interested in this project in the first place are likely to want to play with the signals & data themselves and might expect it.

All further discussions are most welcome!    -73- Bill  AB4EJ

From: Tom McDermott <tom.n5eg at gmail.com<mailto:tom.n5eg at gmail.com>>
Sent: Sunday, May 12, 2019 8:53 AM
To: Engelke, Bill <bill.engelke at ua.edu<mailto:bill.engelke at ua.edu>>
Cc: Scotty Cowling <scotty at tonks.com<mailto:scotty at tonks.com>>; Nathaniel A. Frissell <nathaniel.a.frissell at njit.edu<mailto:nathaniel.a.frissell at njit.edu>>; tangerinesdr at lists.tapr.org<mailto:tangerinesdr at lists.tapr.org>
Subject: Re: Local Host Functional Specification, Version 0.1

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20190513/d9898a4c/attachment-0001.html>