[TangerineSDR] Local Host Functional Specification, Version 0.1

[Tom McDermott]

Hi Bill.   I agree, a common document for issues raised with sections
defined as needed makes the most sense.
I created a folder on the google drive where the specs I wrote are placed.
It may be as good a location as any.

Nathaniel can open up access to the folder as needed I think.  My
preference is that the specs are publicly viewable.

The SATA-2 disk description was meant to relate to the throughput, not the
physical connection.  I'll look
through my documents and clarify.     USB spinning disks actually have a
SATA interface internally, and a
small circuit board that converts it to USB; for USB3 that would be SATA-3.

-- Tom, N5EG




On Mon, May 13, 2019 at 9:08 AM Engelke, Bill <bill.engelke at ua.edu> wrote:

> 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>
> *Sent:* Sunday, May 12, 2019 8:53 AM
> *To:* Engelke, Bill <bill.engelke at ua.edu>
> *Cc:* Scotty Cowling <scotty at tonks.com>; Nathaniel A. Frissell <
> nathaniel.a.frissell at njit.edu>; 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>
> 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/57710943/attachment-0001.html>