<div dir="ltr"><div>Thanks for the good comments, Scotty !</div><div><br></div><div>Section 3:  the ADC clocks MUST come from the same one synthesizer output. If they</div><div>come from two different outputs there is a big problem...<br></div><div><br></div><div>The clocks to the two ADCs  must be (and remain) phase coherent. If the ADC clocks come</div><div> from different outputs of the synthesizer, then each time the synthesizer starts, there could</div><div> be any phase difference between the two. Further they could drift back and forth relative to one another</div><div> a little bit because of the way synthesizers work.  Thus the phase between them under</div><div> the best case would be +/- 180 degrees.  At 30 MHz that would represent +/- 45 degrees.  This</div><div> means that the baseband sampled signal at 30 MHz would also have an unknown phase</div><div> difference of +/- 45 degrees.  That completely wrecks the ability to discriminate polarization.</div><div><br></div><div>There can be a difference in phase between the two ADC clocks, but it must remain constant over time.</div><div>Any difference will be calibrated out when the antennas and feedlines are calibrated for phase delay.</div><div>But then the phase differences cannot change.  The only way I see to do that is to have one <br></div><div>synthesizer output that is distributed to the two ADC clocks.  If the ADCs are on different modules</div><div>then one clock signal has to be routed to the two of them in some manner (parallel, daisy-chained, etc.)</div><div>Maybe there is some other way but it's difficult to see.</div><div><br></div><div>This is one of those things that makes phase coherent receivers very difficult, and why off-the-shelf units</div><div> have to be carefully evaluated, as virtually none of the ones I've seen address this problem properly.</div><div>It's the Radio Astronomy problem.<br></div><div><br></div><div>Section 7:  The spec attempts to be implementation-non-specific.  Forcing a particular method</div><div>to distribute Ethernet data may eliminate all other potential solutions.  The approach you outline</div><div>is a really good and elegant solution, but the spec should not mandate it (it should allow it).<br></div><div><br></div><div>Section 8:  great comment.  I will restructure as you outline.</div><div><br></div><div>-- Tom, N5EG</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 2, 2019 at 5:27 PM Scotty Cowling 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">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" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote></div>