[TangerineSDR] PSWS System Specification preliminary Ver 0.1

Tom McDermott tom.n5eg at gmail.com
Fri May 3 07:09:55 EDT 2019


Thanks for the good comments, Scotty !

Section 3:  the ADC clocks MUST come from the same one synthesizer output.
If they
come from two different outputs there is a big problem...

The clocks to the two ADCs  must be (and remain) phase coherent. If the ADC
clocks come
from different outputs of the synthesizer, then each time the synthesizer
starts, there could
be any phase difference between the two. Further they could drift back and
forth relative to one another
a little bit because of the way synthesizers work.  Thus the phase between
them under
the best case would be +/- 180 degrees.  At 30 MHz that would represent +/-
45 degrees.  This
means that the baseband sampled signal at 30 MHz would also have an unknown
phase
difference of +/- 45 degrees.  That completely wrecks the ability to
discriminate polarization.

There can be a difference in phase between the two ADC clocks, but it must
remain constant over time.
Any difference will be calibrated out when the antennas and feedlines are
calibrated for phase delay.
But then the phase differences cannot change.  The only way I see to do
that is to have one
synthesizer output that is distributed to the two ADC clocks.  If the ADCs
are on different modules
then one clock signal has to be routed to the two of them in some manner
(parallel, daisy-chained, etc.)
Maybe there is some other way but it's difficult to see.

This is one of those things that makes phase coherent receivers very
difficult, and why off-the-shelf units
have to be carefully evaluated, as virtually none of the ones I've seen
address this problem properly.
It's the Radio Astronomy problem.

Section 7:  The spec attempts to be implementation-non-specific.  Forcing a
particular method
to distribute Ethernet data may eliminate all other potential solutions.
The approach you outline
is a really good and elegant solution, but the spec should not mandate it
(it should allow it).

Section 8:  great comment.  I will restructure as you outline.

-- Tom, N5EG



On Thu, May 2, 2019 at 5:27 PM Scotty Cowling via TangerineSDR <
tangerinesdr at lists.tapr.org> wrote:

> Hi Tom,
>
> Here are my comments on your excellent document.
>
> 73,
> Scotty WA2DFI
>
> Notes on PSWS Specification V 0.1 5 May 2019
>
> Section 3.0
> Clock module will have 4 *programmable clock* outputs:
> 1. FPGA
> 2. RF Module #1
> 3. RF Module #2
> 4. High-speed Reference Clock
>
> In addition, two more outputs:
> 5. 1 PPS timing
> 6. 10MHz fixed reference
>
> Clock outputs should be differential LVDS. Single ended clocks will be
> too noisy, especially across a connector boundary.
>
> The FPGA should not provide the ADC clocks, they should come directly
> from the clock module. The ADC may supply a source-synchronous data
> clock to the FPGA.
>
> Section 4.0
> Magnetometer interface can be I2C, SPI, serial UART or RS-485.
>
> The magnetometer will almost certainly need to be remotely mounted. In
> this case, RS-485 is recommended. We can specify two-wires for
> communictions and two wires for power (typically 5V).
>
> Section 5.0
> It is not immediately clear that *each* RF Module has two synchronous
> channels.
>
> Note that the *pluggable filter* can be bypassed with a jumper, making
> it optional. Maybe call it "optional pluggable filter".
>
> Section 6.
> The DE shall also be capable of sourcing or sinking UDP data streams
> to/from any IP address, under direction of the host processor.
>
> The DE will have a three-port GbE switch, connecting the FPGA, host PC
> and external network. How do you want to explain this?
>
> Section 7.0
> Processing the stream from the DE is optional, since it may not be able
> to process this much data. The metadata tasks will fall to the DE in
> this case.
>
> The host will not always transmit the data to the central server. The
> host may direct the DE to stream data directly to the central server if
> it cannot process the volume or rate of data.
>
> Section 8.
> I have been using "Command and Control Protocol" for the protocol used
> between the central server and the host PC. I have been using "Local SDR
> Protocol" for the protocol between the host PC and the DE.
>
> We could use "Remote Command and Control", or "RCC" for the
> host<-->central server communications, and "Local Command and Control"
> or "LCC" for host<-->DE communications. Whatever we use, we should
> define it.
>
> The Remote Command and Control section seems to be missing (although you
> refer to it once in section 10). Even though we don't know what the
> protocol    is, I think it should be mentioned (as defined an a separate
> document?)
>
> I think we need to make a clear distinction between Remote C&C and Local
> SDR C&C. We will need security and maybe encryption on the Remote C&C,
> but not so much on the Local SDR protocol.
>
>
>
> --
> TangerineSDR mailing list
> TangerineSDR at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20190503/ef15cb6a/attachment-0001.html>


More information about the TangerineSDR mailing list