[TangerineSDR] Local Host Functional Specification v 0.3 and TangerineSDR Requirements Document V0.3

[Scotty Cowling]

Hi Bill,

This looks excellent! I have been working on a TangerineSDR requirements 
document, which I have put up on the web page here:

http://TangerineSDR.com/TangerineSDR_documents/TangerineSDR_Requirements_V0_3.pdf

What I call the "C&C Processor" is what you call "Local Host". I like 
your term better, so I will change it in my next revision.

Since the SBC can run several processes, it seems that "Command and 
Control", "web browser", "data analysis", "ring buffer storage", as well 
as optional functions "GnuRadio", "WSPR", "RBN", etc are all just 
applications running under the Local Host operating system. I am not 
sure how to make this more clear (maybe it is clear enough?)

One other thing (maybe Tom already asked for this), can you put section 
numbers on the document to make it easier to reference to specific parts?

You mentioned the Local Host's ability to program the FPGA on the DE. 
While you can always plug a USB Blaster directly onto the DE JTAG port 
(you will need to do this to run the SignalTap debugging software in the 
Quartus tools anyway), here is how it will eventually work.

The MAX10's configuration is in stored in SRAM cells within the part.  
Being volatile, it the SRAM must be loaded at every power up. The MAX10 
uses internal flash memory to store two configuration images. On power 
up, the MAX10 automatically loads the main image into SRAM and releases 
its internal reset, running the default configuration. If this flash 
image gets corrupted, the MAX10 will automatically load the secondary 
image and attempt to run that.

So the idea is to use the main image as the "upgrade-able" image, while 
the secondary image is the "factory" image that is never modified. Both 
images contain a boot loader that implements flash erase and write of 
the main image (but not the secondary one) via the Ethernet port. Note 
that the MAX10 runs out of SRAM. Any changes to the flash image only 
take effect at the next reset cycle (power up or programmable reset).

So the Local Host will run an "update" application that will talk to the 
MAX10's boot loader code. If the main flash image gets corrupted (e.g., 
power fail during update), the secondary image will automatically 
provide the boot loader function. I like the Elecraft model of being 
able to read the current DE firmware version and hardware configuration 
and then go out to the "TangerineSDR Repository" and offer the user 
clickable firmware versions that match his hardware. Firmware versions 
from local storage can also be included for those intrepid souls who 
want to write their own FPGA code (or for us developers writing/updating 
existing code). It can all be GUI-driven (maybe all from a web browser?) 
so it will be easy.

My hope is that it will be so easy that users can switch between 
applications like PSWS, RBN, WSPR at any time. It is *software* defined, 
after all! :-)  I may be expecting too much, however, since external 
connections will likely change for each application, and they are *not* 
software defined.

73,
Scotty WA2DFI

On 2019-05-24 12:39, Engelke, Bill wrote:
>
> Scotty - Please see attached, updated to include some of the things 
> discussed at Dayton.  Next I will work on the Functional 
> Specifications for the Central Control & Database system.
>
> If anyone would like me to start posting to the TAPR github or 
> somewhere, please just text credentials to my mobile number, below.  I 
> can assure everyone that I will not make a mess of it, having done 
> this before.
>
> 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/20190603/2e1167ac/attachment.html>