[TangerineSDR] Seeking your Review and Comment on Tangerine SBC Functional Specification

[Scotty Cowling]

Hi Bill,

On discoverability, it is an artifact for sure, but I would like to 
define it, even if it is just to maintain compatibility with openhpsdr 
systems.

Discoverability should be a local C&C protocol only. It would provide 
the ability to plug multiple boards together with minimal configuration.

73,
Scotty WA2DFI

On 2019-10-08 11:56, Engelke, Bill via TangerineSDR wrote:
> Hello Rob - thanks for your most helpful reply - I will be incorporating your thoughts into the next version.  I have a few follow-up remarks:
>
> - I will discuss the Ring Buffer concept with Nathaniel.  It seems like it could be useful, it's just that it would not be practical with today's hardware to run it at the huge data rate originally envisioned.
> - Excellent idea to add a statement about making the system able to survive power cycles. That was one of the things that made me abandon Linux for a number of years after it first became available - if the power went off, the system would often get bricked. I have been delighted to find that this is not the case with more modern implementations (i.e., Raspberry, Odroid N2 etc)
> - Discoverability: I am not sure of the value of this either, it is an artifact from how the OpenHPSDR-compatible systems work. With TangerineSDR, we do plan to support the config where there are multiple units on the same network (institutional setting); but the plan is that these would be individually configured using a web running in the SBC.
> - Operating system: you mention Debian several times.  The Odroid N2 uses Ubuntu. If someone wants to go through the effort to gen up Debian to run on it, they are welcome to do so, but I would consider that out of scope for Phase 1.
> - Waiting for files to close: what I mean by this is: if a file is actively being uploaded to the server, the server should not attempt to open and read that file before the transfer is complete; in fact, I would expect the file transfer process to maintain exclusive rights to the file until transfer is done (and file closed).  What I have been imagining for Use Case 3 (data pre-processed by GNURadio in TangerineSDR) is that the FFT snapshots (of small chunks of bandwidth around WWV) would be uploaded in real time and stored as database records (rather than files), which makes them immediately available for real-time analysis on the server.  (This is not to say we can't also support Use Case 1, which involves uploading large files from the ring buffer - in which case we have the condition of waiting for a file transfer to complete before we can access the file on the server).  I'm sure there are other ways to "skin this cat," - if I am missing something, please advise.
> - Yes, mender.io is merely an example. I will look into how atomic updates are done with Ubuntu.  QUESTION: I am guessing that some geeks (including self here) will prefer to have control over when updates are applied, and others are happy to let the system handle these automatically; we probably should let people have the choice, shouldn't we? Maybe default to automatic, but let the user opt out of that?  Or, what do you suggest?
>
> Please keep me informed of your progress on building an example system.  We are being asked (by Nathaniel, et al) to make data collection methods common between TangerineSDR and the CWRU system (does it have a name?) ... I have been playing with a development version of the SatNOGS Network, and plan to use a modified version of it for our Phase 1 Central Control System & database.
>
> -tnx es 73 - Bill AB4EJ
>
>
> -----Original Message-----
> From: Rob Wiesler <robert.wiesler at case.edu>
> Sent: Thursday, October 3, 2019 10:02 PM
> To: Engelke, Bill <bill.engelke at ua.edu>
> Cc: TAPR TangerineSDR Modular Software Defined Radio <tangerinesdr at lists.tapr.org>; Ward Silver <hwardsil at gmail.com>; Atkison, Travis <atkison at cs.ua.edu>
> Subject: Re: Seeking your Review and Comment on Tangerine SBC Functional Specification
>
> On Thu, Sep 26, 2019 at 2:48 PM Engelke, Bill <bill.engelke at ua.edu> wrote:
>> You may notice that there are a number of things we have dreamed about which are not included in the Functional Spec (but may be included in  the Future Concepts section). This spec is intended to capture Phase 1 (i.e., what we are going to do that is NSF-funded).  We plan to made the system modular so that if volunteer developers wish to contribute additional work outside the major scope, they can do that.
> I notice that the 24-hour ring buffer is still specified for Phase 1.
> I thought we had decided to remove that?  It should still be possible to add back in the future.  (It doesn't bother me if it stays in - I'm just trying to get my memory of the meeting at DCC in order.)
>
> Since the Local Host (SBC) is physically connected to (or at least co-located with) the DE, I'm not sure if there are any security concerns there at all?  So long as unprivileged users can't reprogram the DE, and reprogramming the DE is either atomic or restartable (i.e.
> a partial update won't brick the DE), that should be fine.
>
> As I mentioned at DCC, the Case PSWS has an additional "Guiding Principle" not listed in the functional specification: the system shall not enter a state during which a power cycle would break it in ways not automatically rectified when power comes back on.  This means that all updates will be atomic (which isn't really the case on Debian systems by default, although it's been getting better over time).
>
> I'm not sure I see any particular value to network discoverability
> (3.5.6) beyond what a normal Debian system already does, at least as far as Phase 1 is concerned.  If there's anything on the local network that needs to talk to a TangerineSDR, that should probably be configured explicitly.
>
> In the caption for Figure 4 in section 3.6, I'm not sure what you mean by waiting for files to close.  Closing a file in a modern operating system is not an expensive operation, so long as you don't subsequently block on syncing the file to disk (which we won't).  If you mean that you want real-time processing of data by the Central System, I don't really see an issue, as there's no reason why we couldn't send data-to-be-uploaded through the network to the database at the same time as we store it to disk (as you would in a typical Store-Forward architecture).  (If this paragraph doesn't make sense to you, that's because I'm having trouble understanding the comment at the end of the caption.)
>
> I know it was just mentioned as an example, but there's no reason to add a dependency on mender.io .  That's just extra complexity we'll have to manage, and quite possibly vaporware to boot.  I'd much rather rely on a normal Debian system update, with our software packaged in a side repo, backed by a simple system to make sure updates are atomic (btrfs snapshots and an initramfs hook to roll back partial changes in case of a powercycle, for example) and don't require user intervention (just a matter of configuring dpkg correctly) by default.  In any case, we need to make sure that operating system updates *and* PSWS-specific updates are handled identically, and are both atomic and non-interactive.
>
> (I'm going to be experimenting with setting up such a system in the near future.  I'll keep you all informed.)
>
> ACK the rest of the changes.
>
> (There's some indication that the list may not like .edu addresses.
> Apologies if I have to resend this.)
>
> --
> 73 DE AC8YV