<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Tom – a question for you – when you say “</span>the FPGA does both the DE function, and via the CPU-block does the SBC<o:p></o:p></p>
<p class="MsoNormal">function<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">” are you suggesting we should try to do
<b><i>all</i></b> the processing of the SBC (which I an anticipating will be considerable) in the NIOS II that is on the FPGA chip? While it probably would simplify things in some ways, I don’t feel confident that it will have the necessary capacity (e.g,
for running a lot of GNUradio stuff). We have been talking about a SBC like the Odroid XU4; my suggestion would be to simply specify that users have to use the specific SBC we select and design for (if they want a near-turnkey system); if they want to implement
something else on their own that is fine, but would have to be technically independent.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thoughts? -73- Bill, AB4EJ<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> TangerineSDR <tangerinesdr-bounces@lists.tapr.org>
<b>On Behalf Of </b>Tom McDermott via TangerineSDR<br>
<b>Sent:</b> Friday, May 3, 2019 10:36 AM<br>
<b>To:</b> TAPR TangerineSDR Modular Software Defined Radio <tangerinesdr@lists.tapr.org><br>
<b>Cc:</b> Tom McDermott <tom.n5eg@gmail.com><br>
<b>Subject:</b> Re: [TangerineSDR] PSWS System Specification preliminary Ver 0.1<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Hi Scotty - yes, having one synthesizer output feed two clock drivers (one per RFM) would be fine.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">It's not a problem to have a phase offset, provided that offset does not change.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I don't think it's a problem to have fixed frequency on the ADC clocks. That clock is not used to tune the receiver,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">the NCO in the DE is used to tune the receiver. So the DE can implement one NCO for the synchronous case,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">and two NCOs for the case where we want the two receivers to tune to different frequencies.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">While the spec describes SBC and DE, those two functions could theoretically co-exist on on module (for<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">example the Red Pitaya) where the FPGA does both the DE function, and via the CPU-block does the SBC<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">function. A concern with having the FPGA do both is the lack of sufficient computational capability in the<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">limited CPU performance that's implemented on the FPGA die. So the spec tries to separate the functionality<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">without saying where it's physically implemented.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I do hope we restrict ourselves to one implementation. If folks can choose any SBC, any Receiver, etc. then there<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">will be no end of "The software doesn't work on my combination", "My hardware receivers aren't coherent",<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">"My hardware is overflowing buffers", "My hardware doesn't support amplitude calibration" ad nauseum.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The data that is produced risks being largely garbage.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-- Tom, N5EG<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, May 3, 2019 at 7:08 AM Scotty Cowling via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org">tangerinesdr@lists.tapr.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi Tom,<br>
<br>
Regarding the clocks, it seems that the AD5344 addresses this problem with the cross-point switch and synchronous dividers.<br>
<br>
We can feed two outputs with one synthesizer if we like, for a fixed (and very small) phase offset. Routing one clock output to two RF Modules is problematic, especially with LVDS outputs. Wouldn't this work?<br>
<br>
Alternatively, we could put a clock distribution chip on the DE to take one Clock Module output and distribute it to FPGA, RFM1 and RFM2, but then we lose the capability to clock the RFMs at different frequencies (for example, when one is a TX and one is an
RX).<br>
<br>
One thing to keep in mind is that the FPGA has multiple clock inputs, so we can route one from each RFM, one from the Clock Module and one from a local oscillator and let the FPGA code decide which one to use. Of course, we would have to either let the FPGA
generate the RFM clocks or route multiple clocks to each RFM to clock the ADCs directly. The reason I bring this up is that I want to use an on-board inexpensive oscillator (and no Clock Module at all) as the inexpensive, entry-level SDR. No, the performance
would not be as good. But the cost would be much lower than with any clock module, and it would be selectable by simply loading the FPGA with a different image and unplugging the Clock Module.<br>
<br>
The section 7 comment was not intended to dictate a data flow path. I just wanted to show that we need (and will have) two GbE ports to use that path in case we want to handle data in this way (for example, if the SBC cannot keep up). We can word it in whatever
way makes it clear that we can do it either way. Isn't your description implementation specific also (i.e., data flows through the SBC)?<br>
<br>
Maybe for PSWS, the data has to flow through the SBC? That is the impression I got, and I am not sure we want to restrict the architecture that way, but we could if that is our intent.<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">On 2019-05-03 04:09, Tom McDermott wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">Thanks for the good comments, Scotty !<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Section 3: the ADC clocks MUST come from the same one synthesizer output. If they<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">come from two different outputs there is a big problem...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The clocks to the two ADCs must be (and remain) phase coherent. If the ADC clocks come<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">from different outputs of the synthesizer, then each time the synthesizer starts, there could<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">be any phase difference between the two. Further they could drift back and forth relative to one another<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">a little bit because of the way synthesizers work. Thus the phase between them under<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">the best case would be +/- 180 degrees. At 30 MHz that would represent +/- 45 degrees. This<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">means that the baseband sampled signal at 30 MHz would also have an unknown phase<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">difference of +/- 45 degrees. That completely wrecks the ability to discriminate polarization.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There can be a difference in phase between the two ADC clocks, but it must remain constant over time.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Any difference will be calibrated out when the antennas and feedlines are calibrated for phase delay.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">But then the phase differences cannot change. The only way I see to do that is to have one
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">synthesizer output that is distributed to the two ADC clocks. If the ADCs are on different modules<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">then one clock signal has to be routed to the two of them in some manner (parallel, daisy-chained, etc.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Maybe there is some other way but it's difficult to see.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This is one of those things that makes phase coherent receivers very difficult, and why off-the-shelf units<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">have to be carefully evaluated, as virtually none of the ones I've seen address this problem properly.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">It's the Radio Astronomy problem.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Section 7: The spec attempts to be implementation-non-specific. Forcing a particular method<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">to distribute Ethernet data may eliminate all other potential solutions. The approach you outline<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">is a really good and elegant solution, but the spec should not mandate it (it should allow it).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Section 8: great comment. I will restructure as you outline.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-- Tom, N5EG<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, May 2, 2019 at 5:27 PM Scotty Cowling via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Hi Tom,<br>
<br>
Here are my comments on your excellent document.<br>
<br>
73,<br>
Scotty WA2DFI<br>
<br>
Notes on PSWS Specification V 0.1 5 May 2019<br>
<br>
Section 3.0<br>
Clock module will have 4 *programmable clock* outputs:<br>
1. FPGA<br>
2. RF Module #1<br>
3. RF Module #2<br>
4. High-speed Reference Clock<br>
<br>
In addition, two more outputs:<br>
5. 1 PPS timing<br>
6. 10MHz fixed reference<br>
<br>
Clock outputs should be differential LVDS. Single ended clocks will be <br>
too noisy, especially across a connector boundary.<br>
<br>
The FPGA should not provide the ADC clocks, they should come directly <br>
from the clock module. The ADC may supply a source-synchronous data <br>
clock to the FPGA.<br>
<br>
Section 4.0<br>
Magnetometer interface can be I2C, SPI, serial UART or RS-485.<br>
<br>
The magnetometer will almost certainly need to be remotely mounted. In <br>
this case, RS-485 is recommended. We can specify two-wires for <br>
communictions and two wires for power (typically 5V).<br>
<br>
Section 5.0<br>
It is not immediately clear that *each* RF Module has two synchronous <br>
channels.<br>
<br>
Note that the *pluggable filter* can be bypassed with a jumper, making <br>
it optional. Maybe call it "optional pluggable filter".<br>
<br>
Section 6.<br>
The DE shall also be capable of sourcing or sinking UDP data streams <br>
to/from any IP address, under direction of the host processor.<br>
<br>
The DE will have a three-port GbE switch, connecting the FPGA, host PC <br>
and external network. How do you want to explain this?<br>
<br>
Section 7.0<br>
Processing the stream from the DE is optional, since it may not be able <br>
to process this much data. The metadata tasks will fall to the DE in <br>
this case.<br>
<br>
The host will not always transmit the data to the central server. The <br>
host may direct the DE to stream data directly to the central server if <br>
it cannot process the volume or rate of data.<br>
<br>
Section 8.<br>
I have been using "Command and Control Protocol" for the protocol used <br>
between the central server and the host PC. I have been using "Local SDR <br>
Protocol" for the protocol between the host PC and the DE.<br>
<br>
We could use "Remote Command and Control", or "RCC" for the <br>
host<-->central server communications, and "Local Command and Control" <br>
or "LCC" for host<-->DE communications. Whatever we use, we should <br>
define it.<br>
<br>
The Remote Command and Control section seems to be missing (although you <br>
refer to it once in section 10). Even though we don't know what the <br>
protocol is, I think it should be mentioned (as defined an a separate <br>
document?)<br>
<br>
I think we need to make a clear distinction between Remote C&C and Local <br>
SDR C&C. We will need security and maybe encryption on the Remote C&C, <br>
but not so much on the Local SDR protocol.<br>
<br>
<br>
<br>
-- <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" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><o:p></o:p></p>
</blockquote>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <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" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>