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

[Scotty Cowling]

Hi Bill,

Thanks for the comments.

I will think a bit more on the discovery feature. Maybe you are right, 
the web server obviates the need for discovery. It might still be useful 
in small systems to allow them to somewhat self-configure. Is there a 
way we could include it as an implementation-optional feature of the 
protocol without it being a security risk? Maybe a feature we can turn off?

My section 4 does need a lot more work. I don't want to limit things to 
just WSPR and RBN, but to anything that can be implemented in an 
application running on the Local Host. I will see how I can word it. 
Making things appealing to more hams is always a good thing. Maybe if we 
can make the TangerineSDR do multiple things at once (like a multi-band 
RBN receiver and PSWS simultaneously) we will get more PSWS users.

73,
Scotty WA2DFI

On 2019-06-03 14:52, Engelke, Bill wrote:
>
> Scotty – I have reviewed the doc you posted, and a few comments…
>
> -I will update the Local Host Functional Spec to have section numbers.
>
> -Regarding the Discovery feature: recall that the Local Host will be 
> running a web server, via which the user will exert control over the 
> Local Host. The user will be able to enter the address of a large 
> local client box to send data to.  Do we really wish to add the 
> ability for the client box to grab control of the Tangerine? This 
> whole Discovery concept seems to me a holdover from the days where the 
> SDR was little more than an ADC.
>
> -You mention WSPR and RBN below (and FT8 reception could also be 
> added) – these will make the devices more appealing to Hams. Perhaps 
> you would like to add these to Section 4.
>
> -Talk to you later – 73- Bill
>
> *From:*TangerineSDR <tangerinesdr-bounces at lists.tapr.org> *On Behalf 
> Of *Scotty Cowling via TangerineSDR
> *Sent:* Monday, June 3, 2019 1:43 PM
> *To:* TAPR TangerineSDR Modular Software Defined Radio 
> <tangerinesdr at lists.tapr.org>
> *Cc:* Scotty Cowling <scotty at tonks.com>
> *Subject:* [TangerineSDR] Local Host Functional Specification v 0.3 
> and TangerineSDR Requirements Document V0.3
>
> 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/ee9ac23c/attachment.html>