<div dir="ltr">Bill and Tom<div><br></div><div>Mike AA8K was recording the session as a podcast and the they will be posted on the website.</div><div>Mike and I are part of the openHPSDR.org teamspeak group.</div><div><br></div><div>Dave KV0S</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 4, 2019 at 10:57 AM Tom McDermott via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org">tangerinesdr@lists.tapr.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Here are my notes from last night's TeamSpeak session. Please let me know if</div><div>anything is captured wrong, and any key items missed.</div><div><br></div><div>1. Will users have upload bandwidth throttles or caps from their ISP's that limit</div><div>how much data they can upload? What will the project do if those are significant?</div><div>Severe caps could restrict the science that can be done.</div><div><br></div><div>2. The discovery process imposes a lot of requirements on the FPGA and DE.</div><div>Are there alternatives for phase 1 that simplify? If the DE streams directly to</div><div>the Internet (such as UDP) it will need to know it's IP address, the subnet mask,</div><div>and the Ethernet and IP addresses of the gateway.</div><div>A. Non-volatile memory on the DE to hold provisioning?</div><div>B. Use of I2C to connect to and provision the DE?</div><div> No decision reached yet.</div><div><br></div><div>3. Where to and how to code HDF5. General agreement that the DE will</div><div>produce internally 24-bit 2's complement binary. Should the DE convert to </div><div>single-precision floating point before sending to the Host? Should the host</div><div>stream straight to disk, or HDF5format then stream to disk? There are </div><div>Pros and Cons for each approach. It will depend on the amount of data</div><div>captured in real time.</div><div><br></div><div>4. Discussion on the approach to time-mark data from the DE. An</div><div>alternative approach of putting time into each packet was discussed, the</div><div>advantage being that it probably works better if packets go missing. The</div><div>NTP 64-bit time format (32-bits of Unix time, plus 32 bits of fractional time)</div><div>might be useful. Can the FPGA do this? </div><div><br></div><div>5. Discussion about the impact of decimation on the time stamping accuracy.</div><div>Are the decimation CIC and FIR low pass filters deterministic? The process is likely</div><div>very deterministic, meaning a calibration offset can be computed for the filter and it</div><div>won't change run-to-run. However the CIC filters are not phase-linear, meaning the</div><div>amount of time compensation changes across the +/- 192 kHz. filter passband.</div><div>The problem should be solvable, but may be a little messy.</div><div><br></div><div>6. Agreement to use GPS time for the time stamping on the DE. The Host or</div><div>central server can convert to UTC time if necessary. The DE FPGA should not</div><div>need to know the history of leap seconds in order to time stamp the packets.</div><div>It will have access to GPS time in hardware from the clock module.</div><div><br></div><div>-- Tom, N5EG</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div class="gmail_attr" dir="ltr">On Tue, Jun 4, 2019 at 7:15 AM Engelke, Bill via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)">
<div lang="EN-US" bgcolor="white">
<div class="gmail-m_5386228731436893148gmail-m_205301747631143837WordSection1">
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Scotty:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Good session last night – I hope someone was keeping notes; although I don’t recall that we made any firm decisions.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Certainly we can have something like Discovery available as an option you can turn on and off with the web UI in Local Host.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">-73- Bill<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) currentcolor currentcolor;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span style="color:windowtext"> TangerineSDR <<a href="mailto:tangerinesdr-bounces@lists.tapr.org" target="_blank">tangerinesdr-bounces@lists.tapr.org</a>>
<b>On Behalf Of </b>Scotty Cowling via TangerineSDR<br>
<b>Sent:</b> Monday, June 3, 2019 5:19 PM<br>
<b>To:</b> TAPR TangerineSDR Modular Software Defined Radio <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>><br>
<b>Cc:</b> Scotty Cowling <<a href="mailto:scotty@tonks.com" target="_blank">scotty@tonks.com</a>><br>
<b>Subject:</b> Re: [TangerineSDR] Local Host Functional Specification v 0.3 and TangerineSDR Requirements Document V0.3<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-bottom:12pt">Hi Bill,<br>
<br>
Thanks for the comments. <br>
<br>
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?<br>
<br>
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.<br>
<br>
73,<br>
Scotty WA2DFI<span style="font-size:12pt"><u></u><u></u></span></p>
<div>
<p class="MsoNormal">On 2019-06-03 14:52, Engelke, Bill wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Scotty – I have reviewed the doc you posted, and a few comments…</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<p class="gmail-m_5386228731436893148gmail-m_205301747631143837MsoListParagraph"><u></u><span>-<span style="font:7pt "Times New Roman"">
</span></span><u></u><span style="color:rgb(31,73,125)">I will update the Local Host Functional Spec to have section numbers.</span><u></u><u></u></p>
<p class="gmail-m_5386228731436893148gmail-m_205301747631143837MsoListParagraph"><u></u><span>-<span style="font:7pt "Times New Roman"">
</span></span><u></u><span style="color:rgb(31,73,125)">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.
</span><u></u><u></u></p>
<p class="gmail-m_5386228731436893148gmail-m_205301747631143837MsoListParagraph"><u></u><span>-<span style="font:7pt "Times New Roman"">
</span></span><u></u><span style="color:rgb(31,73,125)">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.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">-Talk to you later – 73- Bill</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></p>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) currentcolor currentcolor;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span style="color:windowtext"> TangerineSDR
<a href="mailto:tangerinesdr-bounces@lists.tapr.org" target="_blank"><tangerinesdr-bounces@lists.tapr.org></a>
<b>On Behalf Of </b>Scotty Cowling via TangerineSDR<br>
<b>Sent:</b> Monday, June 3, 2019 1:43 PM<br>
<b>To:</b> TAPR TangerineSDR Modular Software Defined Radio <a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">
<tangerinesdr@lists.tapr.org></a><br>
<b>Cc:</b> Scotty Cowling <a href="mailto:scotty@tonks.com" target="_blank"><scotty@tonks.com></a><br>
<b>Subject:</b> [TangerineSDR] Local Host Functional Specification v 0.3 and TangerineSDR Requirements Document V0.3</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:12pt">Hi Bill,<br>
<br>
This looks excellent! I have been working on a TangerineSDR requirements document, which I have put up on the web page here:<br>
<br>
<a href="http://TangerineSDR.com/TangerineSDR_documents/TangerineSDR_Requirements_V0_3.pdf" target="_blank">http://TangerineSDR.com/TangerineSDR_documents/TangerineSDR_Requirements_V0_3.pdf</a><br>
<br>
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.<br>
<br>
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?)<br>
<br>
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?<br>
<br>
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. <br>
<br>
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.<br>
<br>
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).<br>
<br>
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.
<br>
<br>
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. <br>
<br>
73,<br>
Scotty WA2DFI<u></u><u></u></p>
<div>
<p class="MsoNormal">On 2019-05-24 12:39, Engelke, Bill wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">W. D. Engelke (Bill), Asst. Research Engr.<u></u><u></u></p>
<p class="MsoNormal">Center for Advanced Public Safety<u></u><u></u></p>
<p class="MsoNormal">Cyber Hall<u></u><u></u></p>
<p class="MsoNormal">The University of Alabama<u></u><u></u></p>
<p class="MsoNormal">Tuscaloosa, AL 35487<u></u><u></u></p>
<p class="MsoNormal">Desk: (205) 348-7244<u></u><u></u></p>
<p class="MsoNormal">Mobile: (205) 764-3099<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
</blockquote>
<p class="MsoNormal"><span style="font-family:"Times New Roman ,serif",serif;font-size:12pt"> </span><u></u><u></u></p>
</blockquote>
<p class="MsoNormal"><span style="font-family:"Times New Roman",serif;font-size:12pt"><u></u> <u></u></span></p>
</div>
</div>
-- <br>
TangerineSDR mailing list<br>
<a href="mailto:TangerineSDR@lists.tapr.org" target="_blank">TangerineSDR@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote></div>
-- <br>
TangerineSDR mailing list<br>
<a href="mailto:TangerineSDR@lists.tapr.org" target="_blank">TangerineSDR@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">KV0S - Dave Larsen<br>Columbia, MO, USA</div>