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

Dave Larsen kv0s.dave at gmail.com
Tue Jun 4 13:36:58 EDT 2019


Bill and Tom

Mike AA8K was recording the session as a podcast and the they will be
posted on the website.
Mike and I are part of the openHPSDR.org teamspeak group.

Dave KV0S


On Tue, Jun 4, 2019 at 10:57 AM Tom McDermott via TangerineSDR <
tangerinesdr at lists.tapr.org> wrote:

> Here are my notes from last night's TeamSpeak session.   Please let me
> know if
> anything is captured wrong, and any key items missed.
>
> 1. Will users have upload bandwidth throttles or caps from their ISP's
> that limit
> how much data they can upload?  What will the project do if those are
> significant?
> Severe caps could restrict the science that can be done.
>
> 2. The discovery process imposes a lot of requirements on the FPGA and DE.
> Are there alternatives for phase 1 that simplify?    If the DE streams
> directly to
> the Internet (such as UDP) it will need to know it's IP address, the
> subnet mask,
> and the Ethernet and IP addresses of the gateway.
> A. Non-volatile memory on the DE to hold provisioning?
> B. Use of I2C to connect to and provision the DE?
>    No decision reached yet.
>
> 3. Where to and how to code HDF5.  General agreement that the DE will
> produce internally 24-bit 2's complement binary.  Should the DE convert to
> single-precision floating point before sending to the Host? Should the host
> stream straight to disk, or HDF5format then stream to disk? There are
> Pros and Cons for each approach. It will depend on the amount of data
> captured in real time.
>
> 4. Discussion on the approach to time-mark data from the DE.  An
> alternative approach of putting time into each packet was discussed, the
> advantage being that it probably works better if packets go missing.  The
> NTP 64-bit time format (32-bits of Unix time, plus 32 bits of fractional
> time)
> might be useful.  Can the FPGA do this?
>
> 5. Discussion about the impact of decimation on the time stamping accuracy.
> Are the decimation CIC and FIR low pass filters deterministic?  The
> process is likely
> very deterministic, meaning a calibration offset can be computed for the
> filter and it
> won't change run-to-run.  However the CIC filters are not phase-linear,
> meaning the
> amount of time compensation changes across the +/- 192 kHz. filter
> passband.
> The problem should be solvable, but may be a little messy.
>
> 6. Agreement to use GPS time for the time stamping on the DE. The Host or
> central server can convert to UTC time if necessary.  The DE FPGA should
> not
> need to know the history of leap seconds in order to time stamp the
> packets.
> It will have access to GPS time in hardware from the clock module.
>
> -- Tom, N5EG
>
>
>
>
>
> On Tue, Jun 4, 2019 at 7:15 AM Engelke, Bill via TangerineSDR <
> tangerinesdr at lists.tapr.org> wrote:
>
>> Scotty:
>>
>> Good session last night – I hope someone was keeping notes; although I
>> don’t recall that we made any firm decisions.
>>
>>
>>
>> Just to be clear, I am not against Discovery per se.  My concern is that
>> we need to keep the feature set of Phase 1 down to the minimum necessary to
>> achieve the mission, and guard against feature creep.  (Old habit of a
>> Project Manager). Coming out with a second version with more features
>> implemented is also handy for marketing purposes – it gives us an excuse to
>> publish a couple articles about the new stuff, thus keeping the project in
>> public awareness.
>>
>>
>>
>> Certainly we can have something like Discovery available as an option you
>> can turn on and off with the web UI in Local Host.
>>
>>
>>
>> Also – here is an idea for your list of potential ham apps – it is
>> something I have working in my DWatcher app.  We can have some processes
>> available that do things like watch for certain callsigns, grids, or
>> prefixes to show up on the air (digital modes, of course), or maybe (with
>> clever noise analysis) to watch for a given band to open, and send an email
>> to a given email address when detected. (I have configured this to send the
>> email to a mail-to-text site, so I get a text message when any one of a
>> list of D-Star users or DX stations comes on the air). Again, probably
>> something for Phase 2+, but something that might be attractive to hams.
>>
>>
>>
>> -73- Bill
>>
>>
>>
>> *From:* TangerineSDR <tangerinesdr-bounces at lists.tapr.org> *On Behalf Of
>> *Scotty Cowling via TangerineSDR
>> *Sent:* Monday, June 3, 2019 5:19 PM
>> *To:* TAPR TangerineSDR Modular Software Defined Radio <
>> tangerinesdr at lists.tapr.org>
>> *Cc:* Scotty Cowling <scotty at tonks.com>
>> *Subject:* Re: [TangerineSDR] Local Host Functional Specification v 0.3
>> and TangerineSDR Requirements Document V0.3
>>
>>
>>
>> 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>
>> <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> <tangerinesdr at lists.tapr.org>
>> *Cc:* Scotty Cowling <scotty at tonks.com> <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
>>
>>
>>
>>
>>
>>
>> --
>> TangerineSDR mailing list
>> TangerineSDR at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>>
> --
> TangerineSDR mailing list
> TangerineSDR at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>


-- 
KV0S - Dave Larsen
Columbia, MO, USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20190604/29461ea7/attachment-0001.html>


More information about the TangerineSDR mailing list